Cowrie Research

treasury-vote-amplification-governance-token-neutrality-failure

13 min read

Treasury Vote-Amplification / Governance-Token Neutrality Failure

  • Name: Treasury vote-amplification / governance-token neutrality failure
  • Category: exploit pattern / governance failure / treasury-control failure / delegated-vote concentration
  • Summary: This pattern appears when a DAO treasury holds its own governance token, then treats deploy treasury assets as economically separable from reassign the votes attached to those assets even though the chosen wrapper, trust, staking program, or manager keeps those votes live. The attack is not that the beneficiary steals the treasury in one move. It is that the proposal quietly changes the future electorate by handing the treasury’s own constitutional weight to the same bloc asking to control it. Once that transfer executes, follow-on defenses become harder because the proposal did not just pass under the old rules — it also rewired who can win under the next ones. The useful review posture is to keep three questions separate: treasury governance inventory still exists, that inventory still counts as live vote power after the transfer, and that now-live vote power is large enough to change who can pass or block the next constitutional action.
  • Quick routing split: Compound goldCOMP is the clean treasury-self-delegation exemplar. Use beneficial-owner-vote-operator-separation-failure when the sharper question is broader operator-versus-principal vote control, such as exchange custody or wrapper operators voting other people’s balances, and use governance-decay-remnant-authority-capture when the sharper issue is not treasury vote-routing at all but a stale electorate still guarding live admin power. Use backstop-failure-governance-capture when the important preserved lesson is not the treasury-vote transfer itself but the inability of veto, guardian, or emergency governance machinery to interrupt the resulting electorate mutation in time.
  • What it is:
    • A protocol treasury holds a governance token whose balances still carry voting or delegation rights over treasury, upgrade, timelock, mint, or market-admin outcomes.
    • A proposal asks the DAO to move those governance tokens into a wrapper, trust, staking structure, vault, market-making program, or external manager.
    • The destination keeps the governance rights live rather than neutralizing them, and the delegatee or operating multisig is chosen by the proposal beneficiary or an aligned bloc.
    • The same governance action therefore changes both the treasury’s economic exposure and the future voting distribution.
    • Execution turns a treasury-allocation proposal into a recursive governance-capture path: the beneficiary gains more voting power precisely because the DAO approved handing it treasury assets.
  • Typical preconditions:
    • The DAO treasury holds a meaningful inventory of its own governance token or a wrapper that preserves voting rights.
    • Governance can transfer those tokens into external strategies, trusts, staking programs, or wrappers without first forcing vote neutrality.
    • The destination’s delegation policy either defaults to the beneficiary’s multisig or gives the beneficiary operational control over delegate() or equivalent voting power.
    • Quorum or decisive voting thresholds are low enough that the transferred treasury balance materially changes who can pass future proposals.
    • The DAO lacks a hard rule that treasury-owned governance tokens must stay non-voting, DAO-delegated, or isolated from vote counts.
    • Defenders rely on ad hoc delegate coordination rather than on a built-in constitutional barrier between treasury management and electorate composition.
  • Common vulnerable surfaces:
    • treasury wrappers or trusts that accept the governance token itself and preserve its voting rights
    • staking or yield programs where deposited governance tokens keep live delegation rather than becoming inert
    • governance-token treasury management proposals that route through beneficiary-controlled multisigs, vaults, or TrustSetup-style shells
    • liquidity, locking, or yield wrappers whose economics look like treasury diversification but whose delegatee policy quietly changes future governance
    • any DAO whose treasury inventory is large relative to real free-float and active delegate participation
  • Exploit sequence:
    1. A coordinated bloc accumulates enough delegated or owned governance weight to get close to quorum or majority, but not enough to dominate permanently.
    2. That bloc proposes a treasury allocation involving the protocol’s own governance token inventory.
    3. The proposal routes treasury-held governance tokens into a wrapper, trust, or manager whose delegatee policy favors the proposer or an aligned operator set.
    4. Once executed, the treasury transfer also transfers future voting weight, making the proposer’s bloc larger for subsequent votes.
    5. The bloc uses the amplified electorate to defend the transfer, block reversal, or pursue follow-on treasury, upgrade, or admin proposals.
  • Variants:
    • Explicit self-delegation capture — the wrapper or trust directly delegates treasury-held voting power to the beneficiary’s multisig.
    • Default-delegate capture — the wrapper’s default delegate or operator routing quietly sends treasury voting power to an aligned bloc even if the proposal language emphasizes only economic deployment.
    • Non-recallable vote transfer — the DAO cannot promptly claw back or neutralize the transferred votes even if it regrets the treasury move.
    • Treasury-yield governance capture — a proposal marketed as yield enhancement or treasury efficiency is really an electorate-amplification proposal in disguise.
    • Wrapper-mediated vote laundering — governance tokens remain economically in treasury strategy custody but politically in outside operator custody, blurring who really controls the votes.

