Votes are the same as on the Cosmos Hub:
NoWithVeto is the same as
No but also votes that the proposer
should lose their deposit. The intended cultural norm is that
No should be
used to indicate disagreement with good-faith proposals and
should be used to deter spam proposals.
- this isn’t exactly the same as on the hub, where there’s a distinct veto mechanic; is that mechanic good to copy?
By default, stakeholders’ votes are delegated to the validator their stake is bonded to. Validators’ votes are public, signed by the validator’s key, and act as a default vote for their entire delegation pool.
Stakeholders vote by proving ownership of some amount of bonded stake (their voting power) prior to the beginning of the voting period.
To do this, they create a transaction with a
description reveals the validator and one of the four votes above,
PENb(v) from the transaction’s balance, produces a new note
PENb, and includes , an encryption of the
voting power to the validators’ decryption key.
Descriptions that spend notes contain a proof-of-inclusion for the note they
spend. This establishes that a commitment to the spent note was previously
included in the note commitment tree, an incremental Merkle tree whose
current root (”anchor”) is included in each block. Normally, these proofs are
created and validated with respect to a recent anchor. However, transactions
VoteDescriptions are always validated with respect to the anchor
in the last block before the voting period begins. This prevents
double-voting, by ensuring that only notes created before voting began can be
used to vote.
- vote acceptance thresholds / veto behavior
- encrypt voting power for each vote choice so that the vote does not reveal it