github.com/Finschia/finschia-sdk@v0.48.1/x/gov/spec/01_concepts.md (about)

     1  <!--
     2  order: 1
     3  -->
     4  
     5  # Concepts
     6  
     7  _Disclaimer: This is work in progress. Mechanisms are susceptible to change._
     8  
     9  The governance process is divided in a few steps that are outlined below:
    10  
    11  - **Proposal submission:** Proposal is submitted to the blockchain with a
    12    deposit.
    13  - **Vote:** Once deposit reaches a certain value (`MinDeposit`), proposal is
    14    confirmed and vote opens. Bonded Atom holders can then send `TxGovVote`
    15    transactions to vote on the proposal.
    16  - If the proposal involves a software upgrade:
    17      - **Signal:** Validators start signaling that they are ready to switch to the
    18      new version.
    19      - **Switch:** Once more than 75% of validators have signaled that they are
    20      ready to switch, their software automatically flips to the new version.
    21  
    22  ## Proposal submission
    23  
    24  ### Right to submit a proposal
    25  
    26  Any Atom holder, whether bonded or unbonded, can submit proposals by sending a
    27  `TxGovProposal` transaction. Once a proposal is submitted, it is identified by
    28  its unique `proposalID`.
    29  
    30  ### Proposal types
    31  
    32  In the initial version of the governance module, there are five types of
    33  proposals:
    34  
    35  - `TextProposal` All the proposals that do not involve a modification of
    36    the source code go under this type. For example, an opinion poll would use a
    37    proposal of type `TextProposal`.
    38  - `SoftwareUpgradeProposal`. If accepted, validators are expected to update
    39    their software in accordance with the proposal. They must do so by following
    40    a 2-steps process described in the [Software Upgrade](#software-upgrade)
    41    section below. Software upgrade roadmap may be discussed and agreed on via
    42    `TextProposals`, but actual software upgrades must be performed via
    43    `SoftwareUpgradeProposals`.
    44  - `CommunityPoolSpendProposal` details a proposal for use of community funds,
    45    together with how many coins are proposed to be spent, and to which recipient account.
    46  - `ParameterChangeProposal` defines a proposal to change one or
    47    more parameters. If accepted, the requested parameter change is updated
    48    automatically by the proposal handler upon conclusion of the voting period.
    49  - `CancelSoftwareUpgradeProposal` is a gov Content type for cancelling a software upgrade.
    50  
    51  Other modules may expand upon the governance module by implementing their own
    52  proposal types and handlers. These types are registered and processed through the
    53  governance module (eg. `ParamChangeProposal`), which then execute the respective
    54  module's proposal handler when a proposal passes. This custom handler may perform
    55  arbitrary state changes.
    56  
    57  ## Deposit
    58  
    59  To prevent spam, proposals must be submitted with a deposit in the coins defined in the `MinDeposit` param. The voting period will not start until the proposal's deposit equals `MinDeposit`.
    60  
    61  When a proposal is submitted, it has to be accompanied by a deposit that must be strictly positive, but can be inferior to `MinDeposit`. The submitter doesn't need to pay for the entire deposit on their own. If a proposal's deposit is inferior to `MinDeposit`, other token holders can increase the proposal's deposit by sending a `Deposit` transaction. The deposit is kept in an escrow in the governance `ModuleAccount` until the proposal is finalized (passed or rejected).
    62  
    63  Once the proposal's deposit reaches `MinDeposit`, it enters voting period. If proposal's deposit does not reach `MinDeposit` before `MaxDepositPeriod`, proposal closes and nobody can deposit on it anymore.
    64  
    65  ### Deposit refund and burn
    66  
    67  When a the a proposal finalized, the coins from the deposit are either refunded or burned, according to the final tally of the proposal:
    68  
    69  - If the proposal is approved or if it's rejected but _not_ vetoed, deposits will automatically be refunded to their respective depositor (transferred from the governance `ModuleAccount`).
    70  - When the proposal is vetoed with a supermajority, deposits be burned from the governance `ModuleAccount`.
    71  
    72  ## Vote
    73  
    74  ### Participants
    75  
    76  _Participants_ are users that have the right to vote on proposals. On the
    77  Cosmos Hub, participants are bonded Atom holders. Unbonded Atom holders and
    78  other users do not get the right to participate in governance. However, they
    79  can submit and deposit on proposals.
    80  
    81  Note that some _participants_ can be forbidden to vote on a proposal under a
    82  certain validator if:
    83  
    84  - _participant_ bonded or unbonded Atoms to said validator after proposal
    85    entered voting period.
    86  - _participant_ became validator after proposal entered voting period.
    87  
    88  This does not prevent _participant_ to vote with Atoms bonded to other
    89  validators. For example, if a _participant_ bonded some Atoms to validator A
    90  before a proposal entered voting period and other Atoms to validator B after
    91  proposal entered voting period, only the vote under validator B will be
    92  forbidden.
    93  
    94  ### Voting period
    95  
    96  Once a proposal reaches `MinDeposit`, it immediately enters `Voting period`. We
    97  define `Voting period` as the interval between the moment the vote opens and
    98  the moment the vote closes. `Voting period` should always be shorter than
    99  `Unbonding period` to prevent double voting. The initial value of
   100  `Voting period` is 2 weeks.
   101  
   102  ### Option set
   103  
   104  The option set of a proposal refers to the set of choices a participant can
   105  choose from when casting its vote.
   106  
   107  The initial option set includes the following options:
   108  
   109  - `Yes`
   110  - `No`
   111  - `NoWithVeto`
   112  - `Abstain`
   113  
   114  `NoWithVeto` counts as `No` but also adds a `Veto` vote. `Abstain` option
   115  allows voters to signal that they do not intend to vote in favor or against the
   116  proposal but accept the result of the vote.
   117  
   118  _Note: from the UI, for urgent proposals we should maybe add a ‘Not Urgent’
   119  option that casts a `NoWithVeto` vote._
   120  
   121  ### Weighted Votes
   122  
   123  [ADR-037](../../../docs/architecture/adr-037-gov-split-vote.md) introduces the weighted vote feature which allows a staker to split their votes into several voting options. For example, it could use 70% of its voting power to vote Yes and 30% of its voting power to vote No.
   124  
   125  Often times the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Currently, it is not possible for them to do "passthrough voting" and giving their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll.
   126  
   127  To represent weighted vote on chain, we use the following Protobuf message.
   128  
   129  +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/proto/cosmos/gov/v1beta1/gov.proto#L32-L40
   130  
   131  +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/proto/cosmos/gov/v1beta1/gov.proto#L126-L137
   132  
   133  For a weighted vote to be valid, the `options` field must not contain duplicate vote options, and the sum of weights of all options must be equal to 1.
   134  
   135  ### Quorum
   136  
   137  Quorum is defined as the minimum percentage of voting power that needs to be
   138  casted on a proposal for the result to be valid.
   139  
   140  ### Threshold
   141  
   142  Threshold is defined as the minimum proportion of `Yes` votes (excluding
   143  `Abstain` votes) for the proposal to be accepted.
   144  
   145  Initially, the threshold is set at 50% with a possibility to veto if more than
   146  1/3rd of votes (excluding `Abstain` votes) are `NoWithVeto` votes. This means
   147  that proposals are accepted if the proportion of `Yes` votes (excluding
   148  `Abstain` votes) at the end of the voting period is superior to 50% and if the
   149  proportion of `NoWithVeto` votes is inferior to 1/3 (excluding `Abstain`
   150  votes).
   151  
   152  ### Inheritance
   153  
   154  If a delegator does not vote, it will inherit its validator vote.
   155  
   156  - If the delegator votes before its validator, it will not inherit from the
   157    validator's vote.
   158  - If the delegator votes after its validator, it will override its validator
   159    vote with its own. If the proposal is urgent, it is possible
   160    that the vote will close before delegators have a chance to react and
   161    override their validator's vote. This is not a problem, as proposals require more than 2/3rd of the total voting power to pass before the end of the voting period. If more than 2/3rd of validators collude, they can censor the votes of delegators anyway.
   162  
   163  ### Validator’s punishment for non-voting
   164  
   165  At present, validators are not punished for failing to vote.
   166  
   167  ### Governance address
   168  
   169  Later, we may add permissioned keys that could only sign txs from certain modules. For the MVP, the `Governance address` will be the main validator address generated at account creation. This address corresponds to a different PrivKey than the Tendermint PrivKey which is responsible for signing consensus messages. Validators thus do not have to sign governance transactions with the sensitive Tendermint PrivKey.
   170  
   171  ## Software Upgrade
   172  
   173  If proposals are of type `SoftwareUpgradeProposal`, then nodes need to upgrade
   174  their software to the new version that was voted. This process is divided in
   175  two steps.
   176  
   177  ### Signal
   178  
   179  After a `SoftwareUpgradeProposal` is accepted, validators are expected to
   180  download and install the new version of the software while continuing to run
   181  the previous version. Once a validator has downloaded and installed the
   182  upgrade, it will start signaling to the network that it is ready to switch by
   183  including the proposal's `proposalID` in its _precommits_.(_Note: Confirmation
   184  that we want it in the precommit?_)
   185  
   186  Note: There is only one signal slot per _precommit_. If several
   187  `SoftwareUpgradeProposals` are accepted in a short timeframe, a pipeline will
   188  form and they will be implemented one after the other in the order that they
   189  were accepted.
   190  
   191  ### Switch
   192  
   193  Once a block contains more than 2/3rd _precommits_ where a common
   194  `SoftwareUpgradeProposal` is signaled, all the nodes (including validator
   195  nodes, non-validating full nodes and light-nodes) are expected to switch to the
   196  new version of the software.
   197  
   198  _Note: Not clear how the flip is handled programmatically_