diff --git a/docs/docs/delegators/delegator-guide-cli.md b/docs/docs/delegators/delegator-guide-cli.md index 9bbd7624dac..550da38fc77 100644 --- a/docs/docs/delegators/delegator-guide-cli.md +++ b/docs/docs/delegators/delegator-guide-cli.md @@ -300,7 +300,7 @@ If you run your own full-node, just use `tcp://localhost:26657` as the address. Finally, let us set the `chain-id` of the blockchain we want to interact with: ```bash -gaiad config chain-id cosmoshub-2 +gaiad config chain-id cosmoshub-4 ``` ## Querying the State @@ -484,7 +484,8 @@ At the end of the voting period, the proposal is accepted if there are more than // =text/parameter_change/software_upgrade // ex value for flag: =0.0025uatom -gaiad tx gov submit-proposal --title "Test Proposal" --description "My awesome proposal" --type --deposit=10000000uatom --gas auto --gas-adjustment 1.5 --gas-prices --from +// the proposal must meet the minimum deposit amount - please check the current chain params +gaiad tx gov submit-legacy-proposal --title "Test Text Proposal" --description "My awesome proposal" --type "text" --deposit=10000000uatom --gas auto --gas-adjustment 1.5 --gas-prices --from // Increase deposit of a proposal // Retrieve proposalID from $gaiad query gov proposals --status deposit_period @@ -512,10 +513,10 @@ gaiad tx staking delegate --from --chain-id cosmoshub-2 +gaiad query account --chain-id cosmoshub-4 ``` Then, copy `unsignedTx.json` and transfer it (e.g. via USB) to the offline computer. If it is not done already, [create an account on the offline computer](#using-a-computer). For additional security, you can double check the parameters of your transaction before signing it using the following command: @@ -527,7 +528,7 @@ cat unsignedTx.json Now, sign the transaction using the following command. You will need the `chain-id`, `sequence` and `account-number` obtained earlier: ```bash -gaiad tx sign unsignedTx.json --from --offline --chain-id cosmoshub-2 --sequence --account-number > signedTx.json +gaiad tx sign unsignedTx.json --from --offline --chain-id cosmoshub-4 --sequence --account-number > signedTx.json ``` Copy `signedTx.json` and transfer it back to the online computer. Finally, use the following command to broadcast the transaction: diff --git a/docs/docs/getting-started/installation.md b/docs/docs/getting-started/installation.md index 9991842b384..9fccaef73f8 100644 --- a/docs/docs/getting-started/installation.md +++ b/docs/docs/getting-started/installation.md @@ -7,7 +7,7 @@ This guide will explain how to install the `gaiad` binary and run the cli. With ## Build Requirements -At present, the SDK fully supports installation on linux distributions. For the purpose of this instruction set, we'll be using `Ubuntu 20.04.3 LTS`. It is also possible to install `gaiad` on Unix, while Windows may require additional unsupported third party installation. All steps are listed below for a clean install. +At present, the SDK fully supports installation on linux distributions. For the purpose of this instruction set, we'll be using `Ubuntu 22.04 LTS`. It is also possible to install `gaiad` on Unix, while Windows may require additional unsupported third party installation. All steps are listed below for a clean install. 1. [Update & install build tools](#build-tools) 2. [Install Go](#install-go) @@ -28,7 +28,7 @@ sudo apt-get install -y make gcc ## Install Go :::tip -**Go 1.20+** is required. +**Go 1.21+** is required. ::: We suggest the following two ways to install Go. Check out the [official docs](https://golang.org/doc/install) and Go installer for the correct download for your operating system. Alternatively, you can install Go yourself from the command line. Detailed below are standard default installation locations, but feel free to customize. @@ -37,12 +37,12 @@ We suggest the following two ways to install Go. Check out the [official docs](h **Ubuntu:** -At the time of this writing, the latest release is `1.20.3`. We're going to download the tarball, extract it to `/usr/local`, and export `GOROOT` to our `$PATH` +At the time of this writing, the latest release is `1.21.7`. We're going to download the tarball, extract it to `/usr/local`, and export `GOROOT` to our `$PATH` ```bash -curl -OL https://go.dev/dl/go1.20.3.linux-amd64.tar.gz +curl -OL https://go.dev/dl/go1.21.7.darwin-amd64.tar.gz -sudo tar -C /usr/local -xvf https://go.dev/dl/go1.20.3.linux-amd64.tar.gz +sudo tar -C /usr/local -xvf https://go.dev/dl/go1.21.7.darwin-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin @@ -94,10 +94,10 @@ You should see something similar to the following: ```bash name: gaia server_name: gaiad -version: v9.0.0 +version: v15.0.0 commit: 682770f2410ab0d33ac7f0c7203519d7a99fa2b6 build_tags: netgo,ledger -go: go version go1.20.3 linux/amd64 +go: go version go1.21.7 linux/amd64 ``` ### Build Tags diff --git a/docs/docs/getting-started/quickstart.mdx b/docs/docs/getting-started/quickstart.mdx index 0f0ae87dea3..2e167042e27 100644 --- a/docs/docs/getting-started/quickstart.mdx +++ b/docs/docs/getting-started/quickstart.mdx @@ -24,7 +24,7 @@ For reference, the list of `rpc_servers` and `persistent` peers can be found in ```bash # Build gaiad binary and initialize chain cd $HOME -git clone -b v14.1.0 https://github.com/cosmos/gaia --depth=1 +git clone -b v15.0.0 https://github.com/cosmos/gaia --depth=1 cd gaiad make install gaiad init CUSTOM_MONIKER --chain-id cosmoshub-4 diff --git a/docs/docs/governance/current-parameters.js b/docs/docs/governance/current-parameters.js index 415fb92f0f0..c3758b53f8c 100644 --- a/docs/docs/governance/current-parameters.js +++ b/docs/docs/governance/current-parameters.js @@ -1,130 +1,123 @@ export const currentParams = { lastRelease: { - releaseName: 'v11', - releaseDate: '', - blockHeight: '', - governanceProposalLink: '', + releaseName: "v11", + releaseDate: "", + blockHeight: "", + governanceProposalLink: "", }, currentRelease: { - releaseName: 'v12', - releaseDate: '', - blockHeight: '', - governanceProposalLink: '', - gaidExecutionOutput : '❯ gaiad version --long\nname: gaia\nserver_name: gaiad\nversion: v12.0.0\ncommit: 6f8067d76ce30996f83645862153ccfaf5f13dd1\nbuild_tags: netgo,ledger\ngo: go version go1.20.4 darwin/arm64\nbuild_deps:\n- cosmossdk.io/api@v0.2.6\n- cosmossdk.io/core@v0.5.1\n- cosmossdk.io/depinject@v1.0.0-alpha.3\n- cosmossdk.io/errors@v1.0.0\n- filippo.io/edwards25519@v1.0.0-rc.1\n- github.com/99designs/go-keychain@v0.0.0-20191008050251-8e49817e8af4\n- github.com/99designs/keyring@v1.2.1 => github.com/cosmos/keyring@v1.2.0\n- github.com/ChainSafe/go-schnorrkel@v1.0.0\n- github.com/Workiva/go-datastructures@v1.0.53\n- github.com/armon/go-metrics@v0.4.1\n- github.com/beorn7/perks@v1.0.1\n- github.com/bgentry/speakeasy@v0.1.1-0.20220910012023-760eaf8b6816\n- github.com/btcsuite/btcd/btcec/v2@v2.3.2\n- github.com/cenkalti/backoff/v4@v4.1.3\n- github.com/cespare/xxhash/v2@v2.1.2\n- github.com/coinbase/rosetta-sdk-go@v0.7.9\n- github.com/cometbft/cometbft-db@v0.7.0\n- github.com/confio/ics23/go@v0.9.0\n- github.com/cosmos/btcutil@v1.0.4\n- github.com/cosmos/cosmos-db@v0.0.0-20221226095112-f3c38ecb5e32\n- github.com/cosmos/cosmos-proto@v1.0.0-beta.1\n- github.com/cosmos/cosmos-sdk@v0.45.16-ics => github.com/cosmos/cosmos-sdk@v0.45.16-ics-lsm\n- github.com/cosmos/go-bip39@v1.0.0\n- github.com/cosmos/iavl@v0.19.5\n- github.com/cosmos/ibc-apps/middleware/packet-forward-middleware/v4@v4.1.0\n- github.com/cosmos/ibc-go/v4@v4.4.2\n- github.com/cosmos/interchain-security/v2@v2.0.0 => github.com/cosmos/interchain-security/v2@v2.0.0-lsm\n- github.com/cosmos/ledger-cosmos-go@v0.12.2\n- github.com/creachadair/taskgroup@v0.3.2\n- github.com/davecgh/go-spew@v1.1.1\n- github.com/decred/dcrd/dcrec/secp256k1/v4@v4.0.1\n- github.com/desertbit/timer@v0.0.0-20180107155436-c41aec40b27f\n- github.com/dvsekhvalnov/jose2go@v1.5.0\n- github.com/felixge/httpsnoop@v1.0.2\n- github.com/fsnotify/fsnotify@v1.6.0\n- github.com/go-kit/kit@v0.12.0\n- github.com/go-kit/log@v0.2.1\n- github.com/go-logfmt/logfmt@v0.5.1\n- github.com/gogo/gateway@v1.1.0\n- github.com/gogo/protobuf@v1.3.3 => github.com/regen-network/protobuf@v1.3.3-alpha.regen.1\n- github.com/golang/protobuf@v1.5.3\n- github.com/golang/snappy@v0.0.4\n- github.com/google/btree@v1.1.2\n- github.com/google/orderedcode@v0.0.1\n- github.com/gorilla/handlers@v1.5.1\n- github.com/gorilla/mux@v1.8.0\n- github.com/gorilla/websocket@v1.5.0\n- github.com/gravity-devs/liquidity@v1.6.0 => github.com/gravity-devs/liquidity@v1.6.0-forced-withdrawal\n- github.com/grpc-ecosystem/go-grpc-middleware@v1.3.0\n- github.com/grpc-ecosystem/grpc-gateway@v1.16.0\n- github.com/grpc-ecosystem/grpc-gateway/v2@v2.10.2\n- github.com/gtank/merlin@v0.1.1\n- github.com/gtank/ristretto255@v0.1.2\n- github.com/hashicorp/go-immutable-radix@v1.3.1\n- github.com/hashicorp/golang-lru@v0.5.5-0.20210104140557-80c98217689d\n- github.com/hashicorp/hcl@v1.0.0\n- github.com/hdevalence/ed25519consensus@v0.0.0-20220222234857-c00d1f31bab3\n- github.com/iancoleman/orderedmap@v0.2.0\n- github.com/improbable-eng/grpc-web@v0.15.0\n- github.com/klauspost/compress@v1.15.11\n- github.com/lib/pq@v1.10.7\n- github.com/libp2p/go-buffer-pool@v0.1.0\n- github.com/magiconair/properties@v1.8.7\n- github.com/mattn/go-colorable@v0.1.13\n- github.com/mattn/go-isatty@v0.0.17\n- github.com/matttproud/golang_protobuf_extensions@v1.0.2-0.20181231171920-c182affec369\n- github.com/mimoo/StrobeGo@v0.0.0-20210601165009-122bf33a46e0\n- github.com/minio/highwayhash@v1.0.2\n- github.com/mitchellh/mapstructure@v1.5.0\n- github.com/mtibben/percent@v0.2.1\n- github.com/pelletier/go-toml/v2@v2.0.8\n- github.com/pkg/errors@v0.9.1\n- github.com/pmezard/go-difflib@v1.0.0\n- github.com/prometheus/client_golang@v1.14.0\n- github.com/prometheus/client_model@v0.3.0\n- github.com/prometheus/common@v0.37.0\n- github.com/prometheus/procfs@v0.8.0\n- github.com/rakyll/statik@v0.1.7\n- github.com/rcrowley/go-metrics@v0.0.0-20201227073835-cf1acfcdf475\n- github.com/regen-network/cosmos-proto@v0.3.1\n- github.com/rs/cors@v1.8.2\n- github.com/rs/zerolog@v1.27.0\n- github.com/spf13/afero@v1.9.5\n- github.com/spf13/cast@v1.5.1\n- github.com/spf13/cobra@v1.7.0\n- github.com/spf13/jwalterweatherman@v1.1.0\n- github.com/spf13/pflag@v1.0.5\n- github.com/spf13/viper@v1.16.0\n- github.com/stretchr/testify@v1.8.4\n- github.com/subosito/gotenv@v1.4.2\n- github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7\n- github.com/tendermint/go-amino@v0.16.0\n- github.com/tendermint/tendermint@v0.34.27 => github.com/cometbft/cometbft@v0.34.29\n- github.com/tendermint/tm-db@v0.6.7\n- github.com/tidwall/btree@v1.5.0\n- github.com/zondax/hid@v0.9.1\n- github.com/zondax/ledger-go@v0.14.1\n- golang.org/x/crypto@v0.11.0\n- golang.org/x/exp@v0.0.0-20221205204356-47842c84f3db\n- golang.org/x/net@v0.12.0\n- golang.org/x/sys@v0.10.0\n- golang.org/x/term@v0.10.0\n- golang.org/x/text@v0.11.0\n- google.golang.org/genproto@v0.0.0-20230410155749-daa745c078e1\n- google.golang.org/grpc@v1.56.2 => google.golang.org/grpc@v1.33.2\n- google.golang.org/protobuf@v1.31.0\n- gopkg.in/ini.v1@v1.67.0\n- gopkg.in/yaml.v2@v2.4.0\n- gopkg.in/yaml.v3@v3.0.1\n- nhooyr.io/websocket@v1.8.6\ncosmos_sdk_version: v0.45.16-ics', - golangVersion : '1.20.x', + releaseName: "v12", + releaseDate: "", + blockHeight: "", + governanceProposalLink: "", + gaidExecutionOutput: + "❯ gaiad version --long\nname: gaia\nserver_name: gaiad\nversion: v12.0.0\ncommit: 6f8067d76ce30996f83645862153ccfaf5f13dd1\nbuild_tags: netgo,ledger\ngo: go version go1.20.4 darwin/arm64\nbuild_deps:\n- cosmossdk.io/api@v0.2.6\n- cosmossdk.io/core@v0.5.1\n- cosmossdk.io/depinject@v1.0.0-alpha.3\n- cosmossdk.io/errors@v1.0.0\n- filippo.io/edwards25519@v1.0.0-rc.1\n- github.com/99designs/go-keychain@v0.0.0-20191008050251-8e49817e8af4\n- github.com/99designs/keyring@v1.2.1 => github.com/cosmos/keyring@v1.2.0\n- github.com/ChainSafe/go-schnorrkel@v1.0.0\n- github.com/Workiva/go-datastructures@v1.0.53\n- github.com/armon/go-metrics@v0.4.1\n- github.com/beorn7/perks@v1.0.1\n- github.com/bgentry/speakeasy@v0.1.1-0.20220910012023-760eaf8b6816\n- github.com/btcsuite/btcd/btcec/v2@v2.3.2\n- github.com/cenkalti/backoff/v4@v4.1.3\n- github.com/cespare/xxhash/v2@v2.1.2\n- github.com/coinbase/rosetta-sdk-go@v0.7.9\n- github.com/cometbft/cometbft-db@v0.7.0\n- github.com/confio/ics23/go@v0.9.0\n- github.com/cosmos/btcutil@v1.0.4\n- github.com/cosmos/cosmos-db@v0.0.0-20221226095112-f3c38ecb5e32\n- github.com/cosmos/cosmos-proto@v1.0.0-beta.1\n- github.com/cosmos/cosmos-sdk@v0.45.16-ics => github.com/cosmos/cosmos-sdk@v0.45.16-ics-lsm\n- github.com/cosmos/go-bip39@v1.0.0\n- github.com/cosmos/iavl@v0.19.5\n- github.com/cosmos/ibc-apps/middleware/packet-forward-middleware/v4@v4.1.0\n- github.com/cosmos/ibc-go/v4@v4.4.2\n- github.com/cosmos/interchain-security/v2@v2.0.0 => github.com/cosmos/interchain-security/v2@v2.0.0-lsm\n- github.com/cosmos/ledger-cosmos-go@v0.12.2\n- github.com/creachadair/taskgroup@v0.3.2\n- github.com/davecgh/go-spew@v1.1.1\n- github.com/decred/dcrd/dcrec/secp256k1/v4@v4.0.1\n- github.com/desertbit/timer@v0.0.0-20180107155436-c41aec40b27f\n- github.com/dvsekhvalnov/jose2go@v1.5.0\n- github.com/felixge/httpsnoop@v1.0.2\n- github.com/fsnotify/fsnotify@v1.6.0\n- github.com/go-kit/kit@v0.12.0\n- github.com/go-kit/log@v0.2.1\n- github.com/go-logfmt/logfmt@v0.5.1\n- github.com/gogo/gateway@v1.1.0\n- github.com/gogo/protobuf@v1.3.3 => github.com/regen-network/protobuf@v1.3.3-alpha.regen.1\n- github.com/golang/protobuf@v1.5.3\n- github.com/golang/snappy@v0.0.4\n- github.com/google/btree@v1.1.2\n- github.com/google/orderedcode@v0.0.1\n- github.com/gorilla/handlers@v1.5.1\n- github.com/gorilla/mux@v1.8.0\n- github.com/gorilla/websocket@v1.5.0\n- github.com/gravity-devs/liquidity@v1.6.0 => github.com/gravity-devs/liquidity@v1.6.0-forced-withdrawal\n- github.com/grpc-ecosystem/go-grpc-middleware@v1.3.0\n- github.com/grpc-ecosystem/grpc-gateway@v1.16.0\n- github.com/grpc-ecosystem/grpc-gateway/v2@v2.10.2\n- github.com/gtank/merlin@v0.1.1\n- github.com/gtank/ristretto255@v0.1.2\n- github.com/hashicorp/go-immutable-radix@v1.3.1\n- github.com/hashicorp/golang-lru@v0.5.5-0.20210104140557-80c98217689d\n- github.com/hashicorp/hcl@v1.0.0\n- github.com/hdevalence/ed25519consensus@v0.0.0-20220222234857-c00d1f31bab3\n- github.com/iancoleman/orderedmap@v0.2.0\n- github.com/improbable-eng/grpc-web@v0.15.0\n- github.com/klauspost/compress@v1.15.11\n- github.com/lib/pq@v1.10.7\n- github.com/libp2p/go-buffer-pool@v0.1.0\n- github.com/magiconair/properties@v1.8.7\n- github.com/mattn/go-colorable@v0.1.13\n- github.com/mattn/go-isatty@v0.0.17\n- github.com/matttproud/golang_protobuf_extensions@v1.0.2-0.20181231171920-c182affec369\n- github.com/mimoo/StrobeGo@v0.0.0-20210601165009-122bf33a46e0\n- github.com/minio/highwayhash@v1.0.2\n- github.com/mitchellh/mapstructure@v1.5.0\n- github.com/mtibben/percent@v0.2.1\n- github.com/pelletier/go-toml/v2@v2.0.8\n- github.com/pkg/errors@v0.9.1\n- github.com/pmezard/go-difflib@v1.0.0\n- github.com/prometheus/client_golang@v1.14.0\n- github.com/prometheus/client_model@v0.3.0\n- github.com/prometheus/common@v0.37.0\n- github.com/prometheus/procfs@v0.8.0\n- github.com/rakyll/statik@v0.1.7\n- github.com/rcrowley/go-metrics@v0.0.0-20201227073835-cf1acfcdf475\n- github.com/regen-network/cosmos-proto@v0.3.1\n- github.com/rs/cors@v1.8.2\n- github.com/rs/zerolog@v1.27.0\n- github.com/spf13/afero@v1.9.5\n- github.com/spf13/cast@v1.5.1\n- github.com/spf13/cobra@v1.7.0\n- github.com/spf13/jwalterweatherman@v1.1.0\n- github.com/spf13/pflag@v1.0.5\n- github.com/spf13/viper@v1.16.0\n- github.com/stretchr/testify@v1.8.4\n- github.com/subosito/gotenv@v1.4.2\n- github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7\n- github.com/tendermint/go-amino@v0.16.0\n- github.com/tendermint/tendermint@v0.34.27 => github.com/cometbft/cometbft@v0.34.29\n- github.com/tendermint/tm-db@v0.6.7\n- github.com/tidwall/btree@v1.5.0\n- github.com/zondax/hid@v0.9.1\n- github.com/zondax/ledger-go@v0.14.1\n- golang.org/x/crypto@v0.11.0\n- golang.org/x/exp@v0.0.0-20221205204356-47842c84f3db\n- golang.org/x/net@v0.12.0\n- golang.org/x/sys@v0.10.0\n- golang.org/x/term@v0.10.0\n- golang.org/x/text@v0.11.0\n- google.golang.org/genproto@v0.0.0-20230410155749-daa745c078e1\n- google.golang.org/grpc@v1.56.2 => google.golang.org/grpc@v1.33.2\n- google.golang.org/protobuf@v1.31.0\n- gopkg.in/ini.v1@v1.67.0\n- gopkg.in/yaml.v2@v2.4.0\n- gopkg.in/yaml.v3@v3.0.1\n- nhooyr.io/websocket@v1.8.6\ncosmos_sdk_version: v0.45.16-ics", + golangVersion: "1.20.x", }, nextRelease: { - releaseName: 'v12', - releaseDate: '', - blockHeight: '', - governanceProposalLink: '', + releaseName: "v12", + releaseDate: "", + blockHeight: "", + governanceProposalLink: "", }, - proposals : { - numberOfValidatorsProp: 'https://www.mintscan.io/cosmos/proposals/797', + proposals: { + numberOfValidatorsProp: "https://www.mintscan.io/cosmos/proposals/797", }, auth: { - MaxMemoCharacters: '512', - SigVerifyCostED25519: '590', - SigVerifyCostSecp256k1: '1000', - TxSigLimit: '7', - TxSizeCostPerByte: '10', - }, - bank: { - DefaultSendEnabled: true, - SendEnabled: [], + max_memo_characters: "512", + tx_sig_limit: "7", + sig_verify_cost_ed25519: "590", + tx_size_cost_per_byte: "10", + sig_verify_cost_secp256k1: "1000", }, baseapp: { BlockParams: { - max_bytes: '200000', - max_gas: '40000000', + max_bytes: "200000", + max_gas: "40000000", }, EvidenceParams: { - max_age_duration: '172800000000000', - max_age_num_blocks: '1000000', - max_bytes: '50000', + max_age_duration: "172800000000000", + max_age_num_blocks: "1000000", + max_bytes: "50000", }, ValidatorParams: { - pub_key_types: ['ed25519'], + pub_key_types: ["ed25519"], }, }, crisis: { ConstantFee: { - amount: '1333000000', - denom: 'uatom', + amount: "1333000000", + denom: "uatom", }, }, distribution: { - baseproposerreward: '0.010000000000000000', - bonusproposerreward: '0.040000000000000000', - communitytax: '0.020000000000000000', - withdrawaddrenabled: true, + base_proposer_reward: "0.010000000000000000", + bonus_proposer_reward: "0.040000000000000000", + community_tax: "0.020000000000000000", + withdraw_addr_enabled: true, }, gov: { - depositparams: { - max_deposit_period: '1209600000000000', + deposit_params: { + max_deposit_period: "1209600000000000", min_deposit: [ { - amount: '250000000', - denom: 'uatom', + amount: "250000000", + denom: "uatom", }, ], }, - tallyparams: { - quorum: '0.400000000000000000', - threshold: '0.500000000000000000', - veto_threshold: '0.334000000000000000', + tally_params: { + quorum: "0.400000000000000000", + threshold: "0.500000000000000000", + veto_threshold: "0.334000000000000000", }, - votingparams: { - voting_period: '1209600000000000', + voting_params: { + voting_period: "1209600000000000", + }, + params: { + min_deposit: [ + { + denom: "stake", + amount: "10000000", + }, + ], + max_deposit_period: "172800s", + voting_period: "60s", + quorum: "0.334000000000000000", + threshold: "0.500000000000000000", + veto_threshold: "0.334000000000000000", + min_initial_deposit_ratio: "0.000000000000000000", + burn_vote_quorum: false, + burn_proposal_deposit_prevote: false, + burn_vote_veto: true, + min_deposit_ratio: "0.010000000000000000", }, - }, - liquidity: { - CircuitBreakerEnabled: false, - InitPoolCoinMintAmount: '1000000', - MaxOrderAmountRatio: '0.100000000000000000', - MaxReserveCoinAmount: '0', - MinInitDepositAmount: '1000000', - PoolCreationFee: [ - { - amount: '40000000', - denom: 'uatom', - }, - ], - PoolTypes: [ - { - description: - 'Standard liquidity pool with pool price function X/Y, ESPM constraint, and two kinds of reserve coins', - id: 1, - max_reserve_coin_num: 2, - min_reserve_coin_num: 2, - name: 'StandardLiquidityPool', - }, - ], - SwapFeeRate: '0.003000000000000000', - UnitBatchHeight: 1, - WithdrawFeeRate: '0.000000000000000000', }, mint: { - BlocksPerYear: '4360000', - GoalBonded: '0.670000000000000000', - InflationMax: '0.200000000000000000', - InflationMin: '0.070000000000000000', - InflationRateChange: '1.000000000000000000', - MintDenom: 'uatom', + blocks_per_year: "4360000", + goal_bonded: "0.670000000000000000", + inflation_max: "0.200000000000000000", + inflation_min: "0.070000000000000000", + inflation_rate_change: "1.000000000000000000", + mint_denom: "uatom", }, slashing: { - DowntimeJailDuration: '600000000000', - MinSignedPerWindow: '0.050000000000000000', - SignedBlocksWindow: '10000', - SlashFractionDoubleSign: '0.050000000000000000', - SlashFractionDowntime: '0.000100000000000000', + downtime_jail_duration: "600000000000", + min_signed_per_window: "0.050000000000000000", + signed_blocks_window: "10000", + slash_fraction_double_sign: "0.050000000000000000", + slash_fraction_downtime: "0.000100000000000000", }, staking: { - BondDenom: 'uatom', - HistoricalEntries: 10000, - MaxEntries: 7, - MaxValidators: 180, - UnbondingTime: '1814400000000000', + unbonding_time: "86400s", + max_validators: 100, + max_entries: 7, + historical_entries: 10000, + bond_denom: "stake", + min_commission_rate: "0.000000000000000000", + validator_bond_factor: "-1.000000000000000000", + global_liquid_staking_cap: "1.000000000000000000", + validator_liquid_staking_cap: "1.000000000000000000", }, transfer: { ReceiveEnabled: true, diff --git a/docs/docs/governance/formatting.md b/docs/docs/governance/formatting.md index f3198733ec0..4ec6952d8b0 100644 --- a/docs/docs/governance/formatting.md +++ b/docs/docs/governance/formatting.md @@ -17,21 +17,27 @@ The examples shown below are of the text in a `json` file packaged into a `submi Text proposals are used by delegators to agree to a certain strategy, plan, commitment, future upgrade, or any other statement in the form of text. Aside from having a record of the proposal outcome on the Cosmos Hub chain, a text proposal has no direct effect on the change Cosmos Hub. -There are three components: +There are four components: 1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals -2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal +2. **Summary** - the body of the proposal that further describes what is being proposed and details surrounding the proposal 3. **Deposit** - the amount that will be contributed to the deposit (in micro-ATOMs "uatom") from the account submitting the proposal +4. **Metadata** - usually a link to an off-chain resource ### Real example [Proposal 12](https://www.mintscan.io/cosmos/proposals/12) asked if the Cosmos Hub community of validators charging 0% commission was harmful to the success of the Cosmos Hub. +You can use `gaiad tx gov draft-proposal` and choose `text` to create the proposal file. + +You must submit the proposal using `gaiad tx gov submit-proposal `. + ```json { "title": "Are Validators Charging 0% Commission Harmful to the Success of the Cosmos Hub?", - "description": "This governance proposal is intended to act purely as a signalling proposal. Throughout this history of the Cosmos Hub, there has been much debate about the impact that validators charging 0% commission has on the Cosmos Hub, particularly with respect to the decentralization of the Cosmos Hub and the sustainability for validator operations. Discussion around this topic has taken place in many places including numerous threads on the Cosmos Forum, public Telegram channels, and in-person meetups. Because this has been one of the primary discussion points in off-chain Cosmos governance discussions, we believe it is important to get a signal on the matter from the on-chain governance process of the Cosmos Hub. There have been past discussions on the Cosmos Forum about placing an in-protocol restriction on validators from charging 0% commission. https://forum.cosmos.network/t/governance-limit-validators-from-0-commission-fee/2182 This proposal is NOT proposing a protocol-enforced minimum. It is merely a signalling proposal to query the viewpoint of the bonded Atom holders as a whole. We encourage people to discuss the question behind this governance proposal in the associated Cosmos Hub forum post here: https://forum.cosmos.network/t/proposal-are-validators-charging-0-commission-harmful-to-the-success-of-the-cosmos-hub/2505 Also, for voters who believe that 0% commission rates are harmful to the network, we encourage optionally sharing your belief on what a healthy minimum commission rate for the network using the memo field of their vote transaction on this governance proposal or linking to a longer written explanation such as a Forum or blog post. The question on this proposal is “Are validators charging 0% commission harmful to the success of the Cosmos Hub?”. A Yes vote is stating that they ARE harmful to the network's success, and a No vote is a statement that they are NOT harmful.", - "deposit": "100000uatom" + "summary": "This governance proposal is intended to act purely as a signalling proposal. Throughout this history of the Cosmos Hub, there has been much debate about the impact that validators charging 0% commission has on the Cosmos Hub, particularly with respect to the decentralization of the Cosmos Hub and the sustainability for validator operations. Discussion around this topic has taken place in many places including numerous threads on the Cosmos Forum, public Telegram channels, and in-person meetups. Because this has been one of the primary discussion points in off-chain Cosmos governance discussions, we believe it is important to get a signal on the matter from the on-chain governance process of the Cosmos Hub. There have been past discussions on the Cosmos Forum about placing an in-protocol restriction on validators from charging 0% commission. https://forum.cosmos.network/t/governance-limit-validators-from-0-commission-fee/2182 This proposal is NOT proposing a protocol-enforced minimum. It is merely a signalling proposal to query the viewpoint of the bonded Atom holders as a whole. We encourage people to discuss the question behind this governance proposal in the associated Cosmos Hub forum post here: https://forum.cosmos.network/t/proposal-are-validators-charging-0-commission-harmful-to-the-success-of-the-cosmos-hub/2505 Also, for voters who believe that 0% commission rates are harmful to the network, we encourage optionally sharing your belief on what a healthy minimum commission rate for the network using the memo field of their vote transaction on this governance proposal or linking to a longer written explanation such as a Forum or blog post. The question on this proposal is “Are validators charging 0% commission harmful to the success of the Cosmos Hub?”. A Yes vote is stating that they ARE harmful to the network's success, and a No vote is a statement that they are NOT harmful.", + "deposit": "100000uatom", + "metadata": "ipfs://CID", } ``` @@ -41,7 +47,7 @@ There are three components: There are five (5) components: 1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals -2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal +2. **Sumamary** - the body of the proposal that further describes what is being proposed and details surrounding the proposal 3. **Recipient** - the Cosmos Hub (bech32-based) address that will receive funding from the Community Pool 4. **Amount** - the amount of funding that the recipient will receive in micro-ATOMs (uatom) 5. **Deposit** - the amount that will be contributed to the deposit (in micro-ATOMs "uatom") from the account submitting the proposal @@ -51,24 +57,45 @@ If the description says that a certain address will receive a certain number of ### Real example The `amount` is `1000000000uatom`. 1,000,000 micro-ATOM is equal to 1 ATOM, so `recipient` address `cosmos1xf2qwf6g6xvuttpf37xwrgp08qq984244952ze` will receive 1000 ATOM if this proposal is passed. -The `deposit": "1000000uatom` results in 1 ATOM being used from the proposal submitter's account. +The `deposit": "1000000uatom` results in 1 ATOM being used from the proposal submitter's account. + +You can use the `gaiad tx gov draft-proposal` utility and choose `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` to create a draft proposal file. + +You must use `gaiad tx gov submit-proposal ` to submit the proposal. The proposal cannot be submitted using `submit-legacy-proposal`. ```json { + "messages":[ + { + "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", + "authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn", + "recipient": "cosmos00af8sd0a9dfansdfoiasf0a9ssd9fa09i99990", + "amount": [{ + "denom": "uatom", + "amount": "10000000000" + }] + } + ], + "deposit": "100000uatom", + "proposer": "cosmos12xpdapokdfpsodf32das75sokdaadapsokd1sa", + "metadata": "Community Pool Spend Proposal Example", "title": "Activate governance discussions on the Discourse forum using community pool funds", - "description": "## Summary\nProposal to request for 1000 ATOM from the community spending pool to be sent to a multisig who will put funds towards stewardship of the Discourse forum to make it an authoritative record of governance decisions as well as a vibrant space to draft and discuss proposals.\n## Details\nWe are requesting 1000 ATOM from the community spending pool to activate and steward the Cosmos Hub (Discourse) forum for the next six months.\n\nOff-chain governance conversations are currently highly fragmented, with no shared public venue for discussing proposals as they proceed through the process of being drafted and voted on. It means there is no record of discussion that voters can confidently point to for context, potentially leading to governance decisions becoming delegitimized by stakeholders.\n\nThe requested amount will be sent to a multisig comprising individuals (members listed below) who can ensure that the tokens are spent judiciously. We believe stewardship of the forum requires:\n\n* **Moderation**: Format, edit, and categorize posts; Standardize titles and tags; Monitor and approve new posts; Archive posts.\n* **Facilitation**: Ask clarifying questions in post threads; Summarize discussions; Provide historical precedence to discussions.\n* **Engagement**: Circulate important posts on other social channels to increase community participation; Solicit input from key stakeholders.\n* **Guidance**: Orient and assist newcomers; Guide proposers through governance process; Answer questions regarding the forum or Cosmos ecosystem.\nThe work to steward the forum will be carried out by members of [Hypha Worker Co-op](https://hypha.coop/) and individuals selected from the community to carry out scoped tasks in exchange for ATOM from this budget.\n## Multisig Members\n* Hypha: Mai Ishikawa Sutton (Hypha Co-op)\n* Validator: Daniel Hwang (Stakefish)\n* Cosmos Hub developer: Lauren Gallinaro (Interchain Berlin)\n\nWe feel the membership of the multisig should be rotated following the six-month pilot period to preserve insight from the distinct specializations (i.e., Cosmos Hub validators and developers).\n## Timeline and Deliverables\nWe estimate the total work to take 250-300 hours over six months where we hope to produce:\n* **Moving summaries:** Provide succinct summaries of the proposals and include all publicly stated reasons why various entities are choosing to vote for/against a given proposal. These summaries will be written objectively, not siding with any one entity.\n* **Validator platforms:** Create a section of the Forum where we collate all validators' visions for Cosmos Hub governance to allow them to state their positions publicly. We will work with the smaller validators to ensure they are equally represented.\n* **Regular check-ins with the Cosmonaut DAO:** Collaborate with the future Cosmonaut DAO to ensure maximal accessibility and engagement. Community management is a critical, complementary aspect of increasing participation in governance.\n* **Announcement channel:** Create a read-only announcement channel in the Cosmos Community Discord, so that new proposals and major discussions can be easily followed.\n* **Tooling friendly posts:** Tag and categorize posts so that they can be easily ingested into existing tooling that validators have setup.\n* **Neutral moderation framework:** Document and follow transparent standards for how the forum is moderated.\n\nAt the end of the period, we will produce a report reflecting on our successes and failures, and recommendations for how the work of maintaining a governance venue can be continuously sustained (e.g., through a DAO). We see this initiative as a process of discovery, where we are learning by doing.\n\nFor more context, you can read through the discussions on this [proposal on the Discourse forum](https://forum.cosmos.network/t/proposal-draft-activate-governance-discussions-on-the-discourse-forum-using-community-pool-funds/5833).\n\n## Governance Votes\nThe following items summarize the voting options and what it means for this proposal:\n**YES** - You approve this community spend proposal to deposit 1000 ATOM to a multisig that will spend them to improve governance discussions in the Discourse forum.\n**NO** - You disapprove of this community spend proposal in its current form (please indicate why in the Cosmos Forum).\n**NO WITH VETO** - You are strongly opposed to this change and will exit the network if passed.\n**ABSTAIN** - You are impartial to the outcome of the proposal.\n## Recipient\ncosmos1xf2qwf6g6xvuttpf37xwrgp08qq984244952ze\n## Amount\n1000 ATOM\n\n***Disclosure**: Hypha has an existing contract with the Interchain Foundation focused on the testnet program and improving documentation. This work is beyond the scope of that contract and is focused on engaging the community in governance.*\n\nIPFS pin of proposal on-forum: (https://ipfs.io/ipfs/Qmaq7ftqWccgYCo8U1KZfEnjvjUDzSEGpMxcRy61u8gf2Y)", - "recipient": "cosmos1xf2qwf6g6xvuttpf37xwrgp08qq984244952ze", - "amount": "1000000000uatom", - "deposit": "1000000uatom" + "summary": "## Summary\nProposal to request for 1000 ATOM from the community spending pool to be sent to a multisig who will put funds towards stewardship of the Discourse forum to make it an authoritative record of governance decisions as well as a vibrant space to draft and discuss proposals.\n## Details\nWe are requesting 1000 ATOM from the community spending pool to activate and steward the Cosmos Hub (Discourse) forum for the next six months.\n\nOff-chain governance conversations are currently highly fragmented, with no shared public venue for discussing proposals as they proceed through the process of being drafted and voted on. It means there is no record of discussion that voters can confidently point to for context, potentially leading to governance decisions becoming delegitimized by stakeholders.\n\nThe requested amount will be sent to a multisig comprising individuals (members listed below) who can ensure that the tokens are spent judiciously. We believe stewardship of the forum requires:\n\n* **Moderation**: Format, edit, and categorize posts; Standardize titles and tags; Monitor and approve new posts; Archive posts.\n* **Facilitation**: Ask clarifying questions in post threads; Summarize discussions; Provide historical precedence to discussions.\n* **Engagement**: Circulate important posts on other social channels to increase community participation; Solicit input from key stakeholders.\n* **Guidance**: Orient and assist newcomers; Guide proposers through governance process; Answer questions regarding the forum or Cosmos ecosystem.\nThe work to steward the forum will be carried out by members of [Hypha Worker Co-op](https://hypha.coop/) and individuals selected from the community to carry out scoped tasks in exchange for ATOM from this budget.\n## Multisig Members\n* Hypha: Mai Ishikawa Sutton (Hypha Co-op)\n* Validator: Daniel Hwang (Stakefish)\n* Cosmos Hub developer: Lauren Gallinaro (Interchain Berlin)\n\nWe feel the membership of the multisig should be rotated following the six-month pilot period to preserve insight from the distinct specializations (i.e., Cosmos Hub validators and developers).\n## Timeline and Deliverables\nWe estimate the total work to take 250-300 hours over six months where we hope to produce:\n* **Moving summaries:** Provide succinct summaries of the proposals and include all publicly stated reasons why various entities are choosing to vote for/against a given proposal. These summaries will be written objectively, not siding with any one entity.\n* **Validator platforms:** Create a section of the Forum where we collate all validators' visions for Cosmos Hub governance to allow them to state their positions publicly. We will work with the smaller validators to ensure they are equally represented.\n* **Regular check-ins with the Cosmonaut DAO:** Collaborate with the future Cosmonaut DAO to ensure maximal accessibility and engagement. Community management is a critical, complementary aspect of increasing participation in governance.\n* **Announcement channel:** Create a read-only announcement channel in the Cosmos Community Discord, so that new proposals and major discussions can be easily followed.\n* **Tooling friendly posts:** Tag and categorize posts so that they can be easily ingested into existing tooling that validators have setup.\n* **Neutral moderation framework:** Document and follow transparent standards for how the forum is moderated.\n\nAt the end of the period, we will produce a report reflecting on our successes and failures, and recommendations for how the work of maintaining a governance venue can be continuously sustained (e.g., through a DAO). We see this initiative as a process of discovery, where we are learning by doing.\n\nFor more context, you can read through the discussions on this [proposal on the Discourse forum](https://forum.cosmos.network/t/proposal-draft-activate-governance-discussions-on-the-discourse-forum-using-community-pool-funds/5833).\n\n## Governance Votes\nThe following items summarize the voting options and what it means for this proposal:\n**YES** - You approve this community spend proposal to deposit 1000 ATOM to a multisig that will spend them to improve governance discussions in the Discourse forum.\n**NO** - You disapprove of this community spend proposal in its current form (please indicate why in the Cosmos Forum).\n**NO WITH VETO** - You are strongly opposed to this change and will exit the network if passed.\n**ABSTAIN** - You are impartial to the outcome of the proposal.\n## Recipient\ncosmos1xf2qwf6g6xvuttpf37xwrgp08qq984244952ze\n## Amount\n1000 ATOM\n\n***Disclosure**: Hypha has an existing contract with the Interchain Foundation focused on the testnet program and improving documentation. This work is beyond the scope of that contract and is focused on engaging the community in governance.*\n\nIPFS pin of proposal on-forum: (https://ipfs.io/ipfs/Qmaq7ftqWccgYCo8U1KZfEnjvjUDzSEGpMxcRy61u8gf2Y)", } - ``` -## Param Change +## Legacy Param Change +:::tip +Legacy parameter change proposals are not available for cosmos-sdk modules. -**Note:** Changes to the [`gov` module](https://docs.cosmos.network/main/modules/gov) are different from the other kinds of parameter changes because `gov` has subkeys, [as discussed here](https://github.com/cosmos/cosmos-sdk/issues/5800). Only the `key` part of the JSON file is different for `gov` parameter-change proposals. +You can update these CosmosHub modules using `submit-legacy-proposal`: +* ibc (transfer, interchain-accounts) +* provider +::: -For parameter-change proposals, there are arguably seven (7) components, though three are nested beneath 'Changes': +**Note:** The chages outlined here must be submitted using `submit-legacy-proposal`. + +For `param-change` proposals, there are arguably seven (7) components, though three are nested beneath 'Changes': 1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals 2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal @@ -80,6 +107,13 @@ For parameter-change proposals, there are arguably seven (7) components, though The components must be presented as shown in the example. +:::info +To update any of the cosmos-sdk modules you must use `gaiad tx gov submit-proposal` with a correctly formatted proposal file containing a `MsgUpdateParams`. + +When using `MsgUpdateParams` please note that **all** fields must always be specified (`PUT` semantics). Please be careful to not accidentally submit a proposal +that changes more parameters than was intended. The parameters that you do not want to change you can simply copy from existing module params. +::: + ### Real example This example is 'real', because it was put on-chain using the Theta testnet and can be seen in the block explorer [here](https://explorer.theta-testnet.polypore.xyz/proposals/87). @@ -88,13 +122,13 @@ Not all explorers will show the proposed parameter changes that are coded into t ```json { - "title": "Doc update test: Param change for MaxValidators", - "description": "Testing the proposal format for increasing the MaxValidator param", + "title": "Doc update test: Param change for transfer/SendEnabled", + "description": "Testing the proposal format for enabling IBC transfers on our chain", "changes": [ { - "subspace": "staking", - "key": "MaxValidators", - "value": 200 + "subspace": "transfer", + "key": "transfer", + "value": true } ], "deposit": "100000uatom" diff --git a/docs/docs/governance/proposal-types/community-pool-spend/proposal.json b/docs/docs/governance/proposal-types/community-pool-spend/proposal.json index 0e8a8e22c4a..3e217b18e20 100644 --- a/docs/docs/governance/proposal-types/community-pool-spend/proposal.json +++ b/docs/docs/governance/proposal-types/community-pool-spend/proposal.json @@ -1,17 +1,18 @@ { - "title": "Cosmos Governance Working Group - Q1 2020", - "description": "Cosmos Governance Working Group - Q1 2020 funding\n\nCommunity-spend proposal submitted by Gavin Birch (https://twitter.com/Ether_Gavin) of Figment Networks (https://figment.io)\n\n-=-=-\n\nFull proposal: https://ipfs.io/ipfs/QmSMGEoY2dfxADPfgoAsJxjjC6hwpSNx1dXAqePiCEMCbY\n\n-=-=-\n\nAmount to spend from the community pool: 5250 ATOMs\n\nTimeline: Q1 2020\n\nDeliverables:\n1. A governance working group community & charter\n2. A template for community spend proposals\n3. A best-practices document for community spend proposals\n4. An educational wiki for the Cosmos Hub parameters\n5. A best-practices document for parameter changes\n6. Monthly governance working group community calls (three)\n7. Monthly GWG articles (three)\n8. One Q2 2020 GWG recommendations article\n\nMilestones:\nBy end of Month 1, the Cosmos Governance Working Group (GWG) should have been initiated and led by Gavin Birch of Figment Networks.\nBy end of Month 2, Gavin Birch is to have initiated and led GWG’s education, best practices, and Q2 recommendations.\nBy end of Month 3, Gavin Birch is to have led and published initial governance education, best practices, and Q2 recommendations.\n\nDetailed milestones and funding:\nhttps://docs.google.com/spreadsheets/d/1mFEvMSLbiHoVAYqBq8lo3qQw3KtPMEqDFz47ESf6HEg/edit?usp=sharing\n\nBeyond the milestones, Gavin will lead the GWG to engage in and answer governance-related questions on the Cosmos Discourse forum, Twitter, the private Cosmos VIP Telegram channel, and the Cosmos subreddit. The GWG will engage with stake-holders to lower the barriers to governance participation with the aim of empowering the Cosmos Hub’s stakeholders. The GWG will use this engagement to guide recommendations for future GWG planning.\n\nRead more about the our efforts to launch the Cosmos GWG here: https://figment.io/resources/introducing-the-cosmos-governance-working-group/\n\n-=-=-\n\n_Problem_\nPerhaps the most difficult barrier to effective governance is that it demands one of our most valuable and scarce resources: our attention. Stakeholders may be disadvantaged by informational or resource-based asymmetries, while other entities may exploit these same asymmetries to capture value controlled by the Cosmos Hub’s governance mechanisms.\n\nWe’re concerned that without establishing community standards, processes, and driving decentralized delegator-based participation, the Cosmos Hub governance mechanism could be co-opted by a centralized power. As governance functionality develops, potential participants will need to understand how to assess proposals by knowing what to pay attention to.\n\n_Solution_\nWe’re forming a focused, diverse group that’s capable of assessing and synthesizing the key parts of a proposal so that the voting community can get a fair summary of what they need to know before voting.\n\nOur solution is to initiate a Cosmos governance working group that develops decentralized community governance efforts alongside the Hub’s development. We will develop and document governance features and practices, and then communicate these to the broader Cosmos community.\n\n_Future_\nAt the end of Q1, we’ll publish recommendations for the future of the Cosmos GWG, and ideally we’ll be prepared to submit a proposal based upon those recommendations for Q2 2020. We plan to continue our work in blockchain governance, regardless of whether the Hub passes our proposals.\n\n-=-=-\n\nCosmos forum: https://forum.cosmos.network/c/governance\nCosmos GWG Telegram channel: https://t.me/hubgov\nTwitter: https://twitter.com/CosmosGov", - "recipient": "cosmos1hjct6q7npsspsg3dgvzk3sdf89spmlpfg8wwf7", - "amount": [ + "messages":[ { + "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", + "authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn", + "recipient": "cosmos00af8sd0a9dfansdfoiasf0a9ssd9fa09i99990", + "amount": [{ "denom": "uatom", - "amount": "5250000000" + "amount": "10000000000" + }] } ], - "deposit": [ - { - "denom": "uatom", - "amount": "12000000" - } - ] -} + "deposit": "100000uatom", + "proposer": "cosmos12xpdapokdfpsodf32das75sokdaadapsokd1sa", + "metadata": "Community Pool Spend Proposal Example", + "title": "Grant Proposal: Community Pool Spend", + "summary": "summary" +} \ No newline at end of file diff --git a/docs/docs/governance/proposal-types/param-change.md b/docs/docs/governance/proposal-types/param-change.md index 44e76efcf0f..333b38a5779 100644 --- a/docs/docs/governance/proposal-types/param-change.md +++ b/docs/docs/governance/proposal-types/param-change.md @@ -14,13 +14,12 @@ The complete parameters of the Cosmos Hub are split up into different modules, e There are currently 8 modules active in the Cosmos Hub with parameters that may be altered via governance proposal. New modules may be introduced in the future. 1. [auth](/governance/proposal-types/params-change/Auth.mdx) - Authentication of accounts and transactions -2. [bank](/governance/proposal-types/params-change/Bank.mdx) - Token transfer functionalities -3. [gov](/governance/proposal-types/params-change/Governance.mdx) - On-chain governance proposals and voting -4. [staking](/governance/proposal-types/params-change/Staking.mdx) - Proof-of-stake layer -5. [slashing](/governance/proposal-types/params-change/Slashing.mdx) - Validator punishment mechanisms -6. [distribution](/governance/proposal-types/params-change/Distribution.mdx) - Fee distribution and staking token provision distribution -7. [crisis](/governance/proposal-types/params-change/Crisis.mdx) - Halting the blockchain under certain circumstances (ie. if an invariant is broken) -8. [mint](/governance/proposal-types/params-change/Mint.mdx) - Creation of new units of staking token +2. [gov](/governance/proposal-types/params-change/Governance.mdx) - On-chain governance proposals and voting +3. [staking](/governance/proposal-types/params-change/Staking.mdx) - Proof-of-stake layer +4. [slashing](/governance/proposal-types/params-change/Slashing.mdx) - Validator punishment mechanisms +5. [distribution](/governance/proposal-types/params-change/Distribution.mdx) - Fee distribution and staking token provision distribution +6. [crisis](/governance/proposal-types/params-change/Crisis.mdx) - Halting the blockchain under certain circumstances (ie. if an invariant is broken) +7. [mint](/governance/proposal-types/params-change/Mint.mdx) - Creation of new units of staking token ## What are the current parameter values? diff --git a/docs/docs/governance/proposal-types/params-change/Auth.mdx b/docs/docs/governance/proposal-types/params-change/Auth.mdx index b07afd08335..568d83dfdf0 100644 --- a/docs/docs/governance/proposal-types/params-change/Auth.mdx +++ b/docs/docs/governance/proposal-types/params-change/Auth.mdx @@ -1,11 +1,15 @@ --- -title: auth subspace +title: x/auth --- import { KeyValueTable } from '@site/src/js/KeyValueTable'; import { Var } from '@site/src/js/Var'; import { currentParams } from '@site/docs/governance/current-parameters.js'; +``` +gaiad q auth params +``` + The `auth` module is responsible for authenticating accounts and transactions. It has the following parameters: @@ -14,104 +18,104 @@ The `auth` module is responsible for specifying the base transaction and account ## Governance notes on parameters -### `MaxMemoCharacters` +### `max_memo_characters` **The character limit for each transaction memo.** There is an option to include a "memo," or additional information (data) to Cosmos Hub transactions, whether sending funds, delegating, voting, or other transaction types. This parameter limits the number of characters that may be included in the memo line of each transaction. -- on-chain value: +- on-chain value: - `cosmoshub-4` genesis: `512` - `cosmoshub-3` genesis: `512` -#### Decreasing the value of `MaxMemoCharacters` +#### Decreasing the value of `max_memo_characters` -Decreasing the value of `MaxMemoCharacters` will decrease the character limit for each transaction memo. This may break the functionality of applications that rely upon the data in the memo field. For example, an exchange may use a common deposit address for all of its users, and then individualize account deposits using the memo field. If the memo field suddenly decreased, the exchange may no longer automatically sort its users' transactions. +Decreasing the value of `max_memo_characters` will decrease the character limit for each transaction memo. This may break the functionality of applications that rely upon the data in the memo field. For example, an exchange may use a common deposit address for all of its users, and then individualize account deposits using the memo field. If the memo field suddenly decreased, the exchange may no longer automatically sort its users' transactions. -#### Increasing the value of `MaxMemoCharacters` +#### Increasing the value of `max_memo_characters` -Increasing the value of `MaxMemoCharacters` will increase the character limit for each transaction memo. This may enable new functionality for applications that use transaction memos. It may also enable an increase in the amount of data in each block, leading to an increased storage need for the blockchain and [state bloat](https://thecontrol.co/state-growth-a-look-at-the-problem-and-its-solutions-6de9d7634b0b). +Increasing the value of `max_memo_characters` will increase the character limit for each transaction memo. This may enable new functionality for applications that use transaction memos. It may also enable an increase in the amount of data in each block, leading to an increased storage need for the blockchain and [state bloat](https://thecontrol.co/state-growth-a-look-at-the-problem-and-its-solutions-6de9d7634b0b). -### `TxSigLimit` +### `tx_sig_limit` **The max number of signatures per transaction** Users and applications may create multisignature (aka multisig) accounts. These accounts require more than one signature to generate a transaction. This parameter limits the number of signatures in a transaction. -- on-chain value: +- on-chain value: - `cosmoshub-4` genesis: `7` - `cosmoshub-3` genesis: `7` -#### Decreasing the value of `TxSigLimit` +#### Decreasing the value of `tx_sig_limit` -Decreasing the value of `TxSigLimit` will decrease the maximum number of signatures possible. This may constrain stakeholders that want to use as many as seven signatures to authorize a transaction. It will also break the functionality of entities or applications dependent upon up to seven transactions, meaning that those transactions will no longer be able to be authorized. In this case, funds and functions controlled by a multisignature address will no longer be accessible, and funds may become stranded. +Decreasing the value of `tx_sig_limit` will decrease the maximum number of signatures possible. This may constrain stakeholders that want to use as many as seven signatures to authorize a transaction. It will also break the functionality of entities or applications dependent upon up to seven transactions, meaning that those transactions will no longer be able to be authorized. In this case, funds and functions controlled by a multisignature address will no longer be accessible, and funds may become stranded. -#### Increasing the value of `TxSigLimit` +#### Increasing the value of `tx_sig_limit` -Increasing the value of `TxSigLimit` will increase the maximum number of signatures possible. As this value increases, the network becomes more likely to be susceptible to attacks that slow block production, due to the burden of computational cost when verifying more signatures (since signature verification is costlier than other operations). +Increasing the value of `tx_sig_limit` will increase the maximum number of signatures possible. As this value increases, the network becomes more likely to be susceptible to attacks that slow block production, due to the burden of computational cost when verifying more signatures (since signature verification is costlier than other operations). -### `TxSizeCostPerByte` +### `tx_size_cost_per_byte` **Sets the cost of transactions, in units of gas.** -`TxSizeCostPerByte` is used to compute the gas-unit consumption for each transaction. +`tx_size_cost_per_byte` is used to compute the gas-unit consumption for each transaction. -- on-chain value: +- on-chain value: - `cosmoshub-4` genesis: `10` - `cosmoshub-3` genesis: `10` -#### Decreasing the value of `TxSizeCostPerByte` +#### Decreasing the value of `tx_size_cost_per_byte` -Decreasing the value of `TxSizeCostPerByte` will reduce the number of gas units used per transaction. This may also reduce the fees that validators earn for processing transactions. There may be other effects that have not been detailed here. +Decreasing the value of `tx_size_cost_per_byte` will reduce the number of gas units used per transaction. This may also reduce the fees that validators earn for processing transactions. There may be other effects that have not been detailed here. -#### Increasing the value of `TxSizeCostPerByte` +#### Increasing the value of `tx_size_cost_per_byte` -Increasing the value of `TxSizeCostPerByte` will raise the number of gas units used per transaction. This may also increase the fees that validators earn for processing transactions. There may be other effects that have not been detailed here. +Increasing the value of `tx_size_cost_per_byte` will raise the number of gas units used per transaction. This may also increase the fees that validators earn for processing transactions. There may be other effects that have not been detailed here. -### `SigVerifyCostED25519` +### `sig_verify_cost_ed25519` **The cost for verifying ED25519 signatures, in units of gas.** -Ed25519 is the EdDSA cryptographic signature scheme (using SHA-512 (SHA-2) and Curve25519) that is used by Cosmos Hub validators. `SigVerifyCostED25519` is the gas (ie. computational) cost for verifying ED25519 signatures, and ED25519-based transactions are not currently accepted by the Cosmos Hub. +Ed25519 is the EdDSA cryptographic signature scheme (using SHA-512 (SHA-2) and Curve25519) that is used by Cosmos Hub validators. `sig_verify_cost_ed25519` is the gas (ie. computational) cost for verifying ED25519 signatures, and ED25519-based transactions are not currently accepted by the Cosmos Hub. -- on-chain value: +- on-chain value: - `cosmoshub-4` genesis: `590` - `cosmoshub-3` genesis: `590` -#### Decreasing the value of `SigVerifyCostED25519` +#### Decreasing the value of `sig_verify_cost_ed25519` -Decreasing the value of `SigVerifyCostED25519` will decrease the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519-signed transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time. +Decreasing the value of `sig_verify_cost_ed25519` will decrease the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519-signed transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time. -#### Increasing the value of `SigVerifyCostED25519` +#### Increasing the value of `sig_verify_cost_ed25519` -Increasing the value of `SigVerifyCostED25519` will increase the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519 signature transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time. +Increasing the value of `sig_verify_cost_ed25519` will increase the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519 signature transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time. #### Notes Ed25519 signatures are not currently being accepted by the Cosmos Hub. Ed25519 signatures will be verified and can be considered valid, so the gas to verify them will be consumed. However, the transaction itself will be rejected. It could be that these signatures will be used for transactions a later time, such as after inter-blockchain communication (IBC) evidence upgrades happen. -### `SigVerifyCostSecp256k1` +### `sig_verify_cost_secp256k1` **The cost for verifying Secp256k1 signatures, in units of gas.** -Secp256k1 is an elliptic curve domain parameter for cryptographic signatures used by user accounts in the Cosmos Hub. `SigVerifyCostSecp256k1` is the gas (ie. computational) cost for verifying Secp256k1 signatures. Practically all Cosmos Hub transactions require Secp256k1 signature verifications. +Secp256k1 is an elliptic curve domain parameter for cryptographic signatures used by user accounts in the Cosmos Hub. `sig_verify_cost_secp256k1` is the gas (ie. computational) cost for verifying Secp256k1 signatures. Practically all Cosmos Hub transactions require Secp256k1 signature verifications. -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `1000` - `cosmoshub-3` default: `1000` -#### Decreasing the value of `SigVerifyCostSecp256k1` +#### Decreasing the value of `sig_verify_cost_secp256k1` -Decreasing the value of `SigVerifyCostSecp256k1` will decrease the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Decreasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be greater than what the system's assumption is. +Decreasing the value of `sig_verify_cost_secp256k1` will decrease the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Decreasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be greater than what the system's assumption is. -#### Increasing the value of `SigVerifyCostSecp256k1` +#### Increasing the value of `sig_verify_cost_secp256k1` -Increasing the value of `SigVerifyCostSecp256k1` will increase the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Increasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be less than what the system's assumption is. +Increasing the value of `sig_verify_cost_secp256k1` will increase the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Increasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be less than what the system's assumption is. #### Notes -There should be a better understanding of what the potential implications are for changing `SigVerifyCostSecp256k1`. For example, gas calculations are important because blocks have a gas limit. Transactions could be rejected for exceeding the block gas limit, breaking application functionality or perhaps preventing addresses controlled by multiple signatures from moving funds. +There should be a better understanding of what the potential implications are for changing `sig_verify_cost_secp256k1`. For example, gas calculations are important because blocks have a gas limit. Transactions could be rejected for exceeding the block gas limit, breaking application functionality or perhaps preventing addresses controlled by multiple signatures from moving funds. diff --git a/docs/docs/governance/proposal-types/params-change/Bank.mdx b/docs/docs/governance/proposal-types/params-change/Bank.mdx deleted file mode 100644 index 0207dbf8cb4..00000000000 --- a/docs/docs/governance/proposal-types/params-change/Bank.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: bank subspace ---- - -import { KeyValueTable } from '@site/src/js/KeyValueTable'; -import { Var } from '@site/src/js/Var'; -import { currentParams } from '@site/docs/governance/current-parameters.js'; - -The `bank` module is responsible for token transfer functionalities. It has the following parameters: - - - -## Governance notes on parameters - -### `SendEnabled` - -**Token transfer functionality.** - -The Cosmos Hub (cosmoshub-1) launched without transfer functionality enabled. Users were able to stake and earn rewards, but were unable to transfer ATOMs between accounts until the cosmoshub-2 chain launched. Transfer functionality may be disabled and enabled via governance proposal. - -- on-chain value: `SendEnabled`: -- on-chain value: `DefaultSendEnabled`: -- `cosmoshub-4` added `DefaultSendEnabled`: `true` -- `cosmoshub-3` default: `true` - -#### Enabling `sendenabled` - -Setting the `sendenabled` parameter to `true` will enable ATOMs to be transferred between accounts. This capability was first enabled when the cosmoshub-2 chain launched. - -#### Disabling `sendenabled` - -Setting the `sendenabled` parameter to `false` will prevent ATOMs from being transferred between accounts. ATOMs may still be staked and earn rewards. This is how the cosmoshub-1 chain launched. - -#### Notes - -The cosmoshub-1 chain launched with `sendenabled` set to `false` and with [`withdrawaddrenabled`](./Distribution.mdx#4-withdrawaddrenabled) set to `false`. Staking was enabled on cosmoshub-1, so setting `withdrawaddrenabled` to false was necessary to prevent a loophole that would enable ATOM transfer via diverting staking rewards to a designated address. diff --git a/docs/docs/governance/proposal-types/params-change/Crisis.mdx b/docs/docs/governance/proposal-types/params-change/Crisis.mdx index 7a8348cb713..3aa1416acfa 100644 --- a/docs/docs/governance/proposal-types/params-change/Crisis.mdx +++ b/docs/docs/governance/proposal-types/params-change/Crisis.mdx @@ -1,5 +1,5 @@ --- -title: crisis subspace +title: x/crisis subspace --- import { KeyValueTable } from '@site/src/js/KeyValueTable'; diff --git a/docs/docs/governance/proposal-types/params-change/Distribution.mdx b/docs/docs/governance/proposal-types/params-change/Distribution.mdx index 563495e291e..53d92d666f6 100644 --- a/docs/docs/governance/proposal-types/params-change/Distribution.mdx +++ b/docs/docs/governance/proposal-types/params-change/Distribution.mdx @@ -1,7 +1,11 @@ --- -title: distribution subspace +title: x/distribution --- +```shell +gaiad q distribution params +``` + import { KeyValueTable } from '@site/src/js/KeyValueTable'; import { Var } from '@site/src/js/Var'; import { currentParams } from '@site/docs/governance/current-parameters.js'; @@ -16,67 +20,67 @@ The `distribution` module enables a simple distribution mechanism that passively ## Governance notes on parameters -### `communitytax` +### `community_tax` **The proportion of staking rewards diverted to the community pool.** -Staking on the Cosmos Hub entitles participants to inflationary (aka "block") rewards and transaction fees. A portion of these staking rewards is diverted to the community pool, which can be spent with a successful community-spend governance proposal. `communitytax` is the parameter that determines the proportion of staking rewards diverted to the community pool, which is currently `0.020000000000000000` (2%) of all staking rewards. +Staking on the Cosmos Hub entitles participants to inflationary (aka "block") rewards and transaction fees. A portion of these staking rewards is diverted to the community pool, which can be spent with a successful community-spend governance proposal. `community_tax` is the parameter that determines the proportion of staking rewards diverted to the community pool, which is currently `0.020000000000000000` (2%) of all staking rewards. -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.020000000000000000` - `cosmoshub-3` default: `0.020000000000000000` -#### Decreasing the value of `communitytax` +#### Decreasing the value of `community_tax` -Decreasing the value of the `communitytax` parameter will decrease the rate that the community pool is funded and will increase the staking rewards captured by staking participants. This will make it more likely for the community pool to be exhausted and could potentially increase the motivation for participants to stake. +Decreasing the value of the `community_tax` parameter will decrease the rate that the community pool is funded and will increase the staking rewards captured by staking participants. This will make it more likely for the community pool to be exhausted and could potentially increase the motivation for participants to stake. -#### Increasing the value of `communitytax` +#### Increasing the value of `community_tax` -Increasing the value of the `communitytax` parameter will increase the rate that the community pool is funded and will decrease the staking rewards captured by staking participants. This will make it more less for the community pool to be exhausted and could potentially decrease the motivation for participants to stake. +Increasing the value of the `community_tax` parameter will increase the rate that the community pool is funded and will decrease the staking rewards captured by staking participants. This will make it more less for the community pool to be exhausted and could potentially decrease the motivation for participants to stake. -### `baseproposerreward` +### `base_proposer_reward` **The fixed base reward bonus for the validator proposing a block, as a proportion of transaction fees.** -All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block: that validator receives a bonus of `0.010000000000000000` (1%) more in transaction fees. The proposer must include a minimum of 2/3 of precommit signatures from the other validators in the active set in order for the block to be valid and to receive the `baseproposerreward` bonus. All in Bits has published more in-depth information [here](https://hub.cosmos.network/main/validators/validator-faq.html#how-are-fees-distributed). +All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block: that validator receives a bonus of `0.010000000000000000` (1%) more in transaction fees. The proposer must include a minimum of 2/3 of precommit signatures from the other validators in the active set in order for the block to be valid and to receive the `base_proposer_reward` bonus. All in Bits has published more in-depth information [here](https://hub.cosmos.network/main/validators/validator-faq.html#how-are-fees-distributed). -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.010000000000000000` - `cosmoshub-3` default: `0.010000000000000000` -#### Decreasing the value of `baseproposerreward` +#### Decreasing the value of `base_proposer_reward` -Decreasing the value of the `baseproposerreward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block. +Decreasing the value of the `base_proposer_reward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block. -#### Increasing the value of `baseproposerreward` +#### Increasing the value of `base_proposer_reward` -Increasing the value of the `baseproposerreward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block. +Increasing the value of the `base_proposer_reward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block. #### Notes -The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `baseproposerreward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529). +The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `base_proposer_reward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529). -### `bonusproposerreward` +### `bonus_proposer_reward` **The maximum additional reward bonus for the validator proposing a block, as a proportion of transaction fees.** -All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block. If that validator includes more than a minimum of 2/3 of precommit signatures from the other validators in the active set, they are eligible to receive the `bonusproposerreward` of up to 4% (`0.040000000000000000`), beyond the 1% `baseproposerreward`. The bonus proposer reward amount that a validator receives depends upon how many precommit signatures are included in the proposed block (additional to the requisite 2/3). All in Bits has published more in-depth information [here](https://hub.cosmos.network/main/validators/validator-faq.html#how-are-fees-distributed). +All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block. If that validator includes more than a minimum of 2/3 of precommit signatures from the other validators in the active set, they are eligible to receive the `bonus_proposer_reward` of up to 4% (`0.040000000000000000`), beyond the 1% `base_proposer_reward`. The bonus proposer reward amount that a validator receives depends upon how many precommit signatures are included in the proposed block (additional to the requisite 2/3). All in Bits has published more in-depth information [here](https://hub.cosmos.network/main/validators/validator-faq.html#how-are-fees-distributed). -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.040000000000000000` - `cosmoshub-3` default: `0.040000000000000000` -#### Decreasing the value of `bonusproposerreward` +#### Decreasing the value of `bonus_proposer_reward` -Decreasing the value of the `bonusproposerreward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. +Decreasing the value of the `bonus_proposer_reward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. -#### Increasing the value of `bonusproposerreward` +#### Increasing the value of `bonus_proposer_reward` -Increasing the value of the `bonusproposerreward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. +Increasing the value of the `bonus_proposer_reward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. #### Notes -The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `bonusproposerreward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529). +The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `bonus_proposer_reward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529). #### Example @@ -127,7 +131,7 @@ Changing the `withdrawaddrenabled` to false will prevent delegators from changin #### Notes -This parameter was set to `false` before transfers were enabled in order to prevent stakers from diverting their rewards to other addresses ie. to avoid a loophole that would enable ATOM transfer via diverting staking rewards to a designated address. This parameter likely is only useful if [`sendenabled`](./Bank.mdx#1-sendenabled) is set to `false`. +This parameter was set to `false` before transfers were enabled in order to prevent stakers from diverting their rewards to other addresses ie. to avoid a loophole that would enable ATOM transfer via diverting staking rewards to a designated address. ## Known Bug @@ -139,4 +143,4 @@ base_proposer_reward: "0.999000000000000000" bonus_proposer_reward: "0.040000000000000000" ``` -Though the system will not allow eg. `baseproposerreward` to be a value greater than 1.0, it will allow the [`communitytax`](#communitytax), [`baseproposerreward`](#baseproposerreward), and [`bonusproposerreward`](#bonusproposerreward) parameters values to total an amount greater than 1.00, which will apparently cause the chain to panic and halt. You can [read more about the reported issue here](https://github.com/cosmos/cosmos-sdk/issues/5808). +Though the system will not allow eg. `base_proposer_reward` to be a value greater than 1.0, it will allow the [`community_tax`](#community_tax), [`base_proposer_reward`](#base_proposer_reward), and [`bonus_proposer_reward`](#bonus_proposer_reward) parameters values to total an amount greater than 1.00, which will apparently cause the chain to panic and halt. You can [read more about the reported issue here](https://github.com/cosmos/cosmos-sdk/issues/5808). diff --git a/docs/docs/governance/proposal-types/params-change/Governance.mdx b/docs/docs/governance/proposal-types/params-change/Governance.mdx index d2216c28f20..ce779d4af6b 100644 --- a/docs/docs/governance/proposal-types/params-change/Governance.mdx +++ b/docs/docs/governance/proposal-types/params-change/Governance.mdx @@ -1,7 +1,11 @@ --- -title: gov subspace +title: x/gov --- +```shell +gaiad q gov params +``` + import { KeyValueTable } from '@site/src/js/KeyValueTable'; import { Var } from '@site/src/js/Var'; import { currentParams } from '@site/docs/governance/current-parameters.js'; @@ -19,32 +23,32 @@ The `gov` module is responsible for the on-chain governance system. In this syst ## Governance notes on parameters -### `depositparams` +### `deposit_params` #### `min_deposit` **The minimum deposit required for a proposal to enter the [voting period](#votingperiod), in micro-ATOMs.** -- on-chain value: +- on-chain value: - [Proposal 47](https://www.mintscan.io/cosmos/proposals/47) change: `64000000` `uatom` - `cosmoshub-4` default: `512000000` `uatom` - `cosmoshub-3` default: `512000000` `uatom` Prior to a governance proposal entering the [voting period](#votingperiod) (ie. for the proposal to be voted upon), there must be at least a minimum number of ATOMs deposited. Anyone may contribute to this deposit. Deposits of passed and failed proposals are returned to the contributors. Deposits are burned when proposals 1) [expire](#max_deposit_period), 2) fail to reach [quorum](#quorum), or 3) are [vetoed](#veto_threshold). This parameter subkey value represents the minimum deposit required for a proposal to enter the [voting period](#votingperiod) in micro-ATOMs, where `512000000uatom` is equivalent to 512 ATOM. -##### Decreasing the value of `mindeposit` +##### Decreasing the value of `min_deposit` -Decreasing the value of the `mindeposit` subkey will enable governance proposals to enter the [voting period](#votingperiod) with fewer ATOMs at risk. This will likely increase the volume of new governance proposals. +Decreasing the value of the `min_deposit` subkey will enable governance proposals to enter the [voting period](#votingperiod) with fewer ATOMs at risk. This will likely increase the volume of new governance proposals. -##### Increasing the value of `mindeposit` +##### Increasing the value of `min_deposit` -Increasing the value of the `mindeposit` subkey will require risking a greater number of ATOMs before governance proposals may enter the [voting period](#votingperiod). This will likely decrease the volume of new governance proposals. +Increasing the value of the `min_deposit` subkey will require risking a greater number of ATOMs before governance proposals may enter the [voting period](#votingperiod). This will likely decrease the volume of new governance proposals. #### `max_deposit_period` **The maximum amount of time that a proposal can accept deposit contributions before expiring, in nanoseconds.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `1209600000000000` - `cosmoshub-3` default: `1209600000000000` @@ -62,13 +66,13 @@ Increasing the value of the `maxdepositperiod` subkey will extend the time for d Currently most network explorers (eg. Hubble, Big Dipper, Mintscan) give the same visibility to proposals in the deposit period as those in the [voting period](#votingperiod). This means that a proposal with a small deposit (eg. 0.001 ATOM) will have the same visibility as those with a full 512 ATOM deposit in the voting period. -### `votingparams` +### `voting_params` #### `votingperiod` **The maximum amount of time that a proposal can accept votes before the voting period concludes, in nanoseconds.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `1209600000000000` - `cosmoshub-3` default: `1209600000000000` @@ -92,13 +96,13 @@ Increasing the value of the `votingperiod` subkey will increase the time for vot Historically, off-chain discussions and engagement appears to be have been greater occurred during the voting period of a governance proposal than when the proposal is posted off-chain as a draft. A non-trivial amount of the voting power has voted in the second week of the voting period. Proposals 23, 19, and 13 each had approximately 80% network participation or more. -### `tallyparams` +### `tally_params` #### `quorum` **The minimum proportion of network voting power required for a governance proposal's outcome to be considered valid.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.400000000000000000` - `cosmoshub-3` default: `0.400000000000000000` @@ -116,7 +120,7 @@ Increasing the value of the `quorum` subkey will require a larger proportion of **The minimum proportion of participating voting power required for a governance proposal to pass.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.500000000000000000` - `cosmoshub-3` default: `0.500000000000000000` @@ -145,7 +149,7 @@ Increasing the value of the `threshold` subkey will increase the proportion of v **The minimum proportion of participating voting power to veto (ie. fail) a governance proposal.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.334000000000000000` - `cosmoshub-3` default: `0.334000000000000000` diff --git a/docs/docs/governance/proposal-types/params-change/Mint.mdx b/docs/docs/governance/proposal-types/params-change/Mint.mdx index de4a9ff4c3c..bf68e8612df 100644 --- a/docs/docs/governance/proposal-types/params-change/Mint.mdx +++ b/docs/docs/governance/proposal-types/params-change/Mint.mdx @@ -1,7 +1,11 @@ --- -title: mint subspace +title: x/mint --- +```shell +gaiad q mint params +``` + import { KeyValueTable } from '@site/src/js/KeyValueTable'; import { Var } from '@site/src/js/Var'; import { currentParams } from '@site/docs/governance/current-parameters.js'; @@ -22,49 +26,49 @@ It can be broken down in the following way: ## Governance notes on parameters -### `MintDenom` +### `mint_denom` **Type of asset/coin that the Cosmos Hub mints.** -- on-chain value +- on-chain value - `cosmoshub-4` default: `uatom` - `cosmoshub-3` default: `uatom` This is the type of asset (aka coin) that is being minted. The Cosmos Hub produces `uatom`, or micro-ATOM, where 1,000,000 uatom is equivalent to 1 ATOM. -#### Changing the `MintDenom` parameter +#### Changing the `mint_denom` parameter -Changing the `MintDenom` will change the asset that the Cosmos Hub mints from the ATOM. This is likely to disrupt the functionality of applications and the expectations of staking participants. +Changing the `mint_denom` will change the asset that the Cosmos Hub mints from the ATOM. This is likely to disrupt the functionality of applications and the expectations of staking participants. -### `InflationRateChange` +### `inflation_rate_change` **A factor of and limit to the speed at which the Cosmos Hub's inflation rate changes.** -- on-chain value: +- on-chain value: - [Proposal 48](https://www.mintscan.io/cosmos/proposals/48) change to `1.000000000000000000` - `cosmoshub-4` default: `0.130000000000000000` - `cosmoshub-3` default: `0.130000000000000000` -Cosmos Hub's inflation rate can change faster or slower, depending on staking participation, and is limited to a minimum of 7% and maximum of 20%. The inflation rate cannot increase or decrease faster than 13% per year (`InflationRateChange`). The speed that the inflation rate changes depends upon two things: +Cosmos Hub's inflation rate can change faster or slower, depending on staking participation, and is limited to a minimum of 7% and maximum of 20%. The inflation rate cannot increase or decrease faster than 13% per year (`inflation_rate_change`). The speed that the inflation rate changes depends upon two things: -1. how far away the _current staking participation ratio_ is from [`GoalBonded`](#5-GoalBonded) (67%) -2. the value of `InflationRateChange`, which is +1. how far away the _current staking participation ratio_ is from [`goal_bonded`](#5-goal_bonded) (67%) +2. the value of `inflation_rate_change`, which is ``` -inflationRateChangePerYear = (1 - bondedRatio/params.GoalBonded) * params.InflationRateChange +inflationRateChangePerYear = (1 - bondedRatio/params.goal_bonded) * params.inflation_rate_change ``` [The source for this information can be found here](https://github.com/cosmos/cosmos-sdk/tree/main/x/mint#begin-block). The inflation rate increases when under 67% of the token supply is staking, and it will take less time to reach the maximum of rate of 20% inflation if (for example) 30% of the token supply is staking than if 50% is staking. -#### Decreasing the value of `InflationRateChange` +#### Decreasing the value of `inflation_rate_change` -Decreasing the value of the `InflationRateChange` parameter will decrease both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take longer for inflation to reach [`InflationMin`](#InflationMin) or [`InflationMax`](#InflationMax). This may lessen the response of staking behaviour to the incentive mechanism [described in the notes below](#notes). +Decreasing the value of the `inflation_rate_change` parameter will decrease both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take longer for inflation to reach [`inflation_min`](#inflation_min) or [`inflation_max`](#inflation_max). This may lessen the response of staking behaviour to the incentive mechanism [described in the notes below](#notes). -#### Increasing the value of `InflationRateChange` +#### Increasing the value of `inflation_rate_change` -Increasing the value of the `InflationRateChange` parameter will increase both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take less time for inflation to reach [`InflationMin`](#InflationMin) or [`InflationMax`](#InflationMax). This may quicken the response of staking behaviour to the incentive mechanism [described in the notes below](#notes). +Increasing the value of the `inflation_rate_change` parameter will increase both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take less time for inflation to reach [`inflation_min`](#inflation_min) or [`inflation_max`](#inflation_max). This may quicken the response of staking behaviour to the incentive mechanism [described in the notes below](#notes). #### Notes @@ -74,86 +78,86 @@ Increasing the value of the `InflationRateChange` parameter will increase both h This means that if the staking participation rate stays the same, the inflation rate will decrease by 1.16% over the course of one year, during which time the Hub's inflation rate will decrease by about 0.1% per month. -If `InflationRateChange` is 26% and the current staking participation ratio (aka "bond ratio") is 73%, then the inflation will decrease by 2.33% over the course of one year, during which time inflation will decrease by about 0.19% per month. +If `inflation_rate_change` is 26% and the current staking participation ratio (aka "bond ratio") is 73%, then the inflation will decrease by 2.33% over the course of one year, during which time inflation will decrease by about 0.19% per month. The Cosmos Hub's inflation rate is tied to its staking participation ratio in order to make staking more or less desirable, since most of the Hub's inflation is used to fund staking rewards. If the speed of inflation responds more strongly to staking participation, it could be that staking behaviour will also respond more strongly. -### `InflationMax` +### `inflation_max` **The maximum rate that the Cosmos Hub can mint new ATOMs, proportional to the supply.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.200000000000000000` - `cosmoshub-3` default: `0.200000000000000000` -The maximum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `InflationMax`, which is 20% (`0.200000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`BlocksPerYear`](#BlocksPerYear)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains below [`GoalBonded`](#GoalBonded)(67%) for long enough, its inflation setting will eventually reach this maximum. +The maximum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `inflation_max`, which is 20% (`0.200000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`blocks_per_year`](#blocks_per_year)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains below [`goal_bonded`](#goal_bonded)(67%) for long enough, its inflation setting will eventually reach this maximum. -#### Decreasing the value of `InflationMax` +#### Decreasing the value of `inflation_max` -Decreasing the value of the `InflationMax` parameter will lower the maximum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. +Decreasing the value of the `inflation_max` parameter will lower the maximum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. -#### Increasing the value of `InflationMax` +#### Increasing the value of `inflation_max` -Increasing the value of the `InflationMax` parameter will raise the maximum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. +Increasing the value of the `inflation_max` parameter will raise the maximum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. #### Notes The effective rate of inflation tends to be different than the set rate of inflation because inflation is dependent upon the number of blocks produced per year. If blocks are produced more slowly than 6.50 seconds per block, then fewer than the assumed 4,855,015 will be produced per year, and effectively inflation will be lower than the set rate. If blocks are produced more quickly than 6.50 seconds per block, then more than the assumed 4,855,015 will be produced per year, and effectively inflation will be higher than the set rate. -### `InflationMin` +### `inflation_min` **The minimum rate that the Cosmos Hub can mint new ATOMs, proportional to the supply.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.070000000000000000` - `cosmoshub-3` default: `0.070000000000000000` -The minimum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `InflationMin`, which is 7% (`0.070000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`BlocksPerYear`](#BlocksPerYear)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains above [`GoalBonded`](#GoalBonded)(67%) for long enough, its inflation setting will eventually reach this minimum. +The minimum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `inflation_min`, which is 7% (`0.070000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`blocks_per_year`](#blocks_per_year)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains above [`goal_bonded`](#goal_bonded)(67%) for long enough, its inflation setting will eventually reach this minimum. -#### Decreasing the value of `InflationMin` +#### Decreasing the value of `inflation_min` -Decreasing the value of the `InflationMin` parameter will lower the minimum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. +Decreasing the value of the `inflation_min` parameter will lower the minimum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. -#### Increasing the value of `InflationMin` +#### Increasing the value of `inflation_min` -Increasing the value of the `InflationMin` parameter will raise the minimum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. +Increasing the value of the `inflation_min` parameter will raise the minimum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. #### Notes The effective rate of inflation tends to be different than the set rate of inflation because inflation is dependent upon the number of blocks produced per year. If blocks are produced more slowly than 6.50 seconds per block, then fewer than the assumed 4,855,015 will be produced per year, and effectively inflation will be lower than the set rate. If blocks are produced more quickly than 6.50 seconds per block, then more than the assumed 4,855,015 will be produced per year, and effectively inflation will be higher than the set rate. -### `GoalBonded` +### `goal_bonded` **The target proportion of staking participation, relative to the ATOM supply.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.670000000000000000` - `cosmoshub-3` default: `0.670000000000000000` -`GoalBonded` is the target proportion of staking participation, relative to the ATOM supply. Currently the goal of the system's design is to have 67% (`0.670000000000000000`) of the total ATOM supply bonded and participating in staking. When over 67% of the supply is staked, the inflation set rate begins decreasing at a maximum yearly rate of [`InflationRateChange`](#InflationRateChange) until it reaches and remains at the [`InflationMin`](#InflationMin) of 7%. When under 67% of the supply is staked, the inflation set rate begins increasing at a maximum yearly rate of [`InflationRateChange`](#InflationRateChange) until it reaches and remains at the [`InflationMax`](#InflationMax) of 20%. +`goal_bonded` is the target proportion of staking participation, relative to the ATOM supply. Currently the goal of the system's design is to have 67% (`0.670000000000000000`) of the total ATOM supply bonded and participating in staking. When over 67% of the supply is staked, the inflation set rate begins decreasing at a maximum yearly rate of [`inflation_rate_change`](#inflation_rate_change) until it reaches and remains at the [`inflation_min`](#inflation_min) of 7%. When under 67% of the supply is staked, the inflation set rate begins increasing at a maximum yearly rate of [`inflation_rate_change`](#inflation_rate_change) until it reaches and remains at the [`inflation_max`](#inflation_max) of 20%. -#### Decreasing the value of `GoalBonded` +#### Decreasing the value of `goal_bonded` -Decreasing the value of the `GoalBonded` parameter will cause the Cosmos Hub's inflation setting to begin decreasing at a lower participation rate, and this may reduce the incentive for staking participation. +Decreasing the value of the `goal_bonded` parameter will cause the Cosmos Hub's inflation setting to begin decreasing at a lower participation rate, and this may reduce the incentive for staking participation. -#### Increasing the value of `GoalBonded` +#### Increasing the value of `goal_bonded` -Increasing the value of the `GoalBonded` parameter will cause the Cosmos Hub's inflation setting to begin increasing at a lower participation rate, and this may increase the incentive for staking participation. +Increasing the value of the `goal_bonded` parameter will cause the Cosmos Hub's inflation setting to begin increasing at a lower participation rate, and this may increase the incentive for staking participation. -### `BlocksPerYear` +### `blocks_per_year` **The system's assumed number of blocks that the Cosmos Hub will produce in one year.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `4360000` - [Proposal 30](https://www.mintscan.io/cosmos/proposals/30) change to `4360000` - `cosmoshub-3` default: `4855015` -`BlocksPerYear` is the setting for the system's assumed number of blocks that the Cosmos Hub will produce in one year. `BlocksPerYear` is currently and the network's inflationary behaviour will be aligned with its settings when the average block time is 7.24 seconds (see [Proposal 30](https://www.mintscan.io/cosmos/proposals/30)) seconds over one year. `BlocksPerYear` is most notably used in by the system to determine the rate that new ATOMs are minted, which can vary if block times vary from 6.50 seconds per block, since effectively a different number of blocks will be produced in one year and ATOMs are minted each block. +`blocks_per_year` is the setting for the system's assumed number of blocks that the Cosmos Hub will produce in one year. `blocks_per_year` is currently and the network's inflationary behaviour will be aligned with its settings when the average block time is 7.24 seconds (see [Proposal 30](https://www.mintscan.io/cosmos/proposals/30)) seconds over one year. `blocks_per_year` is most notably used in by the system to determine the rate that new ATOMs are minted, which can vary if block times vary from 6.50 seconds per block, since effectively a different number of blocks will be produced in one year and ATOMs are minted each block. -#### Changing the `BlocksPerYear` parameter +#### Changing the `blocks_per_year` parameter -Changing the `BlocksPerYear` parameter will change the assumption that system makes about how many Cosmos Hub blocks will be produced per year. If block times are greater than 6.50 seconds, then this parameter should be decreased to make the Cosmos Hub's inflationary behaviour more aligned with its settings. If block times are less than 6.50 seconds, then this parameter should be increased to make the Cosmos Hub's behaviour more aligned with its settings. +Changing the `blocks_per_year` parameter will change the assumption that system makes about how many Cosmos Hub blocks will be produced per year. If block times are greater than 6.50 seconds, then this parameter should be decreased to make the Cosmos Hub's inflationary behaviour more aligned with its settings. If block times are less than 6.50 seconds, then this parameter should be increased to make the Cosmos Hub's behaviour more aligned with its settings. #### Notes diff --git a/docs/docs/governance/proposal-types/params-change/Slashing.mdx b/docs/docs/governance/proposal-types/params-change/Slashing.mdx index 57f417c6e8d..8102de09ec3 100644 --- a/docs/docs/governance/proposal-types/params-change/Slashing.mdx +++ b/docs/docs/governance/proposal-types/params-change/Slashing.mdx @@ -1,7 +1,11 @@ --- -title: slashing subspace +title: x/slashing --- +```shell +gaiad q slashing params +``` + import { KeyValueTable } from '@site/src/js/KeyValueTable'; import { Var } from '@site/src/js/Var'; import { currentParams } from '@site/docs/governance/current-parameters.js'; @@ -12,137 +16,137 @@ The `slashing` module is responsible for enabling the Cosmos Hub to penalize any ## Governance notes on parameters -### `SignedBlocksWindow` +### `signed_blocks_window` **Window for being offline without being slashed, in blocks.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.200000000000000000` - `cosmoshub-3` default: `0.200000000000000000` -If a validator in the active set is offline for too long, the validator will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least the [`DowntimeJailDuration`](#DowntimeJailDuration), which is 10 minutes. +If a validator in the active set is offline for too long, the validator will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least the [`downtime_jail_duration`](#downtime_jail_duration), which is 10 minutes. -How long is being offline for too long? There are two components: `SignedBlocksWindow` and [`MinSignedPerWindow`](#MinSignedPerWindow). Since `MinSignedPerWindow` is 5% and `SignedBlocksWindow` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The time window for being offline without breaking system rules is proportional to this parameter. +How long is being offline for too long? There are two components: `signed_blocks_window` and [`min_signed_per_window`](#min_signed_per_window). Since `min_signed_per_window` is 5% and `signed_blocks_window` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The time window for being offline without breaking system rules is proportional to this parameter. More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness). -#### Decreasing the value of `SignedBlocksWindow` +#### Decreasing the value of `signed_blocks_window` -Decreasing the value of the `SignedBlocksWindow` parameter will decrease the window for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#DowntimeJailDuration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. +Decreasing the value of the `signed_blocks_window` parameter will decrease the window for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#downtime_jail_duration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. **Example:** -If we pass a proposal to cut `SignedBlocksWindow` in half from 10,000 to 5,000 blocks, what happens? +If we pass a proposal to cut `signed_blocks_window` in half from 10,000 to 5,000 blocks, what happens? Validators must now sign at least 5% of 5,000 blocks, which is 250 blocks. That means that a validator that misses 4,750 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules. That's ~9.25 hours instead of ~18.5 hours, assuming 7s block times. -#### Increasing the value of `SignedBlocksWindow` +#### Increasing the value of `signed_blocks_window` -Increasing the value of the `SignedBlocksWindow` parameter will increase the window for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#DowntimeJailDuration). +Increasing the value of the `signed_blocks_window` parameter will increase the window for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#downtime_jail_duration). **Example:** -If we pass a proposal to double `SignedBlocksWindow` from 10,000 to 20,000 blocks, what happens? +If we pass a proposal to double `signed_blocks_window` from 10,000 to 20,000 blocks, what happens? Validators must now sign at least 5% of 20,000 blocks, which is 1000 blocks. That means that a validator that misses 19,000 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules. That's ~37 hours instead of ~18.5 hours, assuming 7s block times. -### `MinSignedPerWindow` +### `min_signed_per_window` **Minimum proportion of blocks signed per window without being slashed.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.050000000000000000` - `cosmoshub-3` default: `0.050000000000000000` -If a validator in the active set is offline for too long, the validator will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least the [`DowntimeJailDuration`](#DowntimeJailDuration), which is 10 minutes. +If a validator in the active set is offline for too long, the validator will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least the [`downtime_jail_duration`](#downtime_jail_duration), which is 10 minutes. -How long is being offline for too long? There are two components: [`SignedBlocksWindow`](#SignedBlocksWindow) and `MinSignedPerWindow`. Since `MinSignedPerWindow` is 5% and `SignedBlocksWindow` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The threshold-proportion of blocks is determined by this parameter, so the greater that `MinSignedPerWindow` is, the lower the tolerance for missed blocks by the system. +How long is being offline for too long? There are two components: [`signed_blocks_window`](#signed_blocks_window) and `min_signed_per_window`. Since `min_signed_per_window` is 5% and `signed_blocks_window` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The threshold-proportion of blocks is determined by this parameter, so the greater that `min_signed_per_window` is, the lower the tolerance for missed blocks by the system. More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness). -#### Decreasing the value of `MinSignedPerWindow` +#### Decreasing the value of `min_signed_per_window` -Decreasing the value of the `MinSignedPerWindow` parameter will increase the threshold for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`SlashFractionDowntime`](#5-SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#3-DowntimeJailDuration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. +Decreasing the value of the `min_signed_per_window` parameter will increase the threshold for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`slash_fraction_downtime`](#5-slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#3-downtime_jail_duration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. **Example:** -If we pass a proposal to cut `MinSignedPerWindow` in half from `0.050000000000000000` (5%) to `0.025000000000000000` (2.5%), what happens? +If we pass a proposal to cut `min_signed_per_window` in half from `0.050000000000000000` (5%) to `0.025000000000000000` (2.5%), what happens? Validators must now sign at least 2.5% of 10,000 blocks, which is 250 blocks. That means that a validator that misses 9,750 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules. That's ~19 hours instead of ~18.5 hours, assuming 7s block times. -#### Increasing the value of `MinSignedPerWindow` +#### Increasing the value of `min_signed_per_window` -Increasing the value of the `MinSignedPerWindow` parameter will decrease the threshold for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#DowntimeJailDuration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. +Increasing the value of the `min_signed_per_window` parameter will decrease the threshold for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#downtime_jail_duration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. **Example:** -If we pass a proposal to double the `MinSignedPerWindow` from `0.050000000000000000` (5%) to `0.100000000000000000` (10%), what happens? +If we pass a proposal to double the `min_signed_per_window` from `0.050000000000000000` (5%) to `0.100000000000000000` (10%), what happens? Validators must now sign at least 10% of 10,000 blocks, which is 1000 blocks. That means that a validator that misses 9,000 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules. That's ~17.5 hours instead of ~18.5 hours, assuming 7s block times. -### `DowntimeJailDuration` +### `downtime_jail_duration` **The suspension time (aka jail time) for a validator that is offline too long, in nanoseconds.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `600000000000` - `cosmoshub-3` default: `600000000000` -A validator in the active set that's offline for too long, besides being slashed, will be temporarily removed from the active set (aka "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)") for at least [`DowntimeJailDuration`](#DowntimeJailDuration), which is 10 minutes (`600000000000` nanoseconds). During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. After the `DowntimeJailDuration` period has passed, the validator operator may send an "[unjail](https://docs.cosmos.network/main/modules/slashing#unjail)" transaction to resume validator operations. +A validator in the active set that's offline for too long, besides being slashed, will be temporarily removed from the active set (aka "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)") for at least [`downtime_jail_duration`](#downtime_jail_duration), which is 10 minutes (`600000000000` nanoseconds). During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. After the `downtime_jail_duration` period has passed, the validator operator may send an "[unjail](https://docs.cosmos.network/main/modules/slashing#unjail)" transaction to resume validator operations. More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness). -#### Decreasing the value of `DowntimeJailDuration` +#### Decreasing the value of `downtime_jail_duration` -Decreasing the value of the `DowntimeJailDuration` parameter will require a validator to wait less time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. +Decreasing the value of the `downtime_jail_duration` parameter will require a validator to wait less time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. -#### Increasing the value of `DowntimeJailDuration` +#### Increasing the value of `downtime_jail_duration` -Increasing the value of the `DowntimeJailDuration` parameter will require a validator to wait more time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. +Increasing the value of the `downtime_jail_duration` parameter will require a validator to wait more time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. -### `SlashFractionDoubleSign` +### `slash_fraction_double_sign` **Proportion of stake-backing that is bruned for equivocation (aka double-signing).** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.050000000000000000` - `cosmoshub-3` default: `0.050000000000000000` A validator proven to have signed two blocks at the same height is considered to have committed equivocation, and the system will then permanently burn ("slash") that validator's total delegations (aka stake-backing) by `0.050000000000000000` (5%). All delegators to an offending validator will lose 5% of all ATOMs delegated to this validator. At this point the validator will be "[tombstoned](https://docs.cosmos.network/main/modules/slashing#staking-tombstone)," which means the validator will be permanently removed from the active set of validators, and the validator's stake-backing will only be slashed one time (regardless of how many equivocations). -#### Decreasing the value of `SlashFractionDoubleSign` +#### Decreasing the value of `slash_fraction_double_sign` -Decreasing the value of the `SlashFractionDoubleSign` parameter will lessen the penalty for equivocation, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are secure. +Decreasing the value of the `slash_fraction_double_sign` parameter will lessen the penalty for equivocation, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are secure. -#### Increasing the value of `SlashFractionDoubleSign` +#### Increasing the value of `slash_fraction_double_sign` -Increasing the value of the `SlashFractionDoubleSign` parameter will heighten the penalty for equivocation, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are secure. +Increasing the value of the `slash_fraction_double_sign` parameter will heighten the penalty for equivocation, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are secure. -### `SlashFractionDowntime` +### `slash_fraction_downtime` **Proportion of stake that is slashed for being offline too long.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `0.000100000000000000` - `cosmoshub-3` default: `0.000100000000000000` -If a validator in the active set is offline for too long, the system will permanently burn ("slash") that validator's total delegations (aka stake-backing) by a `SlashFractionDowntime` of `0.000100000000000000` (0.01%). All delegators to an offending validator will lose 0.01% of all ATOMs delegated to this validator. At this point the validator will be "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)," which means the validator will be temporarily removed from the active set of validators so the validator's stake-backing will only be slashed one time. +If a validator in the active set is offline for too long, the system will permanently burn ("slash") that validator's total delegations (aka stake-backing) by a `slash_fraction_downtime` of `0.000100000000000000` (0.01%). All delegators to an offending validator will lose 0.01% of all ATOMs delegated to this validator. At this point the validator will be "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)," which means the validator will be temporarily removed from the active set of validators so the validator's stake-backing will only be slashed one time. -#### Decreasing the value of `SlashFractionDowntime` +#### Decreasing the value of `slash_fraction_downtime` -Decreasing the value of the `SlashFractionDowntime` parameter will lessen the penalty for liveness violations, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are online. +Decreasing the value of the `slash_fraction_downtime` parameter will lessen the penalty for liveness violations, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are online. -#### Increasing the value of `SlashFractionDowntime` +#### Increasing the value of `slash_fraction_downtime` -Increasing the value of the `SlashFractionDowntime` parameter will heighten the penalty for liveness violations, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are online. +Increasing the value of the `slash_fraction_downtime` parameter will heighten the penalty for liveness violations, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are online. ### `MaxEvidenceAge` diff --git a/docs/docs/governance/proposal-types/params-change/Staking.mdx b/docs/docs/governance/proposal-types/params-change/Staking.mdx index 8acdaebab46..7f65dd7b39a 100644 --- a/docs/docs/governance/proposal-types/params-change/Staking.mdx +++ b/docs/docs/governance/proposal-types/params-change/Staking.mdx @@ -1,7 +1,11 @@ --- -title: staking subspace +title: x/staking --- +```shell +gaiad q staking params +``` + import { KeyValueTable } from '@site/src/js/KeyValueTable'; import { Var } from '@site/src/js/Var'; import { currentParams } from '@site/docs/governance/current-parameters.js'; @@ -14,27 +18,27 @@ The `staking` module is responsible for supporting an advanced Proof of Stake (P ## Governance notes on parameters -### `UnbondingTime` +### `unbonding_time` **The time duration required for bonded ATOMs to unbond and become transferrable, in nanoseconds.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `1814400000000000` - `cosmoshub-3` default: `1814400000000000` -In order to participate as a Cosmos Hub validator or delegator, ATOMs must be bonded (also known as staking). Once bonded, ATOMs are locked by the protocol and are no longer transferrable. When ATOM unbonding is initiated, the `UnbondingTime` of 1814400000000000 nanoseconds (21 days) duration must pass before the ATOMs will be unlocked and transferrable. +In order to participate as a Cosmos Hub validator or delegator, ATOMs must be bonded (also known as staking). Once bonded, ATOMs are locked by the protocol and are no longer transferrable. When ATOM unbonding is initiated, the `unbonding_time` of 1814400000000000 nanoseconds (21 days) duration must pass before the ATOMs will be unlocked and transferrable. ATOMs are used as a bond when staking. A bond may be slashed (ie. partially destroyed) when a validator has been proven to have broken protocol rules. Why? Primarily as a solution to the "[nothing-at-stake](https://medium.com/coinmonks/understanding-proof-of-stake-the-nothing-at-stake-theory-1f0d71bc027)" problem. In the scenario of an accidental or malicious attempt to rewrite history and reverse a transaction, a new chain ("fork") may be created in parallel with the primary chain. Without the risk of losing this bond, the optimal strategy for any validator is to validate blocks on both chains so that the validator gets their reward no matter which fork wins. A bond makes it more likely that the optimal strategy for validators will be to only validate blocks for the true ("canonical") chain. -Why is `UnbondingTime` so long? It can take time to discover that a validator has committed equivocation ie. signed two blocks at the same block height. If a validator commits equivocation and then unbonds before being caught, the protocol can no longer slash (ie. partially destroy) the validator's bond. +Why is `unbonding_time` so long? It can take time to discover that a validator has committed equivocation ie. signed two blocks at the same block height. If a validator commits equivocation and then unbonds before being caught, the protocol can no longer slash (ie. partially destroy) the validator's bond. -#### Decreasing the value of `UnbondingTime` +#### Decreasing the value of `unbonding_time` -Decreasing the value of the `UnbondingTime` parameter will reduce the time it takes to unbond ATOMs. This will make it less likely for a validator's bond to be slashed after committing equivocation (aka double-signing). +Decreasing the value of the `unbonding_time` parameter will reduce the time it takes to unbond ATOMs. This will make it less likely for a validator's bond to be slashed after committing equivocation (aka double-signing). -#### Increasing the value of `UnbondingTime` +#### Increasing the value of `unbonding_time` -Increasing the value of the `UnbondingTime` parameter will increase the time it takes to unbond ATOMs. This will make it more likely for a validator's bond to be slashed after committing equivocation (aka double-signing). +Increasing the value of the `unbonding_time` parameter will increase the time it takes to unbond ATOMs. This will make it more likely for a validator's bond to be slashed after committing equivocation (aka double-signing). #### Notes @@ -42,23 +46,23 @@ The ability to punish a validator for committing equivocation is associated with 1 second is equal to 1,000,000,000 nanoseconds. -## `MaxValidators` +## `max_validators` **The maximum number of validators that may participate in validating blocks, earning rewards, and governance voting.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `125` - `cosmoshub-3` default: `125` -Validators are ranked by stake-backing based upon the sum of their delegations, and only the top 125 are designated to be active (aka "the active set"). The active set may change any time delegation amounts change. Only active validators may participate in validating blocks, earning rewards, and governance voting. ATOM-holders may participate in staking by delegating their bonded ATOMs to one or more validators in the active set. Delegators may only earn rewards and have their governance votes count if they are delegating to an active validator, the set of which is capped by `MaxValidators`. +Validators are ranked by stake-backing based upon the sum of their delegations, and only the top 125 are designated to be active (aka "the active set"). The active set may change any time delegation amounts change. Only active validators may participate in validating blocks, earning rewards, and governance voting. ATOM-holders may participate in staking by delegating their bonded ATOMs to one or more validators in the active set. Delegators may only earn rewards and have their governance votes count if they are delegating to an active validator, the set of which is capped by `max_validators`. -#### Decreasing the value of `MaxValidators` +#### Decreasing the value of `max_validators` -Decreasing the value of the `MaxValidators` parameter will likely reduce the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may decrease the time it takes to produce each new Cosmos Hub block. +Decreasing the value of the `max_validators` parameter will likely reduce the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may decrease the time it takes to produce each new Cosmos Hub block. -#### Increasing the value of `MaxValidators` +#### Increasing the value of `max_validators` -Increasing the value of the `MaxValidators` parameter will likely increase the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may increase the time it takes to produce each new Cosmos Hub block. +Increasing the value of the `max_validators` parameter will likely increase the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may increase the time it takes to produce each new Cosmos Hub block. #### Notes @@ -68,8 +72,8 @@ It may be argued that after the Cosmos creators, the validator cohort may be the ### `KeyMaxEntries` -- **The maximum number of unbondings between a delegator and validator within the [unbonding period](#UnbondingTime).** -- **A delegator's maximum number of simultaneous redelegations from one validator to another validator within the [unbonding period](#1-UnbondingTime).** +- **The maximum number of unbondings between a delegator and validator within the [unbonding period](#unbonding_time).** +- **A delegator's maximum number of simultaneous redelegations from one validator to another validator within the [unbonding period](#1-unbonding_time).** - on-chain value: - `cosmoshub-4` default: `7` @@ -89,25 +93,25 @@ Increasing the value of the `KeyMaxEntries` parameter will, within the unbonding Aleksandr (All in Bits; Fission Labs) wrote more about `KeyMaxEntries` [here in this article](https://blog.cosmos.network/re-delegations-in-the-cosmos-hub-7d2f5ea59f56). -### `BondDenom` +### `bond_denom` **The unit and denomination for the asset bonded in the system.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `uatom` - `cosmoshub-3` default: `uatom` When using an asset as a bond on the Cosmos Hub, the unit and denomination of the asset is denoted as the `uatom`, or micro-ATOM, where 1 ATOM is considered 1000000uatom. The protocol doesn't use ATOM for bonds, only uatom. -#### Changing the value of `BondDenom` +#### Changing the value of `bond_denom` -Changing the `BondDenom` parameter will make any bond transactions with `uatom` fail and will require the new `BondDenom` parameter string in order for bond transactions to be successful. Changing this parameter is likely to have breaking changes for applications that offer staking and delegation functionality. +Changing the `bond_denom` parameter will make any bond transactions with `uatom` fail and will require the new `bond_denom` parameter string in order for bond transactions to be successful. Changing this parameter is likely to have breaking changes for applications that offer staking and delegation functionality. -### `HistoricalEntries` +### `historical_entries` -**The number of HistoricalEntries to keep.** +**The number of historical_entries to keep.** -- on-chain value: +- on-chain value: - `cosmoshub-4` default: `10000` - Did not exist in `cosmoshub-3` genesis diff --git a/docs/docs/governance/proposal-types/params-change/param-index.mdx b/docs/docs/governance/proposal-types/params-change/param-index.mdx index 7616f2199d0..73af67e8208 100644 --- a/docs/docs/governance/proposal-types/params-change/param-index.mdx +++ b/docs/docs/governance/proposal-types/params-change/param-index.mdx @@ -1,13 +1,13 @@ --- -title: Index of Governable Parameters +title: Legacy subspace parameters order: 2 --- -import { KeyValueTable } from '@site/src/js/KeyValueTable'; -import { Var } from '@site/src/js/Var'; -import { currentParams } from '@site/docs/governance/current-parameters.js'; +import { KeyValueTable } from "@site/src/js/KeyValueTable"; +import { Var } from "@site/src/js/Var"; +import { currentParams } from "@site/docs/governance/current-parameters.js"; -## Querying on-chain parameters +## Querying legacy on-chain parameters Given a subspace and an associated key, you can query on chain parameters using the CLI. @@ -16,34 +16,3 @@ gaiad query params subspace --node --chain- ``` For more information on specific modules, refer to the [Cosmos SDK documentation on modules](https://docs.cosmos.network/main/modules). - -## Current subspaces, keys, and values - -{/*
( -
-

- subspace -

- ( - - {key} - - )} - /> -

