Coinbase Smart Wallet is a passkey-based ERC-4337 smart account, launched by Coinbase in June 2024, that replaces seed phrases with WebAuthn signers and uses a multi-owner contract so the same account can be co-controlled by several passkeys, EOAs, or hardware keys. The contract source lives in the public coinbase/smart-wallet repository on GitHub, the on-ramp is integrated with the Coinbase Developer Platform Paymaster for gas sponsorship on Base, and the wallet adds two distinctive product features absent from most competitors: Sub Accounts, which derive per-app child accounts without re-prompting the user, and Magic Spend, which lets an app pull USDC out of the user's Coinbase exchange balance to fund a transaction inline.
​

This article walks through the architecture, the onboarding flow as a user actually experiences it, the Sub Accounts and Magic Spend primitives, audit history, and a head-to-head against MetaMask Smart Account, Argent, and Safe. It is written for developers and analysts evaluating whether to integrate Coinbase Smart Wallet into a stablecoin app or use it as a personal account.
​

Coinbase Smart Wallet is an ERC-4337 smart contract account that uses passkeys as the signing primitive instead of a 12 or 24-word seed phrase. The wallet launched in June 2024 (Coinbase blog, June 2024) and is positioned as the consumer onramp for Coinbase's developer stack: any app integrating the Coinbase Developer Platform SDK can spin up a Smart Wallet for a new user in a single sheet without a seed phrase backup step.
​

The wallet's design choices map onto three problems Coinbase has been public about. First, seed phrase loss is the dominant reason consumer wallets churn at month one; passkeys delegate that burden to the platform keychain (iCloud, Google Password Manager, 1Password). Second, ERC-20 approvals and gas fees gate first-time users from completing their first onchain action; the Coinbase Paymaster sponsors gas on Base for integrated apps. Third, multi-app fragmentation forces users to approve the same wallet over and over; Sub Accounts collapse that into one root account with per-app children.
​

Coinbase Smart Wallet runs on Base, Ethereum, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, and Zora as of Q1 2026 (Smart Wallet docs). The same passkey controls the same address across every supported chain because the deployment uses a deterministic CREATE2 factory.
​

The wallet has four moving parts: the passkey signer, the multi-owner smart contract, the bundler and paymaster path through ERC-4337 infrastructure, and the embedded popup UI that hosts the signer in any browser context. Each part is replaceable, and each is documented in the open-source repository.
​

A passkey is a public-key credential bound to a domain, stored in the user's platform keychain, and used through the W3C WebAuthn API. Coinbase Smart Wallet uses the secp256r1 curve (also called P-256), which is the curve every modern Apple, Google, and Microsoft device hardware-accelerates. The contract verifies P-256 signatures onchain using a precompile-equivalent path: on chains that ship RIP-7212 (the P-256 precompile), verification is a single opcode; on chains that do not, the wallet uses the Daimo P-256 verifier Solidity library, which Coinbase audits jointly with the Daimo team.
​

The user never sees a seed phrase. Recovery is platform-mediated: iCloud Keychain sync, Google Password Manager sync, or hardware-key escrow. If a user loses every device with the passkey, they fall back to adding a second owner (an EOA, another passkey on a new device, or a hardware wallet) before the loss event. The wallet does not provide social recovery in the Argent sense.
​

The CoinbaseSmartWallet contract is a multi-owner ERC-4337 account: it stores an array of authorized owners (each represented as 64 bytes for a P-256 public key, or 32 bytes for an EOA address) and verifies user operations against any one of them. Adding or removing an owner is itself a transaction signed by an existing owner. This gives the user a clean upgrade path: a phone-bound passkey at signup, a hardware-key backup added a week later, an EOA recovery key from a hardware wallet, all controlling the same address.
​

The contract follows the ERC-1271 standard for smart-contract signatures, so any dApp using SignatureChecker from OpenZeppelin contracts can verify a Smart Wallet signature without special-casing the wallet. Storage uses the ERC-7201 namespaced storage layout to avoid collisions when the contract is upgraded through its UUPS proxy.
​

Every transaction from a Coinbase Smart Wallet is a ERC-4337 user operation. The user signs the operation hash with their passkey; the bundled operation flows through a public bundler (Coinbase runs one on Base, and the wallet falls back to Pimlico or Alchemy bundlers elsewhere) to the singleton EntryPoint contract at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 on every supported chain. The EntryPoint validates the signature, calls the paymaster if one is attached, and executes the call.
​

