MakerDAO B.Protocol Flash-Loan Governance-Vote Acceleration Near Miss (2020-10-26)

  • Name: MakerDAO B.Protocol flash-loan governance-vote acceleration near miss
  • Date: 2020-10-26
  • Protocol: MakerDAO
  • Chain: Ethereum
  • Category: governance capture / flash-loan vote acceleration / continuous-approval governance weakness / emergency-module near miss
  • Loss: no direct treasury drain or oracle theft was realized; the concrete outcome was that B.Protocol accelerated passage of an executive spell that included its own oracle whitelist, while exposing that temporarily borrowed MKR could also have been used to seize sensitive emergency powers before organic MKR holders reacted
  • Summary: This was an important governance near miss rather than a direct drain. Maker’s 2020 executive-vote system treated whatever MKR was locked in the vote at that moment as valid constitutional weight, even if those tokens had been borrowed for one transaction. On 2020-10-26 at 17:37:17 UTC, B.Protocol used a one-transaction route later described by Maker governance as 50,000 ETH flash-borrowed from dYdX, posted into Aave, then used to borrow about 13,000 MKR (about $7M) that was immediately lock()ed, vote()d, lift()ed into the hat, free()d, and returned after the spell had already been schedule()d. The spell they accelerated both raised Maker’s surplus buffer and whitelisted B.Protocol on the ETHUSD Medianizer and OSM oracles. The immediate spell was not itself a treasury-drain payload, but Maker’s own 2020-10-30 emergency executive framed the episode as an urgent flash-loan governance risk: it explicitly said the GSM Pause Delay had to move from 12 hours to 72 hours “to allow governance sufficient time to react to a governance attack on the Maker Protocol” and deauthorized OsmMom / FlipperMom so flash-borrowed MKR could not as easily turn a temporary spell lead into oracle-freeze or liquidation-control authority.
  • Trigger / entry point:
    • Maker executive votes in 2020 used a continuous-approval model: a spell became the leading proposal once its MKR backing surpassed the current incumbent’s backing.
    • The 2020-10-23 executive spell at address 0xb04A29de213411DDb7196eD1327b3B6144893E59 included both a surplus-buffer increase and B.Protocol oracle-whitelist changes.
    • Enough MKR was borrowable on DeFi markets that a short-lived whale position could materially change the live executive-vote ranking; Maker’s own incident post counted 63,445 MKR accessible through Balancer, Aave, and Uniswap flash-loanable liquidity versus a current hat of roughly 79k MKR, and warned that newly introduced executives could be much thinner during hat transitions.
    • The beneficiary of the whitelist, B.Protocol, was also the party that demonstrated the flash-loan maneuver.
  • Root cause:
    • Maker governance authenticated current token custody at vote time, not durable economic ownership or time-weighted voting power.
    • The executive-vote design assumed that MKR backing a spell represented patient governance capital, but DeFi lending markets had made a temporary MKR supermajority rentable.
    • Sensitive governance-adjacent modules such as oracle and liquidation emergency controls still sat close enough to governance that even a brief spell victory could matter.
    • The system lacked enough time separation between borrow voting power, make a spell win, and exercise privileged effects.
  • Exploit path:
    1. On 2020-10-23, Maker governance published executive spell 0xb04A29de213411DDb7196eD1327b3B6144893E59, which would increase the surplus buffer from 2M DAI to 4M DAI and whitelist B.Protocol on the ETHUSD Medianizer and OSM oracles.
    2. Maker’s own incident disclosure fixed the attack timeline more precisely: at 17:37:17 UTC on 2020-10-26, one transaction borrowed 50,000 ETH from dYdX, deposited that WETH into Aave, borrowed about 13,000 MKR, called chief.lock(), chief.vote(), chief.lift(), chief.free(), then spell.schedule(), and finally unwound the Aave and dYdX legs.
    3. That one-block sequence mattered. Maker governance later emphasized that the spell had already been scheduled before the flash-borrowed MKR was freed and returned, so the borrowed constitutional weight only needed to exist long enough to make the spell the hat and survive the scheduling boundary.
    4. Because Maker’s executive voting was continuous approval rather than a long snapshot-based poll, the decisive primitive was not hold MKR for days; it was briefly exceed the current hat / incumbent backing with enough locked MKR.
    5. B.Protocol CEO Yaron Velner later told CoinDesk the team had been waiting extra days for the oracle whitelist and became curious whether the flash-loan path was possible, implying the maneuver was deliberately used to hurry a governance outcome favorable to the project.
    6. Maker governance then treated the episode as a protocol-security warning rather than a harmless one-off. Four days later, Maker published emergency mitigation spell 0xF1079CA834758b1082FB94412BbB0C9f024EA7d6; the executive text explicitly described the change set as an urgent response to flash-loan risk, raised the GSM Pause Delay from 12 hours to 72 hours “to allow governance sufficient time to react to a governance attack on the Maker Protocol,” and deauthorized both OsmMom and FlipperMom so flash-loaned governance could not as easily freeze oracle updates or liquidation flows.
  • What the attacker needed to be true:
    • Enough MKR had to be borrowable from dYdX / Aave-linked liquidity paths to overtake the incumbent executive backing, even if only briefly.
    • Maker had to count borrowed MKR as ordinary valid governance weight the moment it was locked into the vote.
    • The spell benefiting B.Protocol had to be close enough to passing that a flash-borrowed increment could accelerate it.
    • Sensitive governance-controlled actions had to remain reachable quickly enough that a temporary spell victory could matter before defenders re-voted.
    • There had to be no snapshot, seasoning period, or sufficiently long mandatory delay that would separate temporary vote acquisition from spell execution.
  • Technical anatomy worth remembering:
    • This is a governance-capture near miss, not a completed treasury seizure. The important preserved lesson is the mechanism: flash-borrowed governance weight could accelerate or potentially capture continuous-approval voting.
    • The spell B.Protocol accelerated was not arbitrary governance noise. It included B.Protocol’s own oracle-whitelist request, so the beneficiary also demonstrated the exploit path.
    • Maker’s own mitigation is the strongest evidence that the danger was real. The 2020-10-30 executive did not merely tweak parameters; it explicitly said the longer GSM existed to let governance react to an attack and removed governance’s ability to quickly touch OsmMom / FlipperMom, which only makes sense if temporary vote capture could otherwise turn into privileged oracle or liquidation control before organic governance could respond.
    • The forum disclosure preserved the exact one-block governance lifecycle that matters for future comparisons: borrowed collateral → borrowed MKR → lock/vote/lift → schedule → unwind. That is much sharper than merely saying flash loans influenced a vote, because it shows the critical scheduling boundary was inside the attacker funding window.
    • Maker’s emergency post also preserved a second important metric: the protocol counted 63,445 MKR of flash-loan-accessible liquidity while the hat held about 79k MKR, and explicitly worried about the thinner moment when a new executive first tries to replace the old one. The dangerous surface was therefore not only the current hat but the transition interval where incumbent backing temporarily thins.
    • This case is a useful precursor to later flash-loan governance attacks such as Beanstalk: it preserves the earlier stage where borrowed voting power mainly accelerated a favorable spell, but clearly exposed how a stronger payload could have done worse.
    • The control-surface lesson is about time. Continuous-approval governance plus borrowable governance tokens plus short-latency emergency modules is an attack surface even when the first public use is only a self-serving whitelist acceleration.
  • Representative addresses and control points:
    • Executive spell accelerated with flash-borrowed MKR: 0xb04A29de213411DDb7196eD1327b3B6144893E59
    • Emergency mitigation spell: 0xF1079CA834758b1082FB94412BbB0C9f024EA7d6
    • Governance call sequence called out by Maker’s incident disclosure: chief.lock() → chief.vote() → chief.lift() → chief.free() → spell.schedule() → later spell.cast() after GSM expiry
    • Emergency modules later deauthorized by mitigation spell: OsmMom (oracle freeze module) and FlipperMom (liquidations circuit breaker)
    • Borrow path described in reporting: dYdX flash loan → Aave collateral / borrow leg → MKR voting position
  • Response / mitigation:
    • Maker proposed and passed an urgent governance response on 2020-10-30.
    • The emergency forum post set an explicit interim safety target of 100,000 MKR on the hat, because the team counted 63,445 MKR of flash-loan-accessible liquidity and wanted a margin above that amount during executive transitions.
    • The emergency executive itself said the GSM Pause Delay increase from 12 hours to 72 hours was needed “to allow governance sufficient time to react to a governance attack on the Maker Protocol,” which is the cleanest primary-source statement that Maker understood the event as a constitutional-security warning rather than mere vote gaming.
    • OsmMom was deauthorized so governance could no longer use a flash-loaned spell to quickly freeze oracle updates.
    • FlipperMom was deauthorized so governance could no longer use the same path to quickly freeze or unfreeze liquidations.
    • The broader mitigation lesson was that governance token liquidity on lending venues had become part of Maker’s security boundary.

