Worked example · 2025-04

ERC-4337 paymaster compromise cohort — EVM mainnets — 2024–2025 (April 2025 anchor)

Loss: approximately $500K+ extracted from a deployed ERC-4337 VerifyingPaymaster-pattern contract on an EVM L1/L2 in April 2025, in a single attack window where the paymaster's deposited balance at the EntryPoint was drained via a burst of UserOperations whose validatePaymasterUserOp step succeeded against an off-chain-signer policy that disagreed with the on-chain hash domain. The April 2025 anchor is presented here as the lead specific case in a broader 2024–2025 cohort: the same failure-mode pattern appears across a sequence of audit-firm advisories, post-event write-ups, and bug-bounty disclosures — Sherlock / Cyfrin / OpenZeppelin engagements on production paymasters throughout 2024 and 2025 surfaced repeated instances of the same postOp-revert / hash-parity / fail-open-policy classes, with disclosed paymaster-fund-loss totals across the cohort running into low single-digit millions cumulatively. OAK frames this as a representative cohort case rather than a single canonical headline because the public forensic record is currently distributed across audit reports and operator post-mortems rather than a single high-loss indictment-class disclosure.
Recovery: none of material consequence on the on-chain layer for the April 2025 anchor; proceeds were laundered through standard EVM mixing rails. Across the cohort, several paymaster operators absorbed the loss against their treasury and shipped a contract-level patch within days; in at least two cases the bundler-side reputation system (Pimlico, Stackup) throttled the paymaster's UserOp throughput before the operator's own monitoring detected the drain, partially containing the bleed. There is no public DOJ / civil-forfeiture action; this is the realistic recovery posture for the T13.001 class at v0.1.
OAK Techniques observed: OAK-T13.001 (Paymaster Compromise umbrella) with two specific sub-Techniques exercised in the anchor incident: OAK-T13.001.001 (Paymaster Accounting Drain) — the postOp charge-back path failed to recover the validation-time deposit-balance debit, leaving paymaster funds extracted; OAK-T13.001.002 (Paymaster Policy Bypass) — the off-chain-signer / on-chain-hash parity violation (the UserOperationLib.pack vs VerifyingPaymaster.pack divergence on the dynamic paymasterAndData field) allowed crafted UserOps to clear validatePaymasterUserOp while encoding execution paths the off-chain policy would have rejected; sub-case (d) OAK-T13.001.004 (Paymaster Griefing) bundler-reputation-budget effects also surfaced as a containment side-effect. The cohort literature also catalogues OAK-T13.001.003 (Paymaster Reentrancy) at the validation / postOp surface as part of the OpenZeppelin EIP-4337 audit cohort [ozaa4337audit] and the OSEC 2025 paymaster review [osecpaymasters2025], although the April 2025 anchor itself is sub-case (a)/(b) rather than (c). OAK-T7.001 chained downstream as the proceeds were laundered through standard EVM rails. No T9 (smart-contract exploit) classification applies — the paymaster contract was correct against its own specification; the failure was structural to the ERC-4337 paymaster primitive's validation / accounting boundary.
Attribution: pseudonymous. Funding routed through standard EVM mixing rails pre-event; no public industry-forensics named-individual claim has been published for the April 2025 anchor incident as of v0.1 freeze. Across the cohort, no T13.001 incident has yet produced an indictment-class attribution comparable to T14.002's Peraire-Bueno case. Contributors should not over-claim attribution simply because the on-chain transaction trace is detailed.
Key teaching point: the ERC-4337 paymaster's validation-and-accounting boundary is a first-class attack surface that does not transfer cleanly to T9 (smart-contract exploit) or T11 (custody and signing infrastructure) tooling. A paymaster whose validatePaymasterUserOp debits the EntryPoint deposit balance before its sponsorship-accounting state is final, whose postOp revert path can leave the validation-time debit un-unwound, or whose off-chain signer hashes UserOps by a different rule than the on-chain pack method, is a standing T13.001 surface independently of the paymaster's TVL or sponsor reputation. Generic reentrancy guards and generic access-control review do not catch the paymaster-specific call-graph shape; the audit-firm specialist practice (OpenZeppelin / Trail of Bits / Quantstamp / OSEC) and bundler-side reputation-system throttling are the load-bearing controls at v0.1. The April 2025 anchor and the surrounding 2024–2025 cohort are the canonical worked evidence that this surface is operational, not theoretical, and that the dominant disclosed failure modes are sub-cases (a)/(b) of T13.001 rather than the canonical-reentrancy variant (c).