Three treasury-to-electorate promotions reviewers should not collapse

  1. Treasury governance inventory still exists as a live constitutional object

    • The DAO still owns a large block of its own governance token, directly or through a wrapper that can preserve vote rights.
    • This is only the inventory question: there is dormant constitutional weight sitting in treasury form.

  2. That inventory still deserves to count as live vote power after the proposed transfer

    • The harder question is whether the destination wrapper, trust, staking program, delegate policy, or operator set leaves those votes active, reroutes them to a beneficiary, or makes them hard to neutralize later.
    • This is the vote-neutrality question: treasury inventory remained a live electorate rather than inert treasury capital.

  3. That newly routed vote power is large enough to change who can pass or block the next action

    • Even when the vote rights remain live, the constitutional danger depends on what post-execution coalition math now looks like: quorum, veto thresholds, reversal difficulty, timelock control, and follow-on proposal reach.
    • This is the power-amplification question: the treasury move also changed who governs next.

Healthy review gets sharper once teams stop flattening those three promotions into one vague question like does the treasury still own the tokens economically?.

  • Detection heuristics:
    • Ask whether transferred treasury governance tokens continue to count toward quorum, proposal thresholds, or live delegated voting power after execution.
    • Model post-execution vote distribution, not just pre-vote coalition math. If the proposal changes who can win the next vote, it is constitutional, not merely financial.
    • Inspect who controls delegation on the destination wrapper or trust: DAO, neutral custody, beneficiary multisig, or some default delegate.
    • Treat any treasury proposal involving the governance token itself as a red-flag item requiring separate analysis of vote routing, recall rights, and post-transfer governance power.
    • Compare treasury-held governance inventory with real active float. If treasury inventory is large enough to swing outcomes, its delegation policy is part of the root trust boundary.
    • Distinguish custody hardening from constitutional hardening. A phase-gated trust shell, narrower multisig, or constrained strategy verb set may reduce operational discretion while leaving the decisive vote-routing outcome untouched.
    • Ask whether the DAO can unwind the investment without first winning another vote against the amplified bloc it just created.
  • Defenses:
    • Keep treasury-held governance tokens vote-neutral by default.
    • If treasury governance tokens must move into an external structure, force delegation back to a neutral DAO-controlled address or explicitly strip their voting rights from governance calculations.
    • Separate treasury allocation from delegate assignment; require an independent governance step for any proposal that changes how treasury-held voting power is exercised.
    • Quarantine or discount treasury-controlled governance balances when computing quorum and decisive voting thresholds.
    • Give the DAO a fast, clearly scoped recall path that can neutralize delegated treasury voting power before a hostile bloc can use it in follow-on proposals.
    • Treat treasury-governance-token deployments as constitutional changes subject to stronger review, longer delays, or guardian veto, not as routine treasury management.

What sound design looks like

  • Treasury-held governance inventory defaults to constitutional neutrality: non-voting, delegated to a neutral DAO-controlled sink, or explicitly excluded from quorum and decisive-vote math until governance deliberately says otherwise.
  • Economic deployment and electorate mutation are separate actions. A treasury strategy, trust, wrapper, or staking program may manage the token’s economics, but it cannot silently inherit delegate() authority or future constitutional weight as part of the same approval.
  • The protocol can state the post-execution vote map in operator terms before any treasury move lands: which bloc, multisig, wrapper, or manager would control the votes immediately after execution, who could reverse that state, and how much active float would remain outside that bloc.
  • Any non-neutral treasury-governance posture is revocable on shorter latency than the next hostile follow-on vote. Recall, undelegate, or vote-neutralization tooling should outrun electorate amplification rather than depend on winning a second race against the newly enlarged bloc.
  • Wrappers and treasury shells are designed so deposited governance token never quietly means beneficiary gains future constitutional weight. If a structure preserves voting rights at all, that fact is explicit, separately approved, and easy to unwind.
  • Custody hardening and constitutional hardening are kept separate in review. A shell that narrows invest/divest verbs, slippage parameters, or operator permissions does not get credit for safety if it still routes treasury votes into the beneficiary bloc.

