The Self-Custody Series, Part III
StarkEx is a self-custodial scalability engine. We’ve described the different facets of a self-custodial system, with wallets being one of them. This post describes the work we’ve been doing with various wallet providers to ensure that StarkEx remains a self-custodial system throughout.
An important trait of a self-custodial system is that every interaction requires the user’s signature. Our guiding principle is “don’t just sign, verify” — it directly follows the old blockchain adage: “don’t trust, verify”. In other words, in the absence of user verification, the system may remain self-custodial in name alone. The user should be able to verify the parameters of the interaction between their wallet and a self-custodial application. For example, when the user provides their signature as part of an interaction with an on-chain contract, the wallet shouldn’t present a seemingly cryptic blob of data, but rather a well-parsed human-readable message. The same principle should apply to Layer-2 applications, where the user is required to sign off-chain transactions.
In order to implement “don’t just sign, verify”, we’ve been working with multiple wallet providers to integrate our protocol directly into their product. This integration is particularly important for ZKP systems. To allow efficient proving of signatures, ZKP Layer-2 systems typically work with a different curve than the standard Ethereum curve, and use different hash functions. One easy way forward is to implement a wallet in the browser. We prefer not to do that for two reasons. First, StarkEx’s goal is to allow the users to have a professional trading platform, directly from their wallet, without requiring them to move those funds elsewhere. Second, building a safe wallet is not a trivial task (Loopring’s recent severe frontend bug is a case in point).
Ledger: Fully Integrated
StarkEx is fully integrated with Ledger. Every interaction, whether an on-chain contract call or an off-chain order submission, will be parsed by Ledger, presented to the user, and explicitly confirmed by the user before signing inside Ledger. Users will be able to verify the parameters of each and every interaction. Furthermore, Ledger will support StarkEx on its native Ethereum application (users won’t even have to install a specific application from Ledger Live).
This integration required adding the STARK-specific curve to Ledger’s firmware, and implementing StarkWare’s hash function (Pedersen hash function) in Ledger’s app. A close collaboration between StarkWare and Ledger resulted in the first hardware wallet brought to Layer-2.
WalletConnect: Fully Integrated
StarkEx is fully integrated with WalletConnect. WalletConnect is an open protocol for connecting (via a QR code) desktop applications to mobile wallets using end-to-end encryption. Together with Pedro Gomes, we implemented StarkEx interactions, to create the StarkEx WalletConnect Provider. DeversiFi, the first self-custodial exchange building on top of StarkEx, integrated WalletConnect to their application. Argent, a mobile wallet, is currently working on integrating with the StarkEx WalletConnect Provider and will support self-custodial trading on DeversiFi soon.
MetaMask: Hybrid Solution
We currently have a hybrid solution for MetaMask users. All on-chain transactions will be handled by MetaMask, and all off-chain transactions will be handled by an in-browser wallet (the first one is DeversiFi’s wallet). This solution is on par with most Layer-2 solutions today, and allows us to immediately support MetaMasks’s large installed base. This solution does not abide by the best practice described above: users cannot verify on-chain contract calls, nor can they verify their off-chain transactions. This will be fixed once MetaMask deploys their Snaps plugin system. We will continue to work closely with the MetaMask team as a Design Partner on Snaps (see our joint demo at Devcon5), which will allow StarkEx to provide MetaMask users with a solution abiding by our Best Practices.