Auditing Account Abstraction And Paymaster Trust

Auditing account abstraction and paymaster trust: validation, payment, and execution are three trusts

In an ERC-4337 stack a user operation is validated by the smart account, paid for by a paymaster, bundled by a bundler, and executed through the entry point, and those are separate trust decisions made by separate parties. Each is a place trust can be misplaced. The account's validation decides whether a signature and nonce are acceptable; if it accepts what it should reject, an attacker executes operations as the account. The paymaster decides whether to sponsor an operation's gas; if it sponsors what it should not, an attacker drains its deposit by submitting operations that cost the paymaster and benefit no legitimate user, a denial-of-wallet on the sponsor. The entry point and bundler order and submit operations; if an operation can be replayed or reordered for gain, the lifecycle itself is the exploit. And validation runs under strict rules about what state it may read, mutable or external state in validation is both a denial vector and a soundness hole. The audit walks the user-operation lifecycle and checks each trust: what validation accepts, what the paymaster agrees to pay for, and what the ordering allows. You audit this by crafting user operations that probe each decision.

When to use

• An ERC-4337 account-abstraction stack validates, sponsors, and executes user operations across a smart account, a paymaster, a bundler, and the entry point.
• A paymaster sponsors gas and could be made to pay for operations it should not.
• Account validation may accept a bad signature or nonce, or read mutable or out-of-scope state.

Scope check

Test account-abstraction trust only against contracts and infrastructure you own or are authorized to assess, on a testnet or a local fork. Submitting user operations and probing a paymaster spends real gas and can drain a real deposit, so use test funds on a fork and never drain a live paymaster or execute against an account that is not yours. If you can't name the authorization, stop.

The loop

1. Establish each trust decision first. Name what the account's validation must accept and reject (which signer, which nonce), what the paymaster agrees to sponsor and under what limit, and what ordering the entry point and bundler guarantee. This is the false-positive killer: an account that validates a correct signature and monotonic nonce only, a paymaster that sponsors within a scoped, limited policy, and a lifecycle with no replay or reorder gain are behaving correctly. Name each trust, then probe it.

2. Test account validation. Craft user operations with a wrong or malformed signature, a reused or out-of-order nonce, and an unexpected signer, and confirm validation rejects each. An account that accepts a signature it should not, or reuses a nonce, lets an attacker execute operations as the account.

3. Test paymaster sponsorship scope. Submit operations the paymaster should not pay for: outside its intended users, actions, or limits, and confirm it declines. Then submit sponsored operations at volume and confirm a per-user and total limit bounds the deposit spend. A paymaster that sponsors broadly or without a spend cap is drainable, its deposit is the loss.

4. Check validation-phase state rules. Determine what the account's and paymaster's validation reads: whether it touches mutable storage or external contracts it should not during validation. Validation that depends on state a bundler cannot trust is both a griefing vector (operations that pass simulation but fail on-chain) and a soundness gap the attacker steers.

5. Assess replay and ordering in the lifecycle. Check whether a user operation can be replayed (across chains, entry points, or after a nonce reset) or reordered by the bundler for gain. Confirm the operation is bound to its chain, entry point, and nonce so it executes once, in one place. A replayable or reorder-sensitive operation is exploited by the party that sequences it.

6. Confirm and record. Confirm on a fork by executing an operation the account should have rejected, draining a scoped amount from a test paymaster, or replaying an operation, with test funds and without touching a live account or paymaster. Kill the lead if validation accepts only a correct signature and nonce, the paymaster sponsors within a scoped and capped policy, validation reads no untrusted state, and operations are bound against replay and reorder gain. Record the crafted user operation, the drained paymaster or unauthorized execution, and the over-permissive validation or sponsorship rule.

Where account-abstraction trust leaks

• Over-permissive account validation. Accepting a bad or replayed signature, or a reused nonce, lets an attacker execute operations as the account.
• Unscoped or uncapped paymaster sponsorship. A paymaster that pays for operations outside its policy or without a spend limit is drainable; its deposit is the loss.
• Untrusted state read in validation. Validation that touches mutable or external state a bundler cannot trust enables griefing and steers soundness gaps.
• Replayable user operations. An operation not bound to its chain, entry point, and nonce can be replayed for repeated effect.
• Reorder-sensitive lifecycle. An operation whose outcome depends on bundler ordering hands value to whoever sequences it.

Worked example (a confirm and a kill)

Confirm. A paymaster sponsors any user operation that calls a particular application contract, with no per-user or total spend cap. On a fork, an attacker submits a flood of operations that each call that contract in a way that costs gas but does nothing useful, and the paymaster pays for all of them until its deposit is exhausted, denying sponsorship to real users. Confirmed paymaster deposit drain via unscoped sponsorship, high, remediation = scope sponsorship to authenticated users and specific actions, and enforce per-user and total spend caps with rate limiting so a flood cannot exhaust the deposit.

Kill. The account validates only a correct signature from the expected signer with a monotonic nonce, the paymaster sponsors only scoped users and actions within per-user and total spend caps, validation reads no mutable or external state a bundler cannot trust, and every operation is bound to its chain, entry point, and nonce. A bad-signature operation is rejected, a sponsorship flood is capped, and a replay reverts. Killed, kill_reason = "validation accepts only a correct signature and nonce, paymaster sponsorship is scoped and capped, validation reads no untrusted state, and operations are replay- and reorder-bound; no operation executes or drains against policy."

Rationalizations to reject

• "The signature check is standard." → Confirm it rejects malformed and replayed signatures and enforces the nonce; standard code with a nonce or domain mistake still lets operations through.
• "The paymaster only sponsors our app." → Scoping to a contract is not scoping to legitimate use; without per-user and total caps an attacker loops that contract to drain the deposit.
• "Validation is simple, it just checks the signer." → Confirm it reads no mutable or external state during validation; that is both a griefing and a soundness rule, not a style preference.
• "Operations have nonces, so no replay." → Verify the operation is also bound to the chain and entry point; a nonce alone does not stop cross-chain or cross-entry-point replay.
• "The bundler is trusted." → The bundler chooses order and can be anyone; design so no operation's outcome depends on it sequencing fairly.

Executing this in practice

You need the account's validation logic (signature and nonce rules and what state it reads), the paymaster's sponsorship policy and spend limits, and how operations are bound against replay and reorder. On a fork, submit operations with bad signatures and reused nonces, probe the paymaster outside its policy and at volume, and attempt replays. Reading the validation and paymaster contracts shows the intended trust; an operation that executes or a deposit that drains against policy shows whether it holds.

Related

• hunting-signature-replay-and-eip712-domain-trust - the signature and domain binding this skill checks in account validation is that skill's whole subject; audit them together for the account.
• hunting-mev-and-transaction-ordering-exposure - the bundler orders user operations, so ordering extraction reappears at the account-abstraction layer.
• hunting-wallet-drainer-and-dapp-approval-abuse - draining a paymaster and draining a user via approvals are two economic attacks on the same wallet stack.
• reviewing-rate-limiting-and-abuse-controls - the per-user and total spend caps that stop a paymaster drain are the rate-limiting discipline applied to gas sponsorship.
• FINDING-SCHEMA.md - source = the crafted user operation, sink = the drained paymaster or unauthorized execution, evidence = the over-permissive validation or sponsorship rule.