Account Abstraction (ERC-4337): How a Smart Contract Wallet Differs From a Regular One, and What It Costs You

A regular Ethereum account is a keypair. One private key controls it, that key signs every transaction, the account must hold ether to pay its own gas, and if the key is lost the funds are gone. A smart contract wallet replaces that keypair with code. ERC-4337 is the standard that lets such an account work on Ethereum without any change to the protocol itself, and as of October 2026 it carries the status Final on the Standards Track. This article explains what the code actually changes, and then what it costs you in new trust assumptions. It is a factual reference and does not constitute investment or financial advice.

What does ERC-4337 actually specify?

ERC-4337 specifies an alternative transaction pipeline that runs above the Ethereum protocol rather than inside it. The specification page lists its status as Final, Standards Track ERC, created on 29 September 2021, authored by Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso and Tjaden Hess. Its Requires field now names EIP-712 and EIP-7702, which is itself a useful signal about how the two standards ended up related.

The pipeline has five named parts. A UserOperation is a pseudo-transaction object carrying the sender, nonce, factory details, calldata, gas limits, fee parameters, paymaster information and signature. Users submit these to a separate mempool instead of broadcasting ordinary transactions. The EntryPoint is a singleton contract that executes bundles of UserOperations through its handleOps function, running a validation loop and then an execution loop. A bundler is a node or block builder that collects UserOperations, validates them, packs them into one ordinary transaction and gets it included. A paymaster is an optional contract that pays fees on behalf of a user. An aggregator lets several UserOperations share a single validation signature.

The important design consequence is that validation and execution are separated. The EntryPoint checks every operation in a bundle first, and only then executes them. That split is what makes sponsorship and alternative signature schemes possible, and it is also the root of several of the risks described later in this article.

How does a smart contract wallet differ from a regular wallet?

It differs in who decides what counts as a valid transaction. In an externally owned account, the protocol decides, and the answer is always the same: one ECDSA signature over secp256k1 from one key. In a smart contract account, the account's own code decides, inside a function called validateUserOp. Everything else follows from that one change.

Comparison of account models on Ethereum as of October 2026

Property	Externally owned account	ERC-4337 smart account	EIP-7702 delegated EOA
What validates a transaction	Protocol, fixed ECDSA secp256k1	Account code, arbitrary logic	Delegate contract code
Who can pay gas	The account only	Account or a paymaster	Account or a sponsor
Several actions in one atomic step	No	Yes, via calldata batching	Yes, via the delegate
Key loss recovery	None	Possible if the code implements it	Possible if the delegate implements it
Needs a new address	Not applicable	Usually yes, a fresh contract address	No, keeps the existing address
Underlying key still works alone	Yes	No, the key is only what the code says it is	Yes, the EOA key remains valid

That last row deserves attention, because it is where most explanations go wrong. An EIP-7702 delegation does not remove the original private key. The key keeps its full authority and can sign ordinary transactions as before. The delegation adds a second way to act on the account, it does not replace the first.

What does gas sponsorship change, and who pays?

Sponsorship moves the fee obligation from the user to a paymaster contract, which must maintain a deposit with the EntryPoint. A paymaster implements validatePaymasterUserOp to decide whether it will cover a given operation, and postOp to settle afterwards. This is what lets an application onboard a user who holds no ether at all, or let a user pay fees in a stablecoin instead, a pattern that intersects with the compliance questions covered in our note on stablecoin regulation and US Treasury guidelines.

The money has to come from somewhere, and the paymaster's deposit is the thing at risk. OtterSec published an analysis of paymaster failure modes on 2 December 2025, written by Nicholas Putra. It describes two patterns worth naming. The first is undercalculated gas: when execution uses less gas than the limits specified, the EntryPoint applies a penalty of 10 per cent of the unused gas against the paymaster's deposit, and a paymaster that does not model this can be farmed by users who set artificially high limits. OtterSec names the SEND Protocol TokenPaymaster as an implementation that does not account for the penalty. The second pattern is post-execution charging. If a paymaster defers collection to postOp rather than securing funds during validation, a user can approve a token allowance so that simulation passes, then revoke the allowance before the operation is actually submitted. The postOp call fails, the bundler is still paid, and the paymaster absorbs the cost. OtterSec analyses Pimlico's SingletonPaymasterV7 to illustrate the shape of the problem.

