Worked example · 2024-03

WOOFi Pro sPMM curve flash-loan manipulation — Arbitrum — 2024-03-05

Loss: approximately $8.5M extracted from WOOFi's sPMM (synthetic Proactive Market Maker) WOO/USDC pool on Arbitrum on 2024-03-05. WOOFi is a multi-chain DEX that prices its single-asset pools through a sPMM-style curve rather than a constant-product invariant; the curve takes an external oracle reference price and applies a configurable spread / inventory-skew adjustment to produce execution prices for incoming swaps. The drained pool was the Arbitrum WOO/USDC pair — the protocol's namesake-token pool, materially smaller in inventory than the protocol's BTC / ETH / stablecoin pools, and therefore the cohort-most-exposed pool to a curve-state manipulation that scales with the relationship between trade-size and inventory.
Recovery: none of material consequence on the on-chain layer. Proceeds were laundered through Tornado Cash within the days following the incident. WOOFi paused the affected sPMM pool on Arbitrum within roughly an hour of the on-chain attack window; the broader protocol on other chains was not directly affected by the same transaction sequence but was paused as a precaution.
OAK Techniques observed: OAK-T9.001 (Oracle / Price-Curve Manipulation) — primary, in the PMM-curve manipulation sub-class: the attacker manipulated the sPMM's internal curve-state (the inventory-driven adjustment to the external oracle reference) by flash-loaning a large WOO position into the pool and pushing the curve into a regime where subsequent swaps priced the WOO inventory at a discount that did not reflect the external reference. OAK-T9.002 (Flash-Loan-Enabled Exploit) as the working-capital precondition that scaled the per-swap mispricing into a multi-million-dollar single-transaction extraction. OAK-T7.001 (Mixer-Routed Hop — proceeds were laundered through Tornado Cash).
Attribution: pseudonymous. No public named-individual attribution. Pre-event funding routed through Tornado Cash; post-event laundering also routed through Tornado Cash. There is no public OAK-G01 / state-actor attribution for this incident.
Key teaching point: PMM-style curves are not flash-loan-resistant by virtue of consulting an external oracle if their internal inventory-skew adjustment can be moved by a single flash-loan-sized trade. The defender intuition that "this pool consults Chainlink so it's flash-loan-safe" is wrong for sPMM-style pools whose execution price is not the oracle reference but a function of the oracle reference and the pool's internal inventory state. The WOOFi Arbitrum case is the canonical 2024 worked example for the PMM-curve sub-class of T9.001 and the cleanest worked-example demonstration that AMM-curve manipulation and oracle-price manipulation are not the same attack surface — the WOOFi sPMM consulted its oracle correctly throughout the exploit window, but the curve's inventory-skew adjustment around the consulted reference was flash-loan-movable in the small-pool regime.

Summary

WOOFi is a DeFi DEX deployed across multiple EVM chains (BNB Chain, Arbitrum, Polygon, Avalanche, Optimism, others). Its core liquidity primitive is a synthetic Proactive Market Maker (sPMM) pool — a single-asset pool that prices incoming swaps via an external oracle reference combined with an inventory-driven spread / skew adjustment, rather than a constant-product invariant or a pure oracle quote. The design intent is to give LP-style yields on single-asset deposits while keeping execution close to fair market price for users.

On 2024-03-05 an attacker exploited the Arbitrum WOO/USDC sPMM pool by manipulating the curve's inventory-skew adjustment with a flash-loaned WOO position. The transaction sequence — per BlockSec, PeckShield, and WOOFi-team post-incident analysis — pushed the pool's WOO inventory state into a regime where the curve's internal spread / skew computation produced execution prices for subsequent attacker-driven sells at a discount that did not match the external oracle reference. Looped trade execution within the manipulated curve state extracted ~$8.5M from the pool before the curve auto-rebalanced and the attacker exited.

