Iron Finance (IRON / TITAN) — Polygon — collapse 2021-06-16

Summary

Iron Finance was a Polygon-deployed (initially Binance Smart Chain) algorithmic-stablecoin protocol whose IRON token was a fractionally-collateralised stablecoin redeemable for a fixed-ratio basket of 75% USDC and 25% TITAN, the protocol's governance / share token. The redemption mechanic was the central piece of the failure: redeeming $1 of IRON returned $0.75 of USDC plus $0.25 of newly-minted TITAN at the prevailing TITAN oracle price. Under normal conditions, the redemption mechanic enforced the IRON $1 peg through arbitrage; under stress, it produced a feedback loop in which falling TITAN price caused redemption-induced TITAN minting, which caused further TITAN selling pressure, which caused further TITAN price decline, which caused further redemption-induced TITAN minting. This is the canonical algorithmic-stablecoin death-spiral structure.

In the week leading up to 2021-06-16, TITAN appreciated from approximately $10 to approximately $64, driven primarily by very high yield-farming rewards on TITAN-denominated vaults and amplified by Mark Cuban's publicly disclosed position. On 2021-06-16, around 10:00 UTC, larger TITAN holders began removing liquidity from the IRON/USDC pool, selling TITAN into the IRON redemption mechanic, and selling the resulting IRON directly to USDC. This caused IRON to depeg below $1 (initially to ~$0.90), which made the redemption arbitrage permanently profitable in one direction: buy IRON cheap on the open market, redeem for USDC plus newly-minted TITAN, dump the TITAN. The death spiral ran for roughly the next 24 hours. TITAN's total supply expanded from approximately 1 billion to approximately 35 trillion through redemption-driven minting, diluting any remaining value to effectively zero. Iron Finance halted minting and redemptions and published its post-mortem on 2021-06-17.

For OAK's purposes, Iron Finance is the canonical worked example of an economic-design failure under adversarial market conditions, a class that OAK v0.1 does not catalogue at the Technique level. The case is also the direct structural precursor to the Terra/LUNA collapse of May 2022, which was a much larger version of the same death-spiral pattern operating on a much larger algorithmic-stablecoin design (UST / LUNA on the Terra L1).

Timeline (UTC unless noted)

When	Event	OAK ref
2021 Q1–Q2	Iron Finance launches on Binance Smart Chain, then expands to Polygon in May 2021 with the IRON / TITAN fractional-stablecoin design (75% USDC + 25% TITAN backing)	(protocol design — no OAK Technique applies)
2021-05 to 2021-06	TITAN-denominated yield-farming vaults rapidly accumulate >$2B TVL; TITAN appreciates from ~$10 to ~$64 over the week ending 2021-06-16	(market-wide accumulation — no OAK Technique applies)
2021-06-16 ~10:00	Larger holders begin removing IRON/USDC LP positions, selling TITAN into the redemption mechanic, and selling resulting IRON to USDC. IRON depegs from $1 to approximately $0.90	T2.001 framing (broadly construed; market-wide pool depth failure)
2021-06-16 ~10:00–12:00	TITAN falls from intraday high of ~$64–65 to ~$30 in approximately two hours; partial recovery to ~$52 within the same window as buyers attempt to defend the position	(death-spiral ignition)
2021-06-16 afternoon	IRON's depeg becomes self-reinforcing: arbitrage path "buy IRON for ~$0.90, redeem for $0.75 USDC plus $0.25 newly-minted TITAN, dump TITAN" runs continuously, producing redemption-driven TITAN supply expansion and corresponding price collapse	(death-spiral primary phase)
2021-06-16 evening – 2021-06-17 morning	TITAN supply expands from ~1B to ~35T through the redemption-mint loop; TITAN price collapses to sub-cent levels and ultimately to effectively zero	(death-spiral terminal phase)
2021-06-17	Iron Finance halts minting and redemptions; publishes post-mortem characterising the event as "the world's first large-scale crypto bank run"; protocol TVL has fallen from >$2B to approximately $356M	(operator response / post-mortem)
2021-06-17	Mark Cuban gives Bloomberg comment acknowledging his LP position in the IRON/USDC QuickSwap pool, blames himself for "being lazy" on the math, calls for stablecoin regulation	(third-party LP comment)
2022-05	Terra/LUNA UST depeg and death-spiral collapse — same class of failure at substantially larger scale (>$40B in evaporated value)	(lineage event — same Technique class)
2022-06	U.S. Federal Reserve publishes "Runs on Algorithmic Stablecoins: Evidence from Iron, Titan, and Steel" (FEDS Notes), explicitly citing Iron Finance as the foundational case for the algorithmic-stablecoin run literature	(academic / regulatory codification)

