Embedded Wallets

The old model and its problem

Under the external-wallet model, a user downloads a standalone wallet, generates and manages a seed phrase, and carries that same wallet across every application. It is self-custodial and portable, but the friction is severe: every site the user visits runs third-party wallet software, the user has to understand phrases like "if you lose it, you lose everything," and most users simply never acquire a dedicated crypto wallet in the first place. Henri Stern's framing of the problem: "you shouldn't need a PhD or deep interest in self-sovereignty to engage in this space."¹

The inversion

Under the embedded-wallet model, the app issues its own wallet as part of onboarding, the same way a bank issues an account number. The wallet remains self-custodial, meaning the cryptographic keys belong to the user rather than the company, but the app handles key management and recovery so the user never has to leave the product or interact with an external wallet at all. The app becomes the interface; the wallet becomes infrastructure sitting underneath it, giving any company the kind of persistent financial relationship with its users that was previously reserved for institutions with their own account infrastructure.

The fragmentation tradeoff

The obvious risk is fragmentation: if every app issues its own wallet, a user could end up with assets spread across many effectively separate accounts. The argument that this is manageable rests on programmability rather than consolidation: each app serves as a control plane for the assets inside it, and the expectation is that some future layer, a wallet aggregator or portability protocol, will let users manage assets across apps without needing to consolidate them into one wallet first. This is an open problem rather than a solved one, though the existence of communities that deliberately fragment their finances across multiple credit cards for rewards suggests some users are comfortable managing dispersed accounts already.

Self-custody as portability

The technical property doing the real work is that because the wallet is self-custodial, the account is portable: it can move if the underlying provider becomes unreliable, the way a bank failure makes concentrating all funds at one institution risky. The account belongs to the user and can be carried elsewhere; the company supplies the interface, the rails, and add-on services, but not the account itself.

A concrete application: preventing double spends

When a stablecoin-backed card is used for a purchase, the flow runs through a merchant terminal authorization, a real-time balance check, a transfer of stablecoins into a smart contract, and end-of-day settlement to the payment network. Two simultaneous authorizations against the same balance could otherwise both pass, a double-spend race condition. The fix built at the account layer freezes a balance on the first authorization so a second cannot pass. That the fix had to be built at the application layer rather than natively on the blockchain is, in this framing, the core argument for purpose-built payment infrastructure rather than treating any general-purpose chain as sufficient.