The Coinbase Developer Platform Paymaster is the default sponsor for apps integrated with the Coinbase Wallet SDK. Developers configure a per-app gas budget in dollars per user per month; the paymaster signs sponsorship attestations the EntryPoint accepts. On Base, where gas costs typically run a fraction of a cent per transfer, a meaningful budget covers thousands of user operations per dollar.
​

The wallet has no installed extension and no mobile app of its own. The signing surface is a popup window served from keys.coinbase.com, embedded into the host dApp through the Smart Wallet SDK. When the dApp requests a signature, the SDK opens the popup, the user authenticates with the platform passkey UI, and the signed user operation returns to the dApp. The popup architecture means a user with a single Coinbase Smart Wallet account can interact with any integrated dApp without installing anything; the cost is that the wallet does not work in environments that block third-party popups or cross-origin storage.
​

The integration surface for a new user is a single SDK call, createOrJoin, that either creates a new Smart Wallet or signs into an existing one. The flow as a user experiences it has four steps and typically completes in 30 to 60 seconds.
​

Step 1: The dApp triggers createOrJoin. The Coinbase Smart Wallet popup opens with two options, sign in with an existing wallet or create a new one. New users tap create.
​

Step 2: Passkey ceremony. The browser or operating system shows its native passkey UI (Face ID, Touch ID, Windows Hello, or a security key prompt). The user authenticates. The platform generates a P-256 keypair, stores the private key in the platform keychain bound to keys.coinbase.com, and returns the public key to the wallet.
​

Step 3: Counterfactual address. The wallet computes the user's smart account address from the public key and the factory address using CREATE2. The address is deterministic; the contract is not yet deployed onchain. The user can receive funds at this address before the contract exists.
​

Step 4: First transaction deploys the contract. When the user signs their first user operation (a transfer, a swap, a mint), the EntryPoint deploys the smart account through the factory in the same transaction. If the dApp has paymaster sponsorship configured, the user pays zero gas. If not, the user funds the account through Magic Spend or an external transfer first.
​

The friction Coinbase removed at each step is concrete: no seed phrase backup, no chain switch dialogs, no separate gas top-up, no install. The flow is the closest thing in onchain UX to a Sign In With Google button, with the difference that the resulting credential controls actual onchain assets.
​

Two product primitives differentiate Coinbase Smart Wallet from generic ERC-4337 implementations: Sub Accounts and Magic Spend. Both shipped through 2024 and 2025 and are documented in the developer docs.
​

A Sub Account is a child smart account derived from a parent Smart Wallet, owned by the same passkey but with its own address and scoped permissions. An app can create a Sub Account for a user on first connect, give it a small spending budget from the parent, and execute transactions from the Sub Account without prompting the parent passkey on every action. The parent retains the ability to revoke or top up.
​

The primitive solves the per-app friction problem in onchain UX: a gaming app or a per-creator tipping app does not need a wallet sheet for every micropayment, because the Sub Account is the budgeted, scoped permission. Sub Accounts are themselves ERC-4337 accounts; the parent-child relationship is enforced by the parent contract's owner check rather than by a new standard. The roadmap for tighter session-key support tracks ERC-7715, which standardizes granular permission grants across smart accounts.
​

Magic Spend is a paymaster-style flow that lets a Coinbase Smart Wallet user fund an onchain action directly from their Coinbase exchange USDC balance, without first withdrawing the USDC into the smart account. When an app calls signAndSendCalls with a Magic Spend permission, the wallet popup shows the user how much USDC will be pulled from Coinbase, the user confirms, and the funds move into the smart account inline as part of the same user operation.
​

The effect on first-touch UX is large. A new user who has a Coinbase exchange balance but no onchain wallet can mint an NFT, deposit into a yield pool, or pay a creator without manually withdrawing first. Magic Spend uses Coinbase's own internal settlement, not a public bridge, so the latency is sub-second and the fee is bounded by the Coinbase paymaster, not by an L1 bridge cost.
​