Note what this means for a user. Sponsorship is not free money appearing from the protocol, it is a business subsidising your transaction. A sponsor can also decline to sponsor, which makes your ability to transact through that route a commercial relationship rather than a protocol guarantee.

What are session keys, and what do they let an application do without you?

A session key is a scoped, temporary credential that an account authorises to act on its behalf within limits. The relevant standard is ERC-7715, which defines a JSON-RPC method called wallet_requestExecutionPermissions, letting an application ask a wallet for permission to execute on the user's behalf. Its status is Draft, created on 24 May 2024, and it requires EIP-4337 and EIP-7710.

The draft status matters. A mechanism that grants an application standing authority to move your assets is being deployed in production while the interface standard governing it is still a draft. The specification itself names the two obvious risks: permissions should be narrow and time-limited, and wallets must enforce them correctly, since the user is entirely dependent on the wallet implementation being right. It also warns that malicious applications can pose as legitimate ones to obtain broad grants. The user-experience appeal is clear for anything resembling automated or delegated trading, a theme that also runs through social trading platforms and the eToro and Public stake, and the structural caution is the same in both settings: a standing permission is only as good as the limits attached to it.

How does social recovery replace the seed phrase?

Social recovery replaces the seed phrase with a rule in the account's code that lets a designated set of parties rotate the signing key. Because validation logic is arbitrary, an account can define guardians, a threshold and a timelock, and then treat a sufficient quorum as authority to install a new key. Nothing about this is special to ERC-4337, it is simply what becomes expressible once code validates transactions.

Hardware-backed keys make this more usable. EIP-7951, status Final and created on 27 May 2025 by Carl Beekhuizen, Ulaş Erdoğan and Doğan Alpaslan, adds a P256VERIFY precompile at address 0x100 for secp256r1 signature verification. The Ethereum Foundation announced on 6 November 2025 that the Fusaka upgrade would activate at epoch 411392 on 3 December 2025 at 21:49:11 UTC, and EIP-7951 was part of it. Secp256r1 is the curve used by Apple Secure Enclave, Android Keystore, HSMs and FIDO2 and WebAuthn authenticators, so a native precompile makes passkey-signed accounts materially cheaper to verify on chain.

Coinbase Smart Wallet is a production example. Its repository describes an ERC-4337 account whose owners are stored as bytes so that a single account can hold both Ethereum address owners and secp256r1 passkey owners, with WebAuthn assertions verified on chain. Removing the seed phrase does not remove the recovery problem, it relocates it into contract code and into whoever holds the guardian keys. That is a different risk, not an absent one, and it maps closely onto the custody questions institutions are already arguing about in FDIC crypto custody approval and banks holding bitcoin.

Did EIP-7702 make ERC-4337 obsolete?

No, and the specifications now reference each other. EIP-7702 has status Final on the Core track, was created on 7 May 2024 by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs and lightclient, and shipped in the Pectra upgrade. The Ethereum Foundation announced on 23 April 2025 that Pectra would activate at epoch 364032 on 7 May 2025 at 10:05:11 UTC.

Mechanically, EIP-7702 adds transaction type 0x04, carrying an authorisation list of tuples signed by EOA holders. Processing an authorisation sets the account's code to the 23-byte value 0xef0100 followed by the delegate address. That value is a pointer: execution is redirected to the delegate's code. The banned 0xef opcode prefix is what signals the special handling to clients.

The two standards converged rather than competed. EntryPoint v0.8 added native support for EIP-7702 authorisations so that delegated EOAs can use the existing ERC-4337 infrastructure, and shipped a Simple7702Account contract described as a fully audited minimalist smart contract wallet. Its canonical deployment address is 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108. The same release raised the unused gas penalty threshold to 40,000 gas, added a native Go implementation of the ERC-7562 tracer for bundlers, and carried three security fixes covering initCode front-running, paymaster postOp calculation and a zero address assignment.

What new risks does a smart contract wallet introduce?

It introduces four that an ordinary keypair does not have: dependence on bundlers, dependence on paymasters, mutable account logic, and a delegation surface that can be phished with a single signature.

New trust assumptions introduced by smart contract wallets, with the standard or source that documents each

