Cowrie Research

treasury-governance-token-vote-neutrality-discipline

13 min read

Treasury Governance-Token Vote-Neutrality Discipline

  • Name: treasury governance-token vote-neutrality discipline
  • Category: governance-design reference / positive-design companion to treasury vote-amplification / constitutional treasury-control discipline
  • Summary: A DAO treasury holding its own governance token should assume that treasury management and electorate management are the same control surface unless the protocol proves otherwise. The healthy default is vote neutrality: treasury-held governance inventory should be non-voting, delegated to a neutral sink, or excluded from decisive-vote math until governance makes a separate, explicit, and reversible choice to use those votes. This note exists to keep the positive-design target explicit instead of forcing readers to infer it only by inverting governance-token neutrality failure, Compound goldCOMP, or the broader defender-path stress described in governance backstop scope and intervention-latency discipline.
  • Why this note exists:
    • The exploit-pattern note already preserves the negative family where a treasury proposal quietly rewrites who governs next by moving treasury-held voting power into a beneficiary-controlled wrapper, trust, or multisig.
    • This note preserves the sharper healthy-side question: what should a protocol do so treasury deployment of the native governance token never silently mutates the electorate?
    • Governance-token treasury inventory is a constitutional object, not just a balance-sheet object. The safe design problem is not only who earns yield on it, but who speaks with it, how quickly that can change, and how reversibly the system can neutralize it.

What this note means by vote neutrality

  • Vote neutrality means treasury-held governance inventory does not quietly count as live constitutional power for a proposal beneficiary, strategy operator, wrapper default delegate, or other aligned bloc.
  • A neutral treasury-governance posture can be implemented in different ways:
    • undelegated balances that cannot affect quorum or vote totals
    • delegation to a DAO-controlled neutral sink whose mandate is do not vote except under separately authorized constitutional process
    • explicit exclusion of treasury-controlled balances from quorum / decisive-vote calculations
    • wrappers or staking structures whose deposited balances either lose vote rights or route those rights back to a neutral DAO-controlled delegate
  • The useful question is not does the DAO still economically own the tokens? It is after this treasury move lands, who becomes harder to vote out?

The main assumptions a healthy treasury-governance-token policy should make explicit

1. Treasury inventory of the native governance token is constitutional inventory

  • If the treasury asset itself defines quorum, proposal thresholds, or decisive voting power, then deploying that asset is governance design.
  • A yield, staking, market-making, or trust proposal involving the native governance token should be reviewed like a constitutional change, not like ordinary treasury diversification.
  • The protocol should say plainly whether treasury-held governance inventory is meant to be politically inert, politically active under DAO control, or politically unavailable by default.

2. Economic deployment and vote routing must be separable

  • A healthy wrapper or trust can manage custody, staking, or yield strategy without inheriting discretionary control over delegate() or equivalent voting rights.
  • If a single proposal both moves the treasury tokens and reassigns their vote path, that proposal is combining two control surfaces that should usually be distinct.
  • The safe default is treasury transfer does not change delegatee. Any change in vote routing should require a separate, explicit, reviewable action.

3. Post-execution governance state matters more than pre-vote coalition math

  • The important question is not only whether the proposal can pass under the old electorate.
  • The sharper question is what the electorate looks like after execution: who crosses quorum then, who can block reversal, and whether the transfer creates a self-reinforcing constitutional bloc.
  • A proposal that appears reversible before execution can become practically irreversible after execution if it amplifies its own beneficiary with treasury-owned votes.

4. Recall and neutralization must outrun the next hostile follow-on vote

  • Vote neutrality is not only a static policy question. It is also a latency question.
  • If treasury-governance votes can ever leave neutral state, the protocol needs a faster path to pull them back than the beneficiary has to use them in a second proposal.
  • If reversal still depends on winning a normal governance race against the newly enlarged bloc, the supposed neutrality policy is already too weak.

5. Wrapper defaults are governance policy, not implementation detail

  • Default delegatee settings, migration behavior, emergency-exit paths, and phased invest/divest logic all affect who controls treasury votes.
  • A design is unsafe if the proposal text talks about yield while the wrapper documentation or code quietly talks about delegate to operator multisig.
  • Treasury wrappers should make vote semantics obvious enough that reviewers can reason about them without reconstructing hidden operator assumptions from code.