The proximate cause is the WOOFi sPMM pool-state code path being movable by a single flash-loan-sized trade, in the small-pool regime, at a magnitude that produced exploitable execution-price discrepancies between the curve output and the oracle reference. The economic root cause is that the sPMM curve's inventory-skew adjustment was parameterised for a normal-distribution-of-trade-sizes assumption that breaks down when an attacker can supply trade size in the same order of magnitude as the pool's full inventory in a single transaction — exactly the regime that flash-loan working capital makes available.

For OAK's purposes the case is a clean T9.001 PMM-curve-manipulation extraction with a T9.002 flash-loan working-capital precondition. The novel OAK contribution of the worked example is documenting the PMM-curve manipulation sub-class as distinct from the canonical thin-pool oracle-input manipulation sub-class (Inverse Finance 2022 at /examples/2022-04-inverse-finance.md) and from the canonical AMM constant-product manipulation sub-class (bZx 2020 at /examples/2020-02-bzx.md). PMM-style curves are increasingly common in DEX architectures (DODO, Hashflow, Native, others); the WOOFi case is the canonical 2024 evidence that the design's external-oracle-consultation does not by itself make the design flash-loan-resistant.

Timeline (UTC)

When	Event	OAK ref
Pre-event	WOOFi deploys sPMM pools across multiple EVM chains; Arbitrum WOO/USDC pool inventory reaches a state where flash-loan-sized trades can move the curve's internal skew adjustment materially	T9.001 surface (PMM-curve, latent)
Pre-event	Attacker funds wallet via Tornado Cash; analyses sPMM pool-state and identifies the inventory-skew sensitivity to flash-loan-sized WOO inputs	(off-OAK pre-event observation)
2024-03-05 (attack tx window, ~09:00 UTC)	Attacker opens flash loan; sells flash-loaned WOO into the WOOFi Arbitrum sPMM pool, pushing the inventory-skew adjustment into the manipulated regime; loops swap execution against the manipulated curve to extract value at oracle-divergent execution prices; repays flash loan; exits with ~$8.5M	T9.001 + T9.002 extraction
2024-03-05 (within hour)	On-chain monitoring (BlockSec PhalconHQ, PeckShield, others) flags anomalous flow; community signals propagate	(defender response / community detection)
2024-03-05 (within hour)	WOOFi operations team confirms the exploit; pauses the affected Arbitrum sPMM pool; pauses sPMM pools on other chains as a precaution	(operator response)
2024-03-05 onward	WOOFi publishes public acknowledgement; post-incident timeline and remediation plan circulated	(operator response / transparency)
2024-03-05 onward	BlockSec, PeckShield, SlowMist publish post-incident write-ups converging on the PMM-curve inventory-skew manipulation root cause	(transparency / cohort signal)
Days following	Attacker laundering routes proceeds through Tornado Cash	T7.001 (off this example's framing)
2024-03 onward	WOOFi re-parameterises the sPMM curve's inventory-skew bounds and adjusts pool deployment criteria to require a minimum-inventory threshold relative to flash-loan-available trade size; redeployment sequenced across chains	(operator response)
Continuing	No public recovery; no civil-forfeiture action	(recovery state)

What defenders observed

The bug shape was a curve-state manipulation, not an oracle-feed manipulation. The WOOFi sPMM consulted its external oracle correctly throughout the exploit window. The exploit moved the pool's internal inventory-skew state — the sPMM's spread adjustment around the consulted oracle reference — not the oracle reference itself. Defender threat models for PMM-style pools that focus only on oracle-feed integrity miss the curve-state surface; the canonical T9.001 framing for PMM pools needs to cover both. The contrast with Inverse Finance 2022 at /examples/2022-04-inverse-finance.md is instructive: Inverse Finance was a thin-pool oracle-input manipulation (the oracle-derivation Sushiswap pair was movable by flash-loan-sized trades), where the oracle output itself was wrong; WOOFi 2024 was a curve-state manipulation where the oracle output was correct but the pool's adjustment around the oracle output was movable.
Single-asset PMM pools concentrate inventory in ways that are flash-loan-relevant. A constant-product AMM with WOO/USDC liquidity has the full pool's USD value distributed across both sides of the pair; a sPMM single-asset WOO pool concentrates the protocol's WOO inventory on one side and consults the oracle for the USDC-equivalent. The relationship between flash-loan-available trade size and pool inventory is therefore higher in the sPMM single-asset configuration than in a comparable-TVL constant-product pool. Defender threat models for PMM-style pools should treat the inventory-to-flash-loan-capital ratio as a first-class parameter, not as an implicit consequence of pool TVL.
Small-token-namesake-pools are the highest-risk cohort within a multi-pool sPMM deployment. The WOOFi protocol operated sPMM pools for BTC, ETH, stablecoins, and the namesake WOO token across multiple chains. The protocol's BTC / ETH / stablecoin pools had inventory in dollar terms that exceeded any reachable flash-loan-sized trade by a comfortable margin; the WOO/USDC Arbitrum pool was the smallest pool and the highest-flash-loan-leverage cohort case. Defender monitoring within a multi-pool sPMM deployment should rank pools by inventory-to-flash-loan ratio and treat the smallest pools as the primary monitoring targets — exactly the cohort framing that the Hundred Finance / Midas Capital / Onyx cohort taught for Compound v2 forks at /examples/2024-09-onyx.md.
Detection latency was operator-acceptable but recovery latency was effectively infinite. WOOFi paused within roughly an hour of the on-chain attack window. By that time the funds were already moving toward Tornado Cash. The protocol-pause primitive on Arbitrum protects future drains but does not unwind completed extraction; once funds reach a public mixer in the same transaction window, on-chain recovery is structurally foreclosed — the same shape as Onyx 2024 at /examples/2024-09-onyx.md and most 2024 EVM exploit cases.
Cross-chain pool deployment is operationally relevant during incident response even when the exploit fires on one chain only. The same sPMM contract pattern was deployed across multiple chains; the operator response was to pause the pattern across chains as a precaution, not just on the affected chain. Worked examples for multi-chain protocol incidents should preserve the cross-chain pause-coverage dimension as a recurring operator-response feature.

What this example tells contributors writing future Technique pages

T9.001 covers PMM-curve manipulation as a distinct sub-class. WOOFi 2024 is the canonical 2024 worked example. The T9.001 technique page should include a "PMM-Curve Sub-Class" section distinguishing this surface from the thin-pool oracle-input manipulation sub-class (Inverse Finance 2022) and the AMM constant-product manipulation sub-class (bZx 2020 at /examples/2020-02-bzx.md). The three sub-classes share the precondition (T9.002 flash-loan working capital) but differ in the manipulation target (oracle-derivation pool input versus AMM curve invariant versus PMM curve internal-skew state).
External-oracle consultation does not by itself make a pricing primitive flash-loan-resistant. The WOOFi sPMM consulted Chainlink correctly throughout the exploit window. The defender heuristic "this contract uses Chainlink, so it's flash-loan-safe" is wrong when the contract's execution price is a non-trivial function of the oracle reference and pool internal state. Contributors writing the Mitigations layer for T9.001 should make this distinction explicit: oracle-feed integrity is a necessary but not sufficient condition for flash-loan resistance; pool-state movability under flash-loan-sized trades is a separate property that needs its own mitigation framing.
Inventory-to-flash-loan-capital ratio is a first-class threat-model parameter for single-asset PMM pools. Worked examples for single-asset PMM pools should report this ratio explicitly, not implicitly through pool TVL. The defender practice the WOOFi case suggests is monitoring this ratio as a continuous metric and treating the smallest pools in a multi-pool deployment as the highest-priority surveillance targets.
PMM-style DEX architectures (DODO, Hashflow, Native, WOOFi, others) are a discrete cohort for cohort-monitoring purposes. The empty-market rounding-error cohort framing at /examples/2024-09-onyx.md for Compound v2 forks generalises to PMM-style pricing primitives: the architectural pattern is shared across protocols, the curve-state-manipulation surface is shared, and the monitoring discipline that should apply is cohort-level. The WOOFi case is the canonical 2024 evidence; future T9.001 worked examples in this cohort should cross-reference WOOFi as the cohort-anchor 2024 case.
Pseudonymous attribution is the realistic attribution status for this class. Funding through Tornado Cash, laundering through Tornado Cash, no industry forensics provider has produced a named-individual claim. Contributors should not over-claim attribution simply because the on-chain forensics are detailed.

Public references

[woofipostmortem2024] — WOOFi protocol-side post-incident statement on the March 2024 Arbitrum sPMM exploit, including remediation timeline and cross-chain pause coverage.
[blocksecwoofi2024] — BlockSec PhalconHQ forensic analysis of the WOOFi Arbitrum exploit transaction trace including the flash-loan / sPMM curve-state manipulation breakdown.
[peckshieldwoofi2024] — PeckShield headline figures and on-chain analytics for the WOOFi 2024 Arbitrum drain (~$8.5M extracted).
[slowmistwoofi2024] — SlowMist incident analysis covering funding-source tracking and Tornado Cash laundering pattern.
[rektwoofi2024] — Rekt News public-facing summary framing the case as a sPMM curve-state manipulation.
[woofispmmdocs] — WOOFi protocol documentation on the sPMM design, oracle consultation, and inventory-skew adjustment mechanism.

Citations

[woofipostmortem2024] — Operator post-incident statement; primary source for affected-pool identification and operator timeline.
[blocksecwoofi2024] — Forensic transaction-trace analysis; primary technical source for the curve-state manipulation root cause.
[peckshieldwoofi2024] — Headline figures and on-chain analytics; primary source for cited $8.5M loss figure.
[slowmistwoofi2024] — Funding-source tracking and laundering pattern; primary source for pseudonymous attribution status.
[rektwoofi2024] — Public-facing summary; secondary source for cohort framing.
[woofispmmdocs] — sPMM design documentation; primary source for distinguishing curve-state manipulation from oracle-feed manipulation.

Discussion

WOOFi 2024 is OAK's canonical case for the PMM-curve manipulation sub-class of T9.001. The case sits at the intersection of an architectural pattern (single-asset PMM pools that consult external oracles but maintain internal inventory-skew adjustment) and a precondition Technique (T9.002 flash-loan working capital), with the attacker using the precondition to push the architectural pattern into a regime where the internal-skew adjustment produced exploitable execution-price discrepancies.

The cohort framing applies. PMM-style pricing primitives are a discrete architectural cohort: DODO, Hashflow, Native, WOOFi, and similar DEX designs share the structural property that execution price is a function of an external oracle reference and pool internal state. The shared property creates a shared threat surface — flash-loan-driven curve-state manipulation in the small-pool regime — and a shared mitigation surface (inventory-to-flash-loan-capital ratio bounds, curve-state-movement-rate limits, per-trade-size caps relative to pool inventory). The WOOFi case is the canonical 2024 evidence that the cohort-level monitoring discipline was not yet operational across the PMM cohort; whether subsequent improvements have closed the gap is a question for ongoing cohort surveillance.

The structural distinction between PMM-curve manipulation and thin-pool oracle-input manipulation is the analytically important feature. Inverse Finance 2022 at /examples/2022-04-inverse-finance.md was a thin-pool oracle-input case: the oracle-derivation Sushiswap pair was movable by flash-loan-sized trades, with the result that the oracle output itself was wrong during the exploit window. WOOFi 2024 was a curve-state manipulation case: the oracle output was correct throughout the exploit window, but the pool's adjustment around the correct oracle output was movable by flash-loan-sized trades. The defender mitigations for the two cases are not interchangeable; oracle-feed-integrity tooling does not address curve-state-movability surfaces. Worked examples and the T9.001 technique page should preserve the distinction explicitly.

For OAK's broader credibility, including WOOFi 2024 in v0.1 closes a gap: it adds a 2024 PMM-cohort worked example to a corpus that otherwise covers oracle-input manipulation (Inverse Finance) and AMM-curve manipulation (bZx, Cream Finance) without the PMM-curve sub-class. The case extends the T9.001 technique page coverage of pricing-primitive manipulation across the three principal architectural sub-classes used in 2020–2025-era DeFi.