Worked example · 2023-02

BonqDAO Tellor oracle manipulation — Polygon — 2023-02-01

Loss: approximately $120M nominal at-time. The realised economic loss to attackers and counterparties was substantially smaller — on the order of low-single-digit millions in tradeable value — because the inflated BEUR (BonqDAO's stablecoin) and the underlying WALBT (wrapped AllianceBlock token) collateral were both thinly traded. The attacker minted ~100M BEUR and seized ~113M WALBT against the manipulated price feed; the on-DEX liquidity available to convert either side into liquid assets was a fraction of the nominal figure. The ~$120M headline became the canonical citation in industry write-ups, but the OAK framing should keep the nominal-vs-realised distinction explicit: the on-chain accounting damage (insolvent troves, broken stablecoin peg, frozen collateral) and the realised attacker proceeds are different magnitudes for the same incident.
OAK Techniques observed: OAK-T9.001 (Oracle / Price-Feed Manipulation) as the extraction mechanism, executed against Tellor's optimistic-oracle dispute-window primitive used as the WALBT price feed; OAK-T9.002 (Flash-Loan-Enabled Exploit) as the working-capital precondition that funded the Tellor stake-and-report cycle and the trove-seizure cascade; OAK-T17.002 (Liquidation-Cascade Engineering) — the oracle-inflated WALBT price triggered mass trove liquidations, allowing the attacker to seize ~113M WALBT collateral at distressed valuations; the cascade dynamics converted a single oracle-manipulation event into multi-position collateral seizure across the BonqDAO trove set; OAK-T7.001 (Mixer-Routed Hop — proceeds were laundered through Tornado Cash).
Attribution: pseudonymous. No public named-individual attribution. Funding was routed through Tornado Cash; no industry forensics provider has converted the on-chain analysis into a named-individual claim, and there is no public OAK-G01 / state-actor attribution for this incident.
Key teaching point: optimistic oracles require adversarially-set dispute windows. Tellor's design is a stake-report-dispute primitive in which a reporter posts a price, a dispute window opens, and the price finalises if not disputed. BonqDAO consumed Tellor reports with the dispute-window setting Tellor recommends as the starting configuration — not the setting an adversarially-thinking protocol consuming an optimistic oracle for a thinly-traded collateral asset would have chosen. The structural OAK lesson is not "Tellor is unsafe" — Tellor's own documentation flags the configuration tradeoff — but that the consuming protocol owns the dispute-window-against-economic-loss-tolerance decision, and BonqDAO's chosen window was incompatible with the adversarial economics of WALBT as a low-liquidity collateral.

Summary

BonqDAO was a CDP-style stablecoin protocol on Polygon, modelled on Liquity, in which users locked collateral (including WALBT, the wrapped form of AllianceBlock's ALBT token) into individual troves to mint BEUR (a euro-pegged stablecoin). On 2023-02-01, an attacker exploited BonqDAO's consumption of the Tellor oracle as the WALBT price feed to manipulate the recorded WALBT price first upward (allowing a controlled trove to mint ~100M BEUR against modest WALBT collateral) and then downward (causing every other WALBT-collateralised trove on the protocol to enter the liquidatable range, allowing the attacker to seize ~113M WALBT at the manipulated price).

The proximate cause — per PeckShield, Halborn, BlockSec, and academic write-ups, all converging on the same root-cause description — was that BonqDAO consumed Tellor's reported WALBT price with a dispute window short enough that, given the economic incentives in play, an attacker could submit a manipulated report, wait out the window, and have BonqDAO accept the report as final. Tellor's reporter-stake at the time was approximately ten Tellor TRB tokens (~$1,500–$2,000 in market terms during the attack window); the attacker's expected profit from a successfully-finalised manipulated WALBT price report dwarfed the staked TRB at risk by orders of magnitude. The dispute window was operationally short relative to the response latency a non-monitoring third-party disputer would realistically achieve, and BonqDAO did not operate a first-party watchtower against its own oracle inputs.

For OAK's purposes the incident is a clean T9.001 (oracle / price-feed manipulation) extraction with a T9.002 (flash-loan) precondition. The novel OAK contribution of the worked example, beyond the bug class itself, is the optimistic-oracle-dispute-window-not-adversarially-set Mitigation discussion: a defender consuming an optimistic-oracle primitive for a thinly-traded collateral asset must size the dispute window against the economic-loss tolerance of the consuming protocol, not against the expected-honest-behaviour tolerance of the oracle's marketing posture. BonqDAO is the canonical 2023 worked example that this discipline was not yet operational across the optimistic-oracle-consuming layer of DeFi.

Timeline (UTC)

When	Event	OAK ref
Pre-event	BonqDAO deployed on Polygon consuming Tellor as WALBT price feed; dispute-window configuration accepted as Tellor-default rather than economically-sized to BonqDAO's collateral risk	T9.001 surface (latent configuration)
Pre-event (months)	WALBT trading liquidity remains thin across DEX venues; AllianceBlock-side market depth orders of magnitude below the BonqDAO-side notional collateralised	(latent precondition)
2023-02-01 (attack tx window 1)	Attacker stakes the required Tellor TRB and submits a manipulated upward WALBT price report; dispute window passes without successful dispute	T9.001 manipulation phase 1
2023-02-01 (attack tx window 1, continued)	Attacker's controlled trove now valued against the manipulated price; attacker mints ~100M BEUR against modest WALBT collateral	T9.001 extraction phase 1
2023-02-01 (attack tx window 2)	Attacker submits a second Tellor report driving the recorded WALBT price downward; window finalises	T9.001 manipulation phase 2
2023-02-01 (attack tx window 2, continued)	Every other WALBT-collateralised BonqDAO trove enters liquidatable range; attacker seizes ~113M WALBT via liquidation cascade	T9.001 extraction phase 2
2023-02-01 (within hours)	BonqDAO operations team detects the drain; pauses minting; communicates with Tellor team and Polygon chain operators	(operator response)
2023-02-01 onward	PeckShield, Halborn, BlockSec publish post-incident write-ups converging on the same Tellor-dispute-window root cause	(transparency / cohort signal)
Days following	Attacker laundering routes proceeds through Tornado Cash; realised proceeds materially smaller than nominal due to thin BEUR / WALBT liquidity	T7.001 (off this example's framing)
Continuing	No public recovery; no civil-forfeiture action	(recovery state)

What defenders observed

The attack is structurally a T9.001 oracle manipulation, not a Tellor-implementation bug. Tellor performed exactly as documented: a staked reporter submitted a price, the dispute window ran, and the price finalised. The vulnerability lived in BonqDAO's consumption configuration — specifically the chosen dispute-window length and the absence of a first-party watchtower over the BonqDAO-relevant Tellor query IDs. Defenders reviewing this incident should resist the framing "Tellor was hacked"; the structurally accurate framing is "BonqDAO consumed an optimistic oracle without sizing the dispute parameters to the economics of the consumed asset". This distinction is load-bearing for the Mitigations layer: an optimistic oracle is a configurable primitive, not a fixed-safety service, and the consuming protocol owns the configuration-against-economics decision.
The thin-liquidity dimension converted nominal damage into a smaller realised loss but did not retire the Technique. The ~$120M nominal vs. low-single-digit-millions realised gap is unusual and is partly an artifact of WALBT and BEUR both being thinly-traded assets. Defender lessons should not be modulated by this accident. A future T9.001 incident against an optimistic oracle consumed by a CDP protocol with a liquid collateral asset would convert the same configuration error into a realised loss closer to the nominal figure. The OAK Mitigation is the same in either world.
Flash-loaned working capital was the precondition that scaled the attack to its useful size. The Tellor stake-and-report cycle, the trove setup against the manipulated price, and the liquidation cascade against other troves are all capital-intensive operations. T9.002 is the precondition Technique that converts a per-unit oracle-manipulation profit into a single-transaction-window multi-million-dollar extraction. Defender monitoring focused only on the entry-vector Technique (T9.001 oracle manipulation) without the precondition (T9.002 flash-loan-enabled scaling) misses half the structure.
Detection latency was operator-acceptable but recovery latency was effectively infinite. BonqDAO paused minting within hours of the on-chain attack window. By that time the on-chain accounting damage was realised and the attacker had begun moving proceeds toward laundering venues. The protocol-pause primitive on Polygon protects future drains but does not unwind completed extraction; once the manipulated oracle reports have finalised in the consuming protocol's state, on-chain recovery is structurally foreclosed absent a chain-level intervention.
The attribution is pseudonymous and is the realistic attribution status for this class. Funding was routed through Tornado Cash pre-event; no industry forensics provider has converted the on-chain analysis into a named-individual claim. Contributors should not over-claim attribution simply because the on-chain forensics are detailed.

What this example tells contributors writing future Technique pages

T9.001 (Oracle / Price-Feed Manipulation) needs explicit sub-classification for optimistic-oracle dispute-window failures. Canonical T9.001 (Mango Markets 2022, the bZx-class incidents 2020) is "the consuming protocol used a low-liquidity DEX spot price as its oracle and the attacker moved that spot price". The BonqDAO case is a structurally distinct sub-class: the consuming protocol used a stake-and-dispute optimistic oracle, and the attacker exploited the dispute-window configuration rather than the price-source liquidity. Mechanistically these are different defensive baselines (TWAP-and-liquidity-floor sizing vs. dispute-window-and-watchtower sizing). T9.001 contributors should distinguish DEX-spot-price manipulation from optimistic-oracle-dispute-window manipulation explicitly, and link this worked example as the v0.1 reference for the latter sub-class.
The defender-side Mitigation for the optimistic-oracle sub-class is two-pronged. First, the configuration prong: dispute window must be sized against the economic-loss tolerance of the consuming protocol, not the documented-default of the oracle vendor. Second, the operations prong: the consuming protocol must operate (or contract) a first-party watchtower over the queries it consumes, with response latency well inside the dispute window. Either prong alone is insufficient: a long dispute window without a watchtower lets attackers wait out the window in low-monitoring conditions; a short dispute window without an adequate watchtower-response capability is the BonqDAO case. Mitigations contributors should treat both prongs as a single Mitigation entry rather than as independent items.
T9.002 is the precondition that makes per-unit oracle-manipulation profits useful at scale. The BonqDAO, Mango, and bZx worked examples all share the same precondition / extraction structure. Worked examples should preserve the distinction between the precondition Technique (T9.002 flash-loan working capital) and the extraction Technique (T9.001 oracle manipulation) rather than collapsing them.
Nominal-vs-realised loss reporting is a contributor discipline. The BonqDAO ~$120M nominal figure is the canonical industry-write-up number; the realised loss is materially smaller. Worked examples should report both and explain the gap, so that downstream readers (auditors, defenders, Mitigations contributors, journalists) do not over-anchor on whichever figure happens to be more rhetorically convenient.

Public references

[peckshieldbonq2023] — PeckShield post-incident analysis covering the Tellor-feed manipulation and the trove-seizure cascade.
[halbornbonq2023] — Halborn post-incident technical write-up of the BonqDAO Tellor exploit.
[blocksecbonq2023] — BlockSec forensic analysis of the BonqDAO attack including the flash-loan + Tellor stake-and-report transaction-trace breakdown.
[tellorbonq2023] — Tellor team post-incident statement clarifying the optimistic-oracle dispute-window configuration responsibility.
[bonqpostmortem2023] — BonqDAO operations-team post-incident statement on the affected troves and the operator timeline.
[zhou2023sok] — academic taxonomy classifying oracle manipulation as a primary DeFi vulnerability class.

Citations

[peckshieldbonq2023] — PeckShield BonqDAO write-up.
[halbornbonq2023] — Halborn BonqDAO post-mortem.
[blocksecbonq2023] — BlockSec BonqDAO forensic.
[tellorbonq2023] — Tellor team BonqDAO statement.
[bonqpostmortem2023] — BonqDAO operator post-mortem.
[zhou2023sok] — academic SoK classification.

Discussion

BonqDAO is OAK's canonical 2023 case for the optimistic-oracle dispute-window sub-class of T9.001, paired with Mango Markets (October 2022) as the historical precedent in the DEX-spot-price sub-class. The two together span the visible T9.001 sub-classes and illustrate the same end-state (the consuming protocol accepts an attacker-influenced price as authoritative) reached through structurally different defensive failures.

The configuration framing is the analytically important feature of this case. Tellor's design is well-documented; the dispute-window-vs-economic-loss tradeoff is explicit in the Tellor consumer documentation; the attack is reachable only when the consuming protocol selects a configuration that does not match the economics of its consumed asset. The teaching point is not that Tellor or BonqDAO made a coding mistake; it is that the threat model implicit in 2022–2023 DeFi optimistic-oracle consumption — "the oracle's documented defaults are safe enough" — was an unstated assumption, and that the consuming protocol, not the oracle vendor, owns the configuration-against-economics decision in every case where the consuming protocol's economic exposure exceeds the oracle's reporter-stake.

Two open questions remain for OAK v0.x. First, whether the optimistic-oracle-dispute-window sub-class warrants its own Technique ID under T9 (alongside DEX-spot-price manipulation) or whether the broad construction of T9.001 should suffice with sub-class footnoting in the Technique page. The author's lean is the latter for v0.1 with a v0.x revisit if more optimistic-oracle cases accumulate. Second, whether the realised-vs-nominal distinction (here ~$120M nominal vs. low-single-digit-millions realised) should be a contributor-disciplined reporting field across all worked examples or a free-form note. The author's lean is the former, on the grounds that the distinction repeats across the OAK corpus (Beanstalk, Wormhole-restoration, several rug-pulls) and is structurally informative about realised-attack-economics-vs-headline-figures.