Borrowable Governance Weight / Unsnapshotted Voting Power

  • Name: Borrowable governance weight / unsnapshotted voting power
  • Category: exploit pattern / governance failure / flash-loan voting / vote-eligibility timing failure
  • Summary: This pattern appears when governance treats current custody or freshly minted deposit-based weight as immediately legitimate constitutional authority, without a prior-block snapshot, seasoning period, or long enough vote-to-execution gap to separate temporary balance-sheet control from durable political consent. The attacker does not need to steal governance tokens permanently. They only need to rent, borrow, or briefly manufacture enough vote-bearing balance to cross the decisive threshold while the system still believes who holds the weight right now is the same thing as who should be allowed to decide root authority. MakerDAO’s 2020 flash-loan near miss showed the continuous-approval branch: temporarily borrowed MKR could push an executive spell over the incumbent and threaten oracle or liquidation controls before organic holders could counter-vote. Beanstalk showed the harsher deposit-minting branch: flash-loaned stablecoins were converted into whitelisted LP deposits that minted Stalk immediately, letting one transaction rent a supermajority and execute a malicious proposal.
  • What it is:
    • Voting power comes from balances, deposits, LP positions, or governance receipts that become eligible immediately or near-immediately.
    • Governance uses a live balance snapshot, same-window accounting state, or very short execution path rather than a prior-state ownership test.
    • Temporary capital from flash loans, ordinary lending markets, concentrated exchange liquidity, or rapidly manufactured vote-bearing positions can therefore become valid constitutional weight.
    • The dangerous question is not just can someone vote with borrowed assets? but can they vote, win, and reach meaningful execution before those assets have to leave?
    • Once the answer is yes, governance has become a liveness race between attacker-side balance-sheet assembly and defender-side social coordination.
  • Typical preconditions:
    • Governance token balances, deposited receipt tokens, or protocol-native voting units become votable immediately on acquisition or deposit.
    • There is no prior-block / prior-epoch snapshot, mandatory holding period, or sufficiently long seasoning delay before fresh voting weight counts.
    • Borrowable liquidity exists at enough scale to cross quorum, supermajority, incumbent-approval, or emergency thresholds.
    • The protocol couples vote acquisition and meaningful execution closely enough that temporary voting power can still matter before it disappears.
    • Governance retains authority over treasury transfers, upgrades, oracle controls, liquidation controls, or arbitrary execution payloads.
    • Defenders rely on reactive counter-voting, social alerting, or multisig intervention rather than on structural separation between fresh balance acquisition and governance rights.
  • Common vulnerable surfaces:
    • continuous-approval governance where the leading proposal only needs to exceed the current incumbent backing
    • emergency governance paths that allow fast execution once a supermajority threshold is crossed
    • systems where LP tokens, deposits, or receipt positions mint voting power immediately on deposit
    • governance designs that measure weight from current balances at vote time rather than from a prior checkpoint
    • DAO architectures where proposal execution can reach upgrade, treasury, or arbitrary-call surfaces within the same short window that fresh voting power remains available
  • Exploit sequence:
    1. The attacker identifies how voting weight becomes live: borrowed governance token custody, fresh LP deposits, newly minted receipt positions, or another immediate-balance path.
    2. The attacker arranges temporary capital at sufficient scale through a flash loan, borrow loop, or other short-lived funding route.
    3. That capital is converted into vote-eligible balances quickly enough that the system counts it as ordinary governance weight.
    4. The attacker pushes the target proposal, emergency path, or incumbent-overturn threshold past the decisive line.
    5. Before the temporary capital must unwind, the protocol either executes the payload or reaches a state from which defenders cannot respond fast enough.
    6. The attacker unwinds the temporary positions, repays borrowed capital, and keeps whatever treasury access, code execution, or governance victory the short window purchased.
  • Variants:
    • Flash-loan vote acceleration — borrowed governance tokens briefly overtake a live incumbent or accelerate a favorable spell without necessarily draining funds immediately.
    • Flash-loan emergency supermajority — temporary capital crosses a fast-path threshold and directly executes a proposal or emergency upgrade.
    • Deposit-to-vote manufacture — borrowed assets do not vote directly, but can be transformed into vote-bearing LP, staking, or receipt positions that do.
    • Borrow-to-vote governance — the weight is borrowed through ordinary lending markets or rehypothecation over a short but non-zero window rather than a pure one-block flash loan.
    • Same-window proposal-and-execution collapse — even if proposing requires earlier setup, the decisive vote acquisition and payload execution still fit inside the period where the attacker only has temporary weight.