Failure-prevention checklist

  • Make vote neutrality the default treasury posture for the governance token itself: undelegated, DAO-delegated to a neutral sink, or explicitly excluded from governance counts.
  • Treat any proposal that moves treasury-held governance tokens as a constitutional proposal, not a portfolio-management proposal, and route it through stronger review, longer delay, or explicit guardian scrutiny.
  • Separate economic deployment rights from vote-routing rights in code. A trust, wrapper, staking vault, or manager that can hold treasury governance tokens should not get implicit control of delegate() or equivalent governance rights.
  • Require an independent approval step for any change to the delegatee of treasury-held governance inventory, even when the treasury-transfer leg is already approved.
  • Encode a fast recall / neutralization path that can pull delegated treasury voting power back to a neutral state before the recipient bloc can use it in a follow-on vote.
  • Model post-execution governance state before approving the proposal: who crosses quorum, who can block reversal, who can seize timelock / treasury / mint / market-admin surfaces, and how much active float remains outside the beneficiary bloc.
  • Cap or haircut treasury-controlled governance balances in quorum and decisive-vote calculations if the protocol cannot guarantee strict vote neutrality at all times.
  • Make wrapper, trust, and staking documentation state vote semantics plainly. Treasury deposit should never quietly mean beneficiary gains future electorate weight.
  • Drill defender responses for electorate-mutation proposals the same way teams drill arbitrary-upgrade or treasury-sweep proposals; the dangerous object is the change in who can win next, not only the first transfer itself.
  • Audit legacy treasury programs and dormant wrappers regularly. A once-benign yield program can become a capture path later if active float shrinks and treasury inventory becomes constitutionally dominant.
  • Review any neutral by default, live after phase / activation wrapper logic as a constitutional state machine, not just a custody state machine. The dangerous transition is often the one that wakes treasury votes up later under beneficiary-controlled operating assumptions.

Audit prompts

  • If this proposal transfers treasury-held governance tokens, who controls delegation immediately after execution: DAO, neutral sink, beneficiary multisig, wrapper default, or some hidden operator path?
  • Do transferred treasury balances still count toward quorum, proposal thresholds, or vote outcomes, and if so under whose delegatee?
  • Can the beneficiary bloc use the transferred treasury votes to block reversal, pass a follow-on proposal, or seize a stronger root object such as timelock admin, treasury release, proxy upgrade, or mint rights?
  • Is the protocol reviewing only the economic thesis of the treasury move, or also the post-execution electorate map and reversal difficulty?
  • Are treasury-allocation and delegate-assignment actions technically separable, or does one governance action silently do both?
  • What recall path exists if the DAO realizes after execution that it just amplified an aligned bloc with treasury-owned votes? How fast can that path land relative to the beneficiary’s next proposal?
  • How large is treasury-held governance inventory relative to active float, live delegate participation, and quorum? Could one treasury move meaningfully reprice who governs the system?
  • Does the destination wrapper or trust preserve default vote rights during migrations, emergency exits, partial withdrawals, or phased invest / divest transitions?
  • Are dormant treasury wrappers, trusts, or staking programs still carrying live delegated voting weight that governance participants have stopped modeling?
  • Would a real governance backstop treat proposal changes who votes next as an interrupt-worthy root object, or only notice once treasury assets are already gone?

Lessons that should already be standard

  • Treasury deployment of the governance token is governance design, not treasury ops. If the asset being deployed defines the electorate, the proposal is rewriting the constitution.

  • The DAO still owns the tokens economically is not a safety argument if someone else controls how those tokens vote.

  • Vote neutrality for treasury inventory should be the boring default. Requiring people to notice every wrapper-specific delegation footgun is not a serious control model.

  • Post-execution vote maps matter more than pre-vote coalition math. A proposal that is barely safe before execution may be irreversible after execution because it enlarges its own bloc.

  • Recall rights are not optional cleanup tooling. If treasury votes can ever leave a neutral state, the protocol needs a credible path to neutralize them faster than the amplified bloc can exploit them.

  • Low active float turns treasury-held governance balances into latent constitutional explosives. The danger grows as participation decays, even if the wrapper design never changes.

  • Backstops must understand electorate mutation explicitly. A guardian that only watches for direct treasury sweeps can still lose the more subtle race where the treasury is first turned into votes and only later into irreversible control.

  • Every DAO treasury proposal involving the native governance token should answer one blunt question before approval: after this executes, who gets harder to vote out?

  • A safer-looking trust wrapper is not automatically a safer constitutional wrapper. If the proposal still leaves treasury votes live under the beneficiary’s delegate path, the shell only changed optics, not the root capture mechanic.

  • High-signal incidents:

Internal linkages

Control surface

Graph View

Backlinks