Proposals are the means by which validators and certifiers govern the chain. Any user can submit a proposal, though some types of proposals must be submitted by a certifier. Once a proposal is submitted, it must pass a minimum deposit threshold before it can be voted on; this helps reduce spam. In most cases, the deposit is returned at the end of the proposal's life cycle, regardless of whether or not it passes. Proposals submitted by a validator or certifier automatically skip this deposit period.
Proposals that meet the deposit requirement move on to the voting round. Depending on the proposal type, the proposal will either have one or two voting rounds, depending on the security changes the proposal would introduce. For example, plain text proposals don't automatically trigger any action on the chain when they pass, so they just need to pass a single validator voting period. Software upgrade proposals, on the other hand, need to pass the scrutiny of both the certifiers and validators in two separate voting rounds.
Validators have four voting options: Yes, No, Abstain, and No With Veto. Each validator's vote is weighted by the total amount of tokens the validator has staked on the chain. If a sufficient proportion of No With Veto votes are cast, then proposal fails and the deposit is burned. In all other cases, the deposit is returned. A proposal needs the percentage of Yes votes out of all non-abstaining votes to be greater than a threshold. If the proposal does not meet the threshold, the proposal fails.
The certifier voting protocol is more straightforward. Certifiers have two voting options: Yes and No. Each vote is weighted equally; one certifier gets one vote. The percentage of Yes votes out of the total number of votes must pass a threshold. (Note that this threshold is different from the threshold in the validator voting period.)
If a proposal passes, an action may be carried out automatically by the chain, depending on the proposal type. Currently, CertiK Chain supports five types of proposals, detailed below.
A plain text proposal is the "vanilla" proposal; no action is triggered when it passes. Plain text proposals are a good way to gauge interest for a software upgrade or community pool spend proposal before submitting them. A plain text proposal only needs to pass the validator voting period.
A parameter change proposal automatically updates a chain parameter (i.e. the maximum number of validators, the validator voting pass threshold, etc.) if it passes. The proposal specifies the parameter to be changed and the new value. Like a plain text proposal, a parameter change proposal only goes through the validator voting period.
A community pool spend proposal transfers tokens from the community pool to an address if it passes. The recipient of the tokens could be a chain user who has done—or plans to do—development work or a security audit for the chain. The recipient could also be a smart contract that distributes the tokens to multiple addresses after conditions have been met. For example, a bug bounty smart contract could be funded by a community pool spend proposal. When a user finds a bug, the owner of the smart contract could send some tokens to that user as a reward. Just like the first two proposal types, a community pool spend proposal only needs to pass the validator voting period.
A software upgrade proposal introduces a change to the chain's code that all validators need to adopt if it passes. Usually, before submitting a software upgrade proposal, a user will submit a plain text proposal to gauge the interest of their potential code modification. Because a software upgrade can introduce security vulnerabilities, a software upgrade proposal must pass both a certifier voting round as well a validator voting round.
A certifier update proposal adds a new certifier or removes a certifier if it passes. This proposal type must be submitted by a certifier. Its voting protocol is unique, in that it must pass either the certifier voting round or the validator voting round.