Pattern tags

  • governance-capture
  • borrowable-governance-weight
  • Maker’s emergency response shows this was not just someone sped up a favorable vote; temporary borrowed MKR briefly became constitutional truth in a system where crossing the hat and schedule() boundaries could still expose oracle and liquidation control surfaces.

Why the exploit worked

  • Maker treated currently locked MKR as fully legitimate executive-vote weight, so borrowed custody counted the same as durable constitutional ownership.
  • The decisive threshold was not own a lasting majority for days; it was briefly overtake the incumbent hat during an executive-transition window, which made the attack cheaper than headline steady-state hat numbers implied.
  • The critical governance hardening boundary sat inside the attacker funding window: the borrowed MKR only needed to survive long enough to lock() → vote() → lift() → schedule() before being freed and returned.
  • Sensitive governance-adjacent powers still sat close enough to ordinary executive flow that a temporary spell victory had real constitutional weight. Maker’s later deauthorization of OsmMom and FlipperMom is the clean proof that a short-lived hat flip could otherwise have mattered beyond symbolic vote manipulation.

Detection and audit pivots

  • Measure borrowable governance-token float against the replacement threshold, not only against the mature incumbent hat. The dangerous question is how much MKR does a fresh executive need to overtake right now?
  • Monitor for one-transaction or same-window borrow -> lock -> vote -> lift -> schedule -> unwind choreography; that sequence is a constitutional-threat signature, not just unusual market activity.
  • Inventory which executive payloads can still reach emergency modules, oracle controls, liquidation controls, or other fast privileged rails if a temporary voting bloc becomes the hat.
  • Treat new lending venues, wrapper integrations, and concentrated-liquidity changes for governance assets as governance-surface changes that can shrink the cost of a rented-majority attack.
  • Page defenders specifically on thin executive-transition windows where incumbent backing is low enough that flash-borrowable or cheaply borrowable float approaches replacement scale.

