Smart Contract Wallets
A smart contract wallet is a crypto wallet controlled by code running on a blockchain, not by a single private key. Unlike a traditional externally owned account (EOA) - the kind MetaMask creates, where one private key controls everything - a smart contract wallet can enforce rules: multiple signatures required for a transaction, recovery if you lose access, spending limits, or gas fees paid by someone else. These wallets live on-chain as smart contracts, which means their logic can be upgraded, extended, or replaced.
This page maps the entire subject. Beneath it you will find dedicated pages that answer specific questions in depth. Each section below introduces a theme, then points you to the spoke page that covers it completely.
The core difference: EOA versus smart contract wallet
The most fundamental decision a crypto user makes is whether to use an EOA or a smart contract wallet. An EOA is simple: one private key, one address, no conditions. A smart contract wallet is programmable. It can require two signatures for a large transfer, let you change signers without moving funds, or let someone else pay your gas fees. That programmability comes with trade-offs: you need to deploy the contract (which costs gas), you need to understand how to recover access if something goes wrong, and some dapps may not support contract-based signatures.
The page EOA versus smart contract wallet which should you use walks through the real differences and helps you decide based on what you actually need.
Account abstraction: ERC-4337 and beyond
The most widely adopted standard for smart contract wallets on Ethereum is ERC-4337, often called "account abstraction." It introduces a new transaction flow that separates the user's intent from the mechanics of blockchain execution.
How an ERC-4337 useroperation gets executed
Instead of sending a raw transaction, a smart wallet user creates a UserOperation - a data structure that says "I want to call contract X with data Y." This UserOperation goes into a special mempool, not the regular transaction mempool. A bundler picks it up, validates it against the EntryPoint contract, and wraps it into a regular transaction that gets mined in a block.
The page How an ERC-4337 UserOperation gets executed step by step traces the entire lifecycle from user signature to on-chain settlement.
The entrypoint contract as global validator
Every ERC-4337 smart wallet interacts with a single EntryPoint contract. This contract validates UserOperations before execution, checks that the wallet has paid for gas (or a paymaster has sponsored it), and handles the flow of funds between wallets, paymasters, and bundlers. It is the shared infrastructure that makes account abstraction work without changing Ethereum's core protocol.
What the ERC-4337 EntryPoint contract does as a global transaction validator explains the EntryPoint's role in detail.
How paymasters sponsor gas
One of the most practical benefits of ERC-4337 is the ability to separate gas payment from transaction initiation. A paymaster is a contract that agrees to pay gas fees on behalf of users. The paymaster can enforce its own policies - only sponsor transactions to certain dapps, only for users who hold a specific NFT, or only up to a daily limit. This is how wallets can offer "gasless" transactions without actually eliminating gas costs.
The page How paymasters sponsor gas fees and abstract gas from users in ERC-4337 explains how paymasters work, what policies they enforce, and the risks of relying on a third party for gas.
What a bundler does
Bundlers are the infrastructure layer that collects UserOperations, validates them, and submits them to the blockchain. They are not miners or validators; they are specialized relayers that compete to include UserOperations in blocks. Some bundlers run their own mempools, while others use public mempools. The choice of bundler affects latency, censorship resistance, and cost.
What a bundler does in the ERC-4337 mempool and how UserOperations reach blocks covers the bundler's role from mempool to finality.
ERC-4337 versus Native Account Abstraction on L2s
Not all chains implement account abstraction the same way. zkSync and Starknet have built account abstraction directly into their protocol layers, meaning every account is a smart contract by default. Ethereum's ERC-4337 is a layer on top of the existing protocol. The two approaches have different trade-offs in terms of composability, gas costs, and developer experience.
The comparison ERC-4337 versus native account abstraction on zkSync and Starknet explains the architectural differences and what they mean for users and developers.
Recovery and security models
The biggest weakness of an EOA is that losing the private key means losing the wallet forever. Smart contract wallets solve this with programmable recovery mechanisms.
Social recovery with guardian threshold voting
Social recovery lets you designate trusted people or institutions as guardians. If you lose access, you initiate a recovery request. Once a threshold number of guardians approve (say, 3 of 5), the wallet's signer gets rotated to a new key. The guardians themselves cannot move funds - they only vote on who controls the wallet. Time-locks and cancellation windows prevent a malicious guardian from stealing control.
The page How social recovery works with guardian threshold voting in smart wallets explains the mechanics, including guardian selection, timelock durations, and the risks of losing all guardians simultaneously.
Multisig Threshold Enforcement
Multisig wallets require M-of-N signatures before a transaction executes. Safe is the most widely used implementation. The contract enforces the threshold at the code level: a transaction proposal collects signatures off-chain, then the contract verifies them on-chain before execution. Multisig is not the same as social recovery - it is a day-to-day control mechanism, not a backup plan.
How M-of-N multisig threshold enforcement works in smart contract wallets covers the enforcement logic, signature collection, and the difference between multisig and recovery.
Social recovery versus seed phrase backup
Many users default to writing down a seed phrase as their backup plan. Social recovery is an alternative that avoids the single point of failure of a seed phrase. But social recovery introduces its own risks: guardians could be unavailable, collude, or be socially engineered. The choice depends on your threat model.
The page Social recovery versus seed phrase backup for wallet security compares both approaches honestly.
Choosing signers and authentication
A smart contract wallet can accept signatures from many types of signers: a hardware wallet, a passkey, an MPC network, or even an email-based proof.
Hardware Signer versus MPC versus Passkey
Hardware wallets like Ledger or Trezor provide strong isolation for private keys. MPC networks split the key across multiple parties and reconstruct signatures without ever assembling the full key. Passkeys use the WebAuthn standard with the secp256r1 curve, letting you sign with your phone's biometric sensor or your laptop's Touch ID. Each approach has different security properties, user experience, and gas costs.
The page Hardware signer versus MPC versus passkey as a smart wallet signer breaks down the trade-offs.
How ERC-1271 contract signature verification works
Smart contracts cannot hold private keys, so they cannot produce ECDSA signatures. ERC-1271 defines a standard way for contracts to verify signatures. A dapp calls isValidSignature on the wallet contract, and the wallet returns whether the signature is valid according to its own logic. This is how smart wallets can sign messages and approve transactions without a private key.
How ERC-1271 contract signature verification works for smart wallets explains the standard and its limitations.
Modular architecture and extensions
Early smart wallets were monolithic - all features baked into one contract. Modern designs use modular architecture, where the core wallet is minimal and features are added as plugins or modules.
Modular smart accounts with ERC-7579
ERC-7579 standardizes how modules interact with a smart account. A module can add session keys, spending limits, recovery logic, or integration with a specific dapp. The wallet owner installs and uninstalls modules without redeploying the contract. This reduces risk because the core wallet logic stays small and audited.
The page Modular smart account architecture with plugin systems and ERC-7579 covers how modules work, the risks of third-party plugins, and the difference between modular and monolithic accounts.
Session keys and scoped permissions
Session keys let a wallet authorize a specific action for a limited time - for example, "allow dapp X to spend up to 100 USDC for the next hour." The user signs once, and the dapp can execute within those bounds without further approvals. This is not the same as giving unlimited access; session keys have explicit scopes and expiry.
The spoke page on modular architecture covers session keys as one type of module.
The developer's choice: infrastructure and providers
Developers building applications with smart wallets face a separate set of decisions: which wallet to integrate, whether to use an embedded wallet provider, and how to handle gas.
Self-Custody versus embedded wallet providers
Embedded wallet providers like Privy, Dynamic, and Web3Auth offer SDKs that create and manage wallets for users. They handle key storage, recovery, and user onboarding. The trade-off is that the provider holds some control over the wallet - either through MPC key shares or by managing the signer infrastructure. Self-custody gives users full control but requires them to manage keys and recovery themselves.
The page Self-custody versus embedded wallet provider for smart accounts helps developers decide which approach fits their application.
Safe versus Argent versus Biconomy
These are the three most prominent smart wallet implementations, but they target different use cases. Safe is the standard for multisig and treasury management. Argent focuses on social recovery and a mobile-first experience. Biconomy provides an SDK for developers to embed smart wallets into applications. Each has different upgrade paths, supported chains, and module ecosystems.
The comparison Safe versus Argent versus Biconomy which smart wallet to choose covers their differences in detail.
Paymaster sponsorship versus self-funded gas
When a user pays their own gas, the wallet must hold ETH (or the chain's native token). With a paymaster, gas can be paid in any token, sponsored by the application, or deferred. The decision affects user experience and cost structure. Paymaster sponsorship introduces dependency on an external service.
The page Paymaster gas sponsorship versus paying your own gas in smart wallets explains when each approach makes sense.
Risks and Misconceptions
Smart contract wallets are not magic. They introduce new failure modes that EOAs do not have.
Smart contract wallet risks
The most catastrophic risk is a bug in the wallet contract that allows an attacker to drain funds. Upgradeable wallets add the risk of an admin key compromise. Paymaster dependency can make a wallet unusable if the paymaster goes down. Bundler centralization can censor certain transactions. Social recovery guardians could collude or be socially engineered.
The page Smart contract wallet risks bugs upgrades and recovery failures catalogs these risks honestly.
Common Misconceptions
Many people believe smart contract wallets are just multisigs, that account abstraction eliminates all gas fees, or that social recovery means a company can reset their wallet. None of these are true. ERC-4337 is not a protocol upgrade that changed Ethereum - it is a contract standard that runs on top of the existing protocol. Smart wallets can work with any dapp that supports ERC-1271 signatures, and passkeys are not the same as passwords.
The page Common misconceptions about smart contract wallets debunked addresses each of these misunderstandings directly.
Costs
Smart contract wallets cost more to deploy and use than EOAs. Deploying a wallet via CREATE2 costs gas for the factory call and storage. Each UserOperation pays the EntryPoint's fixed overhead (~21k gas as of early 2025, though this varies). Paymasters charge a fee on top of sponsored gas. Module installation costs gas. Recovery with multiple guardian signatures costs more than a simple key rotation. On L2s, these costs are lower but still present.
The spoke pages on ERC-4337 mechanics and paymasters include specific cost breakdowns.
Tools and Infrastructure
The ecosystem of tools around smart wallets is large and changing rapidly. Safe remains the most battle-tested multisig wallet, deployed on over a dozen chains. Argent leads on Starknet and zkSync. Biconomy, ZeroDev, and Alchemy's Account Kit provide SDKs for developers. Bundler services like Pimlico, Stackup, and Alchemy's Rundler compete on reliability and price. Embedded wallet providers like Privy, Dynamic, and Web3Auth offer different trade-offs between custody and convenience.
Many of these tools are marked as volatile in the entity inventory - they change pricing, features, and availability. The spoke pages that compare them include current information but should be verified against the provider's documentation.
The Big Picture
Smart contract wallets are not a replacement for EOAs for every user. They are a different tool for a different set of needs: programmable security, recovery, team control, and better user experience for applications. The choice between an EOA and a smart wallet, between social recovery and a seed phrase, between a paymaster and self-funded gas, depends on what you are protecting and who is using the wallet.
This page has mapped the territory. Each spoke page below answers one question completely. Start with the question that matters most to you, and follow the references between them.
Not financial advice. meow-cto.xyz publishes market data and general information about Meow. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.