What defenders observed

• There was no attacker, no exploit transaction, and no operator action to monitor. The failure was a continuous, market-wide redemption cascade running through the public mint / redeem interface that the protocol exposed to all addresses on equal terms. Defender risk teams who instrument only operator-controlled actions (multisig calls, admin-key calls, governance-proposal execution) would have seen nothing. The lead indicators were market-structure indicators: IRON's price drift below $1, the rate of TITAN minting through the redemption interface, and the ratio of TITAN/USDC pool depth to outstanding IRON supply.
• The pool-depth-versus-redemption-pressure ratio was the load-bearing risk metric. OAK's Technique catalogue does not currently treat market-wide pool depth as a first-class defender-side metric (T2.001 treats operator-controlled pool depth as a planted-condition signal, which is structurally different). For Iron Finance and the algorithmic-stablecoin class generally, a defender model needs an instrument that asks: "if the largest 1–2% of holders attempt to exit in a single block, what is the implied price impact?" That metric is absent from OAK v0.1's Detection guidance and is a known gap.
• The redemption mechanic itself is the failure surface; the smart-contract code did exactly what it was designed to do. Iron Finance's published post-mortem and the subsequent Omniscia post-mortem analysis both note that the contracts were not exploited in the conventional sense — there was no reentrancy, no oracle manipulation outside of the protocol's own oracle being used in its designed role, no signature replay, no logic bug. The economic design's response to a stressed input distribution was the failure. This is qualitatively different from every other case currently in the OAK examples corpus.
• Pre-collapse warnings from the protocol team are part of the public record. Iron Finance's documentation explicitly described the protocol as a fractional-reserve stablecoin and noted that, like a fractional-reserve bank, it could fail under a sufficiently large redemption run. The post-mortem explicitly references this prior disclosure. From a defender perspective, this is unusual: in most OAK cases the operator does not pre-disclose the exact failure mode that materialises. Here, the failure mode was disclosed in advance, and the lesson is about defender-side assessment of disclosed but underweighted risks rather than about operator-side concealment.

What this example tells contributors writing future Technique pages