- Read more about the governance implications of the{' '} - {subspaceName} subspace here. -

-
- ) - )} - className="flex flex-col gap-8" -/> */} diff --git a/docs/docs/governance/submitting.md b/docs/docs/governance/submitting.md index b0f28e7da90..35cd7841038 100644 --- a/docs/docs/governance/submitting.md +++ b/docs/docs/governance/submitting.md @@ -48,61 +48,171 @@ Once on-chain, most people will rely upon block explorers to interpret this info ## Sending the transaction that submits your governance proposal -For information on how to use gaiad (the command line interface) to submit an on-chain proposal through the governance module, please refer to the [gaiad resource](/hub-tutorials/gaiad.mdx) for the Cosmos Hub documentation. +For information on how to use gaiad (the command line interface) to submit an on-chain proposal through the governance module, please refer to the [gaiad CLI tutorials](../hub-tutorials/gaiad.mdx) for the Cosmos Hub documentation. + +### Proposal types + +There are 2 proposal types that can be submitted to the CosmosHub governance module. + +#### Legacy proposals (cosmos-sdk < v0.47) +These proposals can be submitted using `gaiad tx gov submit-legacy-proposal`. + +Available proposals that can be submitted using this Tx are: + * cancel-software-upgrade + * change-reward-denoms + * consumer-addition + * consumer-removal + * ibc-upgrade + * param-change (does not work for standard cosmos-sdk modules, works on IBC and ICS modules) + * software-upgrade + * update-client + +You can read more about submitting a legacy proposal in the [cosmos-sdk docs](https://docs.cosmos.network/v0.47/build/modules/gov#submit-legacy-proposal) + +#### Proposals (cosmos-sdk >= v0.47) +These proposals can are submitted using `gaiad tx gov submit-proposal`. + +Using `gaiad tx gov draft-proposal` can help prepare a proposal. The tool will create a file containing the specified proposal message and it also helps with populating all the required proposal fields. +You can always edit the file after you create it using `draft-proposal` + +Most cosmos-sdk modules allow changing their governance gated parameters using a `MsgUpdateParams` which is a new way of updating governance parameters. It is important to note that `MsgUpdateParams` requires **all paramaters to be specified** in the proposal message. + +You can read more about submitting a proposal in the [cosmos-sdk docs](https://docs.cosmos.network/v0.47/build/modules/gov#submit-proposal) + +#### Minimal Deposit amount +:::tip +Please note that cosmoshub-4 uses a minimum initial deposit amount. +::: + +Proposals cannot be submitted successfully without providing a minimum initial deposit. In practice, this means that the `deposit` field in your proposal has to meet the `min_initial_deposit` governance paramter. +The minimum deposit is equal to `min_deposit * min_initial_deposit_ratio`. Only `uatom` is supported as deposit denom. +```shell +// checking the min_initial_deposit +gaiad q gov params -o json +{ + ... + "params": { + ... + "min_deposit": [ + { + "denom": "stake", + "amount": "10000000" + } + ], + "min_initial_deposit_ratio": "0.000000000000000000" +} +``` -### Walkthrough example -This is the generic command format for using gaiad (the command-line interface) to submit your proposal on-chain: +### Walkthrough example (changing x/staking params) + +Let's illustrate how to change the `x/staking` parameters. + +The module has the following parameters (values don't reflect actual on-chain values): +```shell +gaiad q staking params -o json +{ + "unbonding_time": "86400s", + "max_validators": 100, + "max_entries": 7, + "historical_entries": 10000, + "bond_denom": "stake", + "min_commission_rate": "0.000000000000000000", + "validator_bond_factor": "-1.000000000000000000", + "global_liquid_staking_cap": "1.000000000000000000", + "validator_liquid_staking_cap": "1.000000000000000000" +} +``` -```sh -gaiad tx gov submit-proposal \ - -- \ - --from \ - --deposit \ - --chain-id \ - --gas \ - --fees \ - --node \ +We will use `draft-proposal` to help us create a proposal file that we will later submit. +```shell +gaiad tx gov draft-proposal +// running the command will start a terminal applet allowing you to choose the proposal type + +// 1st screen +Use the arrow keys to navigate: ↓ ↑ → ← +? Select proposal type: + text + community-pool-spend + software-upgrade + cancel-software-upgrade + ▸ other // choose this + +// 2nd screen +✔ other +Use the arrow keys to navigate: ↓ ↑ → ← +? Select proposal message type:: +↑ /cosmos.staking.v1beta1.MsgUndelegate + ▸ /cosmos.staking.v1beta1.MsgUpdateParams // choose this option + /cosmos.staking.v1beta1.MsgValidatorBond + /cosmos.upgrade.v1beta1.MsgCancelUpgrade +↓ /cosmos.upgrade.v1beta1.MsgSoftwareUpgrade +``` +After choosing the `/cosmos.staking.v1beta1.MsgUpdateParams` message, the applet will allow you to set the message fields and some other proposal details. +Upon completion, the proposal will be available in the directory where you called the `gaiad` command inside the `draft_proposal.json` file. + +Here is an example of the `draft_proposal.json` file: +```JSON +{ + "messages": [ + { + "@type": "/cosmos.staking.v1beta1.MsgUpdateParams", + "authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn", + "params": { + "unbonding_time": "86400s", + "max_validators": 100, + "max_entries": 7, + "historical_entries": 10000, + "bond_denom": "uatom", + "min_commission_rate": "0.050000000000000000", // we are changing this from 0.000000000000000000 + "validator_bond_factor": "-1.000000000000000000", + "global_liquid_staking_cap": "1.000000000000000000", + "validator_liquid_staking_cap": "1.000000000000000000" + } + } + ], + "metadata": "ipfs://CID", + "deposit": "1000000uatom", + "title": "Updating the staking params (min_comission_rate)", + "summary": "This proposal will attempt to update the min_commission_rate staking parameter. During proposal creation and submission **all** proposal fields must be specified. Pay attention that you don't unintentionally specify different values for fields that you did not intend to change." +} ``` -A specific example is given here: + +Finally, we submit the proposal: ```sh -gaiad tx gov submit-proposal community-pool-spend\ - --~/community_spend_proposal.json \ - --from hypha-dev-wallet \ - --deposit 1000000uatom \ +gaiad tx gov submit-proposal + --from \ --chain-id cosmoshub-4 \ - --gas 500000 \ - --fees 7500uatom \ - --node https://rpc.cosmos.network:443 \ - + --gas \ + --fees \ + --node \ ``` -If `` is left blank, the type will be a Text proposal. Otherwise, it can be set to `param-change` or `community-pool-spend`. Use `--help` to get more info from the tool. +Use `gaiad tx gov --help` to get more info about the CLI options, we will explain some options below: -1. `gaiad` is the command-line interface client that is used to send transactions and query the Cosmos Hub. -2. `tx gov submit-proposal community-pool-spend` indicates that the transaction is submitting a community pool spend proposal. -3. `--~/community_spend_proposal.json` indicates the file containing the proposal details. -4. `--from hypha-dev-wallet` is the account key that pays the transaction fee and deposit amount. This account key must be already saved in the keyring on your device and it must be an address you control. -5. `--gas 500000` is the maximum amount of gas permitted to be used to process the transaction. +1. `--from` is the account key that pays the transaction fee and deposit amount. This account key must be already saved in the keyring on your device and it must be an address you control (e.g. `--from hypha-dev-wallet`). +5. `--gas` is the maximum amount of gas permitted to be used to process the transaction (e.g. `--gas 500000`). - The more content there is in the description of your proposal, the more gas your transaction will consume - If this number isn't high enough and there isn't enough gas to process your transaction, the transaction will fail. - The transaction will only use the amount of gas needed to process the transaction. 6. `--fees` is a flat-rate incentive for a validator to process your transaction. - - The network still accepts zero fees, but many nodes will not transmit your transaction to the network without a minimum fee. - - Many nodes (including the Figment node) use a minimum fee to disincentivize transaction spamming. + - Many nodes use a minimum fee to disincentivize transaction spamming. - 7500uatom is equal to 0.0075 ATOM. -7. `--chain-id cosmoshub-4` is Cosmos Hub 4. For current and past chain-id's, please look at the [cosmos/mainnet resource](https://github.com/cosmos/mainnet). - - The testnet chain ID is `theta-testnet-001`. For current and past testnet information, please look at the [testnet repository](https://github.com/cosmos/testnets). -8. `--node https://rpc.cosmos.network:443` is using an established node to send the transaction to the Cosmos Hub 4 network. For available nodes, please look at the [Chain Registry](https://github.com/cosmos/chain-registry/blob/master/cosmoshub/chain.json). +8. `--node` is using an established node to send the transaction to the Cosmos Hub 4 network. For available nodes, please look at the [Chain Registry](https://github.com/cosmos/chain-registry/blob/master/cosmoshub/chain.json) (e.g. https://rpc.cosmos.network:443). **Note**: be careful what you use for `--fees`. A mistake here could result in spending hundreds or thousands of ATOMs accidentally, which cannot be recovered. ### Verifying your transaction -After posting your transaction, your command line interface (gaiad) will provide you with the transaction's hash, which you can either query using gaiad or by searching the transaction hash using [Mintscan](https://www.mintscan.io/cosmos/txs/0506447AE8C7495DE970736474451CF23536DF8EA837FAF1CF6286565589AB57). The hash should look something like this: `0506447AE8C7495DE970736474451CF23536DF8EA837FAF1CF6286565589AB57` +After posting your transaction, your command line interface (gaiad) will provide you with the transaction's hash, which you can either query using gaiad or by searching the transaction hash using [Mintscan](https://www.mintscan.io/cosmos/txs/0506447AE8C7495DE970736474451CF23536DF8EA837FAF1CF6286565589AB57). The hash should look something like this: `0506447AE8C7495DE970736474451CF23536DF8EA837FAF1CF6286565589AB57`. + +Alternatively, you can check your Tx status and information using: +```shell +gaiad q tx +``` ### Troubleshooting a failed transaction @@ -129,11 +239,12 @@ gaiad q gov proposals --depositor cosmos1hxv7mpztvln45eghez6evw2ypcw4vjmsmr8cdx Once you have the proposal ID, this is the command to deposit extra tokens: ```sh -gaiad tx gov deposit --from +gaiad tx gov deposit --from ``` -In our case above, the `` would be 59 as queried earlier. -The `` is written as `500000uatom`, just like the example above. +The amount per deposit is equal to `min_deposit * min_deposit_ratio`. Only `uatom` is supported as deposit denom. Transactions where `deposit_amount < (min_deposit * min_deposit_ratio)` will be rejected. + + ### Submitting your proposal to the testnet Submitting to the testnet is identical to mainnet submissions aside from a few changes: