How governance works

Governance is the Boardroom: an OpenZeppelin Governor (ICGovernor) plus a TimelockController, voting on gINVEST.

The important structural fact is that the Timelock is the Treasury's authority. It holds authority.governor() and calls every onlyGovernor function directly — on the Treasury, the token, the pool-fee collector, the accumulator, the feeds, staking and the distributor. There is no admin key that can move funds, and there is no relay contract in between: a proposal names the real target contract and its own ABI encoding.

That is the finished shape. The handoff has not happened

Today the deployer's EOA still holds authority.governor, authority.guardian and the Treasury's RESERVEDEPOSITOR role — interim custody, to be revoked at the stage-2 handoff. The Governor and Timelock are deployed and verified, but the Timelock is not yet the Treasury's authority, and there are no voters: INVEST supply is zero, so no gINVEST exists and no proposal can pass. What that interim key can reach is bounded by the fact that the Treasury holds nothing and there is no supply to mint against. See Custody today.

The four steps

	Step	What it means
I	Propose	Your gINVEST must meet the proposal threshold.
II	Vote	Cast with the gINVEST you held at the proposal's snapshot.
III	Timelock	The passed proposal waits out the minimum delay.
IV	Execute	Anyone executes it — the executor role is open.

Parameters

Genesis values, and the bounds the Boardroom may move them within:

Parameter	Genesis (4663)	Bounds
Voting delay	6 h	[1 h, 30 d]
Voting period	48 h	[24 h, 90 d]
Timelock minimum delay	24 h	policy, not code
Proposal threshold	25 bps of live gINVEST supply	≤ 10,000 bps
Quorum	1,000 bps of non-excluded circulating gINVEST at the snapshot	≤ 10,000 bps

Quorum, and why there is a floor

quorum(t) = max( circulating(t) × quorumBps / 1e4 , quorumFloor )

The absolute floor exists so a dormant Boardroom cannot be captured by a handful of votes. It is sized at a tenth of the whole INVEST supply — every token minted at launch, across the anchor and all four sell walls, not the anchor's 60% alone.

Voting weight is your gINVEST at the moment a proposal snapshots. Protocol-held gINVEST — the Treasury's, Staking's, the bond depository's, the redemption module's and the Timelock's — is excluded from the eligible supply. That exclusion set is fixed in the gINVEST constructor and is immutable.

There are no voters at t0

Mainnet launches with no genesis deposit, so nothing is staked and every INVEST in existence sits in one of the five protocol-owned pools. With 60,000 INVEST minted at launch the quorum floor is 6,000 gINVEST — a tenth of the t0 supply. A proposal needs at least that much gINVEST voting, i.e. 10% of the supply bought out of a pool and staked, or the parameter guardian lowers the floor. Plan the first proposals around that valve.

Note that 24,000 of those 60,000 INVEST sit inside sell walls that only trade above three times the launch price, so the practical route to the floor runs through the anchor pool.

Before any of that: none of the 60,000 has been minted, and the pools hold nothing. There is no INVEST to buy, so there is no gINVEST and no electorate at all yet.

Delegation is a separate step

gINVEST is a standard ERC20Votes token, and in that design voting power is dormant by default — even to its own owner. Buying INVEST, staking it and holding gINVEST still leaves your weight at zero. The contract only begins counting your balance once you point it somewhere with a delegate() call, and pointing it at yourself is the ordinary thing to do.

It costs one transaction and you only ever do it once: every later proposal counts your balance automatically. It is not a transfer and not a lock — delegation moves voting weight, never ownership, so your gINVEST stays in your wallet and stays free to move, unwrap or unstake.

This matters more at launch than it will later. Weight is snapshotted when a proposal opens, so gINVEST delegated after that snapshot does not count toward that proposal, and with a quorum floor of 6,000 gINVEST against a supply mostly locked in pools, undelegated holders are the likeliest reason an early proposal stalls.

Lockout-proof tuning

The rule is asymmetric on purpose:

• Raises of quorumFloor, quorumBps or proposalThresholdBps go through governance, and a floor raise is additionally capped at the reachable non-excluded supply (ICGovernor_FloorUnreachable) — governance cannot lock itself out.
• The parameter guardian may only lower. That is an escape valve, not a capture power: quorum measures participation, and a proposal still needs FOR > AGAINST to pass. Lowering the bar to vote does not decide the vote.
• Voting delay and period have permanent floors and caps.
• setProposalThreshold is disabled outright.

Roles on the Timelock

Role	Holder
Propose	the Governor
Cancel	the Governor and the Investors Center Safe
Execute	anyone — a passed proposal is not gated on a privileged key
Administer roles	nobody; the deployer gave this up at handoff

The Safe's ability to cancel is a deliberate, accepted residual: it can veto a queued proposal but cannot enact one.

What proposals look like

Every proposal is a direct call on the contract it affects — there is no relay in between. These are the shapes the Boardroom will see most:

1. Vet a price feed — approve the exact valuation configuration a new reserve asset may carry. The operator then activates it separately, through an announced queue.
2. Arm — or close — self-service listing — approve, once, the valuation policy under which the operator may list a whole class of real-world assets without a further vote, and the on-chain proof an asset must pass to qualify. It is off unless the Boardroom has armed it, closing it again is a single proposal that takes effect immediately, and every asset listed under it is still announced and cancellable before it takes effect. This is the one proposal that widens what an operator key can do, so it is worth reading Listing without a vote before voting on it.
3. Pin an accumulator route or policy — fix which venue the treasury may buy a given asset through, and the caps that bound those purchases.
4. Treasury roles and parameters — grant or revoke a role, and tune the rate limits that bound how much value any role can move.
5. Emissions and staking — set the reward rate, the epoch length and the warm-up rules.
6. Bonds — set the vesting bounds, lower the absolute price floor, arm the price band.
7. The pool fees — register, retire or re-oracle a protocol-owned pool in the collector's venue registry; choose which pool is the anchor (the one INVEST is sold into and the one whose price everything else reads, and it must be a stablecoin pool); set the deviation band between venues; re-point the team wallet or the accumulator; and move the collected balances to a successor collector if a venue is ever abandoned. The rate itself is part of each pool's identity and cannot be changed by anyone.
8. Games — grant the game house its Treasury role and set its risk budget.

The redemption backstop

RedemptionModule is a frozen Treasury role (REDEEMER) that governance cannot revoke. It is a pro-rata, balance-based, oracle-independent rage-quit: you can redeem for a slice of the raw reserve tokens even if every price feed is down. The share that wraps the protocol-owned INVEST/USDG position is set as the immutable excludedReserve at construction, so the protocol's own liquidity is not redeemable out from under itself.