Worked example · 2024-03
Coinbase Smart Wallet pre-launch audit disclosure (H-01 ownership-recovery loss-of-funds) — Base — 2024-03
Summary
The Coinbase Smart Wallet is a passkey-based smart-account contract system designed for the Base L2 ecosystem, providing an ERC-4337-compatible smart-account experience with passkey owners (validated via WebAuthnSol) alongside Ethereum-address owners. The smart-account contract uses a MultiOwnable access-control primitive: an arbitrary number of owner identities — addresses or passkey public keys — can be added or removed from the account, and any owner can authorise transactions on the account's behalf [coinbasesmartwallet].
Code4rena conducted a public audit of the Coinbase Smart Wallet contract system between 2024-03-14 and 2024-03-21, ahead of the wallet's general-availability launch on Base. The aggregated findings produced 1 HIGH-severity vulnerability (H-01), 2 MEDIUM-severity vulnerabilities, and 26 reports detailing LOW-severity / non-critical issues [c4rcoinbase2024].
H-01 — titled "All Smart Wallet funds will be lost if users remove all owners" — documents a class-level loss-of-funds condition reachable from the smart-account's ownership-management surface. The MultiOwnable contract's removeOwnerAtIndex() function did not enforce a minimum-owner invariant; a sequence of legitimate owner-removal operations could leave the smart account in a state where no owner remained, and therefore no party was authorised to recover or move funds held by the account. The finding's stated impact was that any Coinbase Smart Wallet user who hit the buggy code path post-deployment would have lost the funds in the affected account, regardless of the funds' nominal value or the user's prior security posture.
The mitigation was deployed in the April 2024 Code4rena mitigation-review round. The fix updated the parameterisation of removeOwnerAtIndex() to also take an owner argument, providing the structural enforcement for the minimum-owner invariant. Three wardens — McToady, imare, and cheatc0d3 — verified the mitigation against the original H-01 finding plus the additional Medium-severity issues identified in the original audit [c4rcoinbasemitigation2024].
The smart wallet was subsequently deployed on Base mainnet (initial general-availability rollout in 2024 Q2) and operated at production scale without the H-01 surface. As of v0.1 freeze no public exploitation of the post-mitigation surface has been reported.
For OAK's purposes the case is positioned analogously to the audit-cohort cases that anchor T13.001 in /examples/2025-04-erc4337-paymaster.md: a structural T13 surface, a class-level loss-of-funds condition, a pre-deployment disclosure with a deployable patch, and a vendor that shipped the patch. The novel OAK contribution is the smart-account ownership-management surface as a structurally distinct sub-shape of T13 — adjacent to but not the same as the session-key authorisation surface that T13.003 covers in its narrow sense, and clearly distinct from the paymaster validation-and-accounting boundary (T13.001) and the bundler MEV surface (T13.002). A future v0.x update may warrant promoting the smart-account ownership-management surface to its own T13.x sub-Technique.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| 2024-02-29 | Coinbase publicly announces Smart Wallet feature for the Base L2 ecosystem [coindeskcoinbasesw2024] |
(vendor announcement — pre-audit) |
| 2024-03-14 to 2024-03-21 | Code4rena public audit of Coinbase Smart Wallet smart-contract system | (cohort audit signal) |
| 2024-03-21 (audit close) | H-01 disclosed: "All Smart Wallet funds will be lost if users remove all owners" — MultiOwnable.removeOwnerAtIndex() does not enforce a minimum-owner invariant; class-level loss-of-funds condition reachable from the smart-account ownership-management surface [c4rcoinbase2024] |
T13 / T9.004 disclosure (H-01) |
| 2024-03-21 (audit close) | 2 Medium-severity findings + 26 Low / non-critical findings disclosed alongside H-01 | (cohort audit signal) |
| 2024-04 | Coinbase deploys mitigation: removeOwnerAtIndex() updated to take an owner argument; minimum-owner invariant enforced |
(mitigation deployed) |
| 2024-04 | Code4rena mitigation-review round: McToady, imare, cheatc0d3 verify H-01 fix + Medium-severity fixes [c4rcoinbasemitigation2024] |
(mitigation verified) |
| 2024 Q2 | Coinbase Smart Wallet general-availability launch on Base mainnet without the H-01 surface | (vendor production deploy) |
| 2024–2025 | Smart Wallet operates at production scale on Base; no public exploitation of the post-mitigation surface | (post-mitigation operational record) |
| 2024–2025 (cohort) | Adjacent smart-account audit-disclosure cohort: Argent / Safe / Biconomy / ZeroDev publish session-key best-practice and smart-account contract advisories [smartsessions2024] [openfortssa2026] |
(T13 cohort transparency surface) |
What defenders observed
- The bug class is access-control-misconfiguration but the structural locus is smart-account-specific. H-01 is, at the bug-class level, an access-control misconfiguration on a state-mutating function (the missing minimum-owner invariant on
removeOwnerAtIndex()) — recognisably in the OAK-T9.004 family. But the structural locus is the smart-account's MultiOwnable primitive — a smart-account-era specialisation of access control that does not appear in legacy contract-architecture review. Generic access-control auditing (theonlyOwnermodifier scan, the role-grant enumeration, the multisig-threshold review) does not catch the bug class because the failure is not a missing modifier or a wrong threshold — it is a missing invariant on the ownership-management state machine itself. The mitigation surface is correspondingly specialised: smart-account-architecture review with explicit attention to the ownership-state machine's reachable-state space. - The class-level loss-of-funds framing is structurally important. H-01's stated impact applies to any user who hit the buggy code path, regardless of the user's wallet balance or security posture — because the bug is in the smart-account-contract's invariant set, not in any one user's authorisation flow. This is the same shape as the paymaster-class bugs that anchor T13.001 in the cohort framing of
/examples/2025-04-erc4337-paymaster.md: a smart-account-vendor-side bug whose impact distributes across the vendor's user base rather than concentrating at any single user. Defender threat models for users of smart-account products should treat the vendor-side contract's invariant set as part of the user's wallet threat model. - Pre-deployment audit disclosure is the canonical T13 2024 evidence shape. Unlike T9 / T10 / T11 — where v0.1's worked-example anchors are dominated by realised-extraction events with public forensic write-ups — T13's 2024 evidence base is dominated by audit-cohort disclosures of class-level bugs that vendors patched before public exploitation. The H-01 finding sits inside this audit-cohort evidence shape: Code4rena public audit, public finding, public mitigation, public verification, vendor production deploy without the bug. This is the same evidence shape as the OpenZeppelin three-audit Ethereum Foundation EIP-4337 engagement, the Quantstamp Alchemy paymaster audits, and the OSEC 2025 paymaster review that jointly anchor T13.001 in
/examples/2025-04-erc4337-paymaster.md. Defenders evaluating T13 risk should treat the audit-cohort literature as the canonical evidence base, not as an absence of evidence. - The remediation pipeline executed cleanly and is the defender lesson contributors should preserve. Code4rena public audit → finding disclosed with severity rating → vendor ships mitigation → public mitigation-review round → vendor production deploy without the bug. This is the operationally-functioning version of the disclosure-and-remediation chain, in contrast to the operationally-broken version that produced the September 2024 Onyx and the April 2025 paymaster-drain anchor in
/examples/2025-04-erc4337-paymaster.md(publicly-disclosed vulnerability class with a deployable fix not deployed in time in a specific operator's environment). Contributors writing future T13 worked examples should preserve the contrast — the audit cohort's existence is necessary but not sufficient; the cohort-level disclosure-to-deployment pipeline is the load-bearing control. - Adjacent 2024 cohort signals corroborate T13's audit-cohort evidence shape. The smartsessions ERC-7579 module published its first public auditable reference implementation in 2024; OpenFort published its session-account security architecture analysis in 2026 surveying the 2023–2025 cohort
[openfortssa2026]; Argent and Biconomy published session-key best-practice guidance during the same window. Each of these is independently a T13.003-cohort signal; together with H-01 they establish 2024 as the year T13 transitioned from theoretical-surface to operational-cohort-with-vendor-mitigation-pipeline.
What this example tells contributors writing future Technique pages
- T13 has a smart-account-ownership-management sub-shape that prior anchors do not cover. The April 2025 paymaster anchor in
/examples/2025-04-erc4337-paymaster.mdcovers T13.001 (paymaster compromise); the Cardex 2025 anchor at/examples/2025-02-cardex-session-key-frontend-leak.mdcovers T13.003 (session-key hijacking, dApp-side key compromise sub-pattern); the EIP-7702 cohort at/examples/2025-05-eip7702-crimeenjoyor-delegation-phishing-cohort.mdcovers T13.004 (delegation abuse). The Coinbase Smart Wallet H-01 finding anchors a smart-account ownership-management surface that is structurally adjacent to T13.003 (both are smart-account-authorisation-surface failures) but distinct in the bug-class shape (ownership-state-machine reachable-state vs. session-key scope-and-revocation). A future v0.x update may warrant promoting this surface to its own T13.x sub-Technique; until then, contributors classifying similar incidents (smart-account-ownership-state machine reachability bugs, multi-owner invariant violations, owner-recovery-flow surface failures) should map them to T13 (broadly) + T9.004 with explicit reference to the smart-account-ownership-management sub-shape framing. - Audit-cohort evidence is canonical for T13 — contributors should not require realised-extraction events as the bar. OAK's T9 / T10 / T11 worked-example tradition leans heavily on realised extraction with public forensic write-ups. T13's 2024 evidence base is structurally different: dominated by audit-cohort disclosures of class-level bugs that vendors patched before public exploitation. The H-01 finding plus the OpenZeppelin / Quantstamp / OSEC / Trail of Bits / Cyfrin / Sherlock paymaster cohort jointly anchor T13 as a Tactic-level operational reality at v0.1 freeze. Contributors writing future T13 worked examples should not feel obliged to find a comparable-scale realised-extraction event — a well-characterised audit finding with a public disclosure, a deployable mitigation, and a vendor that shipped the mitigation is sufficient evidence for a T13 anchor.
- The H-01 finding is the structural counterpart to the paymaster 2024 audit cohort that anchors T13.001 in /examples/2025-04-erc4337-paymaster.md. The two cases together illustrate the canonical T13 2024 evidence shape: at the paymaster surface (T13.001), the audit cohort enumerates the validation-and-accounting boundary failure modes; at the smart-account ownership-management surface (this case), the audit cohort enumerates the ownership-state-machine reachable-state failure modes. Contributors writing future T13 Mitigation entries should preserve the parallel structure — paymaster-side controls (hash-parity verification, postOp revert-safety, deny-by-default policy semantics) and smart-account-ownership-management-side controls (minimum-owner invariant enforcement, owner-removal flow surface review, recovery-flow reachability analysis) are co-equal load-bearing surfaces under the T13 Tactic.
- The operationally-functioning disclosure-and-remediation chain is the deployable defender pattern that contributors should reference at v0.1. Code4rena public audit → finding disclosed with severity rating → vendor ships mitigation → public mitigation-review round → vendor production deploy without the bug. This is the chain that succeeded for Coinbase Smart Wallet H-01. The chain that failed for the April 2025 paymaster anchor (publicly-disclosed bug class, deployable fix, not deployed in time in a specific operator's environment) is the contrast case. Contributors writing future T13 worked examples should preserve the disclosure-and-remediation chain as a first-class lessons-learned dimension, with H-01 as the success-case anchor and the April 2025 paymaster as the failure-case anchor.
Public references
[c4rcoinbase2024]— Code4rena public audit report on Coinbase Smart Wallet (March 2024); H-01 "All Smart Wallet funds will be lost if users remove all owners" finding plus the 2 Medium-severity and 26 Low / non-critical issues; canonical primary source.[c4rcoinbasemitigation2024]— Code4rena mitigation-review round (April 2024); McToady, imare, cheatc0d3 verification of H-01 fix and the additional Medium-severity issues' fixes.[coinbasesmartwallet]— Coinbase Smart Wallet GitHub repository (coinbase/smart-wallet); MultiOwnable contract source; canonical reference for the ownership-management primitive.[coindeskcoinbasesw2024]— CoinDesk reporting on the Coinbase Smart Wallet feature announcement (2024-02-29); pre-audit timeline anchor.[smartsessions2024]— Rhinestone SmartSessions ERC-7579 module — leading audited reference for modular session-key implementation in the 2024 smart-account cohort.[openfortssa2026]— OpenFort session-account security architecture analysis surveying the 2023–2025 smart-account audit cohort.[corbadosmartwallet]— Corbado technical analysis of Coinbase Smart Wallet's passkey + WebAuthnSol architecture.
Discussion
The Coinbase Smart Wallet H-01 disclosure (March 2024) is OAK's canonical T13 2024 worked example, structurally paired with the April 2025 paymaster anchor (/examples/2025-04-erc4337-paymaster.md) to jointly establish T13 as a Tactic-level operational reality at v0.1 freeze. The two cases together cover two of the three structurally-distinct T13 sub-shapes — paymaster validation-and-accounting boundary (T13.001 anchor) and smart-account ownership-management surface (this case, with framing for a future T13.x sub-Technique) — alongside the Cardex 2025 (T13.003 dApp-side key compromise anchor) and EIP-7702 cohort 2025 (T13.004 delegation abuse anchor) entries.
The defender lesson is that T13's 2024 evidence base is dominated by audit-cohort disclosures rather than by realised-extraction events, and that this evidentiary shape reflects the operationally-functioning version of the disclosure-and-remediation chain rather than an absence of attack-surface activity. The H-01 finding documents that a major smart-account vendor's pre-launch ownership-management contract had a class-level loss-of-funds condition; the audit cohort disclosed it; the vendor patched it; the patched contract operates at production scale on Base. This is the success case of the audit-cohort-to-vendor-mitigation pipeline. The April 2025 paymaster anchor is the failure case of the same pipeline — publicly-disclosed bug class, deployable fix, not deployed in time. Contributors writing future T13 worked examples should preserve the parallel and the contrast.
The cohort framing matters because T13's pre-2024 status was theoretical-surface — the ERC-4337 specification was finalised in March 2023 (EntryPoint v0.6) and production deployments were thin through 2023. By 2024 the audit cohort had stabilised, the vendor mitigation pipeline was operational at major vendors, and the public disclosure-and-remediation chain had executed on multiple class-level findings. The H-01 case is one specific datapoint inside this 2024 stabilisation; the broader cohort (OpenZeppelin EIP-4337 engagement, Quantstamp Alchemy paymaster audits, Code4rena Biconomy paymaster contest, the smartsessions ERC-7579 reference implementation, OpenFort session-account security architecture analysis) is the joint evidence base.
The attribution status is N/A — H-01 was disclosed by a Code4rena warden in the public audit cohort and remediated by Coinbase pre-deployment. The case has no operator-cluster attribution surface and should not be folded into any actor cohort by analogy. The defender value is in the disclosure-and-remediation pipeline framing, not in any threat-actor-cluster framing.