6. Active-float decay makes old treasury structures more dangerous over time

  • A treasury wrapper that looked harmless when participation was high can become decisive later if voter engagement falls and treasury inventory becomes a larger fraction of live float.
  • Governance-token treasury structures need recurring review as electorate conditions change, not just one-time approval when the program launches.
  • Vote-neutrality policy should be robust to shrinking participation, not only to the day-one governance environment.

7. Governance backstops should treat electorate mutation as a root object

  • Guardians, timelocks, break-glass paths, and counter-governance runbooks should explicitly classify proposal changes who votes next as an interrupt-worthy event.
  • A treasury proposal that does not immediately steal funds can still be the cleanest path to later irreversible control.
  • If the backstop only watches for direct treasury sweeps or arbitrary upgrades, it may miss the earlier and more dangerous constitutional step.

What sound design looks like

  • Treasury-held governance inventory defaults to constitutional neutrality: it does not quietly count toward an operator-controlled voting bloc, and its treatment is legible in both policy and code.
  • Treasury strategy approval and treasury vote-routing approval are distinct governance actions with distinct review paths, delay assumptions, and operator permissions.
  • The DAO can state the post-execution electorate map before approving any treasury-governance-token move: who controls votes immediately after execution, who can reverse that state, and how much active float remains outside the beneficiary path.
  • Wrapper, trust, and staking designs make the neutral path the easy path. Deposited governance tokens either stay inert, route to a neutral sink, or require an extra explicit step before becoming live voting power.
  • Recall, undelegate, or neutralization tooling is faster than follow-on governance capture. The system can restore neutrality before an amplified bloc can convert treasury votes into stronger root authority.
  • Periodic review keeps neutrality assumptions current as active float, treasury inventory share, wrapper design, and governance participation change.

Useful positive design shapes

1. Neutral sink delegation

  • Treasury-held governance tokens delegate to a DAO-controlled sink address whose standing mandate is abstention or bounded constitutional use only.
  • This keeps the votes from silently following whichever wrapper, trust, or strategy currently custodies the tokens.
  • The sink should be operationally boring and politically legible: everyone knows where the votes rest and what process is required to move them.

2. Vote-stripping wrappers or governance-excluded accounting

  • Wrappers, staking vaults, or trust structures can preserve economics while stripping or excluding governance rights from decisive-vote calculations.
  • The point is not necessarily to destroy the votes forever. The point is to stop treasury yield programs from quietly doubling as electorate-rewrite programs.
  • If the protocol cannot implement strict stripping, it should at least make exclusion or neutral delegation unavoidable.

3. Split approval model: economic deployment first, vote activation second

  • Treasury moves involving the governance token should default to two explicit approvals:
    1. approve custody / yield / treasury deployment
    2. separately approve any non-neutral use of the attached voting rights
  • This lets delegates review economic and constitutional risk independently and makes hidden vote routing much harder to smuggle through a treasury proposal.

4. Fast neutrality switch and recall path

  • If treasury votes ever become live outside neutral state, the protocol should retain a narrowly scoped emergency path to undelegate, redelegate to the neutral sink, or otherwise suspend those votes before a follow-on proposal lands.
  • The safe design question is not only can we claw assets back? but can we de-amplify the newly enlarged bloc before it governs again?

5. Post-execution electorate modeling as part of proposal review

  • Proposal review should include a mandatory after execution governance map: beneficiary-controlled votes, neutral votes, recoverable votes, and quorum impact.
  • This is the constitutional equivalent of stress testing. A treasury motion involving native governance tokens should not pass review without a public model of its new electorate shape.

6. Periodic neutrality audits for dormant wrappers and changing float

  • DAO operations should periodically inventory every trust, wrapper, staking program, market-making arrangement, and custody shell holding the native governance token.
  • The review should ask whether those balances still vote, under whose delegatee, whether recall still works, and whether declining participation has made them newly dangerous.

Red flags that usually mean neutrality is only cosmetic

  • treasury-held governance balances remain delegated to a beneficiary multisig, wrapper default, or external operator after a treasury management proposal lands
  • a single proposal both moves treasury governance tokens and changes where those votes point
  • the destination wrapper documentation emphasizes yield or custody but is vague about vote rights, delegatee defaults, or reversal mechanics
  • reversing the treasury vote routing would require winning a second ordinary governance vote against the newly amplified bloc
  • treasury-governance inventory is large relative to active float, but no one models its quorum effect after execution
  • dormant wrappers or trusts still carry live delegated voting power because the program is considered ops rather than constitutional
  • the only backstop monitors direct treasury outflows and ignores proposals that mutate who votes next

