A user signs up for your on-chain product. To do anything, they need a wallet. So you show them a browser extension to install, twelve random words to write down and never lose or screw themselves forever, and a popup demanding they approve a transaction in language they don't understand. Forty percent of them close the tab right there. The ones who push through are now one phishing email away from losing everything you helped them put on-chain.
That's the default Web3 onboarding, and it's why mainstream products built on it bleed users at the door. The instinct is to fix it by hiding the keys — spin up a custodial backend, hold everyone's funds, and hand them a normal login. Now onboarding is smooth and you're an unlicensed custodian holding a honeypot, one breach away from a headline and a regulator.
The good news: you no longer have to choose. The tooling to give users a Web2 experience over genuinely self-custodied accounts is here, in production, securing real money. You just have to build it correctly, because the security tradeoffs moved — they didn't disappear.
Why the seed phrase was always the problem
A traditional wallet is a private key. Lose the key, lose everything. Leak the key, lose everything. There's no recovery, no support line, no undo. The seed phrase is that key in human-writable form, and it puts the single most catastrophic failure mode in your product directly in the hands of a user who's never thought about key management and never will.
This is an externally owned account — an EOA. One key, full control, no programmable logic. Every guarantee and every catastrophe routes through that one secret. You cannot build forgiving UX on top of an unforgiving primitive. The fix isn't better seed-phrase education. It's a different kind of account.
Smart accounts change what an account can do
A smart account is a contract that acts as the user's wallet. Because it's a contract, it can hold logic — rules about who can authorize what, under which conditions, with what limits. The account is no longer one key with absolute power. It's programmable.
ERC-4337 — account abstraction — is the standard that makes this work without changing the underlying chain. It introduces a parallel transaction system: users submit UserOperations, a bundler packages them, and an EntryPoint contract validates them against the account's own rules. The account decides what counts as a valid signature, who can pay the gas, and what each signer is allowed to do.
That one shift unlocks the entire UX toolbox. Every painful part of the EOA experience becomes a design decision instead of a hard constraint.
The toolbox, and what each one trades
Embedded wallets. The key is generated for the user behind a normal login — email, a social account, a passkey — and stored split or secured so that no single party, including you, can unilaterally reconstruct it. The user never sees a seed phrase. They sign up like it's any app. The tradeoff: the security now depends entirely on how that key is provisioned and protected. Done with a reputable provider using secure enclaves or threshold cryptography, it's strong. Done by stuffing a raw key in your database, you've rebuilt custodial risk with extra steps. The implementation is the security.
Social recovery. Instead of a seed phrase, the account names a set of guardians — other devices, trusted contacts, the user's own backup keys. Lose your primary signer, and a threshold of guardians can authorize recovery to a new one. The catastrophic failure mode of the EOA — one lost key, everything gone — stops existing. The tradeoff: guardian selection and the recovery flow become attack surface. A recovery process that's too easy is a social-engineering hole; too hard and you've recreated the lockout you were solving. The threshold and the guardian set have to be designed, not defaulted.
Session keys. A temporary, scoped key the user authorizes once for a limited purpose — "this key can make trades up to $100 for the next hour, and nothing else." The user plays your game or uses your app without approving every single action, because the session key is pre-authorized within tight bounds. The tradeoff is the scope. A session key with broad permissions and a long lifetime is a standing liability. The discipline is making every session key as narrow and short-lived as the task allows, and revocable instantly.
Sponsored gas (paymasters). A paymaster contract pays gas on the user's behalf, so a new user can transact without first acquiring the chain's native token — the single most baffling step in Web3 onboarding. You can sponsor gas, or let users pay in a stablecoin. The tradeoff is economic, not security: a poorly-scoped paymaster is a faucet attackers will drain, so sponsorship needs rate limits and rules about what it'll pay for.
How we actually assemble it
The wins compound, but only behind real boundaries. The pattern we build:
./chain
signup → email / passkey login, no seed phrase shown ever
account → ERC-4337 smart account deployed for the user
recovery → guardian set configured, threshold > 1
session → scoped, short-lived keys for in-app actions
gas → paymaster sponsors or accepts stablecoin
The user logs in with an email and a passkey. A smart account is deployed for them on first action. Recovery guardians are set so a lost device is an inconvenience, not a death sentence. In-app actions run through session keys scoped to exactly what that flow needs. Gas is sponsored so the user never touches a native token. From the user's side, it's an app with a login. Underneath, they hold a self-custodied account with programmable, revocable, recoverable authority.
The security discipline that makes this real rather than custody-in-disguise:
- The user must be able to exit with their keys. If they can't export and self-custody, you built a custodial product wearing account-abstraction makeup. Self-custody means the user can leave with their assets, against your wishes if necessary.
- No single party reconstructs the key alone. Not your backend, not one provider, not one device. The moment one entity can sign for the user unilaterally, you're a custodian and a target.
- Session keys are scoped to the minimum and expire fast. Every permission a session key holds is a permission an attacker inherits if they steal it.
- The recovery flow is threat-modeled like the front door it is. Guardians, thresholds, and the recovery transaction all get the same scrutiny as the primary auth path, because to an attacker they are an auth path.
- The smart account contract is audited. It's a contract holding user funds. It gets the same security treatment as any contract holding user funds, because that's what it is.
What fixed looks like
A fixed onboarding looks like signing up for any modern app. Email or a passkey, no extension, no twelve words, no native-token scavenger hunt before the first action. Behind it, every user holds a self-custodied ERC-4337 smart account: recoverable through guardians, operated day-to-day through narrowly-scoped session keys, with gas abstracted away. They can export their keys and leave whenever they want. No single party — including you — can move their funds alone.
You get the conversion of Web2 onboarding and the custody profile of self-sovereign accounts at the same time. You are not holding a honeypot. You are not an unlicensed custodian. And a phishing email no longer drains an account, because there's no seed phrase to phish and a stolen session key can do almost nothing.
This is for you if
You're a funded US founder shipping an on-chain product to real users — people, not crypto-natives — and you've watched wallet onboarding kill your conversion while refusing to take on custody to fix it. You want account abstraction built properly: smart accounts, social recovery, session keys, embedded wallets, with the security tradeoffs designed deliberately instead of defaulted. Wallet-and-onboarding architecture engagements start at $50k+; a full embedded-account system with recovery, session keys, and audited smart-account contracts runs $100k+.
This is not for you if you're launching a memecoin or an NFT drop where the audience is already crypto-native and brings their own wallet. Those users have MetaMask and a seed phrase in a drawer; they don't need this. We build wallet experiences for products aimed at people who've never heard of a seed phrase and shouldn't have to — production systems where onboarding friction is real revenue and custody is real liability.