The Natural Evolution of Onchain Wallets

The Promise

The original vision of web3 was radical in its simplicity: give people direct control over their digital assets, their identity, and their data. No intermediaries, nor custodians. No one standing between you and your money who can freeze your account, reverse your transaction, or decide you're no longer welcome.

Self-custody was the mechanism: a cryptographic key pair, a private key that only you hold and a public key that the world can verify, was all you needed to participate in a permissionless economy. No bank approvals, KYC for basic access, nor terms of service that can change overnight. Only your keys, your assets, your sovereignty.

The UX Reality

The purest expression of this principle is the seed phrase: 12 or 24 words from which your private key is derived, and with it your entire onchain identity. Write it down, store it safely, and you have unconditional, permanent access to your assets.

As a cryptographic design, it's elegant. As a user experience, it's a disaster.

Seed phrases ask every new user to immediately understand private key management and recognize the irreversible consequences of loss. You're handed a piece of paper at signup and told: lose this and your money is gone forever. There's no "forgot password", no customer support.

The result was predictable. Mainstream adoption stalled. Even experienced users weren't immune: billions of dollars have been permanently lost to misplaced seed phrases, compromised backups, and simple human error.

The KMS Era

Embedded wallet providers saw this clearly: abstract the key management away entirely. Let users sign up with an email or a Google account, handle the private key behind the scenes, and deliver an experience indistinguishable from any modern app. No seed phrase. No browser extension. Just a product that works.

It was a genuine breakthrough. Millions of users who would never have installed MetaMask were suddenly onboarding in seconds. Entire product categories became viable because the friction disappeared.

But the UX simplicity hides real complexity. Behind every familiar login flow, a KMS provider is distributing ECDSA key material across the user's device, the provider's servers, and a recovery mechanism; in some designs the full key is generated and then split; in others, shares are generated distributedly so the full key never exists in one place. When the user needs to sign, the system either reassembles the key in a secure environment or runs a distributed signing protocol, all gated by an authentication session token. The engineering is impressive: hardware enclaves, encrypted share storage, tamper detection.

None of it changes what's underneath. The auth token becomes the root of trust, meaning a phished OTP or hijacked OAuth session can grant signing capability. The key material must still be accessible at signing time, creating an exposure window whose security depends entirely on implementation. And most critically, the system protects who can sign but has no opinion on what gets signed: a compromised application layer will produce a valid signature for a malicious transaction without hesitation. The key has unlimited authority, and the wallet has no way to constrain it.

The Deeper Issue: Account = Key

All of this complexity exists because of a fundamental design decision in Ethereum's original account model.

With an Externally Owned Account (EOA), the account is the key. Your address is derived from your public key, and your authority is your private key. There is no separation between identity and access; they are cryptographically fused. Lose the key, lose the account. Compromise the key, compromise everything.

Every KMS provider, no matter how sophisticated their share splitting or threshold signing, is ultimately building elaborate infrastructure to protect that fusion. They're not solving the key problem; they're managing it. The private key is still there. It still has unlimited authority. It still represents a single point of total compromise.

Unlinking the Account from the Key

Account abstraction changes the equation by breaking the coupling between the account and the ECDSA key.

With a smart contract account, the account becomes an independent onchain entity. The key becomes just one replaceable, constrained signer among potentially many. Your address is no longer derived from a private key; it's determined by a contract. Your authority is no longer a single secret; it's a set of programmable rules.

A signer can be rotated without changing your account address. A compromised signer can be revoked without losing your identity or your assets. Multiple signers, whether human, device, or AI agent, can coexist on the same account with different permission scopes. And crucially, the account can enforce rules about what any given signer is allowed to do: spending limits, whitelisted contracts, sessions that expire after a set duration, required cosignatures above certain thresholds.

With an EOA, if an attacker obtains signing capability, they have full, unrestricted control. With a smart account, even a compromised signer can only operate within its defined boundaries. The security question shifts from "how do we protect the key?" to "what is this key allowed to do?"

Passkeys Complete the Picture

Passkeys (WebAuthn / FIDO2) are cryptographic credentials bound to the user's hardware that never leave the device. The private key material lives in the device's secure enclave, the same hardware that protects Face ID and fingerprint data. It cannot be exported, copied, or accessed by any software.

When you combine passkeys with smart accounts, the passkey is a signer on the account, not the account itself. And it's a signer that doesn't need managing:

• No key to split. The passkey's private key is generated and stored in hardware. No secret to shard across iframes, TEEs, or MPC nodes. No momentary exposure during signing.
• No token as root of trust. The user authenticates directly with biometrics. No session token that grants signing access if stolen.
• No provider dependency for custody. The user's device is the signer. When passkeys sync via iCloud Keychain or Google Password Manager, they travel end-to-end encrypted with keys that neither Apple nor Google can access. The platform is a transport layer for encrypted blobs, not a custodian.

The user taps their fingerprint. The secure enclave signs. The smart account validates and enforces its permission rules. That's it.

And because the account is decoupled from any single signer, recovery becomes an account level concern, not a key level crisis. Add a backup passkey. Designate a guardian. Set up social recovery. The options are programmable and composable.

The Permission Layer Is the Real Frontier

The embedded wallet industry has spent years optimizing how to split, store, and reconstitute a 32 byte private key. All of that complexity exists to protect a design that smart accounts with passkeys simply don't need.

The harder, and more valuable, problem is the permission layer. Not how you protect the signer, but what the signer is allowed to do. This is especially true as accounts are no longer just used by humans: AI agents needing constrained, revocable authority; session keys for temporary app interactions; delegated signers for automated strategies and treasury management; permissions across apps where identity and authorization rules travel with the user.

These are permission problems, not key management problems. And they're best solved at the account layer, where rules are transparent, onchain, and enforceable. The Ethereum protocol itself is converging here, with proposals like EIP-8141 bringing native account abstraction that unlinks accounts from prescribed signing schemes at the protocol level.

The seed phrase era gave us self custody. The KMS era gave us usability. The smart account era gives us both, with accounts that are sovereign, keys that are replaceable, and a permission layer that's programmable.

That's the evolution.