Risk surface	What it depends on	Documented where
EntryPoint	One singleton contract shared by every account	ERC-4337 security considerations
Bundler	An operator choosing to include your operation	ERC-4337, ERC-7562 validation rules
Paymaster	A funded third party and its deposit	OtterSec analysis, 2 December 2025
Upgradeable logic	Whoever controls the upgrade path	Coinbase Smart Wallet UUPS pattern
Delegation	One signature granting persistent control	arXiv 2512.12174, 13 December 2025
Module code	Third-party validators, hooks and executors	ERC-7579 and ERC-6900, both Draft

Bundler trust

A bundler can decline to include your UserOperation, and it can reorder the operations it does include. ERC-4337's own security considerations state that the EntryPoint "will need to be audited and formally verified, because it will serve as a central trust point" for the whole system. ERC-7562 exists to constrain this layer. Its status is In review, created on 1 September 2023 by Yoav Weiss, Dror Tirosh, Alex Forshtat and Shahaf Nacson, and it bans environment opcodes such as TIMESTAMP, BLOCKHASH and GASPRICE during validation, sandboxes which storage slots validation may touch, requires paymasters, factories and aggregators to post stake, and tracks entity reputation through opsSeen and opsIncluded counters.

On bundler market concentration, I could not verify a figure from a primary or methodologically documented source during this research. Several secondary pages quote a share for the largest operators. None of those numbers survived checking against the dashboard they cite, so this article states the structural concern and omits the percentage rather than repeating an unverifiable one.

Paymaster risk

Covered above in the sponsorship section. The short version is that the paymaster is a funded counterparty whose deposit can be drained by griefing, and whose willingness to sponsor is discretionary.

Upgradeable wallet logic

If an account's code can change, then the question "who can change it" becomes as important as "who holds the key". Coinbase Smart Wallet uses the UUPSUpgradeable pattern, with upgrades reachable through whitelisted cross-chain functions. Its own documentation warns against delegating directly to an implementation contract via EIP-7702 and recommends an EIP7702Proxy pattern instead, which is a concrete illustration of how the two mechanisms interact badly when combined naively.

Modularity compounds this. ERC-7579 defines four module types, validation, execution, fallback and hooks, and was created on 14 December 2023. ERC-6900 covers similar ground and was created on 18 April 2023. Both remain Draft, despite being used in production systems that hold real balances, which is an uncomfortable fact that vendor explainers describing either as final get wrong.

Delegation and phishing

This is the newest and best-measured risk. A paper titled "EIP-7702 Phishing Attack" by Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu and Shiping Chen, submitted to arXiv on 13 December 2025 as 2512.12174, describes a class of attack in which a victim signs a single authorisation tuple that grants unconditional and persistent execution control over their account. The authors conducted a measurement of EIP-7702 usage across major EVM chains covering more than 150,000 authorisation and execution events, around 26,000 addresses and hundreds of delegator contracts. Their finding is that authorisation usage is highly concentrated among a small number of contract families linked to criminal activity, with losses in ether, ERC-20 tokens and NFTs across multiple incidents.

The EIP-7702 specification itself anticipates much of this. It names insecure delegate implementations, front-running of initialisation because storage cannot be atomically initialised at delegation time, storage collisions during migration between delegates, changed tx.origin behaviour that breaks reentrancy guards relying on tx.origin equalling msg.sender, and asset sweeping risk for relayers of sponsored transactions.

Trail of Bits published a complementary list on 11 March 2026, written by Coriolan Pinhas, covering six recurring implementation mistakes. Two are worth repeating for non-developers. If an account omits gas fields from what its signature covers, an attacker can inflate a single gas number and drain ether. And once validation succeeds in ERC-4337, the bundler is paid whether or not execution later reverts, so a revert does not undo the cost.

What has actually gone wrong so far?

The largest loss involving a smart contract wallet was not a failure of ERC-4337. The FBI's Internet Crime Complaint Center issued PSA I-022625-PSA on 26 February 2025, stating that North Korea was responsible for the theft of approximately 1.5 billion US dollars in virtual assets from Bybit on or about 21 February 2025, and naming the activity TraderTraitor. Reporting on the incident attributes the entry point to a compromised Safe{Wallet} developer workstation and hijacked AWS session tokens, used to serve modified JavaScript from the Safe interface so that signers approved a transaction different from the one displayed.

