Governance

What governance covers

On-chain governance on Asentum exists to make a small set of high-stakes decisions that can't be made by the protocol alone:

• Protocol upgrades. Changes to the consensus rules, fee market, contract VM, or signature scheme that require a hard fork.
• Parameter tuning. Block size, gas target, base-fee adjustment rate, slashing severities, commission caps, unbonding period.
• Treasury & growth-fund allocations. How the ecosystem allocation gets deployed.
• Validator-set policies. Diminishing-returns cap, minimum self-stake, candidate eligibility.

What governance does not cover: anything that contradicts the protocol's locked-in invariants (max supply, post-quantum signatures, the JS contract model). Those are not parameters; they are the chain's identity.

Voting power

Voting power is proportional to bonded ASE — both self-bonded validator stake and delegated stake count. There is no separate governance token. If you delegate your ASE to a validator, your voting power flows to that validator by default; you can override it on a per-proposal basis.

This is the same model Cosmos uses, and it's the same model Asentum delegation uses. See Delegation.

Proposal lifecycle

1. Discussion. Proposals start as drafts on the public forum. Anyone can write one. The community discusses, refines, and rallies (or doesn't).
2. On-chain submission. A proposal becomes formal when it's submitted on-chain with a deposit in ASE. The deposit prevents spam.
3. Voting period. A fixed-duration voting window (length TBD before mainnet) during which any bonded ASE holder can vote yes / no / abstain.
4. Quorum & threshold. Proposals pass only if a quorum of voting power participates and a threshold of votes is "yes." Both numbers will be locked before mainnet.
5. Execution. Passed proposals are executed automatically by the protocol on a delay (timelock), so there's a window for delegators to react if they disagree with how their delegate voted.

Status