Failure-prevention checklist

  • Require a durable-time separation between acquire governance weight and exercise constitutional power; snapshotting, vote seasoning, staking lockups, or cooldown windows should make one-transaction borrowing useless.
  • Model governance-token lending markets, flash-loan venues, and delegated wrapper positions as part of the live constitutional attack surface, then size quorum / hat thresholds against borrowable float rather than circulating supply headlines.
  • Keep emergency modules, oracle-freeze rails, liquidation circuit breakers, and other fast privileged controls behind stricter authority lanes than ordinary parameter updates, or at minimum behind longer delays than one spell-lead transition.
  • Treat executive-transition thinness as its own risk state. Defenses should be sized for how much MKR does a new spell need to overtake the incumbent right now?, not just for the current steady-state hat total.
  • Predeclare emergency backstop procedure for governance capture: who can signal, what modules can be deauthorized, and which powers must become exit-only or delayed if temporary vote capture is suspected.
  • Rehearse governance attack in progress monitoring around lock() / vote() / lift() / schedule() sequences so defenders can distinguish organic governance movement from transient rented-majority choreography.

Audit prompts

  • If an attacker can borrow or temporarily control a large amount of governance token for one block or one day, what exact privileged actions can they complete before organic voters can react?
  • Which governance surfaces are truly constitutional, and which are actually emergency or operational authority that should never be reachable on the same latency as ordinary policy changes?
  • During an executive replacement, what is the minimum borrowed token quantity needed to become the hat, and how does that compare with borrowable liquidity across lending markets, DEX pools, wrappers, and custodial delegates?
  • Can a proposal be scheduled, queued, or otherwise hardened while the borrowed voting weight still exists, even if that weight disappears before cast() or final execution?
  • Are oracle-freeze, liquidation-freeze, pause, upgrade, or treasury-reach powers bundled into the same governance lane as routine whitelist or parameter changes?
  • What monitoring or guardian path triggers when vote movement arrives in one transaction, from one temporary financing route, or through a beneficiary-controlled position?

Lessons that should already be standard

  • Holds voting token at this moment is not the same thing as deserves constitutional authority; borrowed governance weight must be treated as adversarial until time has done real work.
  • Governance delay is not procedural bloat when emergency powers sit nearby. It is the buffer that keeps a transient rented majority from becoming oracle, liquidation, or treasury reality.
  • Executive-transition windows are often weaker than steady state. Security review should focus on the thinnest moment when a new proposal tries to replace the incumbent, not only the mature proposal that already sits at the top.
  • Governance-adjacent emergency modules are not harmless operational conveniences. If they can freeze markets or oracle rails quickly, they are constitutional attack surfaces.
  • A self-serving but non-catastrophic use of rented governance should be treated as a real exploit rehearsal, not as proof that the system survived.

Why this incident matters

  • It adds a valuable governance near miss to the corpus: flash-loaned constitutional power used not for a famous treasury drain, but for same-cycle acceleration of a favorable executive spell.
  • It shows that governance capture is not only about final theft events. A protocol can reveal a dangerous constitutional weakness before the catastrophic payload arrives.
  • It preserves the specific design warning that continuous-approval governance is vulnerable when borrowed voting weight can briefly outrank the incumbent and immediately reach emergency control surfaces.
  • It is a useful bridge between abstract flash-loan-governance theory and later realized treasury-drain events like Beanstalk.

Internal linkages

Control surface