cosmos · zramsay · Nov 6, 2018 · Oct 30, 2018 · Oct 30, 2018 · Oct 30, 2018
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -188,6 +188,7 @@ IMPROVEMENTS
     * [cli] #2128 fixed segfault when exporting directly after `gaiad init`
     * [cli] [\#1255](https://github.com/cosmos/cosmos-sdk/issues/1255) open KeyBase in read-only mode
      for query-purpose CLI commands
+    * [docs] Added commands for querying governance deposits, votes and tally
 
 * Gaia
     * [x/stake] [#2023](https://github.com/cosmos/cosmos-sdk/pull/2023) Terminate iteration loop in `UpdateBondedValidators` and `UpdateBondedValidatorsFull` when the first revoked validator is encountered and perform a sanity check.
@@ -231,6 +232,7 @@ BUG FIXES
 * Gaia
   * [x/stake] Return correct Tendermint validator update set on `EndBlocker` by not
   including non previously bonded validators that have zero power. [#2189](https://github.com/cosmos/cosmos-sdk/issues/2189)
+  * [docs] Fixed light client section links
 
 * SDK
     * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger) [#1988] (https://github.com/cosmos/cosmos-sdk/issues/1988)

diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
@@ -42,7 +42,8 @@ module.exports = {
           "/sdk/core/app4",
           "/sdk/core/app5",
           // "/sdk/modules",
-          "/sdk/clients"
+          "/sdk/clients",
+          "/sdk/cosmos-sdk-cli"
         ]
       },
       // {
@@ -72,8 +73,8 @@ module.exports = {
         title: "Light Client",
         collapsable: false,
         children: [
-	  "/light/",
-	  "/light/getting_started"
+	  "/lite/",
+	  "/lite/getting_started"
 	]
       },
       {

diff --git a/docs/config.js b/docs/config.js
diff --git a/docs/lite/readme.md b/docs/lite/readme.md
@@ -30,7 +30,7 @@ An application developer that would like to build a third party integration can
 with the LCD for the Cosmos Hub (or any other zone) and only needs to initialise it. Afterwards his
 application can interact with the zone as if it was running against a full node.
 
-![high-level](pics/high-level.png)
+![high-level](./pics/high-level.png)
 
 An application developer that wants to build an third party application for the Cosmos Hub (or any
 other zone) should build it against it's canonical API. That API is a combination of multiple parts.
@@ -74,7 +74,7 @@ The original trusted validator set should be prepositioned into its trust store,
 validator set comes from genesis file. During runtime, if LCD detects a different validator set,
 it will verify it and save new validated validator set to the trust store.
 
-![validator-set-change](pics/validatorSetChange.png)
+![validator-set-change](./pics/validatorSetChange.png)
 
 ### Trust Propagation
 
@@ -83,7 +83,7 @@ validator set evolution. Validator set is the foundation of trust, and the trust
 other blockchain data, such as block and transaction. The propagate architecture is shown as
 follows:
 
-![change-process](pics/trustPropagate.png)
+![change-process](./pics/trustPropagate.png)
 
 In general, by trusted validator set, LCD can verify each block commit which contains all pre-commit
 data and block header data. Then the block hash, data hash and appHash are trusted. Based on this

diff --git a/docs/lite/specification.md b/docs/lite/specification.md
@@ -12,7 +12,7 @@ we need to extract name, height and store root hash from these substores to buil
 Merkle leaf nodes, then calculate hash from leaf nodes to root. The root hash of the simple Merkle
 tree is the AppHash which will be included in block header.
 
-![Simple Merkle Tree](pics/simpleMerkleTree.png)
+![Simple Merkle Tree](./pics/simpleMerkleTree.png)
 
 As we have discussed in [LCD trust-propagation](https://github.com/irisnet/cosmos-sdk/tree/bianjie/lcd_spec/docs/spec/lcd#trust-propagation),
 the AppHash can be verified by checking voting power against a trusted validator set. Here we just
@@ -65,7 +65,7 @@ type KeyExistsProof struct {
 The data structure of exist proof is shown as above. The process to build and verify existance proof
 is shown as follows:
 
-![Exist Proof](pics/existProof.png)
+![Exist Proof](./pics/existProof.png)
 
 Steps to build proof:
 
@@ -92,12 +92,12 @@ the postition of the target key in the whole key set of this IAVL tree. As shown
 out the left key and the right key. If we can demonstrate that both left key and right key
 definitely exist, and they are adjacent nodes. Thus the target key definitely doesn't exist.
 
-![Absence Proof1](pics/absence1.png)
+![Absence Proof1](./pics/absence1.png)
 
 If the target key is larger than the right most leaf node or less than the left most key, then the
 target key definitely doesn't exist.
 
-![Absence Proof2](pics/absence2.png)![Absence Proof3](pics/absence3.png)
+![Absence Proof2](./pics/absence2.png)![Absence Proof3](./pics/absence3.png)
 
 ```go
 type proofLeafNode struct {
@@ -147,7 +147,7 @@ in commitID equals to proof RootHash. If not, the proof is invalid. Then sort th
 commitInfo array by the hash of substore name. Finally, build the simple Merkle tree with all
 substore commitInfo array and verify if the Merkle root hash equal to appHash.
 
-![substore proof](pics/substoreProof.png)
+![substore proof](./pics/substoreProof.png)
 
 ```go
 func SimpleHashFromTwoHashes(left []byte, right []byte) []byte {
@@ -187,7 +187,7 @@ Above sections refer appHash frequently. But where does the trusted appHash come
 appHash exist in block header, so next we need to verify blocks header at specific height against
 LCD trusted validator set. The validation flow is shown as follows:
 
-![commit verification](pics/commitValidation.png)
+![commit verification](./pics/commitValidation.png)
 
 When the trusted validator set doesn't match the block header, we need to try to update our
 validator set to the height of this block. LCD have a rule that each validator set change should not
@@ -198,7 +198,7 @@ validator set update be accomplished.
 
 For instance:
 
-![Update validator set to height](pics/updateValidatorToHeight.png)
+![Update validator set to height](./pics/updateValidatorToHeight.png)
 
 * Update to 10000, tooMuchChangeErr
 * Update to 5050,  tooMuchChangeErr

diff --git a/docs/sdk/clients.md b/docs/sdk/clients.md
@@ -1,15 +1,7 @@
 # Clients
 
-::: tip Note
-🚧 We are actively working on documentation for SDK clients.
-:::
-
 ## Gaia CLI
 
-::: tip Note
-🚧 We are actively working on improving documentation for Gaiacli and Gaiad.
-:::
-
 `gaiacli` is the command line interface to manage accounts and transactions on Cosmos testnets. Here is a list of useful `gaiacli` commands, including usage examples.
 
 ### Keys
@@ -329,6 +321,40 @@ Additionally, as you can get all the outgoing redelegations from a particular va
 
 To get previous redelegation(s) status on past blocks, try adding the `--height` flag.
 
+#### Query Parameters
+
+Parameters define high level settings for staking. You can get its current values by using:
+
+```
+gaiacli query parameters
+```
+
+With the above command you will get the values for:
+
+- Maximum and minumum inflation rate
+- Maximum annual change in inflation rate,
+- Goal of bonded tokens (%)
+- Unbonding time
+- Maximum numbers of validators
+- Coin denomination for staking
+
+All this values can be updated though a `governance` process by submitting a parameter change `proposal`.
+
+#### Query Pool
+
+A staking `Pool` defines the dynamic parameters of the current state. You can query them with the following command:
+
+```
+gaiacli query pool
+```
+
+With the `pool` command you will get the values for:
+
+- Loose and bonded tokens
+- Token supply
+- Current anual inflation and the block in which the last inflation was processed
+- Last recorded bonded shares
+
 ### Governance
 
 Governance is the process from which users in the Cosmos Hub can come to consensus on software upgrades, parameters of the mainnet or on custom text proposals. This is done through voting on proposals, which will be submitted by `Atom` holders on the mainnet.
@@ -342,7 +368,7 @@ Some considerations about the voting process:
 - Voters can choose between options `Yes`, `No`, `NoWithVeto` and `Abstain`
   At the end of the voting period, a proposal is accepted if `(YesVotes/(YesVotes+NoVotes+NoWithVetoVotes))>1/2` and `(NoWithVetoVotes/(YesVotes+NoVotes+NoWithVetoVotes))<1/3`. It is rejected otherwise
 
-For more information about the governance process and how it works, please check out the Governance module [specification](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/governance).
+For more information about the governance process and how it works, please check out the Governance module [specification](./../spec/governance).
 
 #### Create a Governance proposal
 
@@ -395,6 +421,23 @@ gaiacli tx deposit \
 
 > _NOTE_: Proposals that don't meet this requirement will be deleted after `MaxDepositPeriod` is reached.
 
+##### Query deposits
+
+Once a new proposal is created, you can query all the deposits submitted to it:
+
+```bash
+gaiacli query deposits \
+  --proposal-id=<proposal_id>
+```
+
+You can also query a deposit submitted by a specific address:
+
+```bash
+gaiacli query deposit \
+  --proposal-id=<proposal_id> \
+  --depositer=<account_cosmos>
+```
+
 #### Vote on a proposal
 
 After a proposal's deposit reaches the `MinDeposit` value, the voting period opens. Bonded `Atom` holders can then cast vote on it:
@@ -408,7 +451,7 @@ gaiacli tx vote \
   --chain-id=<chain_id>
 ```
 
-##### Query vote
+##### Query votes
 
 Check the vote with the option you just submitted:
 
@@ -418,43 +461,18 @@ gaiacli query vote \
   --voter=<account_cosmos>
 ```
 
-#### Query Parameters
-
-You can get the current parameters that define high level settings for staking:
+You can also get all the previous votes submitted to the proposal by other accounts with:
 
-```
-gaiacli query parameters
+```bash
+gaiacli query votes \
+  --proposal-id=<proposal_id>
 ```
 
-With the above command you will get the values for:
-
-- Maximum and minumum Inflation rate
-- Maximum annual change in inflation rate,
-- Goal of bonded tokens (%)
-- Unbonding time
-- Maximum numbers of validators
-- Coin denomination for staking
+#### Query proposal tally results
 
-All this values can be updated though a `governance` process by submitting a parameter change `proposal`.
+To check the current tally results of a given proposal you can use the `tally` command:
 
-#### Query Pool
-
-A staking `Pool` defines the dynamic parameters of the current state. You can query them with the following command:
-
-```
-gaiacli query pool
+```bash
+gaiacli query tally \
+  --proposal-id=<proposal_id>
 ```
-
-With the `pool` command you will get the values for:
-
-- Loose and bonded tokens
-- Token supply
-- Current anual inflation and the block in which the last inflation was processed
-- Last recorded bonded shares
-
-
-## Gaia-Lite
-
-::: tip Note
-🚧 We are actively working on documentation for Gaia-lite.
-:::