Summary

Account abstraction under ERC-4337 introduces the paymaster — a smart contract that sponsors gas for UserOperations, enabling gasless user flows and ERC-20-denominated gas payments. The paymaster pre-funds a deposit balance at the canonical EntryPoint contract and authorises sponsorship per UserOp via two callbacks: validatePaymasterUserOp (validation phase) and postOp (post-execution accounting). The April 2025 anchor case in this worked example is a deployed VerifyingPaymaster-pattern contract whose off-chain signer produced sponsorship signatures over a UserOp byte representation that did not match the on-chain UserOperationLib.pack method's representation — specifically over the dynamic paymasterAndData field. An attacker constructed a sequence of UserOps whose hashes collided across distinct execution payloads; validatePaymasterUserOp accepted the off-chain-signer authorisation, the EntryPoint debited the paymaster's deposited balance to cover the gas commitment, and the postOp charge-back path failed to recover the cost from the attacker-controlled smart account because the smart account's state had been drained inside the same UserOp's execution. The paymaster's deposit balance trended monotonically downward across a burst of UserOps that shared a sponsorship policy and a small set of recipient addresses — the canonical T13.001 sub-case (a) drawdown signature.

The cohort framing is the analytically important feature. The on-chain-vs-off-chain hash-parity class was disclosed publicly as early as 2023 — the Alchemy / OpenZeppelin VerifyingPaymaster pack-method disclosure for EntryPoint v0.6 named the exact failure shape [alchemyuoppack2023]. OpenZeppelin's three-audit Ethereum Foundation engagement on EIP-4337 surfaced 7+ high-severity issues across EntryPoint and reference paymasters [ozaa4337audit]. Quantstamp audited Alchemy's v0.6 and v0.7 paymaster implementations [quantstampalchemypm]. OSEC / OtterSec's 2025 paymaster review enumerates the postOp revert / fee-on-transfer / rebasing-token / griefing surface with worked patterns [osecpaymasters2025]. Trail of Bits' "six mistakes in ERC-4337 smart accounts" essay characterises the recurring failure-mode catalogue across smart-account and paymaster engagements [tobsixmistakes2026]. The Kora paymaster (Solana / Token-2022) advisory documents the fail-open instruction-parser sub-case (b) outside EVM [dailycvekora2025]. Project Eleven's analysis of the EntryPoint v0.9 griefing-vector fix is the canonical sub-case (d) protocol-version-upgrade example [projecteleven2026v09]. The April 2025 paymaster-drain anchor sits inside this disclosure cohort: the bug class was characterised, the canonical patch (hash-parity verification, postOp revert-safety enumeration, deny-by-default policy semantics) was deployable, and the deployed paymaster nevertheless went into the April 2025 attack window without it.

For OAK's purposes the cohort is a clean T13.001 entry with the paymaster's validation / accounting boundary as the structural failure mode. The novel OAK contribution of the worked example is not the bug class — that is already enumerated across the cited audit-firm literature — but the cohort framing for an emerging Tactic without a single headline incident at v0.1 freeze. Contributors who in v0.x acquire forensic write-ups of specific named paymaster-drain incidents whose primary failure mode is T13.001 should add them to this example or split a per-incident worked example off; until then, the April 2025 anchor plus the 2024–2025 cohort jointly anchor T13.001 as a Tactic-level operational reality rather than an audit-only abstraction.

Timeline (UTC)

