Decentralized Governance
Penumbra has a decentralized governance system intended to help the community of Penumbra users and stakeholders coordinate and express their opinions about the future of the protocol. As a decentralized protocol, no single entity is in control of the network. Penumbra's governance system does not have control over the network either, and acts as a coordination and signaling mechanism for the community.
Penumbra's governance system is modeled after the design of the Cosmos SDK: validators cast default votes on behalf of their delegators, which delegators can permissionlessly override.
Proposal Types
There are several types of proposal:
- Signaling: the primary type of proposal, which has no effect on the chain. Signaling proposals allow collecting community sentiment as part of the process for reaching consensus.
- Upgrade: a special kind of signaling proposal that also coordinates a chain halt. Once the chain halts, full node operators can choose whether to apply an upgrade to a new software version.
- Emergency: a special kind of signaling proposal that also coordinates a chain halt. Emergency proposals have special acceptance criteria but limited powers, described below.
- Parameter Change: adjusts technical parameters for the chain's operation.
- (Un)Freeze IBC Client: allows (un)freezing an IBC client for a counterparty chain, e.g., in the event the community determines that a counterparty chain was compromised.
- Community Pool Spend: spends funds from the community pool. Currently disabled via chain parameter pending community consensus around the role of the community pool and to minimize protocol risk.
To deter spam, proposal submission requires posting a deposit, which can be slashed if the community rejects the proposal with an overwhelming margin (on mainnet, >80% rejection).
Voting
Both delegators and validators can vote on proposals. Validator votes are public, and act as default votes for their delegators. Delegator votes are private, and override the validator's vote. Delegators can vote only if they held their delegation tokens when the proposal was submitted.
Non-emergency proposals pass as long as they achieve:
- Duration: voting ends after a specified period, allowing delegators to vote (initially 48h);
- Quorum: the minimum percentage of staked tokens that must have voted (40% on mainnet);
- Threshold: the percentage of YES votes out of all votes must be above this threshold (67% on mainnet).
Emergency proposals have special criteria: they pass immediately as soon as 1/3+1 of the stake weight votes YES, without waiting for delegator votes. However, emergency proposals cannot actually do anything. This replicates the ability of a 1/3+1 stake-weight minority to halt the chain.
Voting Receipts
Delegators who vote on governance proposals receive voting receipt tokens, in proportion to their voting power. The voting receipt tokens are the same regardless of how the delegator voted, and are an on-chain equivalent of an "I Voted" sticker. They serve no other function in the protocol than to indicate to a user that they have already voted.