The Coinbase Smart Wallet contract suite has been audited by OpenZeppelin and Certora, with reports published alongside the code in the coinbase/smart-wallet GitHub repository. The two audits cover the multi-owner contract, the factory, the P-256 verifier path, and the upgrade machinery; Certora's contribution adds formal verification of the owner-check invariants. Coinbase has not published a per-version active-accounts number; treat any claim of "millions of Coinbase Smart Wallet users" as unsourced unless it links to a Coinbase blog or filing.
​

The repository ships under the Creative Commons Zero v1.0 Universal license for the documentation and the BSD-3-Clause license for the contracts, both permissive. The Daimo P-256 verifier the wallet depends on for chains without RIP-7212 is similarly open, audited separately by Veridise and Cantina. Anyone reproducing the wallet's verification path can build against the same dependencies the production contract uses.
​

The smart-wallet category has consolidated around four leading implementations in 2026, each with a different design center. The table summarizes the trade-offs along the dimensions most integrators evaluate.
​

The honest summary: Coinbase Smart Wallet wins on consumer UX (passkey signup, gas sponsorship default, exchange-funded transactions). MetaMask Smart Account wins on installed base, since it can upgrade an existing seed phrase user into a smart account through ERC-7702 without changing addresses. Argent wins on recovery, because guardian-based social recovery is more robust than platform keychain sync for users worried about iCloud lockouts. Safe wins on institutional use, because multisig is the only acceptable treasury control surface for funds and DAOs.
​

Coinbase Smart Wallet is the right pick for consumer apps that need a fast first-time onboarding flow, especially apps that already use Base or that have meaningful USDC traffic. The combination of passkey signup, Coinbase paymaster gas sponsorship, and Magic Spend funding from the Coinbase exchange compresses onboarding from minutes to seconds.
​

It is the wrong pick for treasuries, DAOs, or any account where the signing policy needs to be m-of-n across multiple human signers; Safe is the standard there. It is also the wrong pick for users who want guardian-based social recovery independent of any platform keychain; Argent's recovery model is stronger for that case. And it is the wrong pick for app teams that need their users to retain a specific existing Ethereum address; an EOA upgraded via ERC-7702 keeps the address, while a new Coinbase Smart Wallet creates a new one.
​

No. The wallet uses a passkey stored in the platform keychain (iCloud, Google Password Manager, Windows Hello, or a hardware security key). Recovery depends on the platform keychain or on adding a second owner before any loss event. The contract supports multiple owners, so adding a hardware wallet as a backup owner is the recommended recovery setup.
​

Base, Ethereum, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, and Zora as of Q1 2026, per the official documentation. The same passkey controls the same address on every supported chain because the deployment uses a CREATE2 deterministic factory.
​

Yes. The contracts and SDK live at github.com/coinbase/smart-wallet. The contracts use the BSD-3-Clause license. Audit reports from OpenZeppelin and Certora are published alongside the code.
​

A normal ERC-4337 paymaster sponsors gas. Magic Spend funds the call value itself by pulling USDC from a Coinbase exchange balance into the smart account inline. The two can stack: an app can sponsor gas through the Coinbase Developer Platform Paymaster and fund the USDC transfer through Magic Spend in the same user operation.
​

Yes. The multi-owner contract accepts any combination of P-256 passkey owners and secp256k1 EOA owners. A common production setup uses a passkey as the daily signer and a hardware wallet EOA as a recovery owner.
​

Eco is the cross-chain stablecoin routing layer that consumer apps and smart wallets integrate with to move USDC across the chains Coinbase Smart Wallet supports. An app using Coinbase Smart Wallet on Base for first-touch onboarding can route stablecoin actions to Ethereum, Arbitrum, or Polygon through Eco Routes without making the user switch chains or hold gas on each network. The combination is increasingly common: passkey signup on Base, cross-chain settlement through Eco, gas sponsorship through the Coinbase paymaster on the origin chain.
​

Sources and methodology. Contract architecture and supported-chain list verified against the coinbase/smart-wallet GitHub repository and the official Smart Wallet documentation in May 2026. ERC references link to the canonical EIP texts at eips.ethereum.org. Audit attribution from the OpenZeppelin and Certora reports published in the repository.
​

Coinbase Smart Wallet's pitch is straightforward. Passkeys remove the seed phrase. The Coinbase paymaster removes the gas. Magic Spend removes the funding step. Sub Accounts remove the per-app re-approval. Each removal targets a known failure mode in consumer onchain onboarding, and the contract is open enough that any integrator can verify what they are shipping users into.
​