• Economic-design failure under adversarial market conditions is a structural gap in OAK v0.1. OAK's Techniques are organised around on-chain attack primitives — exploit families, custody-and-signing surfaces, laundering rails, operator-controlled extraction patterns. Iron Finance has none of these. The failure surface is the protocol's redemption mechanic operating under a stressed-but-permissionless input distribution, and the closest fit in OAK v0.1 — T2.001 (Single-Sided Liquidity Plant) — captures only the surface-level "pool depth was insufficient" observation, not the structural feedback loop that drove the cascade. A future v0.x update should consider whether OAK's scope extends to economic-design-failure modes (algorithmic-stablecoin death spirals; cascading-liquidation events such as the March 12, 2020 ETH price-discovery failure on MakerDAO; oracle-driven leverage-cascade liquidations). If so, a new Tactic / Technique family is likely required, because retrofitting these cases under T2.001 (Single-Sided Liquidity Plant) or T5.005 (Treasury-Management Exit) is a poor structural fit and obscures the actual defender-relevant signal.
• The Iron Finance case is the foundational precursor to Terra/LUNA. Contributors writing the eventual Terra/LUNA worked example should reference this entry directly, because the failure mechanic is the same class, only at substantially larger scale and with substantially larger systemic spillover. The lineage is on the public record (the U.S. Federal Reserve's June 2022 FEDS Notes paper "Runs on Algorithmic Stablecoins: Evidence from Iron, Titan, and Steel" was published explicitly to draw the connecting line between the Iron / Titan / Steel cases and the broader algorithmic-stablecoin run literature, and predates the Terra/LUNA event by less than a month). Treating Iron Finance and Terra/LUNA as separate one-off events rather than as instances of a shared class is the documentation pattern that OAK should specifically avoid.
• Defender-relevant signals for this class are market-structure signals, not on-chain-primitive signals. The lead indicators in the Iron Finance event were stablecoin peg drift, redemption-interface throughput, and pool-depth-versus-redemption-pressure ratio. None of these are first-class artefacts in OAK v0.1's Detection guidance, which is dominated by transaction-level primitives (mempool ordering, opcode patterns, address-graph features). A future Technique page in this class will need to point to market-structure instrumentation (DEX-pool TVL telemetry, oracle-feed monitoring, redemption-throughput dashboards) as the load-bearing detection surface.

Public references

• [ironfinancepostmortem2021] — Iron Finance's own 2021-06-17 post-mortem characterising the event as "the world's first large-scale crypto bank run."
• [omnisciatitanpostmortem2021] — Omniscia's independent technical post-mortem of the IRON / TITAN redemption mechanic and the death-spiral feedback loop.
• [finematicsironfinance2021] — Finematics's plain-language reconstruction of the bank-run mechanics and the redemption-arbitrage feedback loop.
• [fedsnotesalgostablecoinruns2022] — U.S. Federal Reserve FEDS Notes (June 2022), "Runs on Algorithmic Stablecoins: Evidence from Iron, Titan, and Steel," the canonical academic / regulatory codification of the run dynamics that includes Iron Finance as a primary case.
• [saengchotedefibankrun2021] — Kanis Saengchote, "A DeFi Bank Run: Iron Finance, IRON Stablecoin, and the Fall of TITAN" (SSRN), the standalone academic treatment of the case.
• [coindeskironfinancebankrun2021] — CoinDesk reporting on the post-mortem and the "first large-scale bank run" framing.
• [wakeforestbuilttofail2021] — Wake Forest Law Review, "Built to Fail: The Inherent Fragility of Algorithmic Stablecoins," which uses Iron Finance as a foundational case in its argument about algorithmic-stablecoin design.
• [chainalysis2025rug] for cumulative cohort context, with the explicit note that this case is not a rug pull and is structurally distinct from the rug-pull cohort.

Discussion

Iron Finance is the earliest large-scale instance of an algorithmic-stablecoin death spiral running to completion in the public on-chain record, and it is structurally distinct from every other case currently in the OAK corpus along three axes worth naming.

First, the absence of an attacker is load-bearing. Every other worked example currently in examples/ involves either an operator-side action (rug pull, treasury exit, multisig misuse) or an external attacker (exploit, signature replay, bridge bug, social engineering). Iron Finance has neither. The redemption mechanic was permissionless and operated as designed; the input distribution that drove the cascade was the aggregate behaviour of unrelated holders responding rationally to a depegged stablecoin. There is no party against whom enforcement action makes sense, no laundering chain to reconstruct, no recovery to negotiate. OAK's current Tactic / Technique structure assumes an adversarial actor at the centre of the case, and Iron Finance is the cleanest demonstration in the corpus that this assumption does not always hold.

Second, the economic-design failure class is a real and recurring pattern that OAK v0.1 does not catalogue. The class includes at minimum: algorithmic-stablecoin death spirals (Iron Finance 2021; Terra/LUNA 2022; the bUSD / IRON / TITAN / STEEL cohort the FEDS Notes paper documents); cascading-liquidation events on lending protocols when oracle-derived collateral values move faster than liquidation throughput (March 12, 2020 on MakerDAO is the canonical instance, with multiple similar but smaller events through 2021–2024); leverage-cascade liquidations on perps venues during oracle de-syncs. These cases share a structural property that OAK should name: the protocol's contracts perform exactly the operations they were designed to perform, the failure is in the economic-design response to a stressed input distribution, and the loss accrues to honest market participants rather than to identifiable victims of an identifiable attacker. A v0.x consideration is whether to introduce a new Tactic family — provisional name "Economic-Design Failure Under Adversarial Market Conditions," or similar — with sub-Techniques covering algorithmic-stablecoin death spirals, oracle-cascading-liquidations, and leverage-cascade liquidations. The alternative, which is the convention this worked example uses, is to cite T2.001 broadly construed and flag the gap; that convention is structurally unsatisfactory and should be revisited.

Third, the lineage to Terra/LUNA is direct and worth documenting at the framework level rather than only at the per-case level. The Iron Finance failure mechanic — fractional algorithmic backing, redemption-driven minting of the share token, feedback loop between share-token price and stablecoin peg — is the same mechanic that ran inside the Terra/LUNA UST / LUNA design eleven months later, only with a substantially larger total value at risk and substantially larger systemic spillover into centralised lenders (Celsius, Voyager, Three Arrows Capital) that held UST or LUNA-derivative exposure. The U.S. Federal Reserve's FEDS Notes paper of June 2022 cites Iron Finance as the foundational case for the run literature; the academic and regulatory codification of the connecting line between the cases predates the OAK framework and should be reflected in OAK's eventual Technique-level treatment of the class. Contributors writing the Terra/LUNA worked example should treat it as the second instance of the class for which this entry is the first instance, not as a separate one-off event.