Three governance-authority promotions reviewers should not collapse

  1. Temporary balance-sheet control exists

    • Borrowable tokens, flash-loanable stablecoins, mintable LP receipts, or wrapper paths mean an attacker can briefly assemble something that looks like governance weight.
    • This is only the weakest fact: capital can reach the vote surface at all.
  2. That temporary control still counts as constitutional weight for this exact vote path

    • The harder question is whether the protocol promotes freshly acquired balances, fresh LP deposits, new staking receipts, or same-window wrapper mints into legitimate voting power before any prior-block snapshot, seasoning period, or exclusion rule says otherwise.
    • Most of the real danger sits here: governance has decided that balance is present now is close enough to stake deserves to decide root authority.
  3. That accepted weight still deserves this much execution reach before defenders can react

    • Even if the system accepts the weight, the next question is what it can actually do before it disappears: overtake the live hat, queue an executive spell, cross an emergency threshold, execute arbitrary calls, or touch treasury / oracle / upgrade authority.
    • This is the decisive promotion, because temporary weight only becomes catastrophic when the constitution lets it cross a meaningful execution boundary faster than defenders can neutralize it.

Healthy review gets materially sharper once teams stop flattening those three promotions into one vague claim that borrowed tokens can vote.

  • Detection heuristics:
    • Ask when a newly acquired balance first becomes votable. If the answer is immediately, governance should be modeled as borrowable unless liquidity is provably unavailable.
    • Measure attacker-to-threshold time against defender-to-response time. If the attacker can reach execution before delegates can coordinate a counter-vote or pause, the system is structurally fragile.
    • Treat vote-bearing LP or receipt tokens as more dangerous than plain governance tokens when borrowed stablecoins can manufacture the vote-bearing position inside the attack path.
    • Inspect emergency or continuous-approval branches separately from ordinary governance. The shortest path, not the average path, defines the exploit surface.
    • Model not only can flash loans buy the token? but also can flash loans create the vote-bearing wrapper that the protocol counts?
    • Treat borrowed-liquidity markets for governance assets as part of the governance security boundary, not as external market context.
  • Defenses:
    • Use prior-block or prior-epoch snapshots so governance eligibility comes from pre-existing ownership rather than current-transaction custody.
    • Impose seasoning or holding periods before newly acquired balances, deposits, or receipt positions can vote.
    • Separate vote succeeds from payload executes with a real delay long enough for defenders to react.
    • Scope emergency paths narrowly and avoid letting fresh voting weight reach arbitrary execution or root admin authority.
    • Discount or exclude very recently created vote-bearing wrappers, LP positions, or deposited balances from decisive governance thresholds.
    • Monitor borrowable liquidity in governance assets and treat large new lending markets or wrapper integrations as governance-surface changes, not just market-structure changes.

What sound design looks like

  • Governance keeps temporary balance-sheet control exists, that control counts as constitutional weight, and that accepted weight can now move root authority as separate states rather than one blurred moment called the attacker got the tokens.
  • Governance eligibility is anchored to pre-existing stake rather than live transactional custody: prior-block snapshots, epoch checkpoints, or holding-period seasoning mean who votes is decided before the attacker assembles temporary capital.
  • Deposit wrappers, LP receipts, staking claims, and other derived vote-bearing positions do not become immediately constitutional just because they were minted this block or this proposal window.
  • Emergency or continuous-approval paths cannot turn a brief majority into immediate root authority; decisive governance always crosses a defender-readable delay before treasury, upgrade, oracle, mint, or arbitrary-call surfaces move.
  • Borrowable-liquidity changes are treated as governance-surface changes. If a new lending market, wrapper, or pool makes the governance asset rentable at scale, governance timing and thresholds are re-evaluated rather than left on autopilot.
  • The protocol can say plainly which vote-bearing balances are intentionally excluded, delayed, haircutted, or neutralized, instead of assuming every token-shaped balance deserves immediate constitutional weight.

Failure-prevention checklist

  • Treat temporary control exists, temporary control counts as constitutional weight, and accepted weight can cross this execution boundary as separate policy decisions in code, docs, and governance review.
  • Require prior-state checkpoints, epoch snapshots, or explicit seasoning windows before newly acquired balances, deposits, or wrappers can vote.
  • Separate proposal success from execution with enough delay for human defenders to see, classify, and interrupt a hostile borrowed-weight path.
  • Keep emergency fast paths narrow; do not let freshly acquired voting weight touch arbitrary execution, root upgrade authority, treasury release, or oracle / liquidation controls in one short race.
  • Exclude, delay, or haircut freshly minted vote-bearing wrappers, LP receipts, staking receipts, or governance derivatives until they survive beyond the attacker funding window.
  • Review governance whenever a new borrow market, flash-loan route, wrapper integration, or concentrated-liquidity venue materially changes how rentable the governance asset or its vote-bearing wrappers have become.
  • Measure active float and borrowable float together. If enough temporary capital can cross quorum or an emergency supermajority, governance is under-collateralized against rental attacks.
  • Treat continuous approval and ordinary proposals as separate attack surfaces; the shortest route to meaningful execution defines the real risk.
  • Add explicit neutralization paths for suddenly concentrated temporary voting blocs, especially on systems with treasury-held governance inventory or emergency modules.
  • Audit deposit-to-vote transformations, not just direct token borrowing. Flash-loaned stablecoins that can mint vote-bearing LP or receipt positions are governance liquidity too.
  • Rehearse defender paging and cancellation for borrowed-weight paths so the protocol is not discovering its real coordination latency during the first live vote race.