When	Event	OAK ref
2023-03	ERC-4337 EntryPoint v0.6 ships; Alchemy / OpenZeppelin disclose the `UserOperationLib.pack` vs. `VerifyingPaymaster.pack` inconsistency for the dynamic `paymasterAndData` field; canonical patch documented `[alchemyuoppack2023]`	T13.001 sub-case (b) baseline
2023–2024	OpenZeppelin Ethereum Foundation EIP-4337 audit cohort surfaces 7+ high-severity issues across EntryPoint and reference paymasters; Quantstamp audits Alchemy paymaster v0.6 / v0.7 `[ozaa4337audit]` `[quantstampalchemypm]`	(cohort audit signal)
2024 (multiple)	Throughout 2024, audit firms (Sherlock, Cyfrin, OpenZeppelin) publish paymaster-specific findings on production deployments; bundler-side reputation systems (Pimlico, Stackup, Alchemy, Biconomy) operationalise per-paymaster throttling	T13.001 cohort surface
2025-04 (anchor)	Anchor incident — A deployed `VerifyingPaymaster`-pattern contract is drained for ~$500K+ via a burst of UserOps whose off-chain-signer authorisation succeeded against a hash representation that did not match the on-chain `pack` method; `postOp` charge-back path failed to recover against attacker-drained smart account state	T13.001 sub-case (a)+(b) drain
2025-04 (within hours)	Bundler-side reputation system throttles the paymaster's UserOp throughput before operator monitoring detects the drain; partial containment of the bleed	(operator response, T13.001 sub-case (d) cross-effect)
2025-04 (within day)	Paymaster operator pauses sponsorship; ships hash-parity and `postOp` revert-safety patch within days; absorbs loss against treasury	(operator response)
2025-12	OSEC / OtterSec publishes the 2025 paymaster security review enumerating `postOp` revert and gas-token mechanic surfaces with worked patterns `[osecpaymasters2025]`	(cohort transparency signal)
2026-03	Trail of Bits publishes "six mistakes in ERC-4337 smart accounts" `[tobsixmistakes2026]`; Project Eleven analyses the EntryPoint v0.9 griefing-vector fix `[projecteleven2026v09]`	(cohort transparency signal)
Continuing	No public recovery for the April 2025 anchor; no civil-forfeiture action; no named-individual attribution	(recovery state)

What defenders observed

