From 798b2b6ea37612b1f3fabb955c19f120345e276a Mon Sep 17 00:00:00 2001 From: gamarin Date: Mon, 26 Feb 2018 16:07:17 +0100 Subject: [PATCH] Add Readme --- docs/spec/governance/README.md | 28 ++++++++++++++++++++++++++++ docs/spec/governance/governance.md | 4 ++-- 2 files changed, 30 insertions(+), 2 deletions(-) create mode 100644 docs/spec/governance/README.md diff --git a/docs/spec/governance/README.md b/docs/spec/governance/README.md new file mode 100644 index 000000000..e337eca12 --- /dev/null +++ b/docs/spec/governance/README.md @@ -0,0 +1,28 @@ +# Governance module specification + +## Abstract + +This paper specifies the Governance module of the Cosmos-SDK, which was first described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in June 2016. + +The module enables Cosmos-SDK based blockchain to support an on-chain governance system. In this system, token holders can vote on proposals on a 1 token 1 vote basis. Next is a list of features the module currently supports: + +- **Proposal submission:** Users can submit proposals with a deposit. Once the minimum deposit is reached, proposal enters voting period +- **Vote:** Participants can vote on proposals that reached MinDeposit +- **Inheritance and penalties:** Delegators inherit their validator's vote if they don't vote themselves. If validators do not vote, they get partially slashed. +- **Signal and switch:** If a proposal of type `SoftwareUpgradeProposal` is accepted, validators can signal it and switch once enough validators have signalled. +- **Claiming deposit:** Users that deposited on proposals can recover their deposits if the proposal was accepted OR if the proposal never entered voting period. + +Features that may be added in the future are described in [Future improvements](future_improvements.md) + + +## Contents + +1. **[Design overview](overview.md)** +2. **Implementation** + 1. **[State](state.md)** + 2. **Transactions** + 1. [Proposal Submission](proposal_submission.md) + 2. [Deposit](deposit.md) + 3. [Claim Deposit](claim_deposit.md) + 4. [Vote](vote.md) +3. **[Future improvements](future_improvements.md)** diff --git a/docs/spec/governance/governance.md b/docs/spec/governance/governance.md index 145244127..155a20ac2 100644 --- a/docs/spec/governance/governance.md +++ b/docs/spec/governance/governance.md @@ -102,7 +102,7 @@ forbidden. ### Voting period Once a proposal reaches `MinDeposit`, it immediately enters `Voting period`. We -define `Voting period` as the interval between the moment the vote opens and +define `Voting period` as the interval between the moment the vote opens and the moment the vote closes. `Voting period` should always be shorter than `Unbonding period` to prevent double voting. The initial value of `Voting period` is 2 weeks. @@ -557,7 +557,7 @@ upon receiving txGovDeposit from sender do ProposalProcessingQueue.push(txGovDeposit.ProposalID) ``` -#### Claiming deposit +#### Claim deposit Finally, if the proposal is accepted or `MinDeposit` was not reached before the end of the `MaximumDepositPeriod`, then Atom holders can send