Moonwell Rekt: When the AI Writes the Oracle and Nobody Catches the Missing Multiplication

Commissioned, Curated and Published by Russ. Researched and written with AI.

On February 15, at 6:01 PM UTC, governance proposal MIP-X43 executed on Moonwell. Its purpose was routine: enabling Chainlink OEV wrapper contracts across core markets on Base and Optimism. One oracle configuration was wrong. Within four minutes, $1.78 million was gone.

The mechanism was simple. cbETH is a liquid staking token worth roughly 1.12 ETH, which at the time meant roughly $2,200 in dollars. To price it correctly you need two numbers: the cbETH/ETH exchange rate, and the ETH/USD price. Multiply them together and you have a dollar value. The deployed oracle used only the first number. It reported cbETH at $1.12 – the exchange rate, with no USD conversion – live on-chain, against a real market price of around $2,200.

That is a 99.9% discount. Liquidation bots noticed immediately. They always do.

Every cbETH-backed position on the protocol was suddenly underwater by the oracle’s logic. Bots repaid portions of borrowers’ debt, seized cbETH collateral at $1.12 reported value, and pocketed the spread against a $2,200 real-world asset. 1,096.317 cbETH was seized in total. A second group of actors ran the same mispricing in reverse – depositing minimal collateral, borrowing cbETH at the artificial price, and walking away with the spread. The bad debt left behind totalled $1,779,044.83, spread across eleven assets including cbETH ($1.03M), WETH ($479K), and USDC ($232K).

Anthias Labs detected the discrepancy within four minutes and slashed the borrow cap to 0.01. But correcting the oracle itself required a five-day governance voting and timelock period. The damage was done in the time it takes to make a cup of coffee. The fix took nearly a week to deploy.

The GitHub Trail

Pull Request #578 landed in Moonwell’s repo looking clean. Contributor anajuliabit submitted it to activate the Chainlink OEV wrappers. GitHub’s Copilot reviewed all four changed files and generated comments. The PR passed human review, went to governance, and passed with 99.1% in favour.

The commit message contained one line that the DeFi security community was screenshotting within hours of the incident:

Co-Authored-By: Claude Opus 4.6

According to rekt.news’s review of the commit, Claude’s specific contributions included fixing int256 validation, adding a try/catch on chainlinkOracle() to skip re-deploying when two configs share the same oracle, removing an unused ProxyAdmin import, and swapping in assertTrue(answer > 0) to properly catch negative oracle prices. Defensive, tidy, exactly the kind of careful programming you want in production.

What neither Claude nor Copilot flagged: the cbETH price feed was pulling only the cbETH/ETH exchange rate and treating it as a dollar value. The ETH/USD multiplication was absent. No sanity check existed – no floor, no ceiling, no assertion that $1.12 for an asset trading near $2,200 should halt deployment.

What AI Actually Did Wrong (And Didn’t)

The error itself is not exotic. Senior engineers misconfigure price feeds. Auditors miss formula errors. Humans skip sanity checks under deadline pressure. Every one of those failures has a human explanation that doesn’t require an AI in the room.

But Mikko Ohtamaa, after the incident, fed the same PR to Claude with a precise prompt asking it to identify the incorrect oracle address and explain why the ETH rate was wrong. His conclusion, as reported by rekt.news: regardless of whether code is written by AI or by a human, these errors are caught in automated integration tests. In this case tests existed, but there was no price sanity test case – not in the test suite, not in production itself. He also noted that a human deployer should be performing manual checks as part of the DAO process, and that didn’t happen either.

That’s the honest framing. The AI did not introduce a novel vulnerability class. It made a configuration error that humans also make, then produced code that read as correct enough to pass every layer of review. Pashov, who surfaced the Claude co-authorship publicly, put it plainly: the human behind the AI decides and reviews the code, possibly a security auditor as well – and that process failed here.

Patrick Collins of Cyfrin identified the specific failure mode: AI is very good at convincing you that your code is correct. It comments cleanly, handles edge cases with the appearance of rigor, compiles without complaint. A human developer staring at a cbETH oracle outputting $1.12 might feel a flicker of wrongness – a number that doesn’t match what they saw on Coinbase that morning. AI has no such flicker. It produced a plausible result, formatted it well, and moved on.

That is not an argument against using AI to write code. It is an argument about what AI-assisted review does and does not cover.

The Pattern

This was not Moonwell’s first oracle incident. Per a summary by yieldsandmore, there have been three in just over four months:

October 10, 2025: Oracle feeds mispriced three volatile tokens. An attacker flashloaned and drained at 85-88% LTV. Roughly $1.7M in bad debt.

November 4, 2025: The wrsETH oracle fed a value of 1 wrsETH = 1,649,934 ETH, following a Balancer exploit that destabilised rsETH liquidity the day before. The same attacker reportedly took advantage. Roughly $3.7M in bad debt.

February 15, 2026: cbETH oracle missing one multiplication. AI-assisted code. $1.78M in bad debt.

Total across three incidents: approximately $7.2M in bad debt. The October and February incidents share the same root failure: a price feed for a liquid staking token reporting an ETH-denominated ratio as a USD value, with no sanity check to stop it.

What This Means for Engineers Using AI to Write Production Code

The actionable part is not “stop using AI” – that ship has sailed, and the error here was fundamentally a testing and review failure, not an AI failure. The actionable part is:

Price sanity checks are not optional. If your system operates on a price feed, there should be an assertion, in the test suite and in production monitoring, that any reported price outside a credible range halts execution. For cbETH in February 2026, a floor of $500 or a ceiling-vs-median check would have caught $1.12 immediately. That check should not require a human to notice something feels off – it should be hardcoded.

AI-generated code that reads as correct needs to be verified as correct, not just reviewed. Reading code for obvious problems is not the same as running integration tests against real price data. The Moonwell PR passed human review, Copilot review, and a DAO vote. None of that is a substitute for a test case that asks: does this oracle return a number in the right ballpark for an asset I know the price of?

When AI writes the code and humans approve it without deeply understanding it, the accountability chain breaks. The governance process at Moonwell blessed a misconfigured oracle at 99.1% approval. That number doesn’t mean the voters understood the configuration – it means nobody said no. A governance vote is not a security audit.

The five-day timelock is also worth examining. Immutability and mandatory delays are valuable security properties in normal conditions. When your oracle is reporting a live 99.9% pricing error, the inability to fix it for five days is a design constraint that turns a recoverable mistake into a locked-in loss. That tension – between governance process rigour and emergency response speed – is not solved by better AI tooling. It requires explicit design decisions about what classes of failure can trigger accelerated remediation.

The code was wrong. Every system designed to catch wrong code said it was fine. That’s the thing worth fixing.

Sources: rekt.news, Moonwell governance forum MIP-X43, GitHub PR #578