Loopring Smart Wallet 2FA-bypass guardian-recovery exploit — Ethereum — 2024-06-09

Summary

Loopring is a zk-rollup-based EVM-compatible scaling solution that, alongside its rollup operations, deploys a smart-contract-wallet product (Loopring Smart Wallet) on Ethereum and the Loopring rollup. The Smart Wallet implements an account-abstraction pattern with a guardian-based social-recovery flow: the wallet owner designates a set of guardians (other addresses, often other wallets owned by the user or trusted contacts), and a quorum of guardians can initiate a recovery flow that transfers the smart wallet's authority to a new owner-key, gated by an authentication step that is intended to confirm the recovery is authorised.

On 2024-06-09 an attacker exploited a defect in the guardian-recovery flow's authentication step. The defect — per Loopring's own post-incident statement and the corroborating PeckShield, BlockSec, and SlowMist forensic write-ups — allowed an attacker to bypass the 2FA-equivalent authentication that should have constrained guardian-initiated recovery to authorised flows. The bypass mechanism converted the guardian-recovery flow into a wallet-takeover surface: an attacker, by satisfying the bypass preconditions, could initiate a recovery against an affected smart-wallet account and transfer the account's authority to an attacker-controlled key, after which standard drainer semantics applied to the takeover-controlled account.

The drained cohort was a subset of Loopring Smart Wallet users whose account-state matched the exploitable preconditions at the time of the attack — not all Loopring Smart Wallet accounts were vulnerable. Cumulative extraction across the affected cohort was approximately $5M. Loopring's operator response was prompt: the recovery flow was paused, the underlying defect was mitigated, and user-facing communication including reset-recovery-configuration guidance was published. No on-chain reversal of the takeover transactions or the downstream drains is structurally available; once a smart-wallet's authority transfers to the attacker, the affected funds enter the attacker's standard drainer pipeline.

For OAK's purposes the case sits at the intersection of T11.002 (broadly construed wallet-software-flow weakness — here in the smart-wallet-recovery-flow sub-class) and T13 (account-abstraction, broadly construed — the smart-wallet ecosystem within which the recovery-flow surface exists). The novel OAK contribution of the worked example is documenting the smart-wallet recovery-flow surface as a discrete attack-surface class that the current T13 sub-techniques do not cover at sub-technique granularity, and arguing for its inclusion as a future T13 sub-technique. The case is the cleanest 2024 worked example for this surface and should be cross-referenced from any future T13.x update that introduces a smart-wallet-recovery-flow sub-technique.

Timeline (UTC)

