Moonwell Moonriver MFAM Low-Float Governance Capture Attempt (2026-03-24)

  • Name: Moonwell Moonriver MFAM low-float governance capture attempt
  • Date: 2026-03-24
  • Protocol: Moonwell Apollo (Moonriver deployment)
  • Chain: Moonriver
  • Category: governance capture / low-float token accumulation / attempted admin seizure / deprecated-deployment governance failure
  • Loss: no onchain drain completed, but Blockful’s contemporaneous analysis and Moonwell forum discussion put roughly $1.08M of protocol cash at immediate risk across seven Moonriver lending markets
  • Summary: This was a governance attack against Moonwell’s deprecated Moonriver instance, not a flash-loan supermajority like Beanstalk and not a proposal-code swap like Tornado Cash. The attacker simply noticed that MFAM governance power on Moonriver had become cheap enough to buy outright. In about 11 minutes, they funded a deployer, created an attack contract, atomically spent 1,600 MOVR (about $1,808) on SolarBeam to buy 40,170,745.69 MFAM, self-delegated those tokens, proposed a malicious governance action styled to resemble a legitimate recovery proposal, and cast enough For votes to clear Moonwell Apollo’s 40M quorum. If later queued and executed, the proposal would have transferred admin of all seven Moonriver markets, the Comptroller, and the Oracle to attacker-controlled code. The attempt failed only because the attacker later let the proposer balance fall below the 500,000 MFAM proposal threshold, after which the proposal became permissionlessly cancelable and was canceled before execution.
  • Trigger / entry point:
    • Moonwell’s Moonriver governor counted directly held MFAM once delegated; no seasoning period or long-range snapshot stopped newly purchased spot inventory from becoming immediate proposal and voting power.
    • The Moonriver deployment was deprecated but still held meaningful residual cash in seven lending markets plus its Comptroller and Oracle admin surfaces.
    • MFAM spot liquidity on SolarBeam was thin enough that an attacker could buy quorum-scale voting power for about $1.8k.
    • Governance still retained root-level authority over market admin and oracle admin, so a passed proposal could turn cheap voting power into direct protocol control.
  • Root cause:
    • Moonwell left valuable admin rights and idle market cash behind a governance token whose effective float, liquidity, and price on the deprecated deployment had fallen far below the value protected by that governance surface.
    • Direct token holdings became usable governance weight immediately after delegation, so the attacker did not need to borrow, wait, or earn votes through longer-term alignment.
    • Proposal payload authority was broad enough that one successful proposal could seize the markets’ admin path, replace the Comptroller path, and pivot to uncollateralized borrowing or other drain logic without any second bug.
    • In practice, Moonwell’s Moonriver governance had become a cheap constitutional shell guarding more value than the voting market could honestly defend.
  • Exploit path:
    1. At 10:16:30 UTC on 2026-03-24, a hot wallet 0x88baeb35f73c72d0a4554d36851c1a76403937f8 funded deployer 0xe62da344872b1a5644ee521001da6677a7ad736d with 1,682 MOVR in transaction 0xccb0ce74...5700.
    2. At 10:23:48 UTC, the deployer created attack contract 0x18275952D3EA09D80DbE446D2cBA085E01e681B4 in transaction 0xf95f93d59154bf4f51f5b5be6eaab9b404ff250eacf5e638f8a605a13158c006.
    3. At 10:24:24 UTC, that contract wrapped 1,600 MOVR, swapped it on SolarBeam for 40,170,745.69 MFAM, and self-delegated the purchased tokens in one atomic transaction: 0xe03be43390211ced8a57707a7884b2499e0525e5e87076e0e1e7d3df505fe450.
    4. At 10:27:36 UTC, the attacker created proposal #74 in transaction 0xd701a0d2223d9e723d5aa2068e026389d0ab8e3dc242732605f3ae12eb60b066.
    5. The proposal title, MIP-R39: Protocol Recovery - Admin Migration, was chosen to look like a continuation of the legitimate Moonriver recovery proposal #73 rather than an obvious hostile takeover.
    6. Proposal #74 queued nine privileged actions: _setPendingAdmin(attacker) on all seven lending markets plus the Comptroller, and setAdmin(attacker) on the Oracle.
    7. At 10:32:00 UTC, the attacker called castVote(74, 0) in transaction 0xe4c4a6f1f7f24312a7946d31c68eabff9bc6cf458521ace23d7afd2c3472a4ef; Moonwell Apollo’s vote encoding used 0 = Yes, so this single vote pushed the proposal past the 40M MFAM quorum.
    8. Blockful’s review noted that the clean post-execution drain path would be to use the captured admin rights to point all markets at a malicious Comptroller that allowed unlimited uncollateralized borrowing, then remove the remaining cash from the markets.
    9. The proposal never reached execution. By 2026-03-26, the proposer’s balance had fallen below the 500,000 MFAM proposal threshold, making the proposal cancelable by any participant. Moonwell later confirmed on the governance forum that the malicious proposal had been canceled.
  • What the attacker needed to be true:
    • Quorum-scale MFAM had to be acquirable cheaply enough on the open market to make the trade attractive.
    • Newly acquired and newly delegated MFAM had to count for proposal and voting power quickly enough to support a same-window governance strike.
    • The Moonriver deployment had to retain valuable cash and root-level admin rights even though it was already deprecated.
    • Proposal execution authority had to include market-admin and oracle-admin changes rather than only narrow parameter updates.
    • Defenders had to fail to countervote, break-glass, or cancel before queue/execution.
  • Technical anatomy worth remembering:
    • This is a useful governance-capture cousin because the attacker did not rent votes; they bought them outright in a thin, neglected governance market.
    • Within the governance-decay branch, Moonwell is the clean deprecated-deployment quorum buyout anchor: cheap spot MFAM on a sleepy legacy market was enough to threaten root authority, rather than Indexed’s dead-protocol remnant-timelock defender-race shape or Compound goldCOMP’s treasury-self-delegation shape.
    • The decisive mismatch was value protected versus cost to buy quorum. Roughly $1.08M of residual protocol cash sat behind a governance surface that Blockful showed could be captured for about $1,808.
    • The attack also preserved a social-engineering layer: proposal naming mattered. Styling the malicious action as MIP-R39: Protocol Recovery - Admin Migration let it masquerade as routine recovery work on an already messy deprecated deployment.
    • The safe outcome should not hide the design failure. Moonwell survived because the attacker lost or sold down enough MFAM to become cancelable, not because governance itself robustly prevented the takeover once quorum had been crossed.
    • The proposal’s strongest preserved lesson is that deprecated or low-attention deployments can still carry live constitutional risk if the old token, governor, timelock, and admin surfaces remain wired to non-trivial cash balances.
  • Representative transactions and addresses:
    • Governor: 0x2BE2e230e89c59c8E20E633C524AD2De246e7370
    • Timelock: 0x04e6322D196E0E4cCBb2610dd8B8f2871E160bd7
    • MFAM token: 0xBb8d88bcD9749636BC4D2bE22aaC4Bb3B01A58F1
    • Break Glass Guardian: 0x5ded9d1025a158554ab19540ae83182d890bb8db
    • Governance return address: 0x017efffd8abea3b1891f81e7c0e5166458b3584d
    • Comptroller: 0x0b7a0EAA884849c6Af7a129e899536dDDcA4905E
    • Oracle: 0x892bE716Dcf0A6199677F355f45ba8CC123BAF60
    • Attack contract / proposer: 0x18275952D3EA09D80DbE446D2cBA085E01e681B4
    • Deployer: 0xe62da344872b1a5644ee521001da6677a7ad736d
    • Funder: 0x88baeb35f73c72d0a4554d36851c1a76403937f8
    • Contract-creation transaction: 0xf95f93d59154bf4f51f5b5be6eaab9b404ff250eacf5e638f8a605a13158c006
    • Token-purchase / self-delegation transaction: 0xe03be43390211ced8a57707a7884b2499e0525e5e87076e0e1e7d3df505fe450
    • Proposal-creation transaction: 0xd701a0d2223d9e723d5aa2068e026389d0ab8e3dc242732605f3ae12eb60b066
    • Vote-casting transaction: 0xe4c4a6f1f7f24312a7946d31c68eabff9bc6cf458521ace23d7afd2c3472a4ef
  • Response / mitigation:
    • Moonwell governance contributors publicly warned that the live proposal had no corresponding forum process or public rationale.
    • Blockful published a contemporaneous incident analysis explaining that proposal #74 was already wired to attacker-controlled drain logic and that the practical defenses were: defeat the vote, use the Break Glass Guardian, or later cancel if the proposer’s voting power dropped below threshold.
    • Moonwell later confirmed that the proposal was canceled once the proposer no longer satisfied the proposal threshold.
    • The case implies a broader cleanup lesson for dormant deployments: deprecating front-end attention is not the same as decommissioning governance risk; if the instance still holds real cash, either the root admin path has to be extinguished or the residual authority surface has to stay explicitly defended.

