Governed Treasury Release

Under normal operation the Treasury deploys capital exclusively through its autonomous market-making logic. No discretionary transfer exists — with one deliberately narrow, deliberately visible exception: token holders may collectively approve a one-off release of treasury capital to a stated destination. This page describes that mechanism precisely, because its limits are the point.

Who proposes, who decides

A release proposal can be submitted by exactly one address: the launch's designated team address, fixed at deployment. This is an identity check, not a holding threshold — no whale can propose a release, and neither can the team from any other wallet. (The openness is inverted for shutdown proposals, which any 0.05% holder may submit and the team cannot monopolise — the two proposal types have opposite proposer rules on purpose.)

The team proposes; holders decide. A proposal names the asset type (ETH, tokens, or both), the amounts, the destination, and an evidence hash — an on-chain commitment to off-chain justification that voters can verify before voting. Then the standard governance machinery runs: a 7-day voting window, snapshot-weighted votes, 50% quorum of external supply, simple-majority approval. After the window closes there is a 7-day execution window; a proposal not executed in time expires. A 7-day cooldown separates consecutive proposals.

The hard caps

Two independent caps bound every release, both hardcoded constants enforced in code at execution — not policies:

• ETH: at most 20% of the Treasury's live market-making WETH, measured at execution time. The basis is what the Treasury actually holds — team, supporter, and ecosystem funds are not in it and are therefore untouchable by this mechanism entirely.
• Tokens: at most 2% of total token supply — a fixed basis that does not grow with treasury inventory.

The caps are per-proposal, and the cooldown makes them per-fortnight in practice. A team that wanted to drain a treasury through governance would need a majority of external holders to approve it, repeatedly, in public, 20% at a time — which is no longer draining, but the holders choosing to disburse their own system's capital.

Quorum honesty

Quorum is measured against external supply — total supply minus the Treasury's holdings and the canonical pool's holdings, since neither can vote and neither should inflate the denominator. One subtlety is worth knowing: the pool's balance is captured at proposal submission and reused at execution, rather than read live. Reading it live would open a window after voting ends in which the denominator could be nudged to flip a quorum result; capturing at submission closes that window and makes the quorum arithmetic fixed and observable for the proposal's whole life.

Token releases move the floor

Releasing tokens from the Treasury increases circulating supply, which directly lowers the dynamic floor:

P_floor = ethReserve / (totalSupply − treasuryTokenBalance)

A lower floor shifts the entire anchor band built on it — accumulation and liquidation thresholds alike. The GovernanceModule exposes a projection (getFloorProjection) so voters can see the post-release floor before casting a vote, not after.

The arbitrator's one lever

The arbitrator may cancel an active proposal — but only during its open voting window, where the act is visible to every voter, and never during execution. Cancellation is a one-way brake: it can stop a vote from completing, and can never pass, accelerate, or execute one.

What this mechanism is not

It is not a team withdrawal path — the team cannot move a single wei of treasury capital without a passed holder vote. It is not a recurring budget — each release is a discrete, evidenced, capped event. It is not a lever over the engine — market-making behaviour is untouched by any release, before or after. And it is not parameter governance — no vote, by anyone, can alter a deployed launch's configuration.