When	Event	OAK ref
Pre-event	Loopring Smart Wallet deployed on Ethereum and Loopring rollup; guardian-based social-recovery flow includes 2FA-equivalent authentication step intended to constrain guardian-initiated recovery to authorised flows; defect in the authentication step's logic latent in the deployed smart-wallet implementation	T11.002 surface (latent — smart-wallet-recovery-flow sub-class)
Pre-event	Attacker funds wallet via Tornado Cash; analyses Loopring Smart Wallet recovery-flow implementation; identifies the 2FA-bypass precondition pattern	(off-OAK pre-event observation)
2024-06-09 (attack-tx window)	Attacker constructs guardian-recovery transactions against affected Loopring Smart Wallet accounts; bypasses 2FA-equivalent authentication step; takes over multiple smart-wallet accounts; drains takeover-controlled accounts of approximately $5M cumulative	T11.002 + T13 (broadly construed) extraction
2024-06-09 (within hours)	Loopring operations team detects the anomalous recovery-flow pattern via on-chain monitoring; pauses the recovery flow; engages incident response	(operator response)
2024-06-09 (within hours)	Loopring publishes initial public acknowledgement; user-facing communication includes urgent reset-recovery-configuration guidance for affected and at-risk accounts	(operator-side public-acknowledgement)
2024-06-09 onward	PeckShield, BlockSec, SlowMist publish forensic write-ups converging on the 2FA-bypass / guardian-recovery-flow root cause	(transparency / cohort signal)
Days following	Attacker laundering routes proceeds through Tornado Cash	T7.001 (off this example's framing)
2024-06 onward	Loopring deploys mitigation patch to the recovery-flow authentication step; publishes follow-up post-mortem; reset-recovery-configuration uptake among smart-wallet users continues	(operator response)
Continuing	No public on-chain recovery; no civil-forfeiture action	(recovery state)

What defenders observed

• The defect was in the recovery-flow authentication logic, not in the underlying smart-wallet account logic. Loopring's Smart Wallet account-level logic — the EOA-equivalent transaction-execution and balance-management surface — was not the proximate failure. The proximate failure was in the recovery-flow's 2FA-equivalent authentication step, which should have constrained guardian-initiated recovery to authorised guardian-quorum-and-2FA-confirmed flows. The defender lesson is that smart-wallet audit coverage should treat the recovery flow as a first-class audit surface, separately and integratedly with the account-level logic; the recovery flow is structurally distinct enough that a clean account-level audit does not transfer to a clean recovery-flow audit.
• The recovery-flow surface is structurally necessary in account-abstraction smart wallets. The alternative to a recovery flow — a single-key wallet with no recovery — is a worse end-user UX, with higher rates of permanent fund loss from key loss. Smart wallets implement social-recovery / guardian-based recovery flows precisely to mitigate this UX cost. The recovery flow is therefore a structurally necessary surface; it cannot be removed in pursuit of zero-attack-surface design without re-introducing the key-loss UX problem that motivated smart wallets in the first place. Defender practice for smart-wallet ecosystems should accept the recovery flow as a necessary surface and concentrate audit-and-monitoring effort on the authentication-and-authorisation steps that gate recovery initiation, rather than treating the recovery flow as a removable surface.
• The realised loss is bounded by the affected-cohort size and per-account balance, not by the total smart-wallet-population balance. The defect was exploitable only against accounts whose state matched the 2FA-bypass preconditions. Loopring Smart Wallet users whose account-state did not match those preconditions were not vulnerable. The realised loss of approximately $5M reflects the affected-cohort size and per-account balance. Defender threat models for smart-wallet recovery-flow defects should compute realised-loss-bound as a function of the affected-cohort size, not as a function of the total smart-wallet-population TVL — most smart-wallet-recovery-flow defects affect specific account-state preconditions rather than the entire deployed population.
• The operator response shape — pause-recovery-flow + mitigate + reset-recovery-configuration guidance — is the standard playbook for this sub-class. Loopring's response followed the canonical shape: pause the recovery flow at the operator-side level, deploy a mitigation patch for the underlying defect, publish user-facing reset-recovery-configuration guidance for affected and at-risk accounts. The shape is structurally similar to the Li.Fi 2024 facet-pause-and-revoke-approval response shape at /examples/2024-07-li-finance.md — a protocol-side pause primitive that protects future drains, paired with user-side configuration-reset guidance that requires user uptake to be operationally complete. Defender practice should pre-position both halves of this shape (operator-side pause infrastructure and user-side configuration-reset comms) for any smart-wallet ecosystem with a non-trivial recovery flow.
• Pseudonymous attribution is the realistic attribution outcome for this class. Funding was routed through Tornado Cash pre-event; laundering routed through Tornado Cash post-event; no industry forensics provider has converted on-chain analysis into a named-individual claim. There is no public OAK-G01 attribution. Contributors should not over-claim attribution simply because the on-chain forensics are detailed.

What this example tells contributors writing future Technique pages

• T11.002 covers smart-wallet-software-flow weaknesses as a sub-class within its broader wallet-software-compromise construction. The Loopring 2024 case is the canonical 2024 worked example for the smart-wallet-recovery-flow sub-class. The standard T11.002 framing covers EOA wallet-software compromise (e.g., supply-chain compromise of a wallet package, malicious browser extension, mnemonic-extraction malware); the Loopring case is the smart-contract-wallet companion sub-class, where the compromise is of the wallet-software's flow logic rather than of the user's key material directly. T11.002 worked examples should preserve this sub-class distinction, and future contributor guidance may consider whether the smart-wallet-recovery-flow sub-class warrants promotion to a separate technique ID.
• T13 should include a smart-wallet-recovery-flow sub-technique. The current T13 sub-techniques (T13.001 paymaster compromise, T13.002 bundler MEV, T13.003 session-key hijacking) do not have an exact match for smart-wallet recovery-flow defects. The Loopring 2024 case is the canonical 2024 worked example arguing for the inclusion of a smart-wallet-recovery-flow sub-technique within T13's account-abstraction scope. Future contributor guidance writing T13.x updates should consider introducing such a sub-technique with the Loopring 2024 case as the anchor worked example, and should consider whether session-key hijacking (T13.003) and recovery-flow takeover are sufficiently distinct to remain separate sub-techniques or whether they should be unified under a broader smart-wallet-authority-takeover construction.
• Smart-wallet recovery flows are a structurally necessary surface and should be treated as a first-class audit-and-monitoring surface, not as a removable design choice. The Mitigations-layer lesson from the Loopring case is that the recovery flow cannot be designed out of the smart-wallet ecosystem without re-introducing the key-loss UX problem; therefore the audit-and-monitoring effort should focus on the authentication-and-authorisation steps that gate recovery initiation, rather than on the existence of the recovery flow. Future contributor guidance should consider a cross-cutting Mitigation entry covering smart-wallet recovery-flow audit-and-monitoring with the Loopring 2024 case as the primary worked example.
• Affected-cohort-size as the realised-loss bound is the operational analogue of AMM-liquidity-depth as the realised-loss bound for admin-key-mint incidents. Both are structural properties that determine how much of a worst-case nominal loss-shape is realisable in practice; both are load-bearing variables for defender threat-modelling; both should be computed explicitly. The Loopring 2024 case anchors the affected-cohort-size dimension for smart-wallet-recovery-flow defects, in the same way the Holograph 2024 case at /examples/2024-06-holograph.md anchors the AMM-liquidity-depth dimension for admin-key-mint defects. Contributors writing the worked-example layer should compute the realised-loss bound explicitly in both cases and should not collapse realised-loss into the nominal-loss-shape headline.

Public references

• [loopringofficial2024] — Loopring official statement on the June 2024 Smart Wallet recovery-flow exploit, including the defect description, the mitigation timeline, and the user-facing reset-recovery-configuration guidance.
• [peckshieldloopring2024] — PeckShield headline figures and on-chain analytics for the Loopring June 2024 drain.
• [blocksecloopring2024] — BlockSec / on-chain forensic analysis of the Loopring guardian-recovery 2FA-bypass transaction trace.
• [slowmistloopring2024] — SlowMist incident analysis covering proceeds-tracking and Tornado Cash laundering pattern.
• [rektloopring2024] — Rekt News public-facing summary framing the case as a guardian-recovery 2FA-bypass on the Loopring Smart Wallet.
• [zachxbtloopring2024] — ZachXBT / on-chain analyst thread tracking the attacker-controlled addresses and the takeover-and-drain sequence across affected smart-wallet accounts.
• [cointelegraphloopring2024] — Cointelegraph / industry press coverage of the Loopring incident and the smart-wallet-ecosystem framing.

Discussion

Loopring 2024 is OAK's canonical case for the smart-wallet-recovery-flow sub-class of T11.002 broadly construed and the smart-wallet-recovery-flow sub-class within T13's account-abstraction scope. The case is operationally instructive in two distinct dimensions and should be cross-referenced from both the T11.002 and T13 technique pages, with the latter cross-reference paired with future contributor guidance on whether the smart-wallet-recovery-flow surface warrants its own T13.x sub-technique ID.

The smart-wallet-recovery-flow surface is a structurally novel attack surface in the OAK 2024 corpus. Pre-account-abstraction wallet attacks predominantly involved EOA key-material compromise (mnemonic extraction, hardware-wallet supply-chain compromise, malicious wallet-software distribution); the smart-wallet ecosystem introduces a structurally distinct surface — the recovery flow — that has no clean analogue in the EOA wallet ecosystem. The Loopring 2024 case is the cleanest 2024 worked example of an attack against this novel surface, and is the canonical anchor for any future T13.x sub-technique covering smart-wallet-authority-takeover via recovery-flow defects. The corpus's treatment of account abstraction in T13 should evolve to cover the surface explicitly; until that evolution lands, the broad T11.002 construction together with broad T13 framing carries the worked example.

The structural necessity of the recovery flow is the corpus-level framing point that Mitigations-layer guidance should preserve. A naive design philosophy might suggest that smart-wallet ecosystems should remove the recovery flow to eliminate the attack surface; this philosophy does not generalise because the alternative — single-key wallets with no recovery — is a worse end-user UX, with higher rates of permanent fund loss from key loss. The recovery flow is therefore a structurally necessary surface in the smart-wallet ecosystem; the Mitigations-layer effort should concentrate on the authentication-and-authorisation steps that gate recovery initiation, on operator-side audit coverage of the recovery-flow logic as a first-class audit surface, and on user-side configuration discipline (guardian selection, periodic guardian-set review, reset-recovery-configuration uptake after disclosed defects). The Loopring 2024 case anchors all three dimensions in the 2024 cohort.

The affected-cohort-size as realised-loss bound is the corpus-level operational analogue of the AMM-liquidity-depth as realised-loss bound that the Holograph 2024 case at /examples/2024-06-holograph.md anchors. Both are structural properties that determine how much of a worst-case nominal loss-shape is realisable in practice; both should be computed explicitly in the worked-example layer; both should not be collapsed into headline-loss figures. The worked-example layer's discipline of computing realised-loss bound explicitly under the relevant structural property is what makes OAK incident framing operationally useful for defender threat-modelling, and the Loopring case is one of the cleanest 2024 anchors for this discipline in the smart-wallet sub-class.

For OAK's broader credibility, including Loopring 2024 in the worked-examples layer closes three gaps: it adds a 2024 worked example of the smart-wallet-recovery-flow attack surface that the current T13 sub-techniques do not cover at sub-technique granularity, it documents a structurally novel attack surface (the recovery flow itself) as a discrete defensive-design dimension, and it anchors the affected-cohort-size as realised-loss bound dimension for the smart-wallet-defect cohort in 2024.