Loss: about $13.4M, with roughly 17.25M DEI borrowed against manipulated collateral pricing and about 5,446 ETH later bridged out as realized proceeds
Summary: Six weeks after DEUS DAO’s first DEI lending oracle incident, the protocol replaced its direct onchain oracle with a custom Muon offchain VWAP app that still trusted the same Solidly USDC/DEI market. DEUS’s own later writeup described the vulnerable Muon app as Solidly_permissionless_oracle. The attacker discovered that this app parsed swap data too naively: by using a special swap shape with crafted call data and non-zero in/out fields on both token sides, they could make the app treat a complex swap as if it were a simple amount0In / amount1Out trade and report a price near 20 instead of 1. Four minutes later, they launched the main exploit, flash-borrowed 143.2M USDC, pumped the same USDC/DEI pool onchain, posted only 71,436 DEI as collateral, and borrowed 17,246,885 DEI from the lending contract. The preserved lesson is sharper than generic oracle manipulation: DEUS upgraded from a directly manipulable pool oracle to bespoke oracle middleware that still depended on one manipulable venue, still lacked source independence, and still misread attacker-shaped trade data.
Trigger / entry point:
The DEI lending system used a custom Muon VWAP oracle app built around transactions in the Solidly USDC/DEI pool; DEUS later referred to the app as Solidly_permissionless_oracle.
That Muon app inferred price from swap fields in a way that assumed a simple swap shape and did not correctly filter or normalize unusual swap call patterns, flash-swap-like flows, or swaps carrying attacker-meaningful call data.
DEUS’s own exploit notice says the vulnerable app could be tricked by call data and abstract swap structure, causing the oracle to misread a complex swap as a legitimate VWAP input.
The lending flow still performed an onchain price-sensitive check against the same USDC/DEI market family, so the attacker could prepare both the offchain VWAP and the onchain execution environment around one thin reference pool.
DEUS had already learned from the March 2022 incident that this lending product was oracle-fragile, but the replacement oracle still let one venue define solvency.
Root cause:
DEUS treated a custom, not-yet-battle-tested Muon VWAP app as if it were a robust oracle upgrade, even though it still depended on a single manipulable Solidly pool.
The Muon app’s swap parser trusted attacker-shapeable call data and abstract swap structure strongly enough that non-standard swaps with non-zero values on both token sides could be misclassified as clean price observations.
The protocol also kept an onchain price-sensitive path tied to the same USDC/DEI market, so bypassing the new oracle did not require defeating an economically independent backstop.
The deeper design failure was migration without independence: DEUS changed the oracle software layer but did not change the economic truth root. One local pool still defined solvency for both the offchain VWAP and the onchain borrow gate.
Exploit path:
The attacker prepared capital on Ethereum, moved roughly 800 ETH through Tornado Cash and Multichain, and staged the final attack from Fantom address 0x701428525cbac59dae7af833f19d9c3aaa2a37cb.
They spent days probing the offchain oracle behavior and, on 2022-04-28 02:36 UTC, executed transaction 0x8589e136e6ad927096d07baa16852d16f11456c0446efb8f1ecd467ce0d4cb10 to spoof the Muon VWAP input.
According to DEUS’s post-incident writeup, the crafted swap used call data plus non-zero amount0In, amount1In, amount0Out, and amount1Out fields so the Muon app read the trade as 2035723 / 100010, roughly 20, instead of a price near parity.
About four minutes later, in main attack transaction 0x39825ff84b44d9c9983b4cff464d4746d1ae5432977b9a65a92ab47edac9c9b5, the attacker flash-loaned 143,200,000 USDC.
They swapped that USDC into about 9,547,716 DEI through the Solidly sAMM-USDC/DEI_USDC_DEI pool, making DEI appear much more expensive in the same market family used by the lending system.
With the Muon VWAP already poisoned and the onchain pool simultaneously distorted, the attacker posted only 71,436 DEI as collateral and borrowed 17,246,885 DEI from the DEI lender.
After repaying the flash liquidity, the attacker bridged value out and ultimately routed the proceeds toward Ethereum and Tornado Cash, with public reporting tracking about 5,446 ETH leaving Fantom.
What the attacker needed to be true:
The Muon VWAP app had to trust one Solidly market and parse its swap data incorrectly enough that crafted call data produced a false VWAP observation.
The lending system had to honor the Muon price quickly enough that a spoof transaction four minutes earlier still shaped collateral value during the borrow.
The protocol’s onchain protection path had to depend on the same underlying USDC/DEI venue, so a large flash-loan swap could make both oracle layers agree on a false price.
Borrow limits and collateral policy had to let a temporary DEI overvaluation unlock protocol-scale borrowing.
Technical anatomy worth remembering:
This was a useful oracle upgrade that still trusted the same bad market failure. DEUS did not fully solve the March oracle problem; it changed the software layer reading the same venue.
The Muon-side issue was not generic VWAP is bad; it was a parser / filtering failure where obscure swap structure and call data were treated as legitimate price input. DEUS’s own remediation language later described the fix as filtering swaps that used call data and abstract swap structure in Solidly_permissionless_oracle.
The exploit only paid because the offchain oracle and the onchain price check were not economically independent. One attacker-controlled pool state could satisfy both.
Unlike BonqDAO, the attacker did not simply publish the oracle value directly. Unlike Moola or Inverse, they did not only drag a thin market. They first corrupted how the oracle interpreted swap flow, then used a flash-loan pool distortion to make the protocol honor the bad interpretation.
The response hints at the normative lesson too: DEUS immediately moved toward reserve-based pricing, abnormal-request filtering, one-signature-per-wallet restrictions, and per-wallet cooldowns, which is a tacit admission that the first Muon rollout had granted too much immediate authority to one fragile price path.
The incident is worth preserving as a warning about bespoke oracle middleware: moving price formation offchain does not help if the offchain app still consumes one manipulable venue, lacks battle-tested parsing rules, and enters production without a real migration quarantine.
Main exploit transaction: 0x39825ff84b44d9c9983b4cff464d4746d1ae5432977b9a65a92ab47edac9c9b5
Attacker address on Fantom: 0x701428525cbac59dae7af833f19d9c3aaa2a37cb
Prior March exploit transaction that motivated the oracle redesign: 0xe374495036fac18aa5b1a497a17e70f256c4d3d416dd1408c026f3f5c70a3a9c
Affected DEI lending contract highlighted in incident reporting: 0xec1fc57249cea005fc16b2980470504806fca20d
Manipulated venue family: Solidly / Solidex USDC/DEI pool on Fantom
Response / mitigation:
DEUS halted DEI lending, restored the peg, and said user funds would be covered from protocol and team-controlled resources.
In DEUS’s own exploit notice, the immediate fixes were: price calculation based on reserves, filtering abnormal requests, blocking reuse of one Muon signature by the same wallet, and adding a cooldown between borrow and redeem actions for each wallet.
The team also said it would aggregate across multiple DEX sources, add global and per-wallet limits, and keep hardening the Muon app’s swap filtering around call-data-bearing and abstract swap structures.
The enduring lesson is oracle independence plus migration discipline: if an upgrade still lets one local pool define solvency, adding offchain middleware mostly adds complexity, not safety.
Three oracle-migration authority promotions this incident collapsed
1. An attacker-shaped Solidly swap artifact could still be authored inside the one venue DEUS trusted
The first true fact in the system was only that the attacker could still produce a weird but onchain-real swap-shaped event in the Solidly USDC/DEI market family.
DEUS’s own April 28 writeup preserved the precise parser hazard: the vulnerable Muon app could be fooled by call data and abstract swap structure, including swaps where both token sides showed non-zero in/out fields.
At that stage nothing should have implied safe collateral truth; it only meant one local venue now contains an attacker-shaped trade artifact that the oracle app might inspect.
2. The Muon Solidly_permissionless_oracle still promoted that artifact into canonical collateral truth
The decisive second promotion sat in DEUS’s custom offchain app, not merely in Solidly’s pool mechanics. The Muon oracle still interpreted that strange swap as a clean price observation and published roughly 2035723 / 100010, near 20, instead of a price near parity.
DEUS’s own remediation note implicitly confirmed the boundary failure by describing the fix as filtering swaps using call data and abstract swap structure, which means the exploitable question was not only can the market move? but what exact swap object does the oracle admit as a legitimate observation at all?
This is the reusable split worth preserving: an attacker-shaped trade artifact exists and that artifact now counts as canonical VWAP truth for lending were different promotions, but DEUS collapsed them into one parser decision.
3. That published truth still inherited immediate DEI borrow authority even though the onchain guard shared the same truth root
DEUS did not merely record the spoofed Muon answer for monitoring. Four minutes after the oracle-spoof transaction, the attacker could pair it with a large flash-loan distortion in the same USDC/DEI market family, post only 71,436 DEI as collateral, and borrow 17,246,885 DEI.
The important blast-radius detail is that the supposed defense-in-depth path was not economically independent: DEUS’s own summary and later reporting both make clear the onchain price-sensitive check still lived in the same local market family the Muon oracle watched.
That left the full unhealthy ladder intact: one venue can emit a strange swap object, the bespoke oracle still upgrades it into solvency truth, and that published truth still deserves protocol-scale borrow authority immediately after migration. The exploit worked because DEUS treated those as one continuous authority story.
DEUS migrated away from a directly manipulable pool oracle, but the new Muon Solidly_permissionless_oracle still let one Solidly USDC/DEI market family define collateral truth for both the offchain VWAP and the onchain borrow gate
The decisive upstream bug was not only thin market moved; it was bespoke oracle middleware misparsed attacker-shaped swap structure and call data, so a specially formed trade became a false high-confidence price observation
The lending product then treated that freshly published Muon answer as immediate balance-sheet authority, with no real migration quarantine, source-independence requirement, or local clamp that would stop one new reading from unlocking protocol-scale DEI borrowing
The exploit therefore joined three failure surfaces that should have stayed separate: oracle parsing, oracle-source independence, and post-migration borrow authority
Why the exploit worked
DEUS’s April oracle redesign changed software layers without changing economic truth roots. The protocol no longer read one pool directly onchain, but its custom Muon VWAP app still treated one Solidly USDC/DEI market family as the decisive source of price truth, so the new stack preserved the same single-venue fragility behind a more complicated interface.
The Muon app also trusted the wrong object as a valid market observation. DEUS’s own post-incident writeup says the vulnerable Solidly_permissionless_oracle could be fooled by call data and abstract swap structure; a crafted swap with non-zero in/out fields on both token sides was misread as a simple directional trade and published a price near 20 instead of near parity. The important lesson is not just VWAP can be manipulated, but the parser deciding what counts as a trade is itself an oracle-authentication boundary.
The exploit then paid because DEUS still kept an onchain price-sensitive check tied to the same underlying market family. Once the attacker poisoned the Muon reading and then flash-loan-distorted the live Solidly pool, the offchain oracle path and the onchain execution path agreed on the same lie. The protocol had complexity, but not independence.
Borrow authority was granted too quickly and too completely. A spoof transaction only minutes earlier was enough to make 71,436 DEI look like sufficient collateral for 17,246,885 DEI of new borrowing. There was no migration-time quarantine, no local issuance brake sized for a fresh oracle path, and no second trust root that had to concur before protocol-scale lending resumed.
The monetization path was straightforward once those conditions held. The attacker did not need to break lending math after the price landed; normal collateral posting, borrowing, flash-loan repayment, and later bridge-out flow were enough. DEUS had turned one fragile oracle interpretation into immediate spendable balance-sheet authority.
Detection and audit pivots
When reviewing bespoke oracle middleware, inspect the parser as aggressively as the data source. What exact swap shapes, router paths, callback fields, or calldata-bearing variants are admitted as price observations, and which malformed or composite trades still look valid to the oracle app?
Write down the real economic independence inventory, not only the software-component diagram. If the offchain VWAP, fallback check, and onchain guard all ultimately depend on the same local pool or same route family, the protocol still has one truth root no matter how many boxes appear in the architecture.
Compare how much value one fresh oracle observation can unlock against the local brakes on the lending side. If a reading that is only minutes old can authorize protocol-scale borrowing with no quarantine, the protocol is operationally over-trusting that oracle path.
Revisit rushed oracle migrations as if they were new listings. DEUS had already suffered a March oracle incident; the April replacement should have been reviewed under fresh path, fresh parser, fresh authority assumptions rather than treated as a routine patch.
Trace the full monetization chain, not only the oracle bug: crafted swap -> Muon publication -> onchain pool repricing -> collateral post -> borrow -> exit liquidity -> bridge-out. If every link can execute inside one attack window, the oracle path is already too close to reserve outflow.
Failure-prevention checklist
Treat bespoke oracle apps as security-critical parsers, not only as data-transport middleware. Exotic swap structure, calldata-bearing paths, multi-leg trades, and flash-style flows should be normalized or rejected before they can become price observations.
Require real source independence before a replacement oracle path inherits lending authority. Offchain VWAP logic, fallback checks, and onchain execution guards should not all collapse onto the same manipulable venue.
Launch oracle replacements under migration quarantine by default: lower borrow caps, lower collateral factors, disabled large borrows, or delayed full-size lending until the new path proves itself under live conditions.
Put explicit local clamps on fresh oracle authority: rate-of-change bounds, absolute-value sanity checks, per-asset debt ceilings, and issuance throttles should all exist even when the upstream oracle path appears authenticated.
Separate new oracle answer observed from borrow path may mint or lend at scale. Fresh readings should update monitoring state first when the integration is new or recently modified.
Keep protocol-local exit liquidity in scope. If newly borrowed or minted assets can immediately be swapped, redeemed, or bridged, one oracle misread already has a realizable payout rail.
Simulate shared-root attacks in testing. If one pool move or one parser bug can satisfy both the offchain price layer and the onchain safety layer, the protocol does not yet have meaningful oracle defense in depth.
After an oracle incident, treat the replacement itself as high-risk change management. Patch urgency is exactly when protocols most need canaries, caps, and explicit authority narrowing.
Audit prompts
What exact swap shapes, router paths, calldata fields, and token-in/token-out patterns count as valid price observations for this oracle app, and which attacker-shaped variants have been explicitly ruled out?
Which supposedly independent oracle or safety layers still collapse onto the same underlying venue, route family, or liquidity pocket?
If one fresh oracle reading is wrong by 10x or 20x, what exact local control stops it from immediately authorizing protocol-scale borrowing or minting?
Is this oracle path battle-tested production infrastructure, or is it a recent bespoke migration that should still be treated as fresh collateral truth under quarantine?
Could the attacker satisfy both the oracle layer and the downstream onchain safety check with one coordinated pool distortion, or does the protocol force economically independent confirmation somewhere?
How quickly can a freshly manipulated price observation be turned into hard assets through borrowing, swapping, redemption, or bridging, and what slows that conversion down?
If the protocol replaced one oracle after a prior incident, what assumptions actually changed: parser correctness, source independence, fallback policy, or only the branding and transport layer?
What telemetry would show a parser-shaped oracle attack early: impossible swap-field combinations, outlier trade shapes accepted into VWAP, sudden divergence between trade semantics and published price, or one venue suddenly dominating all accepted observations?
Lessons that should already be standard
Moving price formation offchain does not create independence if the new system still trusts the same manipulable venue.
Oracle parsers are oracle security boundaries. If the app misclassifies attacker-shaped trades as normal observations, the bug is already at the truth-publication layer.
A post-incident oracle replacement is one of the highest-risk times to grant immediate full-size lending authority.
Complexity is not defense in depth. An offchain VWAP plus an onchain check is still one oracle if both read the same pool.
Fresh oracle answers should not become protocol-scale borrow power the moment they land, especially when the path is new, bespoke, or recently hotfixed.
If a protocol cannot explain what makes one trade observation admissible and another inadmissible, it does not yet know what object its oracle is really trusting.
The right migration question is not did we replace the old oracle? but did we change the economic truth root and stage the new authority safely?
Why this incident matters
It preserves a mechanically distinct oracle-manipulation branch the corpus should keep: offchain oracle app misparses attacker-shaped market data and still trusts one venue.
It is also a sharp sequel incident. DEUS had already been exploited through the same lending product in March, yet the rushed fix still left a custom oracle path that could be gamed in a different way.
That makes it a useful oracle-migration case study, not just an oracle-bug case study: the protocol changed components without changing the underlying economic dependency, then granted the new path immediate balance-sheet authority.
The note helps separate three related oracle failure modes: thin-market manipulation, disputable-oracle misuse, and bespoke parser/composition failure. DEUS April 2022 belongs squarely in that third bucket even though it still ended with a familiar flash-loan-backed pool distortion.
Positive-design companion: oracle-migration-quarantine-and-canary-design — the sharper design question is how the post-March oracle replacement should have been staged, capped, and canaried before it inherited full lending authority.
The leverage sat in DEUS’s choice to let one Solidly USDC/DEI market define solvency through both a custom Muon VWAP app and an onchain execution check, plus in the parser logic that decided what counted as a legitimate trade observation.
DEUS did not merely suffer a flash-loan attack. It delegated collateral truth to bespoke oracle middleware that still had single-venue assumptions and still misread attacker-shaped swaps.