An institution moving into digital assets eventually asks the question a treasurer asks about a bank mandate: who can move money, under what limit, and what happens when a signer leaves. For an ordinary externally owned Ethereum account (EOA), the answer is binary. Whoever holds the private key can move everything, immediately, with no policy layer in between. Two Ethereum standards now let an account enforce spending policy, delegate narrow permissions and recover from a lost key, but they differ in how they work, in how they reached production, and in what they change about where a compromise happens. This is not advice of any kind; it describes mechanisms.

Two paths to the same idea

Account abstraction means letting an account run its own verification logic, in a smart contract, instead of relying only on a signature check against a single private key. Ethereum has arrived at it from two directions.

ERC-4337: a new kind of account, no protocol change

ERC-4337, "Account Abstraction Using Alt Mempool", is a Final standard in the ERC category, created on 29 September 2021. It explicitly avoids any consensus-layer change. A user submits a UserOperation, a transaction-like object that third-party "bundlers" collect from a separate mempool and pass to a singleton EntryPoint contract, which validates and executes it on behalf of a smart contract account. An optional paymaster contract can sponsor the gas, and the standard lists paying fees in ERC-20 tokens among its use cases. The first EntryPoint contract was deployed on Ethereum mainnet on 1 March 2023. Under ERC-4337, the account of record is a new contract address, not the institution's existing EOA.

EIP-7702: an existing address gains code

EIP-7702, "Set Code for EOAs", is a Final Core standard, created on 7 May 2024, and it does change the protocol. It adds a new transaction type carrying authorisation tuples; in each, an EOA signs over a chain ID, a contract address and a nonce. The network then writes a delegation indicator into the account, so calls to it execute the named contract's code in the EOA's own context. It introduces no new opcodes. It went live on mainnet with the Pectra upgrade on 7 May 2025 (epoch 364032). EntryPoint v0.8, released for that fork, added native support for 7702 authorisations, so delegated EOAs can use the existing bundler and paymaster ecosystem, and shipped an audited Simple7702Account contract. The practical difference: 7702 lets a treasury keep its existing address and add logic to it, while 4337 asks it to adopt a new contract address.

EIP-7702 replaced an earlier design. EIP-3074 proposed EOA delegation through two new opcodes, AUTH and AUTHCALL. It is now Withdrawn, and the recorded reason is "Superseded by EIP-7702". It is not part of the protocol.

What a spending policy replaces

Under a smart contract account, "who can sign" stops being the only control. A policy can encode a limit per period, a list of approved destination contracts, a higher signing threshold above a set amount, and an expiry. No single standard defines a policy language that every institution can adopt. Each wallet vendor implements its own, and the terms do not carry across. Safe's spending-limit feature is one example: an owner names a beneficiary, a token, an amount and either a one-time limit or a daily, weekly or monthly reset, and, in Safe's words, "sending a token within a spending limit doesn't require approvals from the signers of a Safe Account." That is a deliberate carve-out from the multisig threshold, and an institution should treat configuring one with the same care as setting a signing mandate.

Session keys bound what a leaked key can do

A session key is a narrowly scoped credential issued so a bot, an integration or an operator can transact without holding the account's full authority. ZeroDev's permissions documentation describes one implementation as "1 signer + N policies + 1 action": a key, the conditions under which it may be used, and the execution it may trigger. Its built-in policies restrict which contracts and functions can be called, how much gas can be spent, what may be signed, how often operations can be sent and within what time window. Scoped this way, a leaked session key exposes only what its policies allow, not the account's full balance. Because the policies are optional and configurable, that bound is only as tight as the institution sets it. The same delegation problem arises when the party transacting is an autonomous agent, discussed in agentic commerce, when the buyer is software.

Paymasters separate the signer from the payer

Under a plain EOA, the address that signs a transaction pays its gas; sponsoring someone else's transaction means sending them ETH first. A paymaster lets a platform absorb gas for its clients, or lets an account settle fees in a token rather than ETH, on rules the paymaster's operator sets. The trade-off is another contract, possibly one the institution did not write, sitting in the execution path, whose correctness becomes part of the attack surface. Neither ERC-4337 nor EIP-7702 requires one.

Recovery changes the question, not the need for governance

A smart contract account can encode recovery, typically a set of guardians who can replace the signing key, so a single seed phrase is no longer a single point of failure. That turns a cryptographic question into a governance one: who the guardians are, how they are authenticated, and what stops them being coerced or colluding. The standards make such mechanisms possible without prescribing one, so the design and its documentation fall to the institution, as signing authority for a wire transfer does.

Where compromises have happened

The Bybit theft in February 2025 involved a smart contract wallet but did not exploit ERC-4337 or EIP-7702. According to Sygnia's investigation, published 16 March 2025, a Safe{Wallet} developer's machine was compromised on 4 February, the attackers had access to Safe's AWS infrastructure from 5 to 21 February, and on 19 February JavaScript served to Bybit was altered so its signers saw a legitimate-looking transaction while a malicious one was executed. More than 400,000 ETH left Bybit's Ethereum cold wallet on 21 February. Sygnia notes that the FBI attributed the attack to the Lazarus Group, a threat group linked to North Korea. The multisig's on-chain logic was not broken; the interface the signers relied on to show what they were approving was. The lesson is to verify transaction data independently of the signing interface, not only to add signers.

EIP-7702 brings its own risk. The specification itself warns that a poorly implemented delegate can "allow a malicious actor to take near complete control over a signer's EOA", because one authorisation points the whole account at another contract's code. In the weeks after Pectra, Wintermute found, as CoinDesk reported on 2 June 2025, that over 97% of 7702 delegations were authorised to contracts with the same code, "sweepers" built to drain incoming ETH from compromised addresses. The same report said that campaign had not been profitable for the attackers. For an institution, a 7702 authorisation request deserves the scrutiny of a wire authorisation. The specification does allow an account to clear its delegation by re-delegating to the zero address, but that takes another signed authorisation, and funds already moved stay moved.

What remains open

Audits of the core contracts do not cover a vendor's own layer. The Ethereum Foundation commissioned an OpenZeppelin incremental audit of the ERC-4337 reference contracts, published 22 February 2024, which reported 24 issues, none critical or high, all resolved. A wallet vendor's policy engine, paymaster or session-key module sits outside that scope and needs its own audit trail. Revocation behaviour for session keys and guardians also varies by implementation, and an institution has to confirm what its own vendor ships.

A spending-policy engine changes what a compromised key can do, not who holds the assets or who controls the rails an order travels through. Those questions are covered in institutional custody, who actually holds it and who controls institutional access onchain.