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:

Security

• What types of key generation schemes are being used?

Authentication

• What authentication types does this WaaS provider support?

Wallet Interoperability

• 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?

Censorship Resistance

• Who’s involved in the message signing flow?

• Can the WaaS provider block a user from transacting?

UX and Performance

• How does it feel to use the app?

Recovery

• 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?

Web3Auth

Web3Auth is the incumbent in this space. They have been around since 2019, and have dozens of projects using them, including Trust Wallet, Chess.com, Fox, and Nissan.

Security

• Web3Auth employs multiple schemes -  a Shamir Secret Sharing (SSS) scheme and a distributed MPC scheme.

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.

Authentication

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.

Wallet Interoperability

• Web3Auth wallets are not interoperable. If a user on Application A has a Web3Auth wallet and wishes to use it on Application B, they are unable to unless they export their private key and input the private key into another third party wallet.

Censorship Resistance

• Based on the website, there are some protections on censorship resistance with the Torus network. Specifically, the 2/3 share threshold mitigates censorship risk. Even if  Torus nodes decline to return the user's private key share, the user can just reconstruct their private key using their device and recovery shares.

UX and Performance

• Web3Auth has diverse SDKs. They support almost every framework across mobile, web, and gaming. This is a result of their maturity in the market and their team. Please ask the team about specific performance benchmarks.

Recovery

• There seem to be multiple modules for recovery including security questions, etc. Read more here.

Privy

Privy is a key management solution that is targeting applications. Most notably, they’ve been powering a number of onchain social apps like friend.tech.

Security

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.

Authentication

• They support a lot of auth factors available to the user, including:

  • their own wallet (by signing a Sign In With Ethereum (SIWE) challenge)

  • email

  • SMS

  • Google, LinkedIn, TikTok, Twitter, Discord, Github, or Apple accounts

Wallet Interoperability

• 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.

Censorship Resistance

• 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.

• Please DYOR!

UX and Performance

• Privy UX is really smooth. Check out their demo here.

• Please ask the team about specific performance benchmarks.

Recovery

• 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).

Capsule

The Capsule team is the newest project in this category. The team started work on Capsule in mid 2022, and just launched a public beta.

Security

• Capsule uses distributed multi-party computation (MPC), which allows for distributed key generation and distributed key signing. This means that keys are never recombined at any point in the process, mitigating compromise risks. Capsule also leverages passkeys which decouples the security of the auth factor from the security of keys. This means that if users lose access to their emails (via SIM swap or email hack), the security of their funds are not compromised.

Authentication

• Today Capsule only offers email authentication, and they plan to roll out oAuth and social login authentication in the coming months.

Wallet Interoperability

• Capsule wallets are notably portable, meaning users can single sign on across chains, devices, and applications. This means that Capsule wallets are not reliant on needing other applications to integrate against the Capsule SDKs. Capsule manages wallet security cross-app with a permissions system.

Censorship Resistance

• Please DYOR! Capsule passes back the Capsule share to the user so Capsule is unable to censor transactions. Please contact the team about specifics.

UX and Performance

• Capsule leverages DKLS MPC. The team has done some performance optimization so distributed MPC computation is performant on both mobile and web. The UX of wallet creation requires users to sign up with their email, verify with a six digit code, and create a passkey to complete wallet creation. Please ask the team about specific benchmarks and performance.

Recovery

• If a user loses access to their email or original auth factor, the user is still able to recover their wallet via a second auth factor set up during onboarding.

Magic Link

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.

Security

• Magic Link does not leverage MPC. Magic Link leverages AWS HSM modules to store master keys. The storage of private keys is both convenient yet is a single point of failure. Users can potentially face risks if the HSM modules were ever at risk. Note that while there is potential centralization risk, Magic holding keys allows for users to access their accounts in a really easy & seamless way.

Authentication

• Magic has a variety of authentication methods. See here for more info.

Wallet Interoperability

• 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.

Censorship Resistance

• It was difficult to find evidence that there are censorship mitigating factors in Magic Link, aside from the ability for end users to export a private key if they wish to exit the service.

UX and Performance

• 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.

Recovery

• Users can recover their wallet if they have access to the original auth factor (email). If a user does not have access to the original auth factor, they’ll have to enable recovery through SMS.

Turnkey

Turnkey is another newer player in the key management space. Current customers include Station, Dynamic, and Goldfinch.

Security

• The Turnkey team takes a different approach to wallets. Turnkey does not leverage MPC. Turnkey largely leverages passkeys for passwordless login and leverages HSMs (hardware security modules) in AWS for key management. More on this here. As a result, Turnkey does not have a walletless onboarding product and only supports private key infrastructure/management in the background.

Authentication

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.

Wallet Interoperability

• Wallets that are created with Turnkey’s key management system are not designed to be portable.

Censorship Resistance

• Based on their docs, Turnkey allows developers to create sub-organizations that allows their end-users to use Turnkey without giving Turnkey or the application developers access to end-users’ private keys..

UX and Performance

• At the time of writing, I was unable to find info on benchmarks.

Recovery

• Info on this here. Recovery is supported natively by Apple and Google through Turnkey. Please contact the team for more information about this.

Conclusion

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

Resources:

• Shamir Secret Sharing

• What is MPC?

• Difference between shamir secret sharing (SSS) vs Multisig vs aggregated signatures (BLS) vs distributed key generation (dkg) vs threshold signatures

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.