Delegates
Delegation, proposals, Timelock execution, guardian powers and verification.
Governance guide
STONK governance combines delegated stSTONK votes, an OpenZeppelin Governor, and delayed execution through StonkTimelock.
Voting asset
Deposit STONK into StonkVault to receive stSTONK, then delegate to yourself or another address. Delegation assigns voting power without transferring custody. Vote checkpoints use timestamps.
Vault revenue does not create votes: one stSTONK equals one vote before delegation regardless of its STONK redemption value. Deposits mint shares and potential votes; redemption burns both.
Lifecycle
- A delegated holder above the proposal threshold submits targets, values, calldata, and a description.
- After the voting delay, voting opens for the configured period.
- Quorum and a majority of participating votes are required.
- A successful proposal is queued in the Timelock.
- After the Timelock delay, anyone may execute the exact queued operation.
Live contract state is authoritative. The committed mainnet inputs are a one-day voting delay, five-day voting period, 4% quorum, 100 stSTONK proposal threshold, and two-day Timelock delay.
Authority matrix
| Actor | Can | Cannot |
|---|---|---|
| stSTONK delegates | propose and vote | execute without a successful delayed proposal |
| Governor | queue and cancel its proposals | bypass Timelock |
| Timelock | execute approved administration | act before delay |
| genesis Safe | temporarily propose Timelock operations | cancel, execute, or administer Timelock |
| guardian Safe | shut down named modules and cancel queued operations | propose, execute, configure, withdraw, mint, or restart |
| deployer | deploy | retain production authority after handoff |
Governed controls
Governance can create and close bond markets, configure supported assets and price risk limits, authorize treasury operations, administer roles, restart contained modules, update Governor settings within contract constraints, and upgrade Kernel modules through reviewed proposals.
There is no emission-rate control because the protocol has no emission mechanism. A revenue distributor, buyback executor, or new mint path requires new audited code and explicit governance approval.
Proposal review
Every proposal should publish:
- decoded targets, selectors, arguments, and ETH values;
- current and proposed state;
- fork simulation at a named block;
- backing, liquidity, oracle, external-token, and role effects;
- maximum loss or issuance exposure;
- rollback or containment plan; and
- executable post-state assertions.
Do not sign raw calldata whose decoded intent is unavailable.
Bootstrap and retirement
Production uses a genesis Safe as a temporary proposer so governance can be bootstrapped before broad vote distribution. Once stSTONK delegation can reliably reach quorum and an end-to-end proposal has succeeded, governance must revoke the Safe's proposer role. The Timelock never grants the Safe default administration.
Verification
Before relying on a live deployment, verify Governor token, timestamp clock, voting settings, quorum numerator, Timelock address and delay, role members, Kernel executor, Authority control, Safe ownership/threshold, and absence of deployer privileges against the deployment manifest and an independent RPC.