Worked example · 2020-02
bZx Protocol flash-loan-funded exploits — Ethereum — 2020-02-15 and 2020-02-18
Summary
In a four-day window in February 2020, the bZx Protocol — a then-prominent Ethereum lending and margin-trading platform fronted by the Fulcrum interface — suffered two distinct flash-loan-funded exploits. The first incident, on 2020-02-15, drained approximately $350K by abusing bZx's collateralisation and position-opening logic during a flash-loan-funded margin trade routed through Kyber and Uniswap. The second incident, on 2020-02-18, drained approximately $650K by manipulating the price of Synthetix USD (sUSD) on Kyber and Uniswap — bZx's oracle inputs — to inflate the value of sUSD posted as collateral, then borrowing more ETH against the inflated collateral than would otherwise have been possible.
The combined loss is small. The historical significance is not. Pre-bZx, flash-loan-funded oracle manipulation existed primarily as a theoretical concern in academic literature and security-researcher Twitter; bZx demonstrated the attack class in production at scale, on a live protocol with real capital, twice in four days. Every modern T9.001 mitigation — TWAP-windowed oracles, multi-source price feeds, deviation circuit-breakers, single-block-action prohibitions — is downstream of these two incidents. bZx is to T9.001 what The DAO is to T9.005: the year-zero case that defined the technique class and shaped the mitigations the industry now treats as standard.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| 2020-02-15 | Incident #1: attacker takes flash loan (~10,000 ETH from dYdX), opens a 5x leveraged short position on bZx's Fulcrum interface against ETH/wBTC, routes the trade through Kyber to Uniswap, manipulating wBTC price upward on the thin Uniswap pool. The under-collateralised position and the price dislocation combine to leave bZx with an insolvent loan; attacker exits with ~$350K profit. | T9.002 precondition + collateral-logic / oracle-side flaw |
| 2020-02-15 (hours after) | bZx team uses admin keys to pause trading and borrowing, and patches the underlying logic. | (response) |
| 2020-02-18 03:13 (block 9,504,627) | Incident #2: attacker takes flash loan (~7,500 ETH from bZx itself in this case via the Fulcrum interface). Uses ~3,518 ETH to acquire sUSD from the Synthetix issuer at fair price; uses ~900 ETH on Kyber to bid sUSD's reported price up to ~$2 (versus $1 fair value) on bZx's Kyber-fed oracle; posts sUSD into bZx as collateral valued at the inflated oracle price; borrows ~6,796 ETH against the inflated collateral; repays the flash loan and exits with |
T9.001 oracle manipulation, T9.002 enabling precondition |
| 2020-02-18 (hours after) | bZx team again pauses, patches, and publishes post-mortem. Migrates oracle inputs off Kyber-singleton onto Chainlink price feeds. | (response) |
| 2020-02 to 2020-04 | Industry-wide post-mortem cycle. PeckShield, samczsun, and Quantstamp publish technical breakdowns. The "flash-loan attack" enters the standard DeFi-security vocabulary. | (industry response) |
| 2020 onward | TWAP-windowed oracles, multi-source feeds, deviation circuit-breakers, and Chainlink-style aggregator architectures become standard for new lending and margin protocols because of these two incidents. | (downstream standard) |
What defenders observed and learned
- Oracle-input concentration was the failure mode in incident #2. bZx's price feed for sUSD was a single Kyber pool. The pool had thin enough liquidity that ~900 ETH of buying pressure was sufficient to move the reported price to 2× fair value. The defender lesson is design-level: a price oracle whose input is a single venue with thin liquidity is a standing T9.001 surface from the moment it is deployed, regardless of whether anyone has yet attempted to exploit it. This is the lesson that produced the multi-source / TWAP / deviation-breaker design pattern.
- Flash loans collapsed the capital barrier. Pre-flash-loan, an oracle-manipulation attack on a Kyber pool would have required the attacker to risk their own ~$1M+ of capital across several blocks, with all the timing and front-running risk that implies. Flash loans made the same attack atomic, capital-free, and risk-free in execution: borrow, manipulate, exploit, repay, exit, all in a single transaction whose only cost is gas. This is why T9.002 is documented as a Technique in its own right rather than as a mere precondition — it changes the threat model for every protocol whose accounting is sensitive to single-block balances.
- Single-transaction call-trace shape was the unambiguous on-chain signal. Both bZx incidents fit in a single transaction each: flash-loan-borrow → price-manipulating swaps on the oracle's input venue → consume the manipulated price in the target protocol → flash-loan-repay. No live monitoring infrastructure was watching for this pattern in February 2020. Today, this exact fingerprint is what Forta, OpenZeppelin Defender, BlockSec PhalconHQ, and similar runtime-monitoring stacks treat as the baseline T9.002 / T9.001 detection signal.
- The patch-once-attacked posture is not a strategy. Between incident #1 and incident #2, bZx had four days, an active post-mortem, and admin keys with full pause authority. Incident #2 still occurred — exploiting a different but architecturally-related flaw in the same oracle layer. The defender lesson is that under-fixing a Technique class — patching the specific exploited path while leaving the broader Technique surface live — is a recurring failure mode, not a one-off mistake. T9.001 surface remediation requires reasoning about the class, not the specific transaction.
What this example tells contributors writing future Technique pages
- Small-loss cases can be high-leverage teaching cases. The bZx losses are dwarfed by Mango Markets 2022 (
$110M), KuCoin 2020 ($280M), and most other worked examples in this repository. Loss magnitude is not what determines historical significance. bZx is the foundational T9.001 + T9.002 case because it (a) was the first production demonstration of the attack class at scale, (b) directly produced the oracle-resilience design pattern that the industry now treats as baseline, and (c) set the vocabulary ("flash loan attack") that the security community now uses. Technique pages should explicitly identify the historical anchor for their class — where applicable — and not optimise the choice of foundational case purely on dollar terms. - Foundational cases and modern canonical cases are different roles. bZx is the foundational T9.001 case; Mango Markets 2022 is the modern canonical T9.001 case. The two roles complement each other and are not interchangeable. The foundational case explains why the mitigation pattern exists; the modern canonical case demonstrates what happens when the pattern is not honoured in current practice. Technique pages benefit from naming both.
- Use the "flash-loan-funded oracle manipulation" framing where applicable. The chained T9.001 + T9.002 framing is more accurate for bZx-class incidents than either Technique alone. Contributors writing examples that involve thin-liquidity oracle inputs and atomic capital from a flash loan should default to this combined framing and document both Techniques explicitly, even when one of the two appears to dominate the loss attribution.
- Preserve the historical-anchor framing. The DAO worked example (
/Users/dmytro.chystiakov/Projects/oak/examples/2016-06-the-dao.md) sets the template for "year-zero" cases: explain what the case introduced, what current practice inherits from it, and what was unavailable to defenders at the time. bZx fits this template. Contributors writing other foundational-case pages should follow the same structure.
Public references
- PeckShield. bZx Hack II Full Disclosure (With Detailed Profit Analysis). 2020-02-18 —
[peckshieldbzx2020]. The canonical contemporaneous technical breakdown of incident #2; the source most subsequent retrospectives cite for the transaction-level mechanics. - samczsun. Taking undercollateralized loans for fun and for profit. 2020-02 —
[samczsunbzx2020]. Independent technical analysis of incident #1; the canonical security-researcher framing of bZx's collateralisation-logic flaw. - bZx team. Post-mortem of the February 2020 bZx incidents. 2020-02 —
[bzxpostmortem2020]. The protocol's own contemporaneous statement and disclosure of the migration to Chainlink price feeds. - CoinDesk. DeFi Project bZx Exploited for Second Time in a Week, Loses $630K in Ether. 2020-02-18 —
[coindeskbzx2020]. Contemporaneous mainstream-press reporting; useful for the industry-reaction framing. - Quantstamp. Market Dynamics of the 1st bZx Hack: Flash Loans and the Insolvent Loan. 2020-02 —
[quantstampbzx2020]. Audit-firm framing of incident #1's market-microstructure mechanics. - Zhou, L. et al. SoK: Decentralized Finance (DeFi) Attacks. IEEE S&P 2023 —
[zhou2023sok]. Modern academic taxonomy; places bZx as the foundational case in the flash-loan-funded oracle-manipulation class.
Discussion
The bZx incidents are unusual among OAK foundational cases in that they were not catastrophic. The DAO lost ~$60M and forced a chain split. Mt. Gox and the major exchange compromises lost hundreds of millions. The bZx incidents lost ~$1M combined — small enough that the protocol survived and continued operating for years afterwards. This makes the case instructive precisely because the industry response — not the loss number — was disproportionate to the immediate damage. The security community recognised in real time that the failure mode mattered far more than the dollar loss, and responded accordingly: technical post-mortems within days, design-pattern proposals within weeks, widespread adoption of TWAP / multi-source / deviation-breaker oracles within months.
The post-bZx oracle-resilience design pattern is now the de-facto standard for any lending or margin protocol that consumes a price oracle. Chainlink's aggregator architecture, Uniswap V2's TWAP oracles, MakerDAO's Oracle Security Module, and the Pyth / Switchboard pull-oracle architectures on Solana are all downstream artefacts of the lessons bZx exposed. When a protocol does not honour this pattern, the result is a recurrence of the same failure mode in a new context — Mango Markets 2022 (/Users/dmytro.chystiakov/Projects/oak/examples/2022-10-mango-markets.md) is the clearest modern demonstration: a Solana-based protocol whose MNGO oracle took its inputs from a small set of venues without TWAP windows, deviation circuit-breakers, or wider-liquidity reference checks. The Mango oracle architecture in 2022 was, in defender terms, structurally equivalent to bZx's sUSD oracle in 2020, scaled up by two orders of magnitude in TVL. The mitigation pattern existed; it had not been honoured.
The lineage matters because OAK is a defender-perspective framework. From a defender's perspective, the question is not "what new attack technique might emerge?" — it is "where in the deployed system have we failed to honour the mitigation pattern that prior incidents produced?" bZx is the case that established the pattern. Subsequent T9.001 incidents are, almost without exception, cases where the pattern existed but was not applied. Contributors writing T9.001 worked examples should preserve this framing: name what the protocol failed to inherit from bZx, rather than treating each case as a novel attack.
A final note on attribution. Both bZx attackers remain pseudonymous as of this writing. There is no judicial record, no public self-identification, and no forensic identification that has held up to scrutiny. OAK takes the position that absent such evidence, the attribution field should remain "pseudonymous" and the discussion should focus on the behaviour and the failure mode — both of which are firmly on the public record — rather than on speculation about identity. This convention follows The DAO's treatment in OAK and should be the default for unattributed historical cases.