The phrase "write down these 12 words and never lose them" has done more to slow crypto adoption than any market downturn. Passkey wallets erase that prompt. Instead of a seed phrase, you authenticate with the same Face ID or Touch ID you already use to unlock your bank app, and the wallet signs an onchain transaction in the same gesture.
This guide explains how passkey wallets actually work, why they need a smart contract on the other side, which products ship them today, and where the model still has rough edges. If you build consumer apps where every dropped user costs revenue, this is the architecture worth understanding.
What is a passkey, technically
Answer: A passkey is a WebAuthn credential — a public/private keypair generated and stored inside a hardware-backed secure element on your device, used to sign challenges from a relying party (a website or app).
The standard is FIDO2/WebAuthn, ratified by the W3C and FIDO Alliance. The private key never leaves the device's secure boundary: Apple's Secure Enclave on iPhone and Mac, Android's Trusted Execution Environment (TEE) or StrongBox on Pixel and Samsung, or a hardware security key like YubiKey. When an app needs a signature, the OS prompts the user with biometrics, the secure element computes the signature, and only the signature crosses back into application memory.
Passkeys use the P-256 elliptic curve (also called secp256r1 or prime256v1) by default. Apple, Google, and Microsoft sync passkeys across a user's devices through iCloud Keychain, Google Password Manager, and Windows Hello respectively, so a passkey created on an iPhone is also available on the same user's Mac.
Why does P-256 matter for crypto wallets
Answer: Ethereum and most EVM chains historically signed transactions with secp256k1, a different curve. Verifying a P-256 signature inside the EVM was prohibitively expensive — until EIP-7212.
Bitcoin and Ethereum use secp256k1, the curve Satoshi picked in 2009. Passkeys use secp256r1. The two are mathematically similar but not interchangeable, and the EVM has a precompile for secp256k1 (ecrecover) but not for secp256r1.
Two paths solve this:
Solidity verifier libraries. Open-source implementations like FreshCryptoLib and Daimo's P-256 verifier let any smart contract validate a P-256 signature in pure Solidity. The downside: roughly 200,000 to 400,000 gas per verification, which on Ethereum mainnet is real money per transaction.
EIP-7212 (RIP-7212). A precompiled contract at address
0x0000...0100that verifies P-256 signatures for a flat 3,450 gas. Polygon PoS shipped it in April 2024. Optimism, Base, Arbitrum, and other OP Stack/Arbitrum Orbit chains have adopted it as part of the rollup-improvement-proposals track. On chains with the precompile, passkey signatures cost about the same as native ECDSA.
This is why passkey wallets are L2-native. Coinbase Smart Wallet defaults to Base, where the precompile makes the economics work.
How a passkey wallet actually signs a transaction
Answer: The passkey signs, the smart contract verifies, and a bundler relays the result to the chain. The user only sees the biometric prompt.
The full flow, end to end:
Account creation. The dapp calls
navigator.credentials.create(). The OS prompts the user — "Save a passkey for app.example.com?" — and biometrics confirm. The browser returns a public key. The dapp deploys (or counterfactually addresses) an ERC-4337 smart contract wallet whose owner is that public key.Transaction build. When the user taps "Send 50 USDC," the dapp constructs an ERC-4337 UserOperation. The hash of that UserOp becomes the WebAuthn challenge.
Biometric prompt. The dapp calls
navigator.credentials.get()with the challenge. Face ID or Touch ID fires. The Secure Enclave signs and returns a P-256 signature plus the WebAuthnauthenticatorDataandclientDataJSON.Onchain verification. The smart wallet's
validateUserOpfunction reconstructs what was signed (it has to recompute the SHA-256 overauthenticatorDataandclientDataJSON), then verifies the P-256 signature using either the EIP-7212 precompile or a Solidity verifier.Bundler submission. A bundler picks up the UserOp from the alt-mempool, packs it into a transaction, and submits to the EntryPoint contract. Gas is paid by a paymaster — often sponsored by the dapp — so the user never holds ETH.
From the user's perspective: tap "Send," look at the camera, done. From the wallet's perspective: a WebAuthn ceremony, an ERC-4337 UserOperation, and a P-256 verification — all glued together by a smart contract. For the deeper mechanics on the bundler/EntryPoint side, see support/en/articles/15039719.
Which wallets and SDKs ship passkey support today
Answer: Coinbase Smart Wallet leads the consumer side; Privy, Dynamic, and Magic dominate developer-facing embedded wallets; Soul Wallet and Safe modules cover the self-custody power-user crowd.
Coinbase Smart Wallet. Passkey-first by default. Create a wallet in one biometric prompt, no app install, deployed on Base with cross-device sync via the user's Apple or Google account. Coinbase open-sourced the contracts and the WebAuthn Solidity verifier they wrote.
Privy. Embedded-wallet SDK used by Friend.tech, Blackbird, and Pump.fun. Offers passkey-secured wallets where the passkey signs over a wallet stored in a TEE on Privy's infrastructure, plus a fully onchain passkey path for ERC-4337 accounts.
Dynamic. Multi-chain embedded wallet provider with passkey support across EVM, Solana, and Bitcoin. Used by exchanges and consumer apps that need a single SDK across ecosystems.
Magic. Long-time embedded-wallet provider, added passkey-based recovery and signing as an alternative to its email-link flow.
Argent. Argent X on Starknet has used passkey-style biometric signing for years; Starknet's native account abstraction made this trivial. Argent's mobile wallet on EVM uses passkeys for a hardware-backed recovery factor.
Soul Wallet. Open-source ERC-4337 wallet built around passkeys as the primary signer, with social recovery as the fallback.
Safe (passkey module). Safe ships an official passkey signer module for its Smart Account, letting any Safe deployment add a passkey as a co-owner or sole owner.
For a broader landscape view of smart contract wallets, see support/en/articles/15039721.
How does this compare to MetaMask and other EOAs
Answer: An EOA stores a secp256k1 private key (derived from a seed phrase) in browser extension storage, encrypted by a password. A passkey wallet stores a P-256 key in dedicated tamper-resistant hardware and gates every signature behind biometrics.
The differences that matter in practice:
Onboarding. MetaMask: install extension, click through 6 screens, write down 12 words, confirm 12 words. Passkey wallet: tap a button, look at the camera. Coinbase reports passkey signups complete in roughly 15 seconds versus several minutes for traditional crypto onboarding.
Recovery. EOA: the seed phrase is the recovery. Lose it, lose the wallet. Passkey wallet: recovery rides on iCloud Keychain or Google Password Manager. Lose your phone, sign in to your Apple ID on a new one, the passkey is there.
Phishing resistance. Passkeys are bound to the relying party's domain. A WebAuthn credential created for app.uniswap.org will refuse to sign for app.uni-swap.org. Seed phrases have no such protection — users routinely paste them into fake "wallet validators."
Per-transaction friction. MetaMask asks for a password unlock once per session, then signs silently. Passkey wallets prompt for biometrics on every signature. That's a security feature, but it's a UX cost — 0.5 to 1 second per transaction.
Gas abstraction. EOAs must hold the chain's native gas token. Passkey wallets are smart contract wallets, so a paymaster can sponsor gas or accept USDC for fees. EIP-7702 narrows this gap by giving EOAs smart-account features; see support/en/articles/15039722.
The full architectural picture — bundlers, paymasters, validation rules — is covered in support/en/articles/15039723.
What are the real risks and limitations
Answer: Cloud-tied recovery, platform lock-in, cross-chain support, and the gap between "passkey on the device" and "passkey actually verifiable onchain."
Cloud-tied recovery. If your iCloud or Google account is compromised — phished, SIM-swapped, taken over — an attacker can pull your synced passkeys. iCloud Keychain is end-to-end encrypted and Apple's recovery requires the device passcode, but the threat surface is real. For high-value accounts, treat the passkey as one signer in a multisig, not the only signer.
Platform lock-in. Apple, Google, and Microsoft control the syncing infrastructure. Cross-platform passkey portability (Apple iCloud → Google account) is possible via QR-code device hand-off but not seamless. A user who fully switches platforms has to re-add the passkey or rely on a recovery factor.
Chain support. Passkey wallets work cleanly on chains with the EIP-7212 precompile or willingness to pay the Solidity verifier gas cost. Ethereum mainnet, where verifier gas is most expensive, is the worst environment for passkey wallets — which is why most consumer products skip mainnet entirely.
Browser inconsistencies. WebAuthn implementations vary. Safari on iOS handles cross-origin iframe passkey prompts differently than Chrome on Android. Wallet SDKs that try to embed inside another dapp's iframe occasionally hit edge cases that trigger user-visible failures.
No offline signing. A hardware wallet can sign a transaction with no network. A passkey wallet still needs the dapp running and, for ERC-4337, a bundler reachable. The signing itself is offline-capable; the surrounding infrastructure usually isn't.
When should a builder reach for passkey wallets
Answer: When your users are not crypto-native, when you can deploy on an L2 that ships EIP-7212, and when you're willing to own (or buy) the bundler/paymaster stack.
Consumer apps with mainstream audiences — payments, loyalty, gaming, social, real-world assets — are the natural fit. Anything where seed-phrase friction kills the funnel before the user sees the product. DeFi power tools where users already have MetaMask and want to interact with hundreds of contracts per week are a worse fit; the per-signature biometric prompt becomes annoying fast.
If your app uses stablecoins for payments or settlement, the passkey-plus-paymaster combo is particularly strong: users hold no gas token, sign with biometrics, and pay fees in the same USDC they're transacting in. That's the experience consumers expect from Apple Pay, and it's now achievable onchain.
Methodology and sources
This article draws on the W3C Web Authentication Level 3 specification, the FIDO2 documentation from the FIDO Alliance, EIP-7212 (Precompile for secp256r1 Curve Support) on the Ethereum Magicians forum and ethereum/ERCs repository, the Coinbase Smart Wallet documentation and open-source contracts, Privy's developer documentation, the Safe Passkey Signer module documentation, and Daimo's P-256 verifier Solidity library. Gas-cost figures for Solidity P-256 verification are taken from benchmarks published by the FreshCryptoLib and Daimo teams. Onboarding-time comparisons are from Coinbase Smart Wallet launch materials and developer reports from Privy customers.
Related reading
support/en/articles/15039723
support/en/articles/15039719
support/en/articles/15039721
support/en/articles/15039722