That is a web2 supply chain compromise plus blind signing, not a defect in the ERC-4337 specification, and anyone citing Bybit as evidence against account abstraction is citing the wrong thing. The honest lesson is narrower and still serious: a smart contract wallet concentrates authority into code and into the interface that renders what you are signing, and a multisig provides no protection when every signer is shown the same lie. Safe supports ERC-4337 through the Safe4337Module, which acts as both a fallback handler and a module and requires Safe v1.4.1 or newer, but the Bybit loss involved Safe's multisig flow rather than that module.

On the specification itself, the audit record is reassuring rather than alarming. OpenZeppelin's incremental audit of the account-abstraction repository ran from 15 to 19 January 2024 against commit 9879c93 and reported zero critical and zero high severity findings, five medium, eight low, eight notes and three client-reported items. The most interesting medium finding, "Operations Can Throttle Paymasters", arose because the aggregator parameter was semantically overloaded, letting a paymaster's rejection be masked and causing paymasters to be unfairly throttled. It was resolved by removing the intersection calculation from the simulation code and moving that logic off chain into bundlers.

How widely is this actually used?

Adoption is substantial but the public figures come from a dashboard rather than a primary source. BundleBear, an on-chain analytics dashboard and therefore a non-primary source, displayed 1,317,887,534 UserOperations, 68,984,560 accounts with at least one UserOperation, 871,136,661 bundle transactions and 14,881,413 US dollars of paymaster-covered gas when read on 13 October 2026. These are derived aggregates with no published methodology audit, and they should be treated as an order-of-magnitude indication rather than an exact count. The dashboard did not display per-operator market share values at the time of reading.

How strong is the evidence in this article?

Not uniformly. The table below scores each substantive claim by the type of evidence behind it, including the places where this article is weakest.

Evidence strength for each substantive claim made in this article

Claim	Evidence type	Strength
ERC-4337 is Final and defines these five components	Primary specification text	Strong
EIP-7702 is Final and shipped in Pectra on 7 May 2025	Primary specification plus Ethereum Foundation announcement	Strong
EIP-7951 added P256VERIFY in Fusaka on 3 December 2025	Primary specification plus Ethereum Foundation announcement	Strong
ERC-7579, ERC-6900 and ERC-7715 are Draft, ERC-7562 In review	Primary specification registry	Strong
EIP-7702 delegation enables single-signature account takeover	Preprint with on-chain measurement, 150,000 events	Moderate, preprint not yet peer reviewed
Paymaster postOp griefing drains sponsor deposits	Named security firm analysis with code examples	Moderate, vendor research, no incident loss figure
Six recurring smart account implementation mistakes	Named security firm analysis	Moderate, no frequency data given
Bybit loss was 1.5 billion USD, attributed to North Korea	FBI public service announcement	Strong for amount and attribution
Bybit attack path was a compromised developer workstation	Secondary reporting of a third-party forensic investigation	Weak to moderate, not verified against the primary forensic report
Adoption totals for UserOperations and accounts	Third-party dashboard, no methodology audit	Weak, order of magnitude only
Bundler market concentration percentage	Could not verify, claim omitted	Omitted deliberately
General security benefit of account abstraction	Preliminary qualitative academic evaluation	Weak, authors describe it as preliminary

On that last row, the most cited academic treatment is "Account Abstraction, Analysed" by Qin Wang and Shiping Chen of CSIRO Data61, submitted on 1 September 2023. The authors explicitly describe their security evaluation as preliminary and qualitative rather than quantitative. There is still no large-scale quantitative study establishing that smart contract wallets reduce end-user losses relative to externally owned accounts, and anyone claiming otherwise is overstating the literature.

What should a careful reader take away?

A smart contract wallet is a genuine capability upgrade and a genuine expansion of the attack surface, and both halves are real. Gas sponsorship, session keys, social recovery and batching are not marketing. They are direct consequences of letting code decide validity, and the standards enabling them are Final at the layers that matter most, ERC-4337 and EIP-7702 and EIP-7951.

