Smart Wallets With Passkeys: A Practical ERC-4337 Setup Guide (Security, Fees, Recovery)
Passwords are brittle, seed phrases are terrifying for mainstream users, and “gas first, app later” killed more on-ramps than we admit. Passkeys (WebAuthn/FIDO2) and ERC-4337 smart accounts finally fix this. In this guide you’ll set up a passkey-first smart wallet, understand fees and gas sponsorship, configure spending limits and session keys, and design a recovery plan that survives lost phones, without handing custody to anyone.
Why this matters now
Two shifts made smart wallets inevitable: (1) platform passkeys went mainstream, giving users a passwordless login that’s phish-resistant and device-bound; (2) ERC-4337 standardized smart accounts without touching Ethereum consensus, unlocking paymasters (gas sponsorship), session keys, spending limits, and built-in recovery. Put together, everyday crypto starts to feel like using a normal app: Sign in with FaceID, complete the action, no ETH prerequisite.
Passkeys + ERC-4337 basics
Passkeys (WebAuthn/FIDO2) replace passwords with a device-bound keypair. The private key never leaves your phone/laptop or hardware key. Sites get a signed challenge, not a reusable secret. You can store passkeys on platform clouds (iCloud, Google, Microsoft) and also register hardware security keys (USB/NFC) for portability and higher assurance.
ERC-4337 smart accounts are on-chain contracts that define how actions are approved and how gas is paid. Instead of one EOA key signing every transaction, your smart account enforces programmable rules: biometric approval via passkey, limits, time locks, guardians, session keys, and paymasters. The magic is that all of this works without a hard fork: wallets submit UserOperations to special relayers called bundlers who interact with a global EntryPoint contract.
How ERC-4337 works: from click to chain
When you hit “Approve,” the wallet doesn’t broadcast a raw transaction. It builds a UserOperation (UserOp) describing the action, the validation policy, and how to pay gas:
- Wallet builds UserOp → includes call data (“swap 200 USDC”), your account’s validation logic, and a gas plan.
- Bundler picks it up from a special mempool and wraps many UserOps into one on-chain transaction.
- EntryPoint validates each UserOp by calling your smart account’s validateUserOp, checks sponsorship with a paymaster if present, then executes.
- Paymaster may reimburse the bundler in ETH or accept a token (e.g., USDC) depending on policy.
What you need before starting
Device & software
- iOS/Android with FaceID/TouchID (or desktop with platform authenticator)
- Modern browser: Safari, Chrome, Edge, Brave, or mobile in-app browser
- Optional: Hardware security key (FIDO2 USB/NFC) as a second authenticator
Wallet & chain
- A smart-wallet provider that supports ERC-4337 and passkeys
- Target chain where AA infra is live (Ethereum mainnet or a supported L2)
- Small amount of ETH/USDC for testing (not always required if gas is sponsored)
Step-by-step: set up a passkey-first smart wallet
Fees & gas sponsorship: what you pay and when
Smart accounts don’t magically remove gas, they just make who pays and what asset pays more flexible. Here’s how to reason about costs.
Gas anatomy for a UserOperation
Total Gas ≈ preVerificationGas + verificationGasLimit + callGasLimit • preVerificationGas: cost to include the UserOp (roughly constant) • verificationGasLimit: runs your account’s validation (including passkey checks) • callGasLimit: executes the actual action (swap, transfer, mint)
You’ll also see a maxFeePerGas and maxPriorityFeePerGas just like EIP-1559 transactions. Wallets estimate these for you.
Paymasters: sponsored or token gas
- Sponsored gas: the app or a third party pays the ETH to the bundler. Useful for onboarding and complex flows (bridges, account creation).
- Token gas: you pay in a non-ETH token (e.g., USDC). The paymaster handles swap/settlement behind the scenes and charges a small premium.
| Scenario | Who pays | What you see | Typical cost |
|---|---|---|---|
| Sponsored swap in a dApp | App’s paymaster | “Gas covered by X” | $0 to you; app bears ETH + premium |
| You pay with USDC | You via paymaster | USDC deducted for gas | ETH gas + 0.3–1% premium (varies) |
| Fallback to ETH | You directly | Normal EIP-1559 fee prompt | Standard ETH gas |
Rule of thumb: for frequent users, stablecoin gas via paymaster feels great and costs a small spread; for power users and high-value actions, keep some ETH to avoid premiums and rare paymaster outages.
Spending limits & session keys: smooth UX with guardrails
Spending limits and session keys are the unsung heroes of AA. They remove noisy prompts while reducing the blast radius of mistakes.
Spending limits
- Set a daily cap (e.g., $300) for transfers and swaps
- Require second factor for amounts above the cap
- Optionally add a per-dApp budget (DEX, game, mint site)
Session keys
- Scope to one contract and a list of methods
- Set limits (e.g., up to 0.05 ETH or 500 USDC)
- Set expiration (10–60 minutes typical)
- Review & revoke in wallet settings after use
Most theft in consumer wallets is either approval-drain or phishing. Limits and session scopes turn catastrophic approvals into bounded permissions you’ll actually survive.
Recovery plans that work: guardians, MPC, and hardware keys
Smart accounts let you design recovery that fits your life. The safest setups are layered: passkey for daily use, hardware key as secondary, plus a guardian quorum for high-risk changes (ownership rotation, spending-limit edits, recovery).
| Model | How it works | Strengths | Risks/notes |
|---|---|---|---|
| Guardian / Social | Appoint n guardians (friends/devices/services). m-of-n can approve ownership change after a time lock. | Human-centric; easy to explain; no seeds | Choose guardians carefully; collusion risk mitigated by time locks |
| MPC (threshold) | Key split across devices/services; signatures assembled without one device holding the full key. | Great UX with biometrics; resilient to single-device loss | Trust in MPC coordinator; ensure export/migration path |
| Hardware passkeys | Register one or more FIDO2 keys as authenticators for the account. | Offline, durable, vendor-agnostic | Physical loss; keep duplicates; label clearly |
Recovery checklist (print this)
- Register at least two passkeys: your phone/desktop and a hardware key.
- Appoint 2–3 guardians across different platforms; set 48–72h time lock for owner changes.
- Store a written recovery plan offline with wallet address, authenticators, guardians, and instructions.
- Do a dry run on a low-value account: simulate device loss and restore.
- Audit quarterly: remove old devices/guardians; rotate credentials after any compromise.
Migrating from a legacy EOA (Metamask-style)
You have two options when moving from a classic EOA to a smart account:
- Fresh AA address: create a new smart account and move funds/positions over time. Pros: clean start, modern approvals. Cons: you must update whitelists and receive-from addresses.
- Upgrade/Wrap: some wallets let you “upgrade” an EOA or deploy a smart-account module that retains the old address. Pros: fewer address changes. Cons: module complexity; confirm audits and upgrade paths.
Safe migration sequence
- Inventory approvals with an approvals checker; revoke unlimited approvals on the old wallet.
- Create your AA wallet with passkeys and limits as above.
- Bridge small test funds; try one dApp end-to-end with token-gas.
- Move positions in batches; avoid gas peaks; keep the old wallet with near-zero allowance after migration.
Troubleshooting: common hiccups & fixes
| Problem | Why it happens | Fix |
|---|---|---|
| “Passkey not available” on desktop | Browser profile doesn’t allow platform authenticators or you declined device PIN setup | Enable passkeys in browser settings; set a device PIN; try a hardware key as fallback |
| UserOperation reverts at EntryPoint | Validation logic failed (limits/session key expired) or not enough gas | Renew session, raise limit, or switch to ETH gas for one action |
| Paymaster declined | Quota exhausted or token not accepted for this method | Use ETH fallback or a different paymaster; try again later |
| Lost phone with primary passkey | Single-device dependency | Use hardware key or guardian recovery to rotate ownership; then enroll a new phone |
| DApp shows hex gibberish | Poor intent rendering | Prefer wallets/dApps that display human-readable intents; if unsure, cancel |
Security model & privacy: what gets better, and what to watch
What improves
- No raw seed handling for daily actions—phishing surface shrinks
- Device-bound, biometric-gated approvals
- Limits, session keys, and time locks reduce blast radius
- Recovery via guardians or MPC beats “seed or nothing”
New/remaining risks
- Supply-chain: malicious wallet update could show misleading intents
- Platform lock-in if you rely only on synced passkeys; add hardware keys
- Guardian collusion or sim-swap on cloud accounts; mitigated by time locks & multi-platform guardians
- Approval UI phishing still possible; read what you sign
Privacy notes
- Biometrics never leave your device; the wallet receives only a signed challenge.
- Passkey sync is end-to-end encrypted in major platforms; still register a hardware key for vendor-independent recovery.
- Session keys limit data exposure by restricting what a dApp can ask your account to do.
Glossary (quick refresher)
- Passkey: A WebAuthn/FIDO2 credential bound to a device or hardware key, unlocked locally by biometric/PIN.
- Smart Account: A contract account whose validation and features are programmable (limits, recovery, etc.).
- UserOperation (UserOp): A structured request submitted to ERC-4337 infrastructure instead of a raw transaction.
- Bundler: A relayer that collects UserOps and posts them to the EntryPoint contract on chain.
- EntryPoint: The global contract that validates and executes UserOps for smart accounts.
- Paymaster: A contract/service that sponsors gas or accepts alternative gas tokens.
- Session Key: A short-lived, scoped key used for specific dApp actions.
- Guardian: A person/device/service empowered to help recover or approve sensitive changes.
Frequently Asked Questions
Do I still need a seed phrase?
Not for daily use. Your smart account authorizes actions with passkeys and policies. For high-value storage, you can keep a hardware wallet in cold storage or register hardware passkeys as backup authenticators. The goal is seed-less daily UX without giving up sovereignty.
Is paying gas in USDC really safe?
Yes, when implemented by reputable paymasters. You’re trading a small premium for convenience. Keep a little ETH as a fallback in case the paymaster quota is exhausted or the app disables sponsorship.
What happens if I lose my phone?
Use your registered hardware key or guardian quorum to rotate ownership to a new device. This is why we recommend two hardware keys and a 48–72 hour time lock on owner changes.
Are smart wallets compatible with all dApps?
Most EVM dApps work out of the box. A few older apps may assume EOAs for signatures; modern wallets bridge this automatically. If a dApp complains, try the wallet’s “legacy sign” toggle or use a newer interface.
Do session keys let dApps drain my funds?
No—if you scope them correctly. A session key should be bound to a contract, method list, value cap, and short expiry. Treat them like temporary app permissions on your phone.