Design questions worth asking first

  • Does treasury-held inventory of the native governance token vote today, and if so under whose delegatee?
  • If a proposal moves treasury governance tokens, does that same action also change who controls those votes immediately after execution?
  • What does the post-execution electorate map look like, and who becomes harder to vote out because of the transfer?
  • Can the DAO neutralize or recall those votes faster than the beneficiary can use them in the next proposal?
  • Are treasury strategy wrappers, trust shells, and staking programs technically unable to inherit vote-routing authority, or are operators just trusted not to use it?
  • Has the protocol reviewed how shrinking active float changes the danger of old treasury-governance programs?
  • Would the governance backstop classify this proposal as an electorate-mutation event worth interrupting, or only react after funds or admin rights are already gone?

Failure-prevention checklist

  • Make treasury-held balances of the native governance token vote-neutral by default: undelegated, routed to a neutral sink, or excluded from decisive-vote math.
  • Require separate governance approval for any non-neutral use of treasury-owned voting rights, even when custody, staking, or yield deployment of the same tokens is already approved.
  • Ensure wrappers, trusts, and treasury shells cannot quietly inherit delegate() or equivalent vote-routing power as an incidental side effect of receiving treasury assets.
  • Publish post-execution electorate modeling for every proposal involving treasury-held governance tokens: quorum impact, beneficiary-controlled votes, reversal difficulty, and active-float concentration.
  • Keep a narrowly scoped fast path to restore neutrality: undelegate, neutral-sink redelegation, vote suspension, or other bounded constitutional control.
  • Review treasury-governance-token programs periodically as active participation changes. A once-benign structure can become decisive later.
  • Treat wrapper defaults, migration logic, phased invest/divest controls, and emergency exits as governance policy surfaces, not implementation details.
  • Add governance-specific proposal review prompts for does this move treasury votes as well as treasury assets? and who becomes harder to remove afterward?
  • Integrate electorate-mutation alerts into governance monitoring, guardian review, and incident-response runbooks.
  • Audit dormant treasury structures and legacy wrappers for live delegated votes, stale neutrality assumptions, and broken recall paths.

Audit prompts

  • After this proposal executes, who exactly controls the votes attached to treasury-held governance inventory?
  • Are economic deployment and delegate assignment technically separable, or does one action silently do both?
  • Do treasury-controlled balances still count toward quorum, proposal thresholds, or decisive-vote totals while outside neutral state?
  • Could the beneficiary bloc use the transferred treasury votes to block reversal or pass a stronger follow-on proposal?
  • What explicit neutralization path exists, and how fast can it land relative to the next hostile governance action?
  • Does the wrapper or trust preserve, strip, or reroute votes during migrations, partial withdrawals, emergency exits, or phased investment transitions?
  • How large is treasury-held governance inventory relative to active float and real delegate participation today, not only when the structure was first approved?
  • Which governance monitoring or backstop controls would fire if a treasury proposal also mutates the future electorate?

Lessons that should already be standard

  • Treasury deployment of the native governance token is governance design. If the asset defines the electorate, the treasury proposal is constitutional by default.
  • Economic ownership is not enough. If someone else controls how treasury-held governance balances vote, they control part of the constitution.
  • Vote neutrality should be boring and explicit, not an inference reviewers must reconstruct from wrapper code and forum arguments.
  • The dangerous question is usually who governs next?, not only who receives custody today?
  • Recall and neutralization speed matter as much as initial policy. A reversible-neutrality story that loses the race is not much of a defense.
  • Low active float turns old treasury-governance programs into latent capture paths even when no code changed.
  • Governance backstops need to watch electorate mutation explicitly. Waiting for direct treasury loss is often waiting one step too late.
  • Every treasury proposal involving the native governance token should answer one blunt constitutional question before approval: after this executes, who gets harder to vote out?

How to use this note with the exploit corpus

  • Start here when the sharper design question is how should a DAO hold or deploy its own governance token without quietly changing who governs next?
  • Use governance-token neutrality failure when the main task is classifying the negative family.
  • Use this note when the next task becomes what neutral default, split approval, wrapper policy, and recall path should have existed before treasury deployment of governance inventory was allowed?
  • Pair with governance backstop scope and intervention-latency discipline when the sharper follow-up is who should have been able to interrupt electorate mutation and how fast.
  • Pair with decommissioning authority-extinguishment discipline when the risk mainly survives in stale treasury structures or old wrappers that should already have been retired.

Internal linkages

Control surface

Graph View

Backlinks