The costs are equally concrete. You acquire a dependency on bundlers and paymasters, you acquire code that can be upgraded by someone, you acquire modules written by third parties under standards that are still drafts, and under EIP-7702 you acquire a signature that can hand over your account permanently in one step. The measured evidence on that last risk already shows concentration in contract families linked to criminal activity, which makes it the risk to understand first. Institutions weighing these systems face the same custody and capital questions that appear in Basel III crypto capital requirements and the bank pushback, and the pattern of infrastructure being adopted faster than it is independently assessed is not unique to wallets, as our coverage of fractional NFTs and the gap between investment vehicle and hype described in a different corner of the same market.

Frequently asked questions

Is a smart contract wallet safer than a regular wallet?

There is no quantitative evidence establishing that it is. It removes specific failure modes, principally irrecoverable key loss, and adds others, principally dependence on code and on third-party infrastructure. The main academic evaluation available describes its own security assessment as preliminary and qualitative.

Do I need ether in my wallet to use an ERC-4337 account?

Not necessarily. A paymaster can cover the fee, which is the mechanism behind applications that onboard users holding no ether. Whether a paymaster will sponsor you is a commercial decision by whoever funds it, not a protocol guarantee.

Does EIP-7702 delete my private key?

No. The delegation sets your account's code to a 23-byte pointer, 0xef0100 followed by the delegate address, and your original key retains full authority to sign ordinary transactions. Delegation adds an execution path, it does not close the existing one.

Can a bundler steal my funds?

A bundler cannot forge your signature, so it cannot move funds your account's validation logic would reject. It can censor your operation by refusing to include it, and it can reorder operations within a bundle. ERC-7562 constrains what validation may touch specifically so that bundlers cannot be cheaply griefed, and that specification is still In review.

Was the Bybit hack caused by account abstraction?

No. The FBI attributed approximately 1.5 billion US dollars of losses on or about 21 February 2025 to North Korean actors it calls TraderTraitor. Reporting indicates the attack ran through a compromised developer workstation and a modified signing interface, so the signers approved something other than what they were shown. That is a supply chain and interface failure affecting a multisig, not a flaw in ERC-4337.

Which EntryPoint version should I expect to see?

Versions 0.6, 0.7 and 0.8 are all deployed and in use. Version 0.8 is the current one, deployed at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108, and it is the first with native support for EIP-7702 authorisations. Accounts and infrastructure are generally built against one specific EntryPoint version rather than all of them.

Sources

• ERC-4337: Account Abstraction Using Alt Mempool, Ethereum Improvement Proposals, status Final, created 29 September 2021
• EIP-7702: Set Code for EOAs, Ethereum Improvement Proposals, status Final, created 7 May 2024
• EIP-7951: Precompile for secp256r1 Curve Support, Ethereum Improvement Proposals, status Final, created 27 May 2025
• ERC-7562: Account Abstraction Validation Scope Rules, Ethereum Improvement Proposals, status In review
• ERC-7579: Minimal Modular Smart Accounts, Ethereum Improvement Proposals, status Draft
• ERC-6900: Modular Smart Contract Accounts and Plugins, Ethereum Improvement Proposals, status Draft
• ERC-7715: Grant Permissions from Wallets, Ethereum Improvement Proposals, status Draft
• Pectra Mainnet Announcement, Ethereum Foundation, 23 April 2025
• Fusaka Mainnet Announcement, Ethereum Foundation, 6 November 2025
• North Korea Responsible for $1.5 Billion Bybit Hack, FBI Internet Crime Complaint Center, Alert I-022625-PSA, 26 February 2025
• EIP-7702 Phishing Attack, Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, arXiv 2512.12174, 13 December 2025, preprint
• Account Abstraction, Analysed, Qin Wang and Shiping Chen, CSIRO Data61, arXiv 2309.00448, 1 September 2023
• ERC-4337 Account Abstraction Incremental Audit, OpenZeppelin, audit conducted 15 to 19 January 2024
• Six mistakes in ERC-4337 smart accounts, Coriolan Pinhas, Trail of Bits, 11 March 2026
• ERC-4337 paymasters: better UX, hidden risks, Nicholas Putra, OtterSec, 2 December 2025
• EntryPoint v0.8 Released, erc4337 newsletter, non-primary project communication
• coinbase/smart-wallet, implementation repository and README
• Safe and ERC-4337, Safe documentation, vendor documentation
• BundleBear ERC-4337 overview, third-party analytics dashboard, non-primary, read 13 October 2026

Further reading on adjacent infrastructure and regulatory questions: how AI underwriting cut loan approval times to three minutes.