Protocol Governance
On-chain voting that executes itself. Two proposal tiers, a short list of things no vote can ever change, and no multisig standing between a passed vote and its effect.
TL;DR. An on-chain voting contract, live since testnet launch. Validators and delegators vote on proposals that execute automatically after a timelock. Two tiers — hard and soft — with different bonds, quorums, and voting windows; a short list of parameters governance can never touch.
Aevum governs itself through an on-chain voting contract, live since testnet launch. Validators and delegators vote on proposals that execute automatically after a timelock — no multisig, no core-team key. The votes are the actions. What passes is what happens.
Hard vs soft proposals
Two tiers balance scrutiny against efficiency. The tier is fixed at proposal creation and can't be changed later — anything touching a fenced parameter or approving a VM library is automatically hard.
| Soft proposal | Hard proposal | |
|---|---|---|
| Typical scope | Tuning, treasury spends | Protocol invariants, VM libraries |
| Proposal bond | 100 AEV | 1,000 AEV |
| Voting window | 2,160 blocks (~72 min) | Minimum 3 weeks |
| Quorum | 1,000 AEV of voting power | 10% of bonded stake |
| Execution delay | 100 blocks | 1 week |
| Supermajority | > 50% | ≥ 2/3 |
Proposal lifecycle
- Create — a validator submits a proposal with a tier, bond, title, and payload. A rejected spam proposal loses its bond.
- Discuss — the proposal is visible to everyone; most go through at least one amendment.
- Vote — participants vote YES, NO, or ABSTAIN, weighted by stake.
- Tally — once the voting window closes, the contract tallies results. Proposals clearing quorum and supermajority queue for execution.
- Timelock — a waiting period, giving anyone who disagrees time to prepare or exit.
- Execute — the payload runs automatically. No multisig, no human in the loop.
Amendments
While a proposal is being voted on, the proposer can post an amendment that modifies the payload — and every amendment resets the voting window to its full length. That's a real cost to amending, which encourages getting the proposal right the first time while still allowing good-faith corrections.
Hard floors
A short list of things governance cannot touch, no matter how a vote goes:
- The 1-billion-AEV maximum supply
- The post-quantum signature requirement — ML-DSA-65 stays ML-DSA-65
- The plain-JavaScript contract model
- The existence of these hard floors themselves
These are enforced at the chain level, inside the governance contract itself. Changing any of them would need a hard fork of the node binary — social consensus, not a vote.
VM library injection
Governance can approve VM libraries — JavaScript modules stored on-chain and injected into every contract's SES Compartment as frozen endowments. It's how the protocol can add functionality (math or cryptography primitives, for instance) without forcing a node fork. Approved libraries are always hard proposals.
Execution
A passed proposal executes on-chain automatically, on schedule. No multisig signature, no core team key, nothing to click. Once the timelock expires, the governance contract runs the payload in the next block.
Voting power
Voting power is bonded stake. A validator's self-bond counts once. Delegated stake counts for the delegator, by default — not the validator — unless the delegator explicitly opts in to letting their validator vote it on their behalf.