There’s been a lot of discourse about wallets in the past year. A lot of attention has been put into Smart Accounts, intents, and embedded wallets, and for developers, the tradeoffs between each provider and wallet type are really confusing.
For interchangeable parts of the stack like RPCs, it’s lower impact if a dev changes providers for security or developer experience improvements. But for embedded wallets and smart accounts, if there’s a security flaw that forces devs into switching WaaS providers, that can harm adoption for current and future end-users. Imagine having to migrate all of your users from one embedded wallet provider to another because of a supply chain exploit that your paid WaaS provider didn’t disclose.
The purpose of this post is to review five key management solutions: web3auth, Privy, Capsule, Magic Link, and Turnkey. We’ll do a little compare-and-contrast (for morale) based on the following parameters:
How can you use this wallet outside of the app you set it up with?
Where can it not go, and what is it unable to do?
Who’s involved in the message signing flow?
Can the WaaS provider block a user from transacting?
UX and Performance
What happens if your phone gets lost, or stolen?
How does this WaaS provider let you recover keys?
If the WaaS goes out of business, or the website you were accessing your account from goes out of business, how can you move your tokens and collectibles to another wallet?
In the SSS scheme, one share is a social login share backed by the Torus Network, one is a device share stored either in the device or in the browser, and one is a recovery share. The Torus Network provides some decentralization and censorship resistance guarantees.
ShareA is managed and divided across Web3Auth's Auth Network and can be accessed through an OAuth login provider owned by the user, like their Google account.
ShareB is stored on the user's device. The method of storage is specific to the device and system. For instance, on mobile devices, the share could be stored in device storage that's secured with biometrics.
ShareC serves as a recovery share. It's an extra share that the user can keep on a separate device, download, or base on user input with sufficient entropy. This could include a password, security questions, or a hardware device, among other options.
Web3Auth has a lot of diversity in terms of authentication methods. Not only do they support an array of social login providers, but also standards like oAuth and custom login.
Privy uses Shamir Secret Sharing as its foundational security protocol. When a user wants to sign a transaction, shares need to be combined to reconstruct the signing private key. While this ensures that keys are not stored in one place, there is a potential risk during the recombination process where the private keys can be recorded or extracted. Privy also sends users a share to their email or phone number, which means the security of the wallet is tied to the security of the form of authentication. The Privy team has since added opt-in recovery passwords to mitigate this.
They support a lot of auth factors available to the user, including:
their own wallet (by signing a Sign In With Ethereum (SIWE) challenge)
Google, LinkedIn, TikTok, Twitter, Discord, Github, or Apple accounts
Seems like Privy wallets are not interoperable. Based on the docs here, users are reliant on exporting a private key in order to use the same wallet in another application.
Conversely, this can be rationalized as a security and privacy decision.
There isn’t a decentralized network of nodes handling end-user Privy requests. That said, an end-user can export their private keys and use it on another wallet app.
Privy UX is really smooth. Check out their demo here.
Please ask the team about specific performance benchmarks.
Privy can’t help users if:
Account recovery not set up
Credentials are lost
Browser cache cleared
To mitigate this, Privy suggest users to:
Double check what auth method they’re using
Link multiple authentication methods to one wallet (which feels like an emergent opsec/privacy issue. Similar to people getting IG/FB Suggested Follows for their friend’s secret alt accounts because Meta associated their friends).
Magic Link is an incumbent service provider in the wallet space. The Magic team has been around since 2018, and serves projects like ImmutableX, Animoca Brands, Mattel, etc.
Magic supports interoperability if the company that integrates them chooses the “Universal Wallet (forgo ability to customize wallet widget, so that your users can access the same account across other Magic-supported wallets).
If the dev team integrating Magic Link wants to control more of their end user’s experience, they lose the ability to allow their user to access their Magic Link account across applications.
If a user wanted to use a Magic wallet in another application that does not support Magic, they’d need to export their private key and thus, export their wallet.
Magic’s wallet UX shines in its simplicity. Magic also has a wide range of SDKs, featuring SDKs in React Native, native mobile, and Unity.
At the time of writing, I was unable to find info on benchmarks.
Turnkey is another newer player in the key management space. Current customers include Station, Dynamic, and Goldfinch.
Currently, Turnkey only supports webauthn based auth. This can make multi-device connectivity hard to do, eg. a user that has created a device on mobile is unable to access the same wallet on their laptop without Bluetooth enabled, etc. Please ask the team about specifics.
There are a lot of considerations to be made for which WaaS provider a team chooses for their product. Factors like different use cases, different core assumptions about your users, and ease of integration can widen or limit the providers that make the most sense to integrate. No matter what, security and censorship resistance are important to consider, as you don’t want to build an app that suddenly has to stop business as usual because your WaaS provider was attacked.
From a security perspective, an open question recurred: how do you share wallet state safely and securely? Depending on how a given WaaS provider segregates different instances between customers, it may not be feasible to decide to protect end-users and limit security risk. For instance, imagine AppA and AppB are two dapps supported by the same WaaS provider. If AppB lets people log in with WaaS accounts created for AppA, users of AppA who don’t want people knowing their business on AppB will have to use another wallet, or hope that AppB doesn’t sell those associations to data brokers. Additionally, the security of users’ funds is dependent on the least secure application/dapp that end-users allow to move funds.
Nonetheless, the future’s looking bright for doing more cool things onchain, and now that we have a bunch of different providers to choose from, that’s one less blocker getting in the way of teams in the arena, trying things. And that brings us a step closer to the next wave of adoption.
Credits to the anon gigabrains who helped me sanity check this
Note: Additional features outside the scope of the list above will not be discussed in this post - I may be dumb. It's not investment, tax, etiological, epistemic, legal, or life advice. As much as I may try to summarize things, understanding (and dunking on) this post is best done with a baseline knowledge of distributed MPC and Shamir Secret Sharing.