github.com/cosmos/cosmos-sdk@v0.50.10/x/gov/README.md (about) 1 --- 2 sidebar_position: 1 3 --- 4 5 # `x/gov` 6 7 ## Abstract 8 9 This paper specifies the Governance module of the Cosmos SDK, which was first 10 described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in 11 June 2016. 12 13 The module enables Cosmos SDK based blockchain to support an on-chain governance 14 system. In this system, holders of the native staking token of the chain can vote 15 on proposals on a 1 token 1 vote basis. Next is a list of features the module 16 currently supports: 17 18 * **Proposal submission:** Users can submit proposals with a deposit. Once the 19 minimum deposit is reached, the proposal enters voting period. The minimum deposit can be reached by collecting deposits from different users (including proposer) within deposit period. 20 * **Vote:** Participants can vote on proposals that reached MinDeposit and entered voting period. 21 * **Inheritance and penalties:** Delegators inherit their validator's vote if 22 they don't vote themselves. 23 * **Claiming deposit:** Users that deposited on proposals can recover their 24 deposits if the proposal was accepted or rejected. If the proposal was vetoed, or never entered voting period (minimum deposit not reached within deposit period), the deposit is burned. 25 26 This module is in use on the Cosmos Hub (a.k.a [gaia](https://github.com/cosmos/gaia)). 27 Features that may be added in the future are described in [Future Improvements](#future-improvements). 28 29 ## Contents 30 31 The following specification uses *ATOM* as the native staking token. The module 32 can be adapted to any Proof-Of-Stake blockchain by replacing *ATOM* with the native 33 staking token of the chain. 34 35 * [Concepts](#concepts) 36 * [Proposal submission](#proposal-submission) 37 * [Deposit](#deposit) 38 * [Vote](#vote) 39 * [Software Upgrade](#software-upgrade) 40 * [State](#state) 41 * [Proposals](#proposals) 42 * [Parameters and base types](#parameters-and-base-types) 43 * [Deposit](#deposit-1) 44 * [ValidatorGovInfo](#validatorgovinfo) 45 * [Stores](#stores) 46 * [Proposal Processing Queue](#proposal-processing-queue) 47 * [Legacy Proposal](#legacy-proposal) 48 * [Messages](#messages) 49 * [Proposal Submission](#proposal-submission-1) 50 * [Deposit](#deposit-2) 51 * [Vote](#vote-1) 52 * [Events](#events) 53 * [EndBlocker](#endblocker) 54 * [Handlers](#handlers) 55 * [Parameters](#parameters) 56 * [Client](#client) 57 * [CLI](#cli) 58 * [gRPC](#grpc) 59 * [REST](#rest) 60 * [Metadata](#metadata) 61 * [Proposal](#proposal-3) 62 * [Vote](#vote-5) 63 * [Future Improvements](#future-improvements) 64 65 ## Concepts 66 67 *Disclaimer: This is work in progress. Mechanisms are susceptible to change.* 68 69 The governance process is divided in a few steps that are outlined below: 70 71 * **Proposal submission:** Proposal is submitted to the blockchain with a 72 deposit. 73 * **Vote:** Once deposit reaches a certain value (`MinDeposit`), proposal is 74 confirmed and vote opens. Bonded Atom holders can then send `TxGovVote` 75 transactions to vote on the proposal. 76 * **Execution** After a period of time, the votes are tallied and depending 77 on the result, the messages in the proposal will be executed. 78 79 ### Proposal submission 80 81 #### Right to submit a proposal 82 83 Every account can submit proposals by sending a `MsgSubmitProposal` transaction. 84 Once a proposal is submitted, it is identified by its unique `proposalID`. 85 86 #### Proposal Messages 87 88 A proposal includes an array of `sdk.Msg`s which are executed automatically if the 89 proposal passes. The messages are executed by the governance `ModuleAccount` itself. Modules 90 such as `x/upgrade`, that want to allow certain messages to be executed by governance 91 only should add a whitelist within the respective msg server, granting the governance 92 module the right to execute the message once a quorum has been reached. The governance 93 module uses the `MsgServiceRouter` to check that these messages are correctly constructed 94 and have a respective path to execute on but do not perform a full validity check. 95 96 ### Deposit 97 98 To prevent spam, proposals must be submitted with a deposit in the coins defined by 99 the `MinDeposit` param. 100 101 When a proposal is submitted, it has to be accompanied with a deposit that must be 102 strictly positive, but can be inferior to `MinDeposit`. The submitter doesn't need 103 to pay for the entire deposit on their own. The newly created proposal is stored in 104 an *inactive proposal queue* and stays there until its deposit passes the `MinDeposit`. 105 Other token holders can increase the proposal's deposit by sending a `Deposit` 106 transaction. If a proposal doesn't pass the `MinDeposit` before the deposit end time 107 (the time when deposits are no longer accepted), the proposal will be destroyed: the 108 proposal will be removed from state and the deposit will be burned (see x/gov `EndBlocker`). 109 When a proposal deposit passes the `MinDeposit` threshold (even during the proposal 110 submission) before the deposit end time, the proposal will be moved into the 111 *active proposal queue* and the voting period will begin. 112 113 The deposit is kept in escrow and held by the governance `ModuleAccount` until the 114 proposal is finalized (passed or rejected). 115 116 #### Deposit refund and burn 117 118 When a proposal is finalized, the coins from the deposit are either refunded or burned 119 according to the final tally of the proposal: 120 121 * If the proposal is approved or rejected but *not* vetoed, each deposit will be 122 automatically refunded to its respective depositor (transferred from the governance 123 `ModuleAccount`). 124 * When the proposal is vetoed with greater than 1/3, deposits will be burned from the 125 governance `ModuleAccount` and the proposal information along with its deposit 126 information will be removed from state. 127 * All refunded or burned deposits are removed from the state. Events are issued when 128 burning or refunding a deposit. 129 130 ### Vote 131 132 #### Participants 133 134 *Participants* are users that have the right to vote on proposals. On the 135 Cosmos Hub, participants are bonded Atom holders. Unbonded Atom holders and 136 other users do not get the right to participate in governance. However, they 137 can submit and deposit on proposals. 138 139 Note that when *participants* have bonded and unbonded Atoms, their voting power is calculated from their bonded Atom holdings only. 140 141 #### Voting period 142 143 Once a proposal reaches `MinDeposit`, it immediately enters `Voting period`. We 144 define `Voting period` as the interval between the moment the vote opens and 145 the moment the vote closes. The initial value of `Voting period` is 2 weeks. 146 147 #### Option set 148 149 The option set of a proposal refers to the set of choices a participant can 150 choose from when casting its vote. 151 152 The initial option set includes the following options: 153 154 * `Yes` 155 * `No` 156 * `NoWithVeto` 157 * `Abstain` 158 159 `NoWithVeto` counts as `No` but also adds a `Veto` vote. `Abstain` option 160 allows voters to signal that they do not intend to vote in favor or against the 161 proposal but accept the result of the vote. 162 163 *Note: from the UI, for urgent proposals we should maybe add a ‘Not Urgent’ option that casts a `NoWithVeto` vote.* 164 165 #### Weighted Votes 166 167 [ADR-037](https://github.com/cosmos/cosmos-sdk/blob/main/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. 168 169 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. 170 171 To represent weighted vote on chain, we use the following Protobuf message. 172 173 ```protobuf reference 174 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L34-L47 175 ``` 176 177 ```protobuf reference 178 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L181-L201 179 ``` 180 181 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. 182 183 ### Quorum 184 185 Quorum is defined as the minimum percentage of voting power that needs to be 186 cast on a proposal for the result to be valid. 187 188 ### Expedited Proposals 189 190 A proposal can be expedited, making the proposal use shorter voting duration and a higher tally threshold by its default. If an expedited proposal fails to meet the threshold within the scope of shorter voting duration, the expedited proposal is then converted to a regular proposal and restarts voting under regular voting conditions. 191 192 #### Threshold 193 194 Threshold is defined as the minimum proportion of `Yes` votes (excluding 195 `Abstain` votes) for the proposal to be accepted. 196 197 Initially, the threshold is set at 50% of `Yes` votes, excluding `Abstain` 198 votes. A possibility to veto exists if more than 1/3rd of all votes are 199 `NoWithVeto` votes. Note, both of these values are derived from the `TallyParams` 200 on-chain parameter, which is modifiable by governance. 201 This means that proposals are accepted iff: 202 203 * There exist bonded tokens. 204 * Quorum has been achieved. 205 * The proportion of `Abstain` votes is inferior to 1/1. 206 * The proportion of `NoWithVeto` votes is inferior to 1/3, including 207 `Abstain` votes. 208 * The proportion of `Yes` votes, excluding `Abstain` votes, at the end of 209 the voting period is superior to 1/2. 210 211 For expedited proposals, by default, the threshold is higher than with a *normal proposal*, namely, 66.7%. 212 213 #### Inheritance 214 215 If a delegator does not vote, it will inherit its validator vote. 216 217 * If the delegator votes before its validator, it will not inherit from the 218 validator's vote. 219 * If the delegator votes after its validator, it will override its validator 220 vote with its own. If the proposal is urgent, it is possible 221 that the vote will close before delegators have a chance to react and 222 override their validator's vote. This is not a problem, as proposals require more than 2/3rd of the total voting power to pass, when tallied at the end of the voting period. Because as little as 1/3 + 1 validation power could collude to censor transactions, non-collusion is already assumed for ranges exceeding this threshold. 223 224 #### Validator’s punishment for non-voting 225 226 At present, validators are not punished for failing to vote. 227 228 #### Governance address 229 230 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 CometBFT PrivKey which is responsible for signing consensus messages. Validators thus do not have to sign governance transactions with the sensitive CometBFT PrivKey. 231 232 #### Burnable Params 233 234 There are three parameters that define if the deposit of a proposal should be burned or returned to the depositors. 235 236 * `BurnVoteVeto` burns the proposal deposit if the proposal gets vetoed. 237 * `BurnVoteQuorum` burns the proposal deposit if the proposal deposit if the vote does not reach quorum. 238 * `BurnProposalDepositPrevote` burns the proposal deposit if it does not enter the voting phase. 239 240 > Note: These parameters are modifiable via governance. 241 242 ## State 243 244 ### Constitution 245 246 `Constitution` is found in the genesis state. It is a string field intended to be used to descibe the purpose of a particular blockchain, and its expected norms. A few examples of how the constitution field can be used: 247 248 * define the purpose of the chain, laying a foundation for its future development 249 * set expectations for delegators 250 * set expectations for validators 251 * define the chain's relationship to "meatspace" entities, like a foundation or corporation 252 253 Since this is more of a social feature than a technical feature, we'll now get into some items that may have been useful to have in a genesis constitution: 254 255 * What limitations on governance exist, if any? 256 * is it okay for the community to slash the wallet of a whale that they no longer feel that they want around? (viz: Juno Proposal 4 and 16) 257 * can governance "socially slash" a validator who is using unapproved MEV? (viz: commonwealth.im/osmosis) 258 * In the event of an economic emergency, what should validators do? 259 * Terra crash of May, 2022, saw validators choose to run a new binary with code that had not been approved by governance, because the governance token had been inflated to nothing. 260 * What is the purpose of the chain, specifically? 261 * best example of this is the Cosmos hub, where different founding groups, have different interpertations of the purpose of the network. 262 263 This genesis entry, "constitution" hasn't been designed for existing chains, who should likely just ratify a constitution using their governance system. Instead, this is for new chains. It will allow for validators to have a much clearer idea of purpose and the expecations placed on them while operating thier nodes. Likewise, for community members, the constitution will give them some idea of what to expect from both the "chain team" and the validators, respectively. 264 265 This constitution is designed to be immutable, and placed only in genesis, though that could change over time by a pull request to the cosmos-sdk that allows for the constitution to be changed by governance. Communities whishing to make amendments to their original constitution should use the governance mechanism and a "signaling proposal" to do exactly that. 266 267 **Ideal use scenario for a cosmos chain constitution** 268 269 As a chain developer, you decide that you'd like to provide clarity to your key user groups: 270 271 * validators 272 * token holders 273 * developers (yourself) 274 275 You use the constitution to immutably store some Markdown in genesis, so that when difficult questions come up, the constutituon can provide guidance to the community. 276 277 ### Proposals 278 279 `Proposal` objects are used to tally votes and generally track the proposal's state. 280 They contain an array of arbitrary `sdk.Msg`'s which the governance module will attempt 281 to resolve and then execute if the proposal passes. `Proposal`'s are identified by a 282 unique id and contains a series of timestamps: `submit_time`, `deposit_end_time`, 283 `voting_start_time`, `voting_end_time` which track the lifecycle of a proposal 284 285 ```protobuf reference 286 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L51-L99 287 ``` 288 289 A proposal will generally require more than just a set of messages to explain its 290 purpose but need some greater justification and allow a means for interested participants 291 to discuss and debate the proposal. 292 In most cases, **it is encouraged to have an off-chain system that supports the on-chain governance process**. 293 To accommodate for this, a proposal contains a special **`metadata`** field, a string, 294 which can be used to add context to the proposal. The `metadata` field allows custom use for networks, 295 however, it is expected that the field contains a URL or some form of CID using a system such as 296 [IPFS](https://docs.ipfs.io/concepts/content-addressing/). To support the case of 297 interoperability across networks, the SDK recommends that the `metadata` represents 298 the following `JSON` template: 299 300 ```json 301 { 302 "title": "...", 303 "description": "...", 304 "forum": "...", // a link to the discussion platform (i.e. Discord) 305 "other": "..." // any extra data that doesn't correspond to the other fields 306 } 307 ``` 308 309 This makes it far easier for clients to support multiple networks. 310 311 The metadata has a maximum length that is chosen by the app developer, and 312 passed into the gov keeper as a config. The default maximum length in the SDK is 255 characters. 313 314 #### Writing a module that uses governance 315 316 There are many aspects of a chain, or of the individual modules that you may want to 317 use governance to perform such as changing various parameters. This is very simple 318 to do. First, write out your message types and `MsgServer` implementation. Add an 319 `authority` field to the keeper which will be populated in the constructor with the 320 governance module account: `govKeeper.GetGovernanceAccount().GetAddress()`. Then for 321 the methods in the `msg_server.go`, perform a check on the message that the signer 322 matches `authority`. This will prevent any user from executing that message. 323 324 ### Parameters and base types 325 326 `Parameters` define the rules according to which votes are run. There can only 327 be one active parameter set at any given time. If governance wants to change a 328 parameter set, either to modify a value or add/remove a parameter field, a new 329 parameter set has to be created and the previous one rendered inactive. 330 331 #### DepositParams 332 333 ```protobuf reference 334 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L152-L162 335 ``` 336 337 #### VotingParams 338 339 ```protobuf reference 340 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L164-L168 341 ``` 342 343 #### TallyParams 344 345 ```protobuf reference 346 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L170-L182 347 ``` 348 349 Parameters are stored in a global `GlobalParams` KVStore. 350 351 Additionally, we introduce some basic types: 352 353 ```go 354 type Vote byte 355 356 const ( 357 VoteYes = 0x1 358 VoteNo = 0x2 359 VoteNoWithVeto = 0x3 360 VoteAbstain = 0x4 361 ) 362 363 type ProposalType string 364 365 const ( 366 ProposalTypePlainText = "Text" 367 ProposalTypeSoftwareUpgrade = "SoftwareUpgrade" 368 ) 369 370 type ProposalStatus byte 371 372 373 const ( 374 StatusNil ProposalStatus = 0x00 375 StatusDepositPeriod ProposalStatus = 0x01 // Proposal is submitted. Participants can deposit on it but not vote 376 StatusVotingPeriod ProposalStatus = 0x02 // MinDeposit is reached, participants can vote 377 StatusPassed ProposalStatus = 0x03 // Proposal passed and successfully executed 378 StatusRejected ProposalStatus = 0x04 // Proposal has been rejected 379 StatusFailed ProposalStatus = 0x05 // Proposal passed but failed execution 380 ) 381 ``` 382 383 ### Deposit 384 385 ```protobuf reference 386 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L38-L49 387 ``` 388 389 ### ValidatorGovInfo 390 391 This type is used in a temp map when tallying 392 393 ```go 394 type ValidatorGovInfo struct { 395 Minus sdk.Dec 396 Vote Vote 397 } 398 ``` 399 400 ## Stores 401 402 :::note 403 Stores are KVStores in the multi-store. The key to find the store is the first parameter in the list 404 ::: 405 406 We will use one KVStore `Governance` to store four mappings: 407 408 * A mapping from `proposalID|'proposal'` to `Proposal`. 409 * A mapping from `proposalID|'addresses'|address` to `Vote`. This mapping allows 410 us to query all addresses that voted on the proposal along with their vote by 411 doing a range query on `proposalID:addresses`. 412 * A mapping from `ParamsKey|'Params'` to `Params`. This map allows to query all 413 x/gov params. 414 * A mapping from `VotingPeriodProposalKeyPrefix|proposalID` to a single byte. This allows 415 us to know if a proposal is in the voting period or not with very low gas cost. 416 417 For pseudocode purposes, here are the two function we will use to read or write in stores: 418 419 * `load(StoreKey, Key)`: Retrieve item stored at key `Key` in store found at key `StoreKey` in the multistore 420 * `store(StoreKey, Key, value)`: Write value `Value` at key `Key` in store found at key `StoreKey` in the multistore 421 422 ### Proposal Processing Queue 423 424 **Store:** 425 426 * `ProposalProcessingQueue`: A queue `queue[proposalID]` containing all the 427 `ProposalIDs` of proposals that reached `MinDeposit`. During each `EndBlock`, 428 all the proposals that have reached the end of their voting period are processed. 429 To process a finished proposal, the application tallies the votes, computes the 430 votes of each validator and checks if every validator in the validator set has 431 voted. If the proposal is accepted, deposits are refunded. Finally, the proposal 432 content `Handler` is executed. 433 434 And the pseudocode for the `ProposalProcessingQueue`: 435 436 ```go 437 in EndBlock do 438 439 for finishedProposalID in GetAllFinishedProposalIDs(block.Time) 440 proposal = load(Governance, <proposalID|'proposal'>) // proposal is a const key 441 442 validators = Keeper.getAllValidators() 443 tmpValMap := map(sdk.AccAddress)ValidatorGovInfo 444 445 // Initiate mapping at 0. This is the amount of shares of the validator's vote that will be overridden by their delegator's votes 446 for each validator in validators 447 tmpValMap(validator.OperatorAddr).Minus = 0 448 449 // Tally 450 voterIterator = rangeQuery(Governance, <proposalID|'addresses'>) //return all the addresses that voted on the proposal 451 for each (voterAddress, vote) in voterIterator 452 delegations = stakingKeeper.getDelegations(voterAddress) // get all delegations for current voter 453 454 for each delegation in delegations 455 // make sure delegation.Shares does NOT include shares being unbonded 456 tmpValMap(delegation.ValidatorAddr).Minus += delegation.Shares 457 proposal.updateTally(vote, delegation.Shares) 458 459 _, isVal = stakingKeeper.getValidator(voterAddress) 460 if (isVal) 461 tmpValMap(voterAddress).Vote = vote 462 463 tallyingParam = load(GlobalParams, 'TallyingParam') 464 465 // Update tally if validator voted 466 for each validator in validators 467 if tmpValMap(validator).HasVoted 468 proposal.updateTally(tmpValMap(validator).Vote, (validator.TotalShares - tmpValMap(validator).Minus)) 469 470 471 472 // Check if proposal is accepted or rejected 473 totalNonAbstain := proposal.YesVotes + proposal.NoVotes + proposal.NoWithVetoVotes 474 if (proposal.Votes.YesVotes/totalNonAbstain > tallyingParam.Threshold AND proposal.Votes.NoWithVetoVotes/totalNonAbstain < tallyingParam.Veto) 475 // proposal was accepted at the end of the voting period 476 // refund deposits (non-voters already punished) 477 for each (amount, depositor) in proposal.Deposits 478 depositor.AtomBalance += amount 479 480 stateWriter, err := proposal.Handler() 481 if err != nil 482 // proposal passed but failed during state execution 483 proposal.CurrentStatus = ProposalStatusFailed 484 else 485 // proposal pass and state is persisted 486 proposal.CurrentStatus = ProposalStatusAccepted 487 stateWriter.save() 488 else 489 // proposal was rejected 490 proposal.CurrentStatus = ProposalStatusRejected 491 492 store(Governance, <proposalID|'proposal'>, proposal) 493 ``` 494 495 ### Legacy Proposal 496 497 :::warning 498 Legacy proposals are deprecated. Use the new proposal flow by granting the governance module the right to execute the message. 499 ::: 500 501 A legacy proposal is the old implementation of governance proposal. 502 Contrary to proposal that can contain any messages, a legacy proposal allows to submit a set of pre-defined proposals. 503 These proposals are defined by their types and handled by handlers that are registered in the gov v1beta1 router. 504 505 More information on how to submit proposals in the [client section](#client). 506 507 ## Messages 508 509 ### Proposal Submission 510 511 Proposals can be submitted by any account via a `MsgSubmitProposal` transaction. 512 513 ```protobuf reference 514 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.proto#L42-L69 515 ``` 516 517 All `sdk.Msgs` passed into the `messages` field of a `MsgSubmitProposal` message 518 must be registered in the app's `MsgServiceRouter`. Each of these messages must 519 have one signer, namely the gov module account. And finally, the metadata length 520 must not be larger than the `maxMetadataLen` config passed into the gov keeper. 521 The `initialDeposit` must be strictly positive and conform to the accepted denom of the `MinDeposit` param. 522 523 **State modifications:** 524 525 * Generate new `proposalID` 526 * Create new `Proposal` 527 * Initialise `Proposal`'s attributes 528 * Decrease balance of sender by `InitialDeposit` 529 * If `MinDeposit` is reached: 530 * Push `proposalID` in `ProposalProcessingQueue` 531 * Transfer `InitialDeposit` from the `Proposer` to the governance `ModuleAccount` 532 533 ### Deposit 534 535 Once a proposal is submitted, if `Proposal.TotalDeposit < ActiveParam.MinDeposit`, Atom holders can send 536 `MsgDeposit` transactions to increase the proposal's deposit. 537 538 A deposit is accepted iff: 539 540 * The proposal exists 541 * The proposal is not in the voting period 542 * The deposited coins are conform to the accepted denom from the `MinDeposit` param 543 544 ```protobuf reference 545 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.proto#L134-L147 546 ``` 547 548 **State modifications:** 549 550 * Decrease balance of sender by `deposit` 551 * Add `deposit` of sender in `proposal.Deposits` 552 * Increase `proposal.TotalDeposit` by sender's `deposit` 553 * If `MinDeposit` is reached: 554 * Push `proposalID` in `ProposalProcessingQueueEnd` 555 * Transfer `Deposit` from the `proposer` to the governance `ModuleAccount` 556 557 ### Vote 558 559 Once `ActiveParam.MinDeposit` is reached, voting period starts. From there, 560 bonded Atom holders are able to send `MsgVote` transactions to cast their 561 vote on the proposal. 562 563 ```protobuf reference 564 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.proto#L92-L108 565 ``` 566 567 **State modifications:** 568 569 * Record `Vote` of sender 570 571 :::note 572 Gas cost for this message has to take into account the future tallying of the vote in EndBlocker. 573 ::: 574 575 ## Events 576 577 The governance module emits the following events: 578 579 ### EndBlocker 580 581 | Type | Attribute Key | Attribute Value | 582 |-------------------|-----------------|------------------| 583 | inactive_proposal | proposal_id | {proposalID} | 584 | inactive_proposal | proposal_result | {proposalResult} | 585 | active_proposal | proposal_id | {proposalID} | 586 | active_proposal | proposal_result | {proposalResult} | 587 588 ### Handlers 589 590 #### MsgSubmitProposal 591 592 | Type | Attribute Key | Attribute Value | 593 |---------------------|---------------------|-----------------| 594 | submit_proposal | proposal_id | {proposalID} | 595 | submit_proposal [0] | voting_period_start | {proposalID} | 596 | proposal_deposit | amount | {depositAmount} | 597 | proposal_deposit | proposal_id | {proposalID} | 598 | message | module | governance | 599 | message | action | submit_proposal | 600 | message | sender | {senderAddress} | 601 602 * [0] Event only emitted if the voting period starts during the submission. 603 604 #### MsgVote 605 606 | Type | Attribute Key | Attribute Value | 607 |---------------|---------------|-----------------| 608 | proposal_vote | option | {voteOption} | 609 | proposal_vote | proposal_id | {proposalID} | 610 | message | module | governance | 611 | message | action | vote | 612 | message | sender | {senderAddress} | 613 614 #### MsgVoteWeighted 615 616 | Type | Attribute Key | Attribute Value | 617 |---------------|---------------|-----------------------| 618 | proposal_vote | option | {weightedVoteOptions} | 619 | proposal_vote | proposal_id | {proposalID} | 620 | message | module | governance | 621 | message | action | vote | 622 | message | sender | {senderAddress} | 623 624 #### MsgDeposit 625 626 | Type | Attribute Key | Attribute Value | 627 |----------------------|---------------------|-----------------| 628 | proposal_deposit | amount | {depositAmount} | 629 | proposal_deposit | proposal_id | {proposalID} | 630 | proposal_deposit [0] | voting_period_start | {proposalID} | 631 | message | module | governance | 632 | message | action | deposit | 633 | message | sender | {senderAddress} | 634 635 * [0] Event only emitted if the voting period starts during the submission. 636 637 ## Parameters 638 639 The governance module contains the following parameters: 640 641 | Key | Type | Example | 642 |-------------------------------|------------------|-----------------------------------------| 643 | min_deposit | array (coins) | [{"denom":"uatom","amount":"10000000"}] | 644 | max_deposit_period | string (time ns) | "172800000000000" (17280s) | 645 | voting_period | string (time ns) | "172800000000000" (17280s) | 646 | quorum | string (dec) | "0.334000000000000000" | 647 | threshold | string (dec) | "0.500000000000000000" | 648 | veto | string (dec) | "0.334000000000000000" | 649 | expedited_threshold | string (time ns) | "0.667000000000000000" | 650 | expedited_voting_period | string (time ns) | "86400000000000" (8600s) | 651 | expedited_min_deposit | array (coins) | [{"denom":"uatom","amount":"50000000"}] | 652 | burn_proposal_deposit_prevote | bool | false | 653 | burn_vote_quorum | bool | false | 654 | burn_vote_veto | bool | true | 655 | min_initial_deposit_ratio | string | "0.1" | 656 657 658 **NOTE**: The governance module contains parameters that are objects unlike other 659 modules. If only a subset of parameters are desired to be changed, only they need 660 to be included and not the entire parameter object structure. 661 662 ## Client 663 664 ### CLI 665 666 A user can query and interact with the `gov` module using the CLI. 667 668 #### Query 669 670 The `query` commands allow users to query `gov` state. 671 672 ```bash 673 simd query gov --help 674 ``` 675 676 ##### deposit 677 678 The `deposit` command allows users to query a deposit for a given proposal from a given depositor. 679 680 ```bash 681 simd query gov deposit [proposal-id] [depositer-addr] [flags] 682 ``` 683 684 Example: 685 686 ```bash 687 simd query gov deposit 1 cosmos1.. 688 ``` 689 690 Example Output: 691 692 ```bash 693 amount: 694 - amount: "100" 695 denom: stake 696 depositor: cosmos1.. 697 proposal_id: "1" 698 ``` 699 700 ##### deposits 701 702 The `deposits` command allows users to query all deposits for a given proposal. 703 704 ```bash 705 simd query gov deposits [proposal-id] [flags] 706 ``` 707 708 Example: 709 710 ```bash 711 simd query gov deposits 1 712 ``` 713 714 Example Output: 715 716 ```bash 717 deposits: 718 - amount: 719 - amount: "100" 720 denom: stake 721 depositor: cosmos1.. 722 proposal_id: "1" 723 pagination: 724 next_key: null 725 total: "0" 726 ``` 727 728 ##### param 729 730 The `param` command allows users to query a given parameter for the `gov` module. 731 732 ```bash 733 simd query gov param [param-type] [flags] 734 ``` 735 736 Example: 737 738 ```bash 739 simd query gov param voting 740 ``` 741 742 Example Output: 743 744 ```bash 745 voting_period: "172800000000000" 746 ``` 747 748 ##### params 749 750 The `params` command allows users to query all parameters for the `gov` module. 751 752 ```bash 753 simd query gov params [flags] 754 ``` 755 756 Example: 757 758 ```bash 759 simd query gov params 760 ``` 761 762 Example Output: 763 764 ```bash 765 deposit_params: 766 max_deposit_period: 172800s 767 min_deposit: 768 - amount: "10000000" 769 denom: stake 770 params: 771 expedited_min_deposit: 772 - amount: "50000000" 773 denom: stake 774 expedited_threshold: "0.670000000000000000" 775 expedited_voting_period: 86400s 776 max_deposit_period: 172800s 777 min_deposit: 778 - amount: "10000000" 779 denom: stake 780 min_initial_deposit_ratio: "0.000000000000000000" 781 proposal_cancel_burn_rate: "0.500000000000000000" 782 quorum: "0.334000000000000000" 783 threshold: "0.500000000000000000" 784 veto_threshold: "0.334000000000000000" 785 voting_period: 172800s 786 tally_params: 787 quorum: "0.334000000000000000" 788 threshold: "0.500000000000000000" 789 veto_threshold: "0.334000000000000000" 790 voting_params: 791 voting_period: 172800s 792 ``` 793 794 ##### proposal 795 796 The `proposal` command allows users to query a given proposal. 797 798 ```bash 799 simd query gov proposal [proposal-id] [flags] 800 ``` 801 802 Example: 803 804 ```bash 805 simd query gov proposal 1 806 ``` 807 808 Example Output: 809 810 ```bash 811 deposit_end_time: "2022-03-30T11:50:20.819676256Z" 812 final_tally_result: 813 abstain_count: "0" 814 no_count: "0" 815 no_with_veto_count: "0" 816 yes_count: "0" 817 id: "1" 818 messages: 819 - '@type': /cosmos.bank.v1beta1.MsgSend 820 amount: 821 - amount: "10" 822 denom: stake 823 from_address: cosmos1.. 824 to_address: cosmos1.. 825 metadata: AQ== 826 status: PROPOSAL_STATUS_DEPOSIT_PERIOD 827 submit_time: "2022-03-28T11:50:20.819676256Z" 828 total_deposit: 829 - amount: "10" 830 denom: stake 831 voting_end_time: null 832 voting_start_time: null 833 ``` 834 835 ##### proposals 836 837 The `proposals` command allows users to query all proposals with optional filters. 838 839 ```bash 840 simd query gov proposals [flags] 841 ``` 842 843 Example: 844 845 ```bash 846 simd query gov proposals 847 ``` 848 849 Example Output: 850 851 ```bash 852 pagination: 853 next_key: null 854 total: "0" 855 proposals: 856 - deposit_end_time: "2022-03-30T11:50:20.819676256Z" 857 final_tally_result: 858 abstain_count: "0" 859 no_count: "0" 860 no_with_veto_count: "0" 861 yes_count: "0" 862 id: "1" 863 messages: 864 - '@type': /cosmos.bank.v1beta1.MsgSend 865 amount: 866 - amount: "10" 867 denom: stake 868 from_address: cosmos1.. 869 to_address: cosmos1.. 870 metadata: AQ== 871 status: PROPOSAL_STATUS_DEPOSIT_PERIOD 872 submit_time: "2022-03-28T11:50:20.819676256Z" 873 total_deposit: 874 - amount: "10" 875 denom: stake 876 voting_end_time: null 877 voting_start_time: null 878 - deposit_end_time: "2022-03-30T14:02:41.165025015Z" 879 final_tally_result: 880 abstain_count: "0" 881 no_count: "0" 882 no_with_veto_count: "0" 883 yes_count: "0" 884 id: "2" 885 messages: 886 - '@type': /cosmos.bank.v1beta1.MsgSend 887 amount: 888 - amount: "10" 889 denom: stake 890 from_address: cosmos1.. 891 to_address: cosmos1.. 892 metadata: AQ== 893 status: PROPOSAL_STATUS_DEPOSIT_PERIOD 894 submit_time: "2022-03-28T14:02:41.165025015Z" 895 total_deposit: 896 - amount: "10" 897 denom: stake 898 voting_end_time: null 899 voting_start_time: null 900 ``` 901 902 ##### proposer 903 904 The `proposer` command allows users to query the proposer for a given proposal. 905 906 ```bash 907 simd query gov proposer [proposal-id] [flags] 908 ``` 909 910 Example: 911 912 ```bash 913 simd query gov proposer 1 914 ``` 915 916 Example Output: 917 918 ```bash 919 proposal_id: "1" 920 proposer: cosmos1.. 921 ``` 922 923 ##### tally 924 925 The `tally` command allows users to query the tally of a given proposal vote. 926 927 ```bash 928 simd query gov tally [proposal-id] [flags] 929 ``` 930 931 Example: 932 933 ```bash 934 simd query gov tally 1 935 ``` 936 937 Example Output: 938 939 ```bash 940 abstain: "0" 941 "no": "0" 942 no_with_veto: "0" 943 "yes": "1" 944 ``` 945 946 ##### vote 947 948 The `vote` command allows users to query a vote for a given proposal. 949 950 ```bash 951 simd query gov vote [proposal-id] [voter-addr] [flags] 952 ``` 953 954 Example: 955 956 ```bash 957 simd query gov vote 1 cosmos1.. 958 ``` 959 960 Example Output: 961 962 ```bash 963 option: VOTE_OPTION_YES 964 options: 965 - option: VOTE_OPTION_YES 966 weight: "1.000000000000000000" 967 proposal_id: "1" 968 voter: cosmos1.. 969 ``` 970 971 ##### votes 972 973 The `votes` command allows users to query all votes for a given proposal. 974 975 ```bash 976 simd query gov votes [proposal-id] [flags] 977 ``` 978 979 Example: 980 981 ```bash 982 simd query gov votes 1 983 ``` 984 985 Example Output: 986 987 ```bash 988 pagination: 989 next_key: null 990 total: "0" 991 votes: 992 - option: VOTE_OPTION_YES 993 options: 994 - option: VOTE_OPTION_YES 995 weight: "1.000000000000000000" 996 proposal_id: "1" 997 voter: cosmos1.. 998 ``` 999 1000 #### Transactions 1001 1002 The `tx` commands allow users to interact with the `gov` module. 1003 1004 ```bash 1005 simd tx gov --help 1006 ``` 1007 1008 ##### deposit 1009 1010 The `deposit` command allows users to deposit tokens for a given proposal. 1011 1012 ```bash 1013 simd tx gov deposit [proposal-id] [deposit] [flags] 1014 ``` 1015 1016 Example: 1017 1018 ```bash 1019 simd tx gov deposit 1 10000000stake --from cosmos1.. 1020 ``` 1021 1022 ##### draft-proposal 1023 1024 The `draft-proposal` command allows users to draft any type of proposal. 1025 The command returns a `draft_proposal.json`, to be used by `submit-proposal` after being completed. 1026 The `draft_metadata.json` is meant to be uploaded to [IPFS](#metadata). 1027 1028 ```bash 1029 simd tx gov draft-proposal 1030 ``` 1031 1032 ##### submit-proposal 1033 1034 The `submit-proposal` command allows users to submit a governance proposal along with some messages and metadata. 1035 Messages, metadata and deposit are defined in a JSON file. 1036 1037 ```bash 1038 simd tx gov submit-proposal [path-to-proposal-json] [flags] 1039 ``` 1040 1041 Example: 1042 1043 ```bash 1044 simd tx gov submit-proposal /path/to/proposal.json --from cosmos1.. 1045 ``` 1046 1047 where `proposal.json` contains: 1048 1049 ```json 1050 { 1051 "messages": [ 1052 { 1053 "@type": "/cosmos.bank.v1beta1.MsgSend", 1054 "from_address": "cosmos1...", // The gov module module address 1055 "to_address": "cosmos1...", 1056 "amount":[{"denom": "stake","amount": "10"}] 1057 } 1058 ], 1059 "metadata": "AQ==", 1060 "deposit": "10stake", 1061 "title": "Proposal Title", 1062 "summary": "Proposal Summary" 1063 } 1064 ``` 1065 1066 :::note 1067 By default the metadata, summary and title are both limited by 255 characters, this can be overridden by the application developer. 1068 ::: 1069 1070 :::tip 1071 When metadata is not specified, the title is limited to 255 characters and the summary 40x the title length. 1072 ::: 1073 1074 ##### submit-legacy-proposal 1075 1076 The `submit-legacy-proposal` command allows users to submit a governance legacy proposal along with an initial deposit. 1077 1078 ```bash 1079 simd tx gov submit-legacy-proposal [command] [flags] 1080 ``` 1081 1082 Example: 1083 1084 ```bash 1085 simd tx gov submit-legacy-proposal --title="Test Proposal" --description="testing" --type="Text" --deposit="100000000stake" --from cosmos1.. 1086 ``` 1087 1088 Example (`param-change`): 1089 1090 ```bash 1091 simd tx gov submit-legacy-proposal param-change proposal.json --from cosmos1.. 1092 ``` 1093 1094 ```json 1095 { 1096 "title": "Test Proposal", 1097 "description": "testing, testing, 1, 2, 3", 1098 "changes": [ 1099 { 1100 "subspace": "staking", 1101 "key": "MaxValidators", 1102 "value": 100 1103 } 1104 ], 1105 "deposit": "10000000stake" 1106 } 1107 ``` 1108 1109 #### cancel-proposal 1110 1111 Once proposal is canceled, from the deposits of proposal `deposits * proposal_cancel_ratio` will be burned or sent to `ProposalCancelDest` address , if `ProposalCancelDest` is empty then deposits will be burned. The `remaining deposits` will be sent to depositers. 1112 1113 ```bash 1114 simd tx gov cancel-proposal [proposal-id] [flags] 1115 ``` 1116 1117 Example: 1118 1119 ```bash 1120 simd tx gov cancel-proposal 1 --from cosmos1... 1121 ``` 1122 1123 ##### vote 1124 1125 The `vote` command allows users to submit a vote for a given governance proposal. 1126 1127 ```bash 1128 simd tx gov vote [command] [flags] 1129 ``` 1130 1131 Example: 1132 1133 ```bash 1134 simd tx gov vote 1 yes --from cosmos1.. 1135 ``` 1136 1137 ##### weighted-vote 1138 1139 The `weighted-vote` command allows users to submit a weighted vote for a given governance proposal. 1140 1141 ```bash 1142 simd tx gov weighted-vote [proposal-id] [weighted-options] [flags] 1143 ``` 1144 1145 Example: 1146 1147 ```bash 1148 simd tx gov weighted-vote 1 yes=0.5,no=0.5 --from cosmos1.. 1149 ``` 1150 1151 ### gRPC 1152 1153 A user can query the `gov` module using gRPC endpoints. 1154 1155 #### Proposal 1156 1157 The `Proposal` endpoint allows users to query a given proposal. 1158 1159 Using legacy v1beta1: 1160 1161 ```bash 1162 cosmos.gov.v1beta1.Query/Proposal 1163 ``` 1164 1165 Example: 1166 1167 ```bash 1168 grpcurl -plaintext \ 1169 -d '{"proposal_id":"1"}' \ 1170 localhost:9090 \ 1171 cosmos.gov.v1beta1.Query/Proposal 1172 ``` 1173 1174 Example Output: 1175 1176 ```bash 1177 { 1178 "proposal": { 1179 "proposalId": "1", 1180 "content": {"@type":"/cosmos.gov.v1beta1.TextProposal","description":"testing, testing, 1, 2, 3","title":"Test Proposal"}, 1181 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1182 "finalTallyResult": { 1183 "yes": "0", 1184 "abstain": "0", 1185 "no": "0", 1186 "noWithVeto": "0" 1187 }, 1188 "submitTime": "2021-09-16T19:40:08.712440474Z", 1189 "depositEndTime": "2021-09-18T19:40:08.712440474Z", 1190 "totalDeposit": [ 1191 { 1192 "denom": "stake", 1193 "amount": "10000000" 1194 } 1195 ], 1196 "votingStartTime": "2021-09-16T19:40:08.712440474Z", 1197 "votingEndTime": "2021-09-18T19:40:08.712440474Z", 1198 "title": "Test Proposal", 1199 "summary": "testing, testing, 1, 2, 3" 1200 } 1201 } 1202 ``` 1203 1204 Using v1: 1205 1206 ```bash 1207 cosmos.gov.v1.Query/Proposal 1208 ``` 1209 1210 Example: 1211 1212 ```bash 1213 grpcurl -plaintext \ 1214 -d '{"proposal_id":"1"}' \ 1215 localhost:9090 \ 1216 cosmos.gov.v1.Query/Proposal 1217 ``` 1218 1219 Example Output: 1220 1221 ```bash 1222 { 1223 "proposal": { 1224 "id": "1", 1225 "messages": [ 1226 {"@type":"/cosmos.bank.v1beta1.MsgSend","amount":[{"denom":"stake","amount":"10"}],"fromAddress":"cosmos1..","toAddress":"cosmos1.."} 1227 ], 1228 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1229 "finalTallyResult": { 1230 "yesCount": "0", 1231 "abstainCount": "0", 1232 "noCount": "0", 1233 "noWithVetoCount": "0" 1234 }, 1235 "submitTime": "2022-03-28T11:50:20.819676256Z", 1236 "depositEndTime": "2022-03-30T11:50:20.819676256Z", 1237 "totalDeposit": [ 1238 { 1239 "denom": "stake", 1240 "amount": "10000000" 1241 } 1242 ], 1243 "votingStartTime": "2022-03-28T14:25:26.644857113Z", 1244 "votingEndTime": "2022-03-30T14:25:26.644857113Z", 1245 "metadata": "AQ==", 1246 "title": "Test Proposal", 1247 "summary": "testing, testing, 1, 2, 3" 1248 } 1249 } 1250 ``` 1251 1252 #### Proposals 1253 1254 The `Proposals` endpoint allows users to query all proposals with optional filters. 1255 1256 Using legacy v1beta1: 1257 1258 ```bash 1259 cosmos.gov.v1beta1.Query/Proposals 1260 ``` 1261 1262 Example: 1263 1264 ```bash 1265 grpcurl -plaintext \ 1266 localhost:9090 \ 1267 cosmos.gov.v1beta1.Query/Proposals 1268 ``` 1269 1270 Example Output: 1271 1272 ```bash 1273 { 1274 "proposals": [ 1275 { 1276 "proposalId": "1", 1277 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1278 "finalTallyResult": { 1279 "yes": "0", 1280 "abstain": "0", 1281 "no": "0", 1282 "noWithVeto": "0" 1283 }, 1284 "submitTime": "2022-03-28T11:50:20.819676256Z", 1285 "depositEndTime": "2022-03-30T11:50:20.819676256Z", 1286 "totalDeposit": [ 1287 { 1288 "denom": "stake", 1289 "amount": "10000000010" 1290 } 1291 ], 1292 "votingStartTime": "2022-03-28T14:25:26.644857113Z", 1293 "votingEndTime": "2022-03-30T14:25:26.644857113Z" 1294 }, 1295 { 1296 "proposalId": "2", 1297 "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", 1298 "finalTallyResult": { 1299 "yes": "0", 1300 "abstain": "0", 1301 "no": "0", 1302 "noWithVeto": "0" 1303 }, 1304 "submitTime": "2022-03-28T14:02:41.165025015Z", 1305 "depositEndTime": "2022-03-30T14:02:41.165025015Z", 1306 "totalDeposit": [ 1307 { 1308 "denom": "stake", 1309 "amount": "10" 1310 } 1311 ], 1312 "votingStartTime": "0001-01-01T00:00:00Z", 1313 "votingEndTime": "0001-01-01T00:00:00Z" 1314 } 1315 ], 1316 "pagination": { 1317 "total": "2" 1318 } 1319 } 1320 1321 ``` 1322 1323 Using v1: 1324 1325 ```bash 1326 cosmos.gov.v1.Query/Proposals 1327 ``` 1328 1329 Example: 1330 1331 ```bash 1332 grpcurl -plaintext \ 1333 localhost:9090 \ 1334 cosmos.gov.v1.Query/Proposals 1335 ``` 1336 1337 Example Output: 1338 1339 ```bash 1340 { 1341 "proposals": [ 1342 { 1343 "id": "1", 1344 "messages": [ 1345 {"@type":"/cosmos.bank.v1beta1.MsgSend","amount":[{"denom":"stake","amount":"10"}],"fromAddress":"cosmos1..","toAddress":"cosmos1.."} 1346 ], 1347 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1348 "finalTallyResult": { 1349 "yesCount": "0", 1350 "abstainCount": "0", 1351 "noCount": "0", 1352 "noWithVetoCount": "0" 1353 }, 1354 "submitTime": "2022-03-28T11:50:20.819676256Z", 1355 "depositEndTime": "2022-03-30T11:50:20.819676256Z", 1356 "totalDeposit": [ 1357 { 1358 "denom": "stake", 1359 "amount": "10000000010" 1360 } 1361 ], 1362 "votingStartTime": "2022-03-28T14:25:26.644857113Z", 1363 "votingEndTime": "2022-03-30T14:25:26.644857113Z", 1364 "metadata": "AQ==", 1365 "title": "Proposal Title", 1366 "summary": "Proposal Summary" 1367 }, 1368 { 1369 "id": "2", 1370 "messages": [ 1371 {"@type":"/cosmos.bank.v1beta1.MsgSend","amount":[{"denom":"stake","amount":"10"}],"fromAddress":"cosmos1..","toAddress":"cosmos1.."} 1372 ], 1373 "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", 1374 "finalTallyResult": { 1375 "yesCount": "0", 1376 "abstainCount": "0", 1377 "noCount": "0", 1378 "noWithVetoCount": "0" 1379 }, 1380 "submitTime": "2022-03-28T14:02:41.165025015Z", 1381 "depositEndTime": "2022-03-30T14:02:41.165025015Z", 1382 "totalDeposit": [ 1383 { 1384 "denom": "stake", 1385 "amount": "10" 1386 } 1387 ], 1388 "metadata": "AQ==", 1389 "title": "Proposal Title", 1390 "summary": "Proposal Summary" 1391 } 1392 ], 1393 "pagination": { 1394 "total": "2" 1395 } 1396 } 1397 ``` 1398 1399 #### Vote 1400 1401 The `Vote` endpoint allows users to query a vote for a given proposal. 1402 1403 Using legacy v1beta1: 1404 1405 ```bash 1406 cosmos.gov.v1beta1.Query/Vote 1407 ``` 1408 1409 Example: 1410 1411 ```bash 1412 grpcurl -plaintext \ 1413 -d '{"proposal_id":"1","voter":"cosmos1.."}' \ 1414 localhost:9090 \ 1415 cosmos.gov.v1beta1.Query/Vote 1416 ``` 1417 1418 Example Output: 1419 1420 ```bash 1421 { 1422 "vote": { 1423 "proposalId": "1", 1424 "voter": "cosmos1..", 1425 "option": "VOTE_OPTION_YES", 1426 "options": [ 1427 { 1428 "option": "VOTE_OPTION_YES", 1429 "weight": "1000000000000000000" 1430 } 1431 ] 1432 } 1433 } 1434 ``` 1435 1436 Using v1: 1437 1438 ```bash 1439 cosmos.gov.v1.Query/Vote 1440 ``` 1441 1442 Example: 1443 1444 ```bash 1445 grpcurl -plaintext \ 1446 -d '{"proposal_id":"1","voter":"cosmos1.."}' \ 1447 localhost:9090 \ 1448 cosmos.gov.v1.Query/Vote 1449 ``` 1450 1451 Example Output: 1452 1453 ```bash 1454 { 1455 "vote": { 1456 "proposalId": "1", 1457 "voter": "cosmos1..", 1458 "option": "VOTE_OPTION_YES", 1459 "options": [ 1460 { 1461 "option": "VOTE_OPTION_YES", 1462 "weight": "1.000000000000000000" 1463 } 1464 ] 1465 } 1466 } 1467 ``` 1468 1469 #### Votes 1470 1471 The `Votes` endpoint allows users to query all votes for a given proposal. 1472 1473 Using legacy v1beta1: 1474 1475 ```bash 1476 cosmos.gov.v1beta1.Query/Votes 1477 ``` 1478 1479 Example: 1480 1481 ```bash 1482 grpcurl -plaintext \ 1483 -d '{"proposal_id":"1"}' \ 1484 localhost:9090 \ 1485 cosmos.gov.v1beta1.Query/Votes 1486 ``` 1487 1488 Example Output: 1489 1490 ```bash 1491 { 1492 "votes": [ 1493 { 1494 "proposalId": "1", 1495 "voter": "cosmos1..", 1496 "options": [ 1497 { 1498 "option": "VOTE_OPTION_YES", 1499 "weight": "1000000000000000000" 1500 } 1501 ] 1502 } 1503 ], 1504 "pagination": { 1505 "total": "1" 1506 } 1507 } 1508 ``` 1509 1510 Using v1: 1511 1512 ```bash 1513 cosmos.gov.v1.Query/Votes 1514 ``` 1515 1516 Example: 1517 1518 ```bash 1519 grpcurl -plaintext \ 1520 -d '{"proposal_id":"1"}' \ 1521 localhost:9090 \ 1522 cosmos.gov.v1.Query/Votes 1523 ``` 1524 1525 Example Output: 1526 1527 ```bash 1528 { 1529 "votes": [ 1530 { 1531 "proposalId": "1", 1532 "voter": "cosmos1..", 1533 "options": [ 1534 { 1535 "option": "VOTE_OPTION_YES", 1536 "weight": "1.000000000000000000" 1537 } 1538 ] 1539 } 1540 ], 1541 "pagination": { 1542 "total": "1" 1543 } 1544 } 1545 ``` 1546 1547 #### Params 1548 1549 The `Params` endpoint allows users to query all parameters for the `gov` module. 1550 1551 <!-- TODO: #10197 Querying governance params outputs nil values --> 1552 1553 Using legacy v1beta1: 1554 1555 ```bash 1556 cosmos.gov.v1beta1.Query/Params 1557 ``` 1558 1559 Example: 1560 1561 ```bash 1562 grpcurl -plaintext \ 1563 -d '{"params_type":"voting"}' \ 1564 localhost:9090 \ 1565 cosmos.gov.v1beta1.Query/Params 1566 ``` 1567 1568 Example Output: 1569 1570 ```bash 1571 { 1572 "votingParams": { 1573 "votingPeriod": "172800s" 1574 }, 1575 "depositParams": { 1576 "maxDepositPeriod": "0s" 1577 }, 1578 "tallyParams": { 1579 "quorum": "MA==", 1580 "threshold": "MA==", 1581 "vetoThreshold": "MA==" 1582 } 1583 } 1584 ``` 1585 1586 Using v1: 1587 1588 ```bash 1589 cosmos.gov.v1.Query/Params 1590 ``` 1591 1592 Example: 1593 1594 ```bash 1595 grpcurl -plaintext \ 1596 -d '{"params_type":"voting"}' \ 1597 localhost:9090 \ 1598 cosmos.gov.v1.Query/Params 1599 ``` 1600 1601 Example Output: 1602 1603 ```bash 1604 { 1605 "votingParams": { 1606 "votingPeriod": "172800s" 1607 } 1608 } 1609 ``` 1610 1611 #### Deposit 1612 1613 The `Deposit` endpoint allows users to query a deposit for a given proposal from a given depositor. 1614 1615 Using legacy v1beta1: 1616 1617 ```bash 1618 cosmos.gov.v1beta1.Query/Deposit 1619 ``` 1620 1621 Example: 1622 1623 ```bash 1624 grpcurl -plaintext \ 1625 '{"proposal_id":"1","depositor":"cosmos1.."}' \ 1626 localhost:9090 \ 1627 cosmos.gov.v1beta1.Query/Deposit 1628 ``` 1629 1630 Example Output: 1631 1632 ```bash 1633 { 1634 "deposit": { 1635 "proposalId": "1", 1636 "depositor": "cosmos1..", 1637 "amount": [ 1638 { 1639 "denom": "stake", 1640 "amount": "10000000" 1641 } 1642 ] 1643 } 1644 } 1645 ``` 1646 1647 Using v1: 1648 1649 ```bash 1650 cosmos.gov.v1.Query/Deposit 1651 ``` 1652 1653 Example: 1654 1655 ```bash 1656 grpcurl -plaintext \ 1657 '{"proposal_id":"1","depositor":"cosmos1.."}' \ 1658 localhost:9090 \ 1659 cosmos.gov.v1.Query/Deposit 1660 ``` 1661 1662 Example Output: 1663 1664 ```bash 1665 { 1666 "deposit": { 1667 "proposalId": "1", 1668 "depositor": "cosmos1..", 1669 "amount": [ 1670 { 1671 "denom": "stake", 1672 "amount": "10000000" 1673 } 1674 ] 1675 } 1676 } 1677 ``` 1678 1679 #### deposits 1680 1681 The `Deposits` endpoint allows users to query all deposits for a given proposal. 1682 1683 Using legacy v1beta1: 1684 1685 ```bash 1686 cosmos.gov.v1beta1.Query/Deposits 1687 ``` 1688 1689 Example: 1690 1691 ```bash 1692 grpcurl -plaintext \ 1693 -d '{"proposal_id":"1"}' \ 1694 localhost:9090 \ 1695 cosmos.gov.v1beta1.Query/Deposits 1696 ``` 1697 1698 Example Output: 1699 1700 ```bash 1701 { 1702 "deposits": [ 1703 { 1704 "proposalId": "1", 1705 "depositor": "cosmos1..", 1706 "amount": [ 1707 { 1708 "denom": "stake", 1709 "amount": "10000000" 1710 } 1711 ] 1712 } 1713 ], 1714 "pagination": { 1715 "total": "1" 1716 } 1717 } 1718 ``` 1719 1720 Using v1: 1721 1722 ```bash 1723 cosmos.gov.v1.Query/Deposits 1724 ``` 1725 1726 Example: 1727 1728 ```bash 1729 grpcurl -plaintext \ 1730 -d '{"proposal_id":"1"}' \ 1731 localhost:9090 \ 1732 cosmos.gov.v1.Query/Deposits 1733 ``` 1734 1735 Example Output: 1736 1737 ```bash 1738 { 1739 "deposits": [ 1740 { 1741 "proposalId": "1", 1742 "depositor": "cosmos1..", 1743 "amount": [ 1744 { 1745 "denom": "stake", 1746 "amount": "10000000" 1747 } 1748 ] 1749 } 1750 ], 1751 "pagination": { 1752 "total": "1" 1753 } 1754 } 1755 ``` 1756 1757 #### TallyResult 1758 1759 The `TallyResult` endpoint allows users to query the tally of a given proposal. 1760 1761 Using legacy v1beta1: 1762 1763 ```bash 1764 cosmos.gov.v1beta1.Query/TallyResult 1765 ``` 1766 1767 Example: 1768 1769 ```bash 1770 grpcurl -plaintext \ 1771 -d '{"proposal_id":"1"}' \ 1772 localhost:9090 \ 1773 cosmos.gov.v1beta1.Query/TallyResult 1774 ``` 1775 1776 Example Output: 1777 1778 ```bash 1779 { 1780 "tally": { 1781 "yes": "1000000", 1782 "abstain": "0", 1783 "no": "0", 1784 "noWithVeto": "0" 1785 } 1786 } 1787 ``` 1788 1789 Using v1: 1790 1791 ```bash 1792 cosmos.gov.v1.Query/TallyResult 1793 ``` 1794 1795 Example: 1796 1797 ```bash 1798 grpcurl -plaintext \ 1799 -d '{"proposal_id":"1"}' \ 1800 localhost:9090 \ 1801 cosmos.gov.v1.Query/TallyResult 1802 ``` 1803 1804 Example Output: 1805 1806 ```bash 1807 { 1808 "tally": { 1809 "yes": "1000000", 1810 "abstain": "0", 1811 "no": "0", 1812 "noWithVeto": "0" 1813 } 1814 } 1815 ``` 1816 1817 ### REST 1818 1819 A user can query the `gov` module using REST endpoints. 1820 1821 #### proposal 1822 1823 The `proposals` endpoint allows users to query a given proposal. 1824 1825 Using legacy v1beta1: 1826 1827 ```bash 1828 /cosmos/gov/v1beta1/proposals/{proposal_id} 1829 ``` 1830 1831 Example: 1832 1833 ```bash 1834 curl localhost:1317/cosmos/gov/v1beta1/proposals/1 1835 ``` 1836 1837 Example Output: 1838 1839 ```bash 1840 { 1841 "proposal": { 1842 "proposal_id": "1", 1843 "content": null, 1844 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1845 "final_tally_result": { 1846 "yes": "0", 1847 "abstain": "0", 1848 "no": "0", 1849 "no_with_veto": "0" 1850 }, 1851 "submit_time": "2022-03-28T11:50:20.819676256Z", 1852 "deposit_end_time": "2022-03-30T11:50:20.819676256Z", 1853 "total_deposit": [ 1854 { 1855 "denom": "stake", 1856 "amount": "10000000010" 1857 } 1858 ], 1859 "voting_start_time": "2022-03-28T14:25:26.644857113Z", 1860 "voting_end_time": "2022-03-30T14:25:26.644857113Z" 1861 } 1862 } 1863 ``` 1864 1865 Using v1: 1866 1867 ```bash 1868 /cosmos/gov/v1/proposals/{proposal_id} 1869 ``` 1870 1871 Example: 1872 1873 ```bash 1874 curl localhost:1317/cosmos/gov/v1/proposals/1 1875 ``` 1876 1877 Example Output: 1878 1879 ```bash 1880 { 1881 "proposal": { 1882 "id": "1", 1883 "messages": [ 1884 { 1885 "@type": "/cosmos.bank.v1beta1.MsgSend", 1886 "from_address": "cosmos1..", 1887 "to_address": "cosmos1..", 1888 "amount": [ 1889 { 1890 "denom": "stake", 1891 "amount": "10" 1892 } 1893 ] 1894 } 1895 ], 1896 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1897 "final_tally_result": { 1898 "yes_count": "0", 1899 "abstain_count": "0", 1900 "no_count": "0", 1901 "no_with_veto_count": "0" 1902 }, 1903 "submit_time": "2022-03-28T11:50:20.819676256Z", 1904 "deposit_end_time": "2022-03-30T11:50:20.819676256Z", 1905 "total_deposit": [ 1906 { 1907 "denom": "stake", 1908 "amount": "10000000" 1909 } 1910 ], 1911 "voting_start_time": "2022-03-28T14:25:26.644857113Z", 1912 "voting_end_time": "2022-03-30T14:25:26.644857113Z", 1913 "metadata": "AQ==", 1914 "title": "Proposal Title", 1915 "summary": "Proposal Summary" 1916 } 1917 } 1918 ``` 1919 1920 #### proposals 1921 1922 The `proposals` endpoint also allows users to query all proposals with optional filters. 1923 1924 Using legacy v1beta1: 1925 1926 ```bash 1927 /cosmos/gov/v1beta1/proposals 1928 ``` 1929 1930 Example: 1931 1932 ```bash 1933 curl localhost:1317/cosmos/gov/v1beta1/proposals 1934 ``` 1935 1936 Example Output: 1937 1938 ```bash 1939 { 1940 "proposals": [ 1941 { 1942 "proposal_id": "1", 1943 "content": null, 1944 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 1945 "final_tally_result": { 1946 "yes": "0", 1947 "abstain": "0", 1948 "no": "0", 1949 "no_with_veto": "0" 1950 }, 1951 "submit_time": "2022-03-28T11:50:20.819676256Z", 1952 "deposit_end_time": "2022-03-30T11:50:20.819676256Z", 1953 "total_deposit": [ 1954 { 1955 "denom": "stake", 1956 "amount": "10000000" 1957 } 1958 ], 1959 "voting_start_time": "2022-03-28T14:25:26.644857113Z", 1960 "voting_end_time": "2022-03-30T14:25:26.644857113Z" 1961 }, 1962 { 1963 "proposal_id": "2", 1964 "content": null, 1965 "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", 1966 "final_tally_result": { 1967 "yes": "0", 1968 "abstain": "0", 1969 "no": "0", 1970 "no_with_veto": "0" 1971 }, 1972 "submit_time": "2022-03-28T14:02:41.165025015Z", 1973 "deposit_end_time": "2022-03-30T14:02:41.165025015Z", 1974 "total_deposit": [ 1975 { 1976 "denom": "stake", 1977 "amount": "10" 1978 } 1979 ], 1980 "voting_start_time": "0001-01-01T00:00:00Z", 1981 "voting_end_time": "0001-01-01T00:00:00Z" 1982 } 1983 ], 1984 "pagination": { 1985 "next_key": null, 1986 "total": "2" 1987 } 1988 } 1989 ``` 1990 1991 Using v1: 1992 1993 ```bash 1994 /cosmos/gov/v1/proposals 1995 ``` 1996 1997 Example: 1998 1999 ```bash 2000 curl localhost:1317/cosmos/gov/v1/proposals 2001 ``` 2002 2003 Example Output: 2004 2005 ```bash 2006 { 2007 "proposals": [ 2008 { 2009 "id": "1", 2010 "messages": [ 2011 { 2012 "@type": "/cosmos.bank.v1beta1.MsgSend", 2013 "from_address": "cosmos1..", 2014 "to_address": "cosmos1..", 2015 "amount": [ 2016 { 2017 "denom": "stake", 2018 "amount": "10" 2019 } 2020 ] 2021 } 2022 ], 2023 "status": "PROPOSAL_STATUS_VOTING_PERIOD", 2024 "final_tally_result": { 2025 "yes_count": "0", 2026 "abstain_count": "0", 2027 "no_count": "0", 2028 "no_with_veto_count": "0" 2029 }, 2030 "submit_time": "2022-03-28T11:50:20.819676256Z", 2031 "deposit_end_time": "2022-03-30T11:50:20.819676256Z", 2032 "total_deposit": [ 2033 { 2034 "denom": "stake", 2035 "amount": "10000000010" 2036 } 2037 ], 2038 "voting_start_time": "2022-03-28T14:25:26.644857113Z", 2039 "voting_end_time": "2022-03-30T14:25:26.644857113Z", 2040 "metadata": "AQ==", 2041 "title": "Proposal Title", 2042 "summary": "Proposal Summary" 2043 }, 2044 { 2045 "id": "2", 2046 "messages": [ 2047 { 2048 "@type": "/cosmos.bank.v1beta1.MsgSend", 2049 "from_address": "cosmos1..", 2050 "to_address": "cosmos1..", 2051 "amount": [ 2052 { 2053 "denom": "stake", 2054 "amount": "10" 2055 } 2056 ] 2057 } 2058 ], 2059 "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", 2060 "final_tally_result": { 2061 "yes_count": "0", 2062 "abstain_count": "0", 2063 "no_count": "0", 2064 "no_with_veto_count": "0" 2065 }, 2066 "submit_time": "2022-03-28T14:02:41.165025015Z", 2067 "deposit_end_time": "2022-03-30T14:02:41.165025015Z", 2068 "total_deposit": [ 2069 { 2070 "denom": "stake", 2071 "amount": "10" 2072 } 2073 ], 2074 "voting_start_time": null, 2075 "voting_end_time": null, 2076 "metadata": "AQ==", 2077 "title": "Proposal Title", 2078 "summary": "Proposal Summary" 2079 } 2080 ], 2081 "pagination": { 2082 "next_key": null, 2083 "total": "2" 2084 } 2085 } 2086 ``` 2087 2088 #### voter vote 2089 2090 The `votes` endpoint allows users to query a vote for a given proposal. 2091 2092 Using legacy v1beta1: 2093 2094 ```bash 2095 /cosmos/gov/v1beta1/proposals/{proposal_id}/votes/{voter} 2096 ``` 2097 2098 Example: 2099 2100 ```bash 2101 curl localhost:1317/cosmos/gov/v1beta1/proposals/1/votes/cosmos1.. 2102 ``` 2103 2104 Example Output: 2105 2106 ```bash 2107 { 2108 "vote": { 2109 "proposal_id": "1", 2110 "voter": "cosmos1..", 2111 "option": "VOTE_OPTION_YES", 2112 "options": [ 2113 { 2114 "option": "VOTE_OPTION_YES", 2115 "weight": "1.000000000000000000" 2116 } 2117 ] 2118 } 2119 } 2120 ``` 2121 2122 Using v1: 2123 2124 ```bash 2125 /cosmos/gov/v1/proposals/{proposal_id}/votes/{voter} 2126 ``` 2127 2128 Example: 2129 2130 ```bash 2131 curl localhost:1317/cosmos/gov/v1/proposals/1/votes/cosmos1.. 2132 ``` 2133 2134 Example Output: 2135 2136 ```bash 2137 { 2138 "vote": { 2139 "proposal_id": "1", 2140 "voter": "cosmos1..", 2141 "options": [ 2142 { 2143 "option": "VOTE_OPTION_YES", 2144 "weight": "1.000000000000000000" 2145 } 2146 ], 2147 "metadata": "" 2148 } 2149 } 2150 ``` 2151 2152 #### votes 2153 2154 The `votes` endpoint allows users to query all votes for a given proposal. 2155 2156 Using legacy v1beta1: 2157 2158 ```bash 2159 /cosmos/gov/v1beta1/proposals/{proposal_id}/votes 2160 ``` 2161 2162 Example: 2163 2164 ```bash 2165 curl localhost:1317/cosmos/gov/v1beta1/proposals/1/votes 2166 ``` 2167 2168 Example Output: 2169 2170 ```bash 2171 { 2172 "votes": [ 2173 { 2174 "proposal_id": "1", 2175 "voter": "cosmos1..", 2176 "option": "VOTE_OPTION_YES", 2177 "options": [ 2178 { 2179 "option": "VOTE_OPTION_YES", 2180 "weight": "1.000000000000000000" 2181 } 2182 ] 2183 } 2184 ], 2185 "pagination": { 2186 "next_key": null, 2187 "total": "1" 2188 } 2189 } 2190 ``` 2191 2192 Using v1: 2193 2194 ```bash 2195 /cosmos/gov/v1/proposals/{proposal_id}/votes 2196 ``` 2197 2198 Example: 2199 2200 ```bash 2201 curl localhost:1317/cosmos/gov/v1/proposals/1/votes 2202 ``` 2203 2204 Example Output: 2205 2206 ```bash 2207 { 2208 "votes": [ 2209 { 2210 "proposal_id": "1", 2211 "voter": "cosmos1..", 2212 "options": [ 2213 { 2214 "option": "VOTE_OPTION_YES", 2215 "weight": "1.000000000000000000" 2216 } 2217 ], 2218 "metadata": "" 2219 } 2220 ], 2221 "pagination": { 2222 "next_key": null, 2223 "total": "1" 2224 } 2225 } 2226 ``` 2227 2228 #### params 2229 2230 The `params` endpoint allows users to query all parameters for the `gov` module. 2231 2232 <!-- TODO: #10197 Querying governance params outputs nil values --> 2233 2234 Using legacy v1beta1: 2235 2236 ```bash 2237 /cosmos/gov/v1beta1/params/{params_type} 2238 ``` 2239 2240 Example: 2241 2242 ```bash 2243 curl localhost:1317/cosmos/gov/v1beta1/params/voting 2244 ``` 2245 2246 Example Output: 2247 2248 ```bash 2249 { 2250 "voting_params": { 2251 "voting_period": "172800s" 2252 }, 2253 "deposit_params": { 2254 "min_deposit": [ 2255 ], 2256 "max_deposit_period": "0s" 2257 }, 2258 "tally_params": { 2259 "quorum": "0.000000000000000000", 2260 "threshold": "0.000000000000000000", 2261 "veto_threshold": "0.000000000000000000" 2262 } 2263 } 2264 ``` 2265 2266 Using v1: 2267 2268 ```bash 2269 /cosmos/gov/v1/params/{params_type} 2270 ``` 2271 2272 Example: 2273 2274 ```bash 2275 curl localhost:1317/cosmos/gov/v1/params/voting 2276 ``` 2277 2278 Example Output: 2279 2280 ```bash 2281 { 2282 "voting_params": { 2283 "voting_period": "172800s" 2284 }, 2285 "deposit_params": { 2286 "min_deposit": [ 2287 ], 2288 "max_deposit_period": "0s" 2289 }, 2290 "tally_params": { 2291 "quorum": "0.000000000000000000", 2292 "threshold": "0.000000000000000000", 2293 "veto_threshold": "0.000000000000000000" 2294 } 2295 } 2296 ``` 2297 2298 #### deposits 2299 2300 The `deposits` endpoint allows users to query a deposit for a given proposal from a given depositor. 2301 2302 Using legacy v1beta1: 2303 2304 ```bash 2305 /cosmos/gov/v1beta1/proposals/{proposal_id}/deposits/{depositor} 2306 ``` 2307 2308 Example: 2309 2310 ```bash 2311 curl localhost:1317/cosmos/gov/v1beta1/proposals/1/deposits/cosmos1.. 2312 ``` 2313 2314 Example Output: 2315 2316 ```bash 2317 { 2318 "deposit": { 2319 "proposal_id": "1", 2320 "depositor": "cosmos1..", 2321 "amount": [ 2322 { 2323 "denom": "stake", 2324 "amount": "10000000" 2325 } 2326 ] 2327 } 2328 } 2329 ``` 2330 2331 Using v1: 2332 2333 ```bash 2334 /cosmos/gov/v1/proposals/{proposal_id}/deposits/{depositor} 2335 ``` 2336 2337 Example: 2338 2339 ```bash 2340 curl localhost:1317/cosmos/gov/v1/proposals/1/deposits/cosmos1.. 2341 ``` 2342 2343 Example Output: 2344 2345 ```bash 2346 { 2347 "deposit": { 2348 "proposal_id": "1", 2349 "depositor": "cosmos1..", 2350 "amount": [ 2351 { 2352 "denom": "stake", 2353 "amount": "10000000" 2354 } 2355 ] 2356 } 2357 } 2358 ``` 2359 2360 #### proposal deposits 2361 2362 The `deposits` endpoint allows users to query all deposits for a given proposal. 2363 2364 Using legacy v1beta1: 2365 2366 ```bash 2367 /cosmos/gov/v1beta1/proposals/{proposal_id}/deposits 2368 ``` 2369 2370 Example: 2371 2372 ```bash 2373 curl localhost:1317/cosmos/gov/v1beta1/proposals/1/deposits 2374 ``` 2375 2376 Example Output: 2377 2378 ```bash 2379 { 2380 "deposits": [ 2381 { 2382 "proposal_id": "1", 2383 "depositor": "cosmos1..", 2384 "amount": [ 2385 { 2386 "denom": "stake", 2387 "amount": "10000000" 2388 } 2389 ] 2390 } 2391 ], 2392 "pagination": { 2393 "next_key": null, 2394 "total": "1" 2395 } 2396 } 2397 ``` 2398 2399 Using v1: 2400 2401 ```bash 2402 /cosmos/gov/v1/proposals/{proposal_id}/deposits 2403 ``` 2404 2405 Example: 2406 2407 ```bash 2408 curl localhost:1317/cosmos/gov/v1/proposals/1/deposits 2409 ``` 2410 2411 Example Output: 2412 2413 ```bash 2414 { 2415 "deposits": [ 2416 { 2417 "proposal_id": "1", 2418 "depositor": "cosmos1..", 2419 "amount": [ 2420 { 2421 "denom": "stake", 2422 "amount": "10000000" 2423 } 2424 ] 2425 } 2426 ], 2427 "pagination": { 2428 "next_key": null, 2429 "total": "1" 2430 } 2431 } 2432 ``` 2433 2434 #### tally 2435 2436 The `tally` endpoint allows users to query the tally of a given proposal. 2437 2438 Using legacy v1beta1: 2439 2440 ```bash 2441 /cosmos/gov/v1beta1/proposals/{proposal_id}/tally 2442 ``` 2443 2444 Example: 2445 2446 ```bash 2447 curl localhost:1317/cosmos/gov/v1beta1/proposals/1/tally 2448 ``` 2449 2450 Example Output: 2451 2452 ```bash 2453 { 2454 "tally": { 2455 "yes": "1000000", 2456 "abstain": "0", 2457 "no": "0", 2458 "no_with_veto": "0" 2459 } 2460 } 2461 ``` 2462 2463 Using v1: 2464 2465 ```bash 2466 /cosmos/gov/v1/proposals/{proposal_id}/tally 2467 ``` 2468 2469 Example: 2470 2471 ```bash 2472 curl localhost:1317/cosmos/gov/v1/proposals/1/tally 2473 ``` 2474 2475 Example Output: 2476 2477 ```bash 2478 { 2479 "tally": { 2480 "yes": "1000000", 2481 "abstain": "0", 2482 "no": "0", 2483 "no_with_veto": "0" 2484 } 2485 } 2486 ``` 2487 2488 ## Metadata 2489 2490 The gov module has two locations for metadata where users can provide further context about the on-chain actions they are taking. By default all metadata fields have a 255 character length field where metadata can be stored in json format, either on-chain or off-chain depending on the amount of data required. Here we provide a recommendation for the json structure and where the data should be stored. There are two important factors in making these recommendations. First, that the gov and group modules are consistent with one another, note the number of proposals made by all groups may be quite large. Second, that client applications such as block explorers and governance interfaces have confidence in the consistency of metadata structure accross chains. 2491 2492 ### Proposal 2493 2494 Location: off-chain as json object stored on IPFS (mirrors [group proposal](../group/README.md#metadata)) 2495 2496 ```json 2497 { 2498 "title": "", 2499 "authors": [""], 2500 "summary": "", 2501 "details": "", 2502 "proposal_forum_url": "", 2503 "vote_option_context": "", 2504 } 2505 ``` 2506 2507 :::note 2508 The `authors` field is an array of strings, this is to allow for multiple authors to be listed in the metadata. 2509 In v0.46, the `authors` field is a comma-separated string. Frontends are encouraged to support both formats for backwards compatibility. 2510 ::: 2511 2512 ### Vote 2513 2514 Location: on-chain as json within 255 character limit (mirrors [group vote](../group/README.md#metadata)) 2515 2516 ```json 2517 { 2518 "justification": "", 2519 } 2520 ``` 2521 2522 ## Future Improvements 2523 2524 The current documentation only describes the minimum viable product for the 2525 governance module. Future improvements may include: 2526 2527 * **`BountyProposals`:** If accepted, a `BountyProposal` creates an open 2528 bounty. The `BountyProposal` specifies how many Atoms will be given upon 2529 completion. These Atoms will be taken from the `reserve pool`. After a 2530 `BountyProposal` is accepted by governance, anybody can submit a 2531 `SoftwareUpgradeProposal` with the code to claim the bounty. Note that once a 2532 `BountyProposal` is accepted, the corresponding funds in the `reserve pool` 2533 are locked so that payment can always be honored. In order to link a 2534 `SoftwareUpgradeProposal` to an open bounty, the submitter of the 2535 `SoftwareUpgradeProposal` will use the `Proposal.LinkedProposal` attribute. 2536 If a `SoftwareUpgradeProposal` linked to an open bounty is accepted by 2537 governance, the funds that were reserved are automatically transferred to the 2538 submitter. 2539 * **Complex delegation:** Delegators could choose other representatives than 2540 their validators. Ultimately, the chain of representatives would always end 2541 up to a validator, but delegators could inherit the vote of their chosen 2542 representative before they inherit the vote of their validator. In other 2543 words, they would only inherit the vote of their validator if their other 2544 appointed representative did not vote. 2545 * **Better process for proposal review:** There would be two parts to 2546 `proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to 2547 reward third party auditors.