Audit prompts

  • Which governance-authority promotion is happening at each step here: temporary balance-sheet control, accepted constitutional voting weight, or actual ability to cross a meaningful execution boundary before defenders can respond?
  • When does a newly acquired balance first become vote-eligible: same block, same proposal window, next block, next epoch, or only after a holding period?
  • Can borrowed assets be transformed into vote-bearing wrappers, LP positions, staking receipts, or other governance weight faster than defenders can respond?
  • How much borrowable or flash-loanable liquidity exists relative to quorum, supermajority thresholds, and the active float that usually participates?
  • Does any emergency or continuous-approval path let temporary weight reach treasury transfer, upgrade, oracle, liquidation, mint, or arbitrary-call authority before a real delay expires?
  • If an attacker briefly crosses the decisive threshold, what exact object do defenders still control directly: vote cancellation, queue cancellation, guardian pause, vote-neutralization, or only another governance race?
  • Are newly integrated lending markets, AMM pools, wrappers, or staking products changing the governance rental surface without any governance-specific review?
  • Which balances are intentionally non-voting, delayed, or haircutted, and is that policy enforced in code or only assumed in social process?
  • Does the protocol model only direct borrowing of the governance token, or also borrow-and-wrap / borrow-and-deposit routes that manufacture equivalent voting power?
  • How quickly could delegates, guardians, or councils recognize and respond to a borrowed-weight proposal compared with the attacker’s path from borrowed balance to queued execution?
  • If active participation keeps shrinking, does the same old threshold now imply that a flash-loanable or cheaply borrowable position can become constitutionally decisive?

Lessons that should already be standard

  • Borrowable capital can touch the vote surface, that capital deserves constitutional weight, and that accepted weight can cross a root-authority boundary right now are three different claims.
  • Governance based on live custody is governance based on credit markets, whether the docs admit it or not.
  • No one can borrow enough of the token today is not a durable security argument; wrapper design, lending markets, and liquidity venues change faster than constitutions do.
  • Vote-bearing wrappers are governance assets, not harmless treasury or LP plumbing. If they mint immediately, they belong in the threat model immediately.
  • Emergency governance without vote seasoning is often just a faster constitutional race for the attacker, not a stronger defense for the protocol.
  • Defender time matters more than theoretical quorum purity. A protocol that needs hours or days to react cannot safely let one-block or same-window capital become decisive authority.
  • Governance thresholds should be evaluated against rentable float, not just total supply or treasury rhetoric.
  • Borrowed-weight attacks are not only flash-loan governance. Ordinary short-window borrowing, rehypothecation, and deposit-manufactured vote rights can be enough.
  • Every protocol using token balance as constitutional weight should be able to answer one blunt question: what prevents this balance from being rented just long enough to govern?

Case splits worth preserving

  • MakerDAO / B.Protocol is the clean continuous-approval hat flip precursor: the attacker only needed borrowed MKR long enough to lock -> vote -> lift -> schedule before returning the loan. The important governance question is not just can flash-borrowed weight win? but what meaningful scheduling or execution boundary can it cross before defenders can restore the old hat?

  • Beanstalk is the clean borrow -> deposit -> mint voting wrapper -> execute realization: the borrowed capital did not need to borrow governance tokens directly because the protocol itself manufactured immediate constitutional weight from fresh LP deposits. The sharper review question becomes which deposit receipts or wrappers should never have become emergency voting power inside the attacker funding window?

  • High-signal incidents:

    • MakerDAO B.Protocol flash-loan governance-vote acceleration near miss (2020-10-26) — the continuous-approval precursor: flash-borrowed MKR did not directly drain treasury assets, but it proved that a temporarily rented vote bloc could overtake Maker’s live executive ranking, cross the schedule() boundary before loan unwind, and forced Maker to lengthen the GSM delay plus deauthorize OsmMom and FlipperMom.
    • Beanstalk governance takeover (2022-04-17) — the canonical realized case: flash-loaned stablecoins were converted into whitelisted LP deposits, those deposits minted Stalk immediately, and the attacker crossed Beanstalk’s > 2/3 emergency threshold quickly enough to execute malicious proposal logic and drain the protocol.

Internal linkages

Control surface