On February 15, 2026, at 6:01 PM UTC, Moonwell DAO governance proposal MIP-X43 was executed. Its purpose was routine: enable Chainlink OEV wrapper contracts across core markets on Base and Optimism.
Within minutes, liquidation bots had begun systematically draining the protocol.
A single oracle configuration error had caused the cbETH market to report the asset’s price at approximately $1.12 — against a real market value near $2,200. The error was arithmetically straightforward: the configuration used only the raw cbETH/ETH exchange rate rather than multiplying it by the ETH/USD price feed. The delta was roughly 2,000x. Automated liquidators, operating exactly as designed, identified positions that appeared undercollateralized at the false price and began seizing cbETH collateral by repaying minimal debt.
By the time the protocol’s risk manager, Anthias Labs, detected the discrepancy and moved to reduce supply and borrow caps to 0.01, 1,096 cbETH had been liquidated. Total bad debt: $1,779,044.
The Actual Failure Mode
Coverage of this incident focused heavily on the fact that portions of the oracle configuration code were co-authored by an AI model. That is a real detail worth noting — AI-assisted development introduces its own audit considerations, and the industry is still calibrating appropriate review standards for generated code.
But it is not the core failure. The core failure is architectural.
The oracle configuration error was introduced through a governance proposal. The damage it caused was extended because correcting it also required a governance proposal — with an associated timelock. Correcting the oracle required a governance vote and timelock process, meaning liquidations continued until the configuration could be formally patched.
The protocol was harmed by the same mechanism twice: once when the error was deployed, and once when it could not be immediately reversed.
This is not a flaw in Moonwell’s specific governance design. It is an inherent property of all upgradeable protocols. The ability to change a contract after deployment is also, necessarily, the ability to misconfigure it after deployment. The upgrade pathway that enables improvement is the same pathway through which errors propagate. There is no architectural version of upgradeability that provides one without the other.
Three Incidents. One Common Thread.
February’s cbETH incident is not an isolated event in Moonwell’s history. The cbETH incident marks the latest in a series of oracle-related disruptions for Moonwell. In October 2025, a Chainlink pricing discrepancy involving AERO, VIRTUAL, and MORPHO resulted in more than $12 million in liquidations and $1.7 million in bad debt. In November, a wrsETH oracle malfunction left the protocol with roughly $3.7 million in bad debt after distorted pricing fed through a market-based exchange rate.
Three oracle incidents. Over $7 million in cumulative bad debt. Six months.
The common thread across all three is not oracle provider selection, not AI tooling, and not auditor quality. It is that each incident was triggered or extended through a governance execution or upgrade pathway — a mechanism for changing the contract’s configuration after deployment.
Every time Moonwell introduces a new integration or modifies an existing one, it creates a window during which an error can propagate before detection and remediation. That window exists because the protocol was designed to be changeable. The design intent is reasonable. The consequence is a persistent, recurring attack surface that no audit process can close permanently.
The Upgrade Surface as a Liability
This is the argument OWASP formalized in the Smart Contract Top 10: 2026 when it added Proxy & Upgradeability Vulnerabilities as SC10. The classification is not theoretical. It is a recognition that insecure upgrade patterns and weak governance over contract changes have produced a documented, recurring category of loss across the ecosystem.
The standard response to SC10-class incidents is governance improvement: timelocks, multisig requirements, staging environments, more rigorous pre-execution review. These controls reduce the frequency of errors reaching production. They do not eliminate the upgrade surface — and as long as the upgrade surface exists, it will occasionally be traversed by misconfigured code, whether human-written or AI-assisted.
The architectural answer is different. If a contract cannot be upgraded, the upgrade surface does not exist. There is no governance proposal pathway through which a misconfigured oracle can be deployed, because there is no governance proposal pathway at all.
What 0xKeep’s Architecture Means in Practice
0xKeep’s V11 contract is immutable at deployment. There are no admin keys. There is no governance mechanism that can alter contract logic or configuration after the contract is live. There is no oracle to misconfigure — the protocol’s logic does not depend on external price feeds at all. Lock durations and vesting schedules are deterministic functions of the parameters provided at the time of contract interaction. There is nothing to update, and therefore nothing that a subsequent update can break.
This is not a claim that the 0xKeep contract is flawless. It is a claim that the Moonwell failure mode — correct code replaced by misconfigured code through a governance pathway — cannot occur in a protocol with no governance pathway. The attack surface that produced three incidents and $7 million in bad debt for Moonwell does not exist in 0xKeep’s architecture.
The trade-off is real: an immutable contract cannot be improved after deployment. If a bug is found, there is no patch. That is a genuine cost, and any honest assessment of immutable architecture has to acknowledge it.
But the Moonwell data illustrates what the alternative looks like operationally. A protocol that can be improved can also be degraded. In six months, the upgrade mechanism was the vector for loss three times. The question each protocol operator must answer is whether the ability to iterate post-deployment is worth the recurring exposure that ability introduces.
A Note on AI-Assisted Development
The involvement of an AI model in the oracle configuration that failed has attracted significant commentary. It warrants a measured assessment.
AI-assisted development tools can introduce subtle errors that pattern-match to correct code while containing logical flaws — in this case, a missing multiplication that a trained developer might have caught in review. The incident is a legitimate data point for teams calibrating their AI code review processes.
It is not, however, a reason to conclude that AI tooling is uniquely dangerous relative to human-written code. Oracle misconfigurations predate AI development tools by years. The Term Finance incident in April 2025, which triggered faulty liquidations and approximately $1.6 million in losses, involved no AI-generated code. The cause was the same category of error: a configuration change introduced through an upgrade pathway that was not caught before execution.
The Moonwell incident is an AI-assisted development failure. It is also, more structurally, an upgradeability failure. The former will improve as review standards mature. The latter is inherent to the design.
0xKeep operates on an immutable, zero-admin-key architecture. No wallet — including those controlled by the 0xKeep team — can pause, modify, or interact with deployed contracts. Time is the only admin.
Deploy on Base, Arbitrum, or Optimism at 0x-keep.xyz Follow protocol updates: @0xKeep_official