On March 24, 2026, an attacker funded a wallet, purchased 40.17 million MFAM tokens from the SolarBeam decentralized exchange on Moonriver for approximately 1,600 MOVR — worth $1,808 — deployed a contract containing purpose-built exploit logic, and submitted Proposal #74 to Moonwell’s governance system, titled “MIP-R39: Protocol Recovery – Admin Migration.”
The proposal called for the transfer of administrative control over all seven of Moonwell’s Moonriver lending markets, the Comptroller, and the Oracle to the attacker’s contract. That contract, according to blockchain intelligence firm Blockful, already contained the transactions necessary to drain the markets: the admin transfer and the fund extraction were packaged in the same proposal execution.
The attacker’s 40.17 million MFAM exceeded the protocol’s 40 million quorum threshold at the snapshot block. The entire sequence — buying tokens, creating the proposal, and voting it past quorum — took about 11 minutes.
The vote closes on March 27 at 10:28 UTC. As of this writing, 68% of cast votes oppose the proposal. The outcome remains open.
The Arithmetic of Governance Capture
The implied return, if successful, would have been approximately 597 times the cost of the attack. $1,808 in. $1,080,000 out. The ratio is not an anomaly — it is a precise measurement of how badly miscalibrated Moonwell’s Moonriver governance parameters were relative to the assets the governance system controlled.
The MFAM token had been trading at approximately $0.000025 before the attacker’s purchase. At that price, controlling 40 million votes — enough to reach quorum — cost less than a used laptop. The quorum threshold, presumably set when MFAM traded at a higher price or when the community expected more participation, had not been updated to reflect the reality of a deprecated chain with thin liquidity and fragmented token holders.
This is the governance equivalent of a security assumption that was valid at deployment and became invalid over time. The protocol’s governance parameters were set for a specific market and participation context. That context changed. The parameters did not.
For a protocol of that size, the low cost of the attempted takeover points to a governance design mismatch: quorum and proposal thresholds that did not scale with the market value of its governance token.
A Deprecated Chain, a Live Attack Surface
The detail that sharpens this incident considerably is the current status of the Moonriver deployment. The Moonwell deployment on Moonriver had already been deprecated after oracle feeds were discontinued, which led to a full wind-down of markets on that network. Moonwell was in the process of migrating MFAM holders to stkWELL at a 1:1.5 ratio and consolidating governance around its Base deployment.
The attack targeted a deployment that Moonwell had already begun to shut down — one that was no longer receiving active development resources, whose oracle feeds had been discontinued, and whose governance participation had correspondingly declined. The $1.08 million in user funds that remained in those markets had not yet been migrated.
The governance mechanism that controlled those funds was still live. The community attention that might have caught a malicious proposal early was not. A deprecated chain with residual assets and reduced governance participation is, by definition, an undermonitored attack surface. The attacker read that context correctly.
Voting power is snapshotted at the proposal’s start block, meaning MFAM purchased after the attack carries no weight on this vote. Token holders who were not holding MFAM before the attack cannot add meaningful opposition by purchasing tokens now. The defensive options are limited to mobilizing existing holders who were already holding MFAM at the snapshot block, or activating the Break Glass Guardian.
The Break Glass Guardian
The Break Glass Guardian is a 2-of-3 Gnosis Safe multisig that can bypass the protocol’s timelock entirely and transfer admin back to the legitimate governance address, rendering the attacker’s proposal a no-op even if it passes.
The Guardian is an emergency override — an admin key held by a trusted multisig that can intervene when the governance process produces a malicious or erroneous outcome. Its existence is the protocol acknowledging what this attack makes explicit: on-chain governance mechanisms can be captured, and when they are, the fallback is a centralized key.
This is not a criticism of Moonwell specifically. It is a description of the security architecture that underlies most DeFi governance systems. The governance vote is the first line of defense. Behind it is a multisig. Behind the multisig are the people who hold those keys. The “decentralized” governance outcome is ultimately bounded by the “centralized” emergency controls that exist to correct it when it fails.
The Break Glass Guardian is a damage control mechanism. Like the pause buttons discussed in the dTRINITY incident, it operates after the attack has already been identified. It is faster than waiting for a vote to fail, but it requires human coordination — 2 of 3 multisig signers must act, on a timeline dictated by when the attack was detected and when the vote closes.
Governance Tokens Are Access Credentials
DeFi security discussions often focus on technical vulnerabilities such as reentrancy, oracle design, access controls, and key management. Moonwell shows governance can be just as exploitable — especially when a protocol safeguards tens of millions in assets while governance power can be bought for the price of “street-market goods.”
This framing is accurate and worth extending. A governance token is not merely a voting share in the abstract sense. In a protocol where governance controls admin functions — market parameters, oracle selection, contract ownership, fund transfers — a governance token is a fractional share of the admin key. Accumulating enough governance tokens to reach quorum is functionally equivalent to acquiring the admin key itself, if the governance mechanism has no additional safeguards against malicious proposals.
The Beanstalk flash loan governance attack in April 2022 drained $182 million through exactly this mechanism — a single transaction that borrowed enough governance tokens to pass a malicious proposal before the loan was repaid. Flash loan governance attacks introduced the concept at scale. The Moonwell attack is a slower, cheaper version: buy the tokens outright because they are inexpensive enough, submit the proposal, and wait out the voting period.
The attack vector is not new. It has been documented, discussed, and partially mitigated across the ecosystem since 2022. Mitigations include timelocks between proposal submission and execution, minimum voting delays before proposals can pass, guardian multisigs, proposal deposit requirements, and quorum thresholds calibrated to TVL rather than raw token counts. Moonwell had some of these — the vote has a multi-day window, and the Break Glass Guardian exists. What Moonwell’s Moonriver deployment lacked was a quorum threshold that made the attack economically unviable given the current token price and TVL.
Moonwell’s Third Incident in Five Months
This is the third security incident linked to Moonwell in the past five months. The oracle misconfiguration under MIP-X43 in February 2026 caused $1.78 million in bad debt and affected 181 borrowers. Before that, a wrsETH oracle malfunction in November 2025 resulted in approximately $3.7 million in bad debt. Now a governance capture attempt on a deprecated chain has put $1.08 million at additional risk.
Each incident is distinct in mechanism: oracle misconfiguration, oracle malfunction, governance capture. What connects them is that each attacked Moonwell through its administrative and configurational layer — not through the core lending logic, but through the mechanisms that govern how that logic is parameterized and controlled.
The oracle incidents attacked the governance execution process. This incident attacks the governance process itself. In both cases, the vulnerability was not in what the protocol’s code did when operating correctly — it was in who controlled how the protocol was configured, and whether that control was adequately secured.
That is the consistent pattern across this entire series. Protocols that expose administrative control — through governance votes, upgrade keys, oracle configuration, or emergency multisigs — expose the administrative layer as an attack surface. The specific attack vector changes. The target does not.
What 0xKeep’s Architecture Removes
The 0xKeep contract has no governance mechanism. There is no proposal process, no voting threshold, no quorum to capture, no admin migration function that a proposal could execute. There are no market parameters to configure, no oracle to transfer control of, no Comptroller to hand to a malicious contract.
There is also no governance token. MFAM’s value — and the governance attack surface it represents — exists because MFAM controls something worth controlling. 0xKeep’s architecture is designed to control as little as possible. The contract’s behavior at deployment is its complete specification. No token holder, governance process, or emergency multisig can alter what the contract does after it is deployed.
A governance attack requires a governance system. It requires a mechanism by which a sufficient concentration of tokens translates into administrative control. It requires assets under management that are worth the cost of acquiring that control. 0xKeep presents none of these targets, because none of these mechanisms exist.
The $1,808 attack on Moonwell is the cheapest attack in this series. The governance attack surface that made it possible is not — it is the accumulated cost of every design decision that placed administrative control inside a governance mechanism rather than removing it at deployment.
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