Pattern tags

  • governance-capture
  • governance-decay-remnant-authority-capture
  • deprecation-without-deauthorization
  • backstop-failure-governance-capture
  • The decisive attack path was buy quorum on a sleepy legacy market rather than borrow quorum temporarily. MFAM’s market microstructure on Moonriver had decayed far enough that roughly $1.8k could threaten root authority over about $1.08M of protocol value.
  • Newly acquired spot inventory became proposal and voting power quickly enough that the attacker could compress buy tokens, self-delegate, propose, and cross quorum into about fifteen minutes.
  • Proposal #74 was not merely a hostile parameter change. Its nine calls targeted all seven lending markets plus the Comptroller and Oracle, so one successful governance action would have seized the clean second-stage admin rails needed for a later drain.
  • The eventual safe outcome depended on proposer’s-balance decay making the proposal cancelable, which is a useful reminder that Moonwell survived through attacker-side lapse and emergency monitoring rather than through a governor that mechanically resisted a cheap quorum buyout.

Three dormant-governance promotions this incident collapsed

  1. Some quorum-scale MFAM lane still existed

    • Thin SolarBeam liquidity plus immediate self-delegation meant the attacker could still assemble 40,170,745.69 MFAM and push proposal #74 over Moonwell Apollo’s 40M quorum.
    • That only proved a governance lane on Moonriver still worked.
  2. That cheap reachable lane still counted as legitimate constitutional authorship for the deprecated deployment

    • Moonwell’s old thresholds and immediate vote activation promoted newly purchased spot inventory into accepted authorship for the Moonriver instance even though the deployment was already deprecated and thinly defended.
    • This was the decisive constitutional-authentication failure: cheap market access still counted as the polity that may govern these residual assets and admin rails.
  3. That admitted authorship still deserved full market-admin / oracle-admin authority

    • Once proposal #74 crossed quorum, the same admitted governance lane still had enough scope to queue nine privileged calls across all seven markets plus the Comptroller and Oracle.
    • This was the residual-authority failure: a sleepy legacy electorate was still allowed to inherit broad second-stage drain authority instead of a narrower maintenance-only mandate.

