Concepts
Protocol Governance
On-chain, live · Estimated read time: 9 minutes
TL;DR
Asentum is governed by an on-chain voting contract that has been live since testnet launch. Validators and delegators vote on proposals; passing proposals execute automatically after a timelock. Proposals split into two tiers — hard and soft — with different bonds, quorums, and voting windows. Some parameters are fenced behind hard floors that governance cannot cross. Governance can also approve VM libraries that become importable inside every contract.
Hard vs soft proposals
Governance recognises two tiers so that low-stakes changes don't have to wait weeks while high-stakes changes get the scrutiny they deserve.
| Soft proposal | Hard proposal | |
|---|---|---|
| Typical scope | Tuning, treasury spends | Protocol invariants, VM libs |
| Proposal bond | 100 ASE | 1,000 ASE |
| Voting window | 2,160 blocks (~72 min) | Minimum 3 weeks |
| Quorum | 1,000 ASE of voting power | 10% of bonded stake |
| Execution delay | 100 blocks | 1 week |
| Supermajority | > 50% | ≥ 2/3 |
The tier is declared when the proposal is created and cannot be changed afterwards. Any proposal that touches a fenced parameter or approves a VM library is automatically hard.
Proposal lifecycle
- Create. A validator posts a proposal transaction with its tier, bond, title, and payload. The bond is slashed if the proposal is rejected as spam.
- Discuss. The proposal is visible to everyone. Most proposals get amended at least once.
- Vote. Each participant votes YES, NO, or ABSTAIN. Votes are stake-weighted.
- Tally. At the end of the voting window, the contract tallies. If quorum and the supermajority are met, the proposal is queued for execution.
- Timelock. Queued proposals wait for the execution delay. This gives anyone time to exit or prepare if they disagree with the outcome.
- Execute. The proposal payload runs, automatically, at the end of the timelock. No multisig signature, no human in the loop.
Amendments
During the voting window, the proposer can post amendments that modify the payload. Any amendment resets the window to its full length, so amendments are a cost — not a free move. This forces proposers to think before they ship, while keeping the door open for good-faith fixes.
Hard floors
Some things are not governable — no proposal, of any tier, with any voting power, can change them:
- The 1-billion-ASE maximum supply.
- The post-quantum signature requirement (ML-DSA-65 stays ML-DSA-65).
- The plain-JavaScript contract model.
- The existence of the hard floors themselves.
These are enforced at the chain level — not in the governance contract. Touching them would require a hard-fork of the node binary, which requires social consensus, not just a vote.
VM library injection
Governance can approve VM libraries — JavaScript modules whose source is stored on-chain and injected into every contract's SES Compartment as a frozen endowment. This is how functionality like math or cryptography primitives get added without forking the node.
Approved libraries are always hard proposals. See Approved Libraries for the full story.
Execution
Passed proposals execute automatically, on-chain, on schedule. There is no multisig to sign. There is no core team with a key. Once a proposal is queued and the timelock elapses, the governance contract runs the payload in the next block.
This is the point of on-chain governance: the votes are the actions. What passes is what happens.
Voting power
Voting power equals bonded stake. A validator's own self-bond counts once. Delegations count for the delegator — not the validator — by default, though validators can vote a delegator's stake if the delegator explicitly opts in.
For the mechanics of delegation, see Delegation. For the voter's-side view, see Governance (token).
Read next