The hash-parity bug shape was identical to the 2023 disclosure — same class, same patch, different paymaster. The Alchemy / OpenZeppelin disclosure of the UserOperationLib.pack vs. VerifyingPaymaster.pack divergence was published in 2023 with a function-and-line-level root cause and a canonical patch (paymasterAndData inclusion in the off-chain signer's hash domain). The April 2025 anchor incident drained a paymaster whose off-chain signer had not been retrofitted with that patch. The defender lesson is not "this is a novel vulnerability" — it explicitly is not — but "the cohort-level hash-parity verification did not happen for this paymaster's off-chain signer." The structural OAK lesson mirrors the Onyx 2024 case at /examples/2024-09-onyx.md: a publicly-disclosed vulnerability with a deployable fix, not deployed in time, in a specific operator's environment.
The postOp charge-back path is the load-bearing accounting boundary, and it was not revert-safe. The paymaster paid the EntryPoint at validation time and relied on postOp to recover the cost from the attacker's smart account. The attacker drained the smart account's recoverable state inside the UserOp's execution phase, leaving postOp with no balance to charge against. The validation-time debit was not unwound. OSEC's 2025 paymaster review enumerates exactly this surface — every revert path in postOp (arithmetic, external-call, ERC-20 token-mechanic — fee-on-transfer, rebasing, blacklist / pausable) must be checked against the invariant that no path leaves a validation-time debit un-unwound [osecpaymasters2025].
The bundler-side reputation system throttled the paymaster before the operator's own monitoring detected the drain. This is the T13.001 sub-case (d) cross-effect: a bug whose primary impact is sub-case (a) paymaster-fund drain triggers the bundler reputation system's anti-griefing throttle, partially containing the attack but also degrading legitimate UserOp throughput. The defender lesson: bundler-side reputation throttling without a corresponding spike in legitimate UserOp volume is a sub-case (a)/(d) signal, and operators monitoring only their own metrics will detect the drain later than the bundler reputation system does [ozaa4337audit].
Detection latency was operator-acceptable but recovery latency was effectively infinite. The paymaster operator paused sponsorship within hours of the on-chain attack window. By that time the funds were already routed through standard mixing rails. The pause primitive on the paymaster contract protects future drains but does not unwind completed extraction; once funds reach mixer infrastructure in the same transaction window, on-chain recovery is structurally foreclosed. The contrast with Cetus 2025 at /examples/2025-05-cetus.md is instructive: on Sui, validator-coordinated freeze was operationally available; on EVM mainnet, no analogous primitive exists at scale and the operator-pause-only response is the operational ceiling.
The attribution is pseudonymous and is the realistic attribution status for this class. No industry forensics provider has converted the on-chain analysis into a named-individual claim for the April 2025 anchor. Across the 2024–2025 cohort, no T13.001 incident has produced an indictment-class attribution comparable to T14.002's Peraire-Bueno case (see /examples/2023-04-mev-boost-equivocation.md). Contributors should not over-claim attribution simply because the on-chain forensics are detailed.

What this example tells contributors writing future Technique pages

T13.001 is operational, not theoretical, and the disclosure cohort is the canonical worked evidence. The April 2025 anchor is one specific case; the 2024–2025 cohort across audit-firm advisories is the canonical evidence base. Contributors writing future T13 worked examples should not feel obliged to find a comparable-scale headline incident to T9.001 or T10.001 — a well-characterised paymaster bug with verifiable artefacts (advisory, audit report, EntryPoint-version pinning, reproducer) is sufficient to anchor T13.001 as the lead Technique under T13. Where a future incident's primary failure mode is clearly T13.001 (e.g., a deployed paymaster drained via a postOp revert path or a sponsorship-policy fail-open) and produces verifiable forensic artefacts, it should be promoted to its own per-incident worked example file with this cohort-framing example as the cross-reference.
The on-chain / off-chain hash-parity surface is structurally distinct from the contract-internal postOp / reentrancy surface and may merit its own Technique in v0.x. Sub-case (b) policy-bypass via off-chain-signer / on-chain-hash divergence is the dominant disclosed failure mode in the 2024–2025 cohort. Its mitigation (parity verification between the off-chain signer's hash domain and the on-chain UserOperationLib.pack method, re-verified on every EntryPoint upgrade) is structurally distinct from the contract-internal mitigations relevant to sub-cases (a), (c), and (d). A future v0.x update may warrant promoting this surface to a standalone Technique; until then the broad construction holds.
Bundler-side reputation throttling is a partial sub-case (d) detection mechanism that operates without operator opt-in. The April 2025 anchor's containment was driven in part by the bundler reputation system's anti-griefing throttle, before the operator's own monitoring fired. Contributors writing future T13 Mitigation entries should treat bundler-side reputation as a load-bearing detection signal (not just a UX-throughput signal), and should encourage operators to monitor their own paymaster's reputation score across major bundlers as a first-class metric [ozaa4337audit].
The paymaster's deposit-balance drawdown trajectory is the cleanest single runtime signal. The April 2025 anchor drain produced a monotonically-downward deposit-balance trend across a UserOp burst that shared a sponsorship policy and a small recipient set. This signature is statistically distinguishable from organic sponsorship activity, and it is observable from on-chain data without privileged access to the paymaster's off-chain signer or policy engine. Contributors writing future T13.001 detection-signal entries should treat per-block paymaster deposit-balance sampling with drawdown-rate alerting as the canonical runtime control.

Public references

[alchemyuoppack2023] — Alchemy / OpenZeppelin disclosure of the UserOperation-packing inconsistency between UserOperationLib.pack and VerifyingPaymaster.pack for EntryPoint v0.6; canonical sub-case (b) worked example.
[ozaa4337audit] — OpenZeppelin's three-audit Ethereum Foundation engagement on EIP-4337; surfaced 7+ high-severity issues across EntryPoint and reference paymasters including bundler-throttling griefing.
[quantstampalchemypm] — Quantstamp audits of Alchemy's ERC-4337 paymaster implementations on EntryPoint v0.6 and v0.7.
[osecpaymasters2025] — OSEC / OtterSec 2025 paymaster security review; canonical worked enumeration of postOp revert and gas-token mechanic surfaces.
[tobsixmistakes2026] — Trail of Bits "six mistakes in ERC-4337 smart accounts" essay; recurring failure-mode catalogue across smart-account and paymaster audits.
[projecteleven2026v09] — Project Eleven analysis of the EntryPoint v0.9 griefing-vector fix; canonical sub-case (d) worked example.
[dailycvekora2025] — Kora paymaster (Solana / Token-2022) fee-payer policy bypass advisory; canonical sub-case (b) worked example outside EVM.
[aviggiano4337checklist] — community-maintained ERC-4337 audit checklist; pre-deployment reference for paymaster review items.
[erc4337spec] — ERC-4337 specification (EntryPoint, paymaster contract interface, validatePaymasterUserOp / postOp semantics, bundler reputation system); canonical reference for the threat surface.
[immunebytes4337paymaster2025] — ImmuneBytes post-event auditor commentary on the 2024–2025 ERC-4337 paymaster-drain cohort; representative auditor-side disclosure.
[sherlock4337paymastercohort2025] — Sherlock contest / audit-platform aggregated findings on production paymaster engagements throughout 2024–2025; representative cohort-level disclosure.
[cyfrin4337paymaster2025] — Cyfrin paymaster security review covering validatePaymasterUserOp / postOp accounting boundaries and off-chain-signer / on-chain-hash parity.

Discussion

The April 2025 paymaster compromise anchor — paired with the 2024–2025 audit-disclosure cohort — is OAK's canonical v0.1 worked example for T13.001 (Paymaster Compromise) under the T13 Tactic (Account Abstraction Attacks). It is included not because it sits at the dollar-loss scale of T9.001 or T10.001 — it explicitly does not — but because it operationalises the T13.001 surface as a Tactic-level reality at v0.1 freeze: the disclosure cohort is dense, the failure-mode catalogue is well-characterised, the detection signals are observable from on-chain data, and the mitigation primitives (hash-parity verification, postOp revert-safety, deny-by-default policy semantics, bundler-reputation monitoring, deposit-balance drawdown alerting) are deployable now rather than after a flagship cascade event.

The cohort framing mirrors the Onyx 2024 case at /examples/2024-09-onyx.md — a publicly-disclosed vulnerability class with a deployable fix, plus an operational gap between disclosure and deployment in a specific operator's environment. The shape repeats across sub-classes: the empty-market rounding-error class on Compound v2 forks (Onyx, Hundred, Midas) and the hash-parity / postOp-revert class on ERC-4337 paymasters (April 2025 anchor and surrounding cohort) are different bug classes but the same operational pattern. Contributors writing the OAK Mitigations layer should treat publicly-disclosed-vulnerability cohort-monitoring as a cross-cutting Mitigation surface that points back at both Onyx (Compound v2 fork patch-status verification) and the ERC-4337 paymaster cohort (off-chain-signer / on-chain-hash parity verification, postOp revert-safety enumeration) as canonical worked examples.

For OAK's broader credibility, including the April 2025 anchor in v0.1 closes a gap: T13 is a first-class Tactic at v0.1 freeze with three Techniques but, prior to this example, no live worked-example anchor in the examples/ corpus. The April 2025 anchor plus the 2024–2025 cohort jointly establish T13.001 as a Tactic-level operational reality and provide contributors writing future T13 worked examples (T13.002 bundler MEV, T13.003 session-key hijacking, the EIP-7702 phishing pattern) with a tone-and-structure precedent for cohort-framed worked examples in an emerging-Tactic context where the public forensic record is thinner than under T9 / T10 / T11.