Why the exploit worked

  • Moonwell left a deprecated deployment with live market cash and live admin rails behind a token whose effective float and active governance market had become trivial. That is the sharp mismatch here: deprecated socially and cheap to buy politically arrived long before deauthorized technically.
  • Governance authenticated fresh spot ownership too quickly. The attacker did not need time to accumulate legitimacy, organize delegates, or survive a holding period; buying MFAM on SolarBeam and self-delegating it was enough to convert a tiny amount of MOVR into immediate constitutional power.
  • The proposal surface still reached high-authority objects. Capturing the Moonriver governor did not merely grant cosmetic control over an abandoned side deployment; it gave the attacker a path to replace market admins, rewire the Comptroller, and seize the Oracle, after which uncollateralized borrowing or equivalent drain logic would have been a routine second step.
  • Defender success was contingent and late. The proposal was not stopped because Moonwell had already extinguished the dangerous governance lane; it was stopped because the proposer later fell below threshold and became cancelable. In other words, the constitution remained cheaply buyable even though this particular attacker failed to finish the sequence.
  • The case is therefore less about one clever hostile payload than about lifecycle failure: an old governance shell retained more protected value and more root authority than its surviving market participation could honestly defend.

Detection and audit pivots

  • Compare cost to cross threshold/quorum against value still protected by governance on every legacy deployment. When the first number collapses and the second does not, the deployment is already under-decommissioned.
  • Review deprecation as an authority question, not a UX question. Lower forum traffic, stale docs, or reduced front-end prominence do nothing if the old governor still controls market admins, oracle admins, or treasury-relevant paths.
  • Ask when fresh spot inventory becomes constitutional power. If newly purchased tokens can propose or vote immediately on a sleepy deployment, the protocol has effectively delegated root-key pricing to the thinnest live market in that ecosystem.
  • Inventory the clean second-stage takeover rails behind a successful vote. Moonwell’s attacker did not need a second vulnerability because the proposal already targeted the Comptroller and Oracle, which were enough to make later draining logic straightforward.
  • Test backstops against low-attention governance windows. If the best practical defenses are someone notices the forum mismatch, guardian intervenes in time, or later cancel if proposer weight drops, then the deployment is already operating on brittle human latency assumptions.
  • Treat proposal-title camouflage as part of the threat model on retirement paths. Protocol Recovery - Admin Migration was effective precisely because the deployment was already in a messy recovery/deprecation context where a malicious proposal could hide inside expected maintenance noise.

