Redefining Account Architecture: Why a Three-Key System Is the Ideal Solution?
TechFlow Selected TechFlow Selected
Redefining Account Architecture: Why a Three-Key System Is the Ideal Solution?
Requiring users to install wallet software and save mnemonic phrases during onboarding is not advisable; we need a friendly, relatively secure, and forward-looking approach.
Navigating Web3 tides with focused insightsAuthor: Norswap
Translation: TechFlow
I've been thinking a lot about wallets and user onboarding for 0xFable. Here are some of my thoughts. We'll discuss:
-
My ideal account architecture;
-
Security considerations;
-
An overview of existing Web3 login providers,
Clearly, requiring users to install wallet software and save recovery phrases during onboarding is undesirable. We need a friendly, relatively secure, and somewhat forward-looking approach.
Architecture
Each user gets their own smart account containing three keys:
-
Device key——initially storable locally, but ideally using passkeys/webauthn in the future.
-
Recovery key, e.g., controlled by a provider and unlocked via social login.
-
Backup key, e.g., held by a third party (could simply be an email attachment or stored on Dropbox / Google Drive).
If this sounds low-tech or insecure, you're probably already misled by sweet-talking providers—because in reality, they aren't actually any more secure (and often less so——for instance, both keys (2) and (3) being controlled by the same party).
In this setup, you can perform operations using the device key without user interaction. For transfers and transactions involving assets, you can require the recovery key.
The simple pattern is letting users log in via Google/Apple/Facebook, then adding a confirmation prompt. This makes onboarding easy. However, if users want greater security, they can replace this key with a traditional EOA. Moreover, any pair of keys can be used to regenerate the backup key, which only needs to be a file hosted in the cloud.
Security Analysis
How secure is this? Most of the time, it's secure. Two devices or entities must be compromised simultaneously for funds to be lost.
Primarily, there are configuration risks that may reduce security. For example, hosting the backup key on Google Drive while assigning the recovery key to your Google account. Or using a hot wallet as the recovery key, which shares the same risk as the device key. Users might lose their backup. It’s best to periodically prompt users to rotate their device key, forcing them to locate their backup key.
If the backup key is publicly stored, it's also highly susceptible to theft. This is worse than a hot wallet, which encrypts the key on disk (and requires a password to decrypt in memory). In any case, the addition of passkeys (allowing you to authenticate into applications using your device) will solve this problem.
Understand that social login means trusting a provider. The provider essentially holds a key they can use at will, but promise only to use it upon your request after you log in via your social account. Finally, note that when the recovery key is provided by the dapp creator or lacks a confirmation prompt, the dapp creator can easily deceive the user (since they control the frontend holding the device key and possess or can control the recovery key).
Overview of Existing Providers
Who offers this today? As far as I know, no one. The usual issues are either lacking a backup key or having it managed by the same entity (e.g., Coinbase Wallet).
The market mainly splits into two categories:
-
Providers offering integrated multi-key solutions, either using smart accounts or MPC (multi-party computation, a cryptographic technique) to combine multiple keys into a single EOA.
-
Lower-level providers who hold user keys for you and allow signing post-login.
There are many full-stack providers here: Particle Network, Privy, Alembic Tech, Magic, Web3Auth, Turnkey, Dynamic, 0xPass, Fireblocks, Portal, Capsule, ZeroDev, Keyp, Circle Developers.
Key custodians such as: Lit Protocol, Amazon.
Yes, there are many such services. They’re mostly indistinguishable from each other. When the business model is transparent, these typically charge $0.02 to $0.05 per user per year. To me, this seems quite reasonable.
Interestingly, all of these are positioned as developer tools. It seems no company is trying to apply these technologies to become the primary wallet for users.
Of course, to work with existing dapps, you still need to install wallet software. So the system’s advantage reduces to eliminating recovery phrases. But you could also let dapps promote you as the easiest entry point (especially if they integrate you, possibly without requiring wallet installation). You gain users; dapps get free, frictionless onboarding. A win-win.
Concerns About Providers
Beyond failing to implement my ideal architecture, these solutions often introduce significant centralization factors, such as REST APIs or certain MPC computations—if they shut down, you can’t perform these computations yourself (are they even open-sourced? Audited?)
It’s also unclear what happens if you stop working with a provider. They hold (part of) your users’ keys! This concern is very similar to my worries about Rollups-as-a-service.
Afterward, a RaaS founder told me there’s a trade-off between enabling easy exit and preventing founders from deceiving their users (which would harm RaaS overall).
Here’s how to easily switch providers using the above architecture: users submit the hash of their social account on-chain (e.g., [email protected]). Each social login provider has its own private key (no need for a separate key per user, and usually not more secure anyway). The smart account references a singleton contract holding the current provider’s account. Switching providers is as simple as changing this account.
Final Thoughts
We’re clearly moving toward the ideal onboarding goal. Ideally, these easy-entry wallets build direct relationships with users. Then, dapps can ignore the issue entirely and simply partner with wallets to determine the default login wallet.
If that fails, my fallback solution would be launching my own system——creating your own social login provider within the above architecture isn’t difficult. Still, I’d “rather” use an external provider. As noted earlier, if the dapp creator controls the free key, the system isn’t fully decentralized.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@norswap