Failure-prevention checklist

  • Tie deprecation to authority reduction, not just community messaging. A legacy deployment should lose treasury value, market-admin rights, oracle-admin rights, or proposal power as part of the same offboarding plan.
  • Recompute governance security against current attentive float and current market liquidity. If quorum can be bought cheaply on the open market, the deployment is already operating below its constitutional safety margin.
  • Add seasoning, delayed vote activation, or narrower proposal rights on sleepy deployments so newly purchased spot inventory cannot become same-window proposal and voting power against residual protocol cash.
  • Quarantine legacy deployments into maintenance-only or retirement modes. If the product must remain live for withdrawals or repayments, governance there should not still be able to seize broad admin rails in one proposal.
  • Keep break-glass, cancellation, and guardian runbooks explicit and operational while any deprecated deployment still guards real value.
  • Remove residual cash and residual authority together. Leaving seven markets’ cash behind while the old governor still controls the Comptroller and Oracle is how deprecated becomes cheaply capturable.
  • Monitor the ratio cost to reach threshold/quorum versus value protected by governance as a standing governance risk metric, especially on sidechain or long-tail deployments.
  • Treat proposal-title camouflage and low-attention governance windows as expected attack tools, not social oddities.

Audit prompts

  • What is the current all-in cost to cross proposal threshold and quorum on this deployment, and how does that compare with the cash and admin power still protected there?
  • Can freshly purchased and freshly delegated tokens propose or vote immediately, or is there any seasoning period that forces governance power to age before it matters?
  • Which exact powers can one successful proposal seize here: market admin, comptroller admin, oracle admin, proxy admin, treasury transfer, minter rights, or guardian rotation?
  • What machine-checkable condition marks this deployment as truly retired: no new proposals, no admin rights, no residual cash, or merely less community attention?
  • If defenders miss one voting cycle, what concrete path still exists to cancel, pause, or neutralize a hostile proposal before execution?
  • Are proposal thresholds and quorum still calibrated to a real electorate, or are they leftovers from a healthier token distribution that no longer exists?
  • Could treasury-held, foundation-held, or otherwise inert token balances distort the apparent governance market relative to the actually attentive float?
  • What pre-authorized migration or deauthorization path exists if a deprecated deployment becomes cheaper to capture than the value it still controls?

Lessons that should already be standard

  • Deprecated is not a security state. Until authority and value are both removed, it is just a quieter production system.
  • Governance security is partly market microstructure. Thin float and cheap spot inventory can turn an old governor into a bargain root key.
  • Same-window vote activation is especially dangerous on sleepy deployments because defenders do not get time to react before bought votes become constitutional power.
  • A protocol is not safe because the attacker eventually blundered. Moonwell survived because the proposal became cancelable, not because the governance design robustly resisted capture.
  • Quorum numbers can become historical fiction. Thresholds that once represented a live electorate may become trivial after token liquidity, delegate attention, and user interest decay.
  • Residual admin rights on legacy deployments are often more dangerous than residual treasuries alone, because one hostile proposal can first seize the cleaner second-stage root key and drain later.

Why this incident matters

  • It broadens the governance-capture corpus beyond flash-loaned supermajorities and metamorphic proposal payloads into the simpler but very real buy the neglected governance market path.
  • It preserves the operator lesson that deprecated instances need active offboarding of assets and admin rights, not just reduced community attention.
  • It is a sharp example of governance security being denominated in market microstructure: if quorum can be bought for less than one percent of protected value, the governance system is already economically broken.
  • It is also a clean positive-design anchor for decommissioning-authority-extinguishment-discipline and governance-backstop-scope-and-intervention-latency-discipline: once governance security had degraded into can anyone notice and countervote before execution?, the healthier control objective was to extinguish or quarantine the old market-admin and oracle-admin authority instead of leaving it behind a sleepy token market.

Internal linkages

Control surface