diff --git a/.gitbook/defi.mdx b/.gitbook/defi.mdx index e67c9773..35a90266 100644 --- a/.gitbook/defi.mdx +++ b/.gitbook/defi.mdx @@ -2,7 +2,6 @@ description: >- This section helps traders to learn more about trading instruments and start trading on Injective -icon: coins --- # DeFi diff --git a/.gitbook/developers-cosmwasm.mdx b/.gitbook/developers-cosmwasm.mdx index bf5dc87a..4f9fe22b 100644 --- a/.gitbook/developers-cosmwasm.mdx +++ b/.gitbook/developers-cosmwasm.mdx @@ -1,5 +1,5 @@ --- -icon: comet + --- # Cosmwasm Developers diff --git a/.gitbook/developers-defi.mdx b/.gitbook/developers-defi.mdx index 376d8886..51a87418 100644 --- a/.gitbook/developers-defi.mdx +++ b/.gitbook/developers-defi.mdx @@ -1,5 +1,5 @@ --- -icon: money-bill-transfer + --- # DeFi Developers diff --git a/.gitbook/developers-evm.mdx b/.gitbook/developers-evm.mdx index e6616c40..e0929fa7 100644 --- a/.gitbook/developers-evm.mdx +++ b/.gitbook/developers-evm.mdx @@ -1,5 +1,5 @@ --- -icon: rectangle-code + --- # EVM Developers diff --git a/.gitbook/developers-native.mdx b/.gitbook/developers-native.mdx index 9e8d193d..96019625 100644 --- a/.gitbook/developers-native.mdx +++ b/.gitbook/developers-native.mdx @@ -1,5 +1,5 @@ --- -icon: microchip + --- # Native Developers diff --git a/.gitbook/developers-native/core/circuit.mdx b/.gitbook/developers-native/core/circuit.mdx index 105c2925..9158e855 100644 --- a/.gitbook/developers-native/core/circuit.mdx +++ b/.gitbook/developers-native/core/circuit.mdx @@ -1,35 +1,35 @@ -# Circuit +# `x/circuit` ## Concepts -Circuit Breaker is a module that is meant to avoid a chain needing to halt/shut down in the presence of a vulnerability, instead the module will allow specific messages or all messages to be disabled. When operating a chain, if it is app specific then a halt of the chain is less detrimental, but if there are applications built on top of the chain then halting is expensive due to the disturbance to applications. +Circuit Breaker is a module that is meant to avoid a chain needing to halt/shut down in the presence of a vulnerability, instead the module will allow specific messages or all messages to be disabled. When operating a chain, if it is app specific then a halt of the chain is less detrimental, but if there are applications built on top of the chain then halting is expensive due to the disturbance to applications. -Circuit Breaker works with the idea that an address or set of addresses have the right to block messages from being executed and/or included in the mempool. Any address with a permission is able to reset the circuit breaker for the message. +Circuit Breaker works with the idea that an address or set of addresses have the right to block messages from being executed and/or included in the mempool. Any address with a permission is able to reset the circuit breaker for the message. The transactions are checked and can be rejected at two points: * In `CircuitBreakerDecorator` [ante handler](https://docs.cosmos.network/main/learn/advanced/baseapp#antehandler): -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/x/circuit/v0.1.0/x/circuit/ante/circuit.go#L27-L41 -``` +``` * With a [message router check](https://docs.cosmos.network/main/learn/advanced/baseapp#msg-service-router): -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/baseapp/msg_service_router.go#L104-L115 -``` +``` -:::note\ -The `CircuitBreakerDecorator` works for most use cases, but [does not check the inner messages of a transaction](https://docs.cosmos.network/main/learn/beginner/tx-lifecycle#antehandler). This some transactions (such as `x/authz` transactions or some `x/gov` transactions) may pass the ante handler. **This does not affect the circuit breaker** as the message router check will still fail the transaction.\ -This tradeoff is to avoid introducing more dependencies in the `x/circuit` module. Chains can re-define the `CircuitBreakerDecorator` to check for inner messages if they wish to do so.\ +:::note +The `CircuitBreakerDecorator` works for most use cases, but [does not check the inner messages of a transaction](https://docs.cosmos.network/main/learn/beginner/tx-lifecycle#antehandler). This some transactions (such as `x/authz` transactions or some `x/gov` transactions) may pass the ante handler. **This does not affect the circuit breaker** as the message router check will still fail the transaction. +This tradeoff is to avoid introducing more dependencies in the `x/circuit` module. Chains can re-define the `CircuitBreakerDecorator` to check for inner messages if they wish to do so. ::: ## State ### Accounts -* AccountPermissions `0x1 | account_address -> ProtocolBuffer(CircuitBreakerPermissions)` +* AccountPermissions `0x1 | account_address -> ProtocolBuffer(CircuitBreakerPermissions)` ```go type level int32 @@ -57,15 +57,16 @@ type Access struct { } ``` + ### Disable List List of type urls that are disabled. -* DisableList `0x2 | msg_type_url -> []byte{}` +* DisableList `0x2 | msg_type_url -> []byte{}` {/* - should this be stored in json to skip encoding and decoding each block, does it matter? */} ## State Transitions -### Authorize +### Authorize Authorize, is called by the module authority (default governance module account) or any account with `LEVEL_SUPER_ADMIN` to give permission to disable/enable messages to another account. There are three levels of permissions that can be granted. `LEVEL_SOME_MSGS` limits the number of messages that can be disabled. `LEVEL_ALL_MSGS` permits all messages to be disabled. `LEVEL_SUPER_ADMIN` allows an account to take all circuit breaker actions including authorizing and deauthorizing other accounts. @@ -98,7 +99,7 @@ Reset is called by an authorized account to enable execution for a specific msgU ### MsgAuthorizeCircuitBreaker -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/circuit/v1/tx.proto#L25-L75 ``` @@ -108,7 +109,7 @@ This message is expected to fail if: ### MsgTripCircuitBreaker -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/circuit/v1/tx.proto#L77-L93 ``` @@ -118,7 +119,7 @@ This message is expected to fail if: ### MsgResetCircuitBreaker -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/circuit/v1/tx.proto#L95-109 ``` @@ -126,7 +127,7 @@ This message is expected to fail if: * if the type url is not disabled -## Events - list and describe event tags +## Events - list and describe event tags The circuit module emits the following events: @@ -134,35 +135,36 @@ The circuit module emits the following events: #### MsgAuthorizeCircuitBreaker -| Type | Attribute Key | Attribute Value | -| ------- | ------------- | --------------------------- | -| string | granter | {granterAddress} | -| string | grantee | {granteeAddress} | -| string | permission | {granteePermissions} | -| message | module | circuit | -| message | action | authorize\_circuit\_breaker | +| Type | Attribute Key | Attribute Value | +|---------|---------------|---------------------------| +| string | granter | `{granterAddress}` | +| string | grantee | `{granteeAddress}` | +| string | permission | `{granteePermissions}` | +| message | module | `circuit` | +| message | action | `authorize_circuit_breaker` | #### MsgTripCircuitBreaker -| Type | Attribute Key | Attribute Value | -| --------- | ------------- | ---------------------- | -| string | authority | {authorityAddress} | -| \[]string | msg\_urls | \[]string{msg\_urls} | -| message | module | circuit | -| message | action | trip\_circuit\_breaker | +| Type | Attribute Key | Attribute Value | +|----------|---------------|--------------------| +| string | authority | `{authorityAddress}` | +| []string | msg_urls | `[]string{msg_urls}` | +| message | module | `circuit` | +| message | action | `trip_circuit_breaker` | #### ResetCircuitBreaker -| Type | Attribute Key | Attribute Value | -| --------- | ------------- | ----------------------- | -| string | authority | {authorityAddress} | -| \[]string | msg\_urls | \[]string{msg\_urls} | -| message | module | circuit | -| message | action | reset\_circuit\_breaker | +| Type | Attribute Key | Attribute Value | +|----------|---------------|--------------------| +| string | authority | `{authorityAddress}` | +| []string | msg_urls | `[]string{msg_urls}` | +| message | module | `circuit` | +| message | action | `reset_circuit_breaker` | + ## Keys - list of key prefixes used by the circuit module * `AccountPermissionPrefix` - `0x01` -* `DisableListPrefix` - `0x02` +* `DisableListPrefix` - `0x02` ## Client - list and describe CLI commands and gRPC and REST endpoints diff --git a/.gitbook/developers-native/core/crisis.mdx b/.gitbook/developers-native/core/crisis.mdx index 727118a2..7a75cfbe 100644 --- a/.gitbook/developers-native/core/crisis.mdx +++ b/.gitbook/developers-native/core/crisis.mdx @@ -2,48 +2,48 @@ sidebar_position: 1 --- -# Crisis +# `x/crisis` ## Overview -The crisis module halts the blockchain under the circumstance that a blockchain\ -invariant is broken. Invariants can be registered with the application during the\ +The crisis module halts the blockchain under the circumstance that a blockchain +invariant is broken. Invariants can be registered with the application during the application initialization process. ## Contents -* [State](./#state) -* [Messages](./#messages) -* [Events](./#events) -* [Parameters](./#parameters) -* [Client](./#client) - * [CLI](./#cli) +* [State](#state) +* [Messages](#messages) +* [Events](#events) +* [Parameters](#parameters) +* [Client](#client) + * [CLI](#cli) ## State ### ConstantFee -Due to the anticipated large gas cost requirement to verify an invariant (and\ -potential to exceed the maximum allowable block gas limit) a constant fee is\ -used instead of the standard gas consumption method. The constant fee is\ -intended to be larger than the anticipated gas cost of running the invariant\ +Due to the anticipated large gas cost requirement to verify an invariant (and +potential to exceed the maximum allowable block gas limit) a constant fee is +used instead of the standard gas consumption method. The constant fee is +intended to be larger than the anticipated gas cost of running the invariant with the standard gas consumption method. -The ConstantFee param is stored in the module params state with the prefix of `0x01`,\ +The ConstantFee param is stored in the module params state with the prefix of `0x01`, it can be updated with governance or the address with authority. * Params: `mint/params -> legacy_amino(sdk.Coin)` ## Messages -In this section we describe the processing of the crisis messages and the\ +In this section we describe the processing of the crisis messages and the corresponding updates to the state. ### MsgVerifyInvariant Blockchain invariants can be checked using the `MsgVerifyInvariant` message. -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/crisis/v1beta1/tx.proto#L26-L42 ``` @@ -52,10 +52,10 @@ This message is expected to fail if: * the sender does not have enough coins for the constant fee * the invariant route is not registered -This message checks the invariant provided, and if the invariant is broken it\ -panics, halting the blockchain. If the invariant is broken, the constant fee is\ -never deducted as the transaction is never committed to a block (equivalent to\ -being refunded). However, if the invariant is not broken, the constant fee will\ +This message checks the invariant provided, and if the invariant is broken it +panics, halting the blockchain. If the invariant is broken, the constant fee is +never deducted as the transaction is never committed to a block (equivalent to +being refunded). However, if the invariant is not broken, the constant fee will not be refunded. ## Events @@ -66,20 +66,20 @@ The crisis module emits the following events: #### MsgVerifyInvariance -| Type | Attribute Key | Attribute Value | -| --------- | ------------- | ----------------- | -| invariant | route | {invariantRoute} | -| message | module | crisis | -| message | action | verify\_invariant | -| message | sender | {senderAddress} | +| Type | Attribute Key | Attribute Value | +|-----------|---------------|------------------| +| invariant | route | `{invariantRoute}` | +| message | module | `crisis` | +| message | action | `verify_invariant` | +| message | sender | `{senderAddress}` | ## Parameters The crisis module contains the following parameters: | Key | Type | Example | -| ----------- | ------------- | --------------------------------- | -| ConstantFee | object (coin) | {"denom":"uatom","amount":"1000"} | +|-------------|---------------|-----------------------------------| +| ConstantFee | object (coin) | `{"denom":"uatom","amount":"1000"}` | ## Client @@ -95,7 +95,7 @@ The `tx` commands allow users to interact with the `crisis` module. simd tx crisis --help ``` -**invariant-broken** +##### invariant-broken The `invariant-broken` command submits proof when an invariant was broken to halt the chain diff --git a/.gitbook/developers-native/core/gov.mdx b/.gitbook/developers-native/core/gov.mdx index f532fbf8..1bb7170c 100644 --- a/.gitbook/developers-native/core/gov.mdx +++ b/.gitbook/developers-native/core/gov.mdx @@ -2,149 +2,151 @@ sidebar_position: 1 --- -# Gov +# `x/gov` ## Abstract -This paper specifies the Governance module of the Cosmos SDK, which was first\ -described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in\ +This paper specifies the Governance module of the Cosmos SDK, which was first +described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in June 2016. -The module enables Cosmos SDK based blockchain to support an on-chain governance\ -system. In this system, holders of the native staking token of the chain can vote\ -on proposals on a 1 token 1 vote basis. Next is a list of features the module\ +The module enables Cosmos SDK based blockchain to support an on-chain governance +system. In this system, holders of the native staking token of the chain can vote +on proposals on a 1 token 1 vote basis. Next is a list of features the module currently supports: -* **Proposal submission:** Users can submit proposals with a deposit. Once the\ - minimum deposit is reached, the proposal enters voting period. The minimum deposit can be reached by collecting deposits from different users (including proposer) within deposit period. +* **Proposal submission:** Users can submit proposals with a deposit. Once the +minimum deposit is reached, the proposal enters voting period. The minimum deposit can be reached by collecting deposits from different users (including proposer) within deposit period. * **Vote:** Participants can vote on proposals that reached MinDeposit and entered voting period. -* **Inheritance and penalties:** Delegators inherit their validator's vote if\ - they don't vote themselves. -* **Claiming deposit:** Users that deposited on proposals can recover their\ - deposits if the proposal was accepted or rejected. If the proposal was vetoed, or never entered voting period (minimum deposit not reached within deposit period), the deposit is burned. +* **Inheritance and penalties:** Delegators inherit their validator's vote if +they don't vote themselves. +* **Claiming deposit:** Users that deposited on proposals can recover their +deposits if the proposal was accepted or rejected. If the proposal was vetoed, or never entered voting period (minimum deposit not reached within deposit period), the deposit is burned. -This module is in use on the Cosmos Hub (a.k.a [gaia](https://github.com/cosmos/gaia)).\ -Features that may be added in the future are described in [Future Improvements](./#future-improvements). +This module is in use on the Cosmos Hub (a.k.a [gaia](https://github.com/cosmos/gaia)). +Features that may be added in the future are described in [Future Improvements](#future-improvements). ## Contents -The following specification uses _ATOM_ as the native staking token. The module\ -can be adapted to any Proof-Of-Stake blockchain by replacing _ATOM_ with the native\ +The following specification uses *ATOM* as the native staking token. The module +can be adapted to any Proof-Of-Stake blockchain by replacing *ATOM* with the native staking token of the chain. -* [Concepts](./#concepts) - * [Proposal submission](./#proposal-submission) - * [Deposit](./#deposit) - * [Vote](./#vote) - * [Software Upgrade](./#software-upgrade) -* [State](./#state) - * [Proposals](./#proposals) - * [Parameters and base types](./#parameters-and-base-types) - * [Deposit](./#deposit-1) - * [ValidatorGovInfo](./#validatorgovinfo) - * [Stores](./#stores) - * [Proposal Processing Queue](./#proposal-processing-queue) - * [Legacy Proposal](./#legacy-proposal) -* [Messages](./#messages) - * [Proposal Submission](./#proposal-submission-1) - * [Deposit](./#deposit-2) - * [Vote](./#vote-1) -* [Events](./#events) - * [EndBlocker](./#endblocker) - * [Handlers](./#handlers) -* [Parameters](./#parameters) -* [Client](./#client) - * [CLI](./#cli) - * [gRPC](./#grpc) - * [REST](./#rest) -* [Metadata](./#metadata) - * [Proposal](./#proposal-3) - * [Vote](./#vote-5) -* [Future Improvements](./#future-improvements) +* [Concepts](#concepts) + * [Proposal submission](#proposal-submission) + * [Deposit](#deposit) + * [Vote](#vote) + * [Software Upgrade](#software-upgrade) +* [State](#state) + * [Proposals](#proposals) + * [Parameters and base types](#parameters-and-base-types) + * [Deposit](#deposit-1) + * [ValidatorGovInfo](#validatorgovinfo) + * [Stores](#stores) + * [Proposal Processing Queue](#proposal-processing-queue) + * [Legacy Proposal](#legacy-proposal) +* [Messages](#messages) + * [Proposal Submission](#proposal-submission-1) + * [Deposit](#deposit-2) + * [Vote](#vote-1) +* [Events](#events) + * [EndBlocker](#endblocker) + * [Handlers](#handlers) +* [Parameters](#parameters) +* [Client](#client) + * [CLI](#cli) + * [gRPC](#grpc) + * [REST](#rest) +* [Metadata](#metadata) + * [Proposal](#proposal-3) + * [Vote](#vote-5) +* [Future Improvements](#future-improvements) ## Concepts -_Disclaimer: This is work in progress. Mechanisms are susceptible to change._ +*Disclaimer: This is work in progress. Mechanisms are susceptible to change.* The governance process is divided in a few steps that are outlined below: -* **Proposal submission:** Proposal is submitted to the blockchain with a\ +* **Proposal submission:** Proposal is submitted to the blockchain with a deposit. -* **Vote:** Once deposit reaches a certain value (`MinDeposit`), proposal is\ - confirmed and vote opens. Bonded Atom holders can then send `TxGovVote`\ +* **Vote:** Once deposit reaches a certain value (`MinDeposit`), proposal is + confirmed and vote opens. Bonded Atom holders can then send `TxGovVote` transactions to vote on the proposal. -* **Execution** After a period of time, the votes are tallied and depending\ +* **Execution** After a period of time, the votes are tallied and depending on the result, the messages in the proposal will be executed. ### Proposal submission #### Right to submit a proposal -Every account can submit proposals by sending a `MsgSubmitProposal` transaction.\ +Every account can submit proposals by sending a `MsgSubmitProposal` transaction. Once a proposal is submitted, it is identified by its unique `proposalID`. #### Proposal Messages -A proposal includes an array of `sdk.Msg`s which are executed automatically if the\ -proposal passes. The messages are executed by the governance `ModuleAccount` itself. Modules\ -such as `x/upgrade`, that want to allow certain messages to be executed by governance\ -only should add a whitelist within the respective msg server, granting the governance\ -module the right to execute the message once a quorum has been reached. The governance\ -module uses the `MsgServiceRouter` to check that these messages are correctly constructed\ +A proposal includes an array of `sdk.Msg`s which are executed automatically if the +proposal passes. The messages are executed by the governance `ModuleAccount` itself. Modules +such as `x/upgrade`, that want to allow certain messages to be executed by governance +only should add a whitelist within the respective msg server, granting the governance +module the right to execute the message once a quorum has been reached. The governance +module uses the `MsgServiceRouter` to check that these messages are correctly constructed and have a respective path to execute on but do not perform a full validity check. ### Deposit -To prevent spam, proposals must be submitted with a deposit in the coins defined by\ +To prevent spam, proposals must be submitted with a deposit in the coins defined by the `MinDeposit` param. -When a proposal is submitted, it has to be accompanied with a deposit that must be\ -strictly positive, but can be inferior to `MinDeposit`. The submitter doesn't need\ -to pay for the entire deposit on their own. The newly created proposal is stored in\ -an _inactive proposal queue_ and stays there until its deposit passes the `MinDeposit`.\ -Other token holders can increase the proposal's deposit by sending a `Deposit`\ -transaction. If a proposal doesn't pass the `MinDeposit` before the deposit end time\ -(the time when deposits are no longer accepted), the proposal will be destroyed: the\ -proposal will be removed from state and the deposit will be burned (see x/gov `EndBlocker`).\ -When a proposal deposit passes the `MinDeposit` threshold (even during the proposal\ -submission) before the deposit end time, the proposal will be moved into the_active proposal queue_ and the voting period will begin. - -The deposit is kept in escrow and held by the governance `ModuleAccount` until the\ +When a proposal is submitted, it has to be accompanied with a deposit that must be +strictly positive, but can be inferior to `MinDeposit`. The submitter doesn't need +to pay for the entire deposit on their own. The newly created proposal is stored in +an *inactive proposal queue* and stays there until its deposit passes the `MinDeposit`. +Other token holders can increase the proposal's deposit by sending a `Deposit` +transaction. If a proposal doesn't pass the `MinDeposit` before the deposit end time +(the time when deposits are no longer accepted), the proposal will be destroyed: the +proposal will be removed from state and the deposit will be burned (see x/gov `EndBlocker`). +When a proposal deposit passes the `MinDeposit` threshold (even during the proposal +submission) before the deposit end time, the proposal will be moved into the +*active proposal queue* and the voting period will begin. + +The deposit is kept in escrow and held by the governance `ModuleAccount` until the proposal is finalized (passed or rejected). #### Deposit refund and burn -When a proposal is finalized, the coins from the deposit are either refunded or burned\ +When a proposal is finalized, the coins from the deposit are either refunded or burned according to the final tally of the proposal: -* If the proposal is approved or rejected but _not_ vetoed, each deposit will be\ - automatically refunded to its respective depositor (transferred from the governance`ModuleAccount`). -* When the proposal is vetoed with greater than 1/3, deposits will be burned from the\ - governance `ModuleAccount` and the proposal information along with its deposit\ +* If the proposal is approved or rejected but *not* vetoed, each deposit will be + automatically refunded to its respective depositor (transferred from the governance + `ModuleAccount`). +* When the proposal is vetoed with greater than 1/3, deposits will be burned from the + governance `ModuleAccount` and the proposal information along with its deposit information will be removed from state. -* All refunded or burned deposits are removed from the state. Events are issued when\ +* All refunded or burned deposits are removed from the state. Events are issued when burning or refunding a deposit. ### Vote #### Participants -_Participants_ are users that have the right to vote on proposals. On the\ -Cosmos Hub, participants are bonded Atom holders. Unbonded Atom holders and\ -other users do not get the right to participate in governance. However, they\ +*Participants* are users that have the right to vote on proposals. On the +Cosmos Hub, participants are bonded Atom holders. Unbonded Atom holders and +other users do not get the right to participate in governance. However, they can submit and deposit on proposals. -Note that when _participants_ have bonded and unbonded Atoms, their voting power is calculated from their bonded Atom holdings only. +Note that when *participants* have bonded and unbonded Atoms, their voting power is calculated from their bonded Atom holdings only. #### Voting period -Once a proposal reaches `MinDeposit`, it immediately enters `Voting period`. We\ -define `Voting period` as the interval between the moment the vote opens and\ +Once a proposal reaches `MinDeposit`, it immediately enters `Voting period`. We +define `Voting period` as the interval between the moment the vote opens and the moment the vote closes. The initial value of `Voting period` is 2 weeks. #### Option set -The option set of a proposal refers to the set of choices a participant can\ +The option set of a proposal refers to the set of choices a participant can choose from when casting its vote. The initial option set includes the following options: @@ -154,11 +156,11 @@ The initial option set includes the following options: * `NoWithVeto` * `Abstain` -`NoWithVeto` counts as `No` but also adds a `Veto` vote. `Abstain` option\ -allows voters to signal that they do not intend to vote in favor or against the\ +`NoWithVeto` counts as `No` but also adds a `Veto` vote. `Abstain` option +allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote. -_Note: from the UI, for urgent proposals we should maybe add a ‘Not Urgent’ option that casts a `NoWithVeto` vote._ +*Note: from the UI, for urgent proposals we should maybe add a ‘Not Urgent’ option that casts a `NoWithVeto` vote.* #### Weighted Votes @@ -168,11 +170,11 @@ Often times the entity owning that address might not be a single individual. For To represent weighted vote on chain, we use the following Protobuf message. -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L34-L47 ``` -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L181-L201 ``` @@ -180,7 +182,7 @@ For a weighted vote to be valid, the `options` field must not contain duplicate ### Quorum -Quorum is defined as the minimum percentage of voting power that needs to be\ +Quorum is defined as the minimum percentage of voting power that needs to be cast on a proposal for the result to be valid. ### Expedited Proposals @@ -189,31 +191,34 @@ A proposal can be expedited, making the proposal use shorter voting duration and #### Threshold -Threshold is defined as the minimum proportion of `Yes` votes (excluding`Abstain` votes) for the proposal to be accepted. +Threshold is defined as the minimum proportion of `Yes` votes (excluding +`Abstain` votes) for the proposal to be accepted. -Initially, the threshold is set at 50% of `Yes` votes, excluding `Abstain`\ -votes. A possibility to veto exists if more than 1/3rd of all votes are`NoWithVeto` votes. Note, both of these values are derived from the `TallyParams`\ -on-chain parameter, which is modifiable by governance.\ +Initially, the threshold is set at 50% of `Yes` votes, excluding `Abstain` +votes. A possibility to veto exists if more than 1/3rd of all votes are +`NoWithVeto` votes. Note, both of these values are derived from the `TallyParams` +on-chain parameter, which is modifiable by governance. This means that proposals are accepted iff: * There exist bonded tokens. * Quorum has been achieved. * The proportion of `Abstain` votes is inferior to 1/1. -* The proportion of `NoWithVeto` votes is inferior to 1/3, including`Abstain` votes. -* The proportion of `Yes` votes, excluding `Abstain` votes, at the end of\ +* The proportion of `NoWithVeto` votes is inferior to 1/3, including + `Abstain` votes. +* The proportion of `Yes` votes, excluding `Abstain` votes, at the end of the voting period is superior to 1/2. -For expedited proposals, by default, the threshold is higher than with a _normal proposal_, namely, 66.7%. +For expedited proposals, by default, the threshold is higher than with a *normal proposal*, namely, 66.7%. #### Inheritance If a delegator does not vote, it will inherit its validator vote. -* If the delegator votes before its validator, it will not inherit from the\ +* If the delegator votes before its validator, it will not inherit from the validator's vote. -* If the delegator votes after its validator, it will override its validator\ - vote with its own. If the proposal is urgent, it is possible\ - that the vote will close before delegators have a chance to react and\ +* If the delegator votes after its validator, it will override its validator + vote with its own. If the proposal is urgent, it is possible + that the vote will close before delegators have a chance to react and override their validator's vote. This is not a problem, as proposals require more than 2/3rd of the total voting power to pass, when tallied at the end of the voting period. Because as little as 1/3 + 1 validation power could collude to censor transactions, non-collusion is already assumed for ranges exceeding this threshold. #### Validator’s punishment for non-voting @@ -226,19 +231,19 @@ Later, we may add permissioned keys that could only sign txs from certain module #### Burnable Params -There are three parameters that define if the deposit of a proposal should be burned or returned to the depositors. +There are three parameters that define if the deposit of a proposal should be burned or returned to the depositors. -* `BurnVoteVeto` burns the proposal deposit if the proposal gets vetoed. +* `BurnVoteVeto` burns the proposal deposit if the proposal gets vetoed. * `BurnVoteQuorum` burns the proposal deposit if the proposal deposit if the vote does not reach quorum. -* `BurnProposalDepositPrevote` burns the proposal deposit if it does not enter the voting phase. +* `BurnProposalDepositPrevote` burns the proposal deposit if it does not enter the voting phase. -> Note: These parameters are modifiable via governance. +> Note: These parameters are modifiable via governance. ## State ### Constitution -`Constitution` is found in the genesis state. It is a string field intended to be used to descibe the purpose of a particular blockchain, and its expected norms. A few examples of how the constitution field can be used: +`Constitution` is found in the genesis state. It is a string field intended to be used to descibe the purpose of a particular blockchain, and its expected norms. A few examples of how the constitution field can be used: * define the purpose of the chain, laying a foundation for its future development * set expectations for delegators @@ -248,16 +253,16 @@ There are three parameters that define if the deposit of a proposal should be bu Since this is more of a social feature than a technical feature, we'll now get into some items that may have been useful to have in a genesis constitution: * What limitations on governance exist, if any? - * is it okay for the community to slash the wallet of a whale that they no longer feel that they want around? (viz: Juno Proposal 4 and 16) - * can governance "socially slash" a validator who is using unapproved MEV? (viz: commonwealth.im/osmosis) - * In the event of an economic emergency, what should validators do? - * Terra crash of May, 2022, saw validators choose to run a new binary with code that had not been approved by governance, because the governance token had been inflated to nothing. + * is it okay for the community to slash the wallet of a whale that they no longer feel that they want around? (viz: Juno Proposal 4 and 16) + * can governance "socially slash" a validator who is using unapproved MEV? (viz: commonwealth.im/osmosis) + * In the event of an economic emergency, what should validators do? + * Terra crash of May, 2022, saw validators choose to run a new binary with code that had not been approved by governance, because the governance token had been inflated to nothing. * What is the purpose of the chain, specifically? - * best example of this is the Cosmos hub, where different founding groups, have different interpertations of the purpose of the network. + * best example of this is the Cosmos hub, where different founding groups, have different interpertations of the purpose of the network. -This genesis entry, "constitution" hasn't been designed for existing chains, who should likely just ratify a constitution using their governance system. Instead, this is for new chains. It will allow for validators to have a much clearer idea of purpose and the expecations placed on them while operating thier nodes. Likewise, for community members, the constitution will give them some idea of what to expect from both the "chain team" and the validators, respectively. +This genesis entry, "constitution" hasn't been designed for existing chains, who should likely just ratify a constitution using their governance system. Instead, this is for new chains. It will allow for validators to have a much clearer idea of purpose and the expecations placed on them while operating thier nodes. Likewise, for community members, the constitution will give them some idea of what to expect from both the "chain team" and the validators, respectively. -This constitution is designed to be immutable, and placed only in genesis, though that could change over time by a pull request to the cosmos-sdk that allows for the constitution to be changed by governance. Communities whishing to make amendments to their original constitution should use the governance mechanism and a "signaling proposal" to do exactly that. +This constitution is designed to be immutable, and placed only in genesis, though that could change over time by a pull request to the cosmos-sdk that allows for the constitution to be changed by governance. Communities whishing to make amendments to their original constitution should use the governance mechanism and a "signaling proposal" to do exactly that. **Ideal use scenario for a cosmos chain constitution** @@ -271,23 +276,25 @@ You use the constitution to immutably store some Markdown in genesis, so that wh ### Proposals -`Proposal` objects are used to tally votes and generally track the proposal's state.\ -They contain an array of arbitrary `sdk.Msg`'s which the governance module will attempt\ -to resolve and then execute if the proposal passes. `Proposal`'s are identified by a\ -unique id and contains a series of timestamps: `submit_time`, `deposit_end_time`,`voting_start_time`, `voting_end_time` which track the lifecycle of a proposal +`Proposal` objects are used to tally votes and generally track the proposal's state. +They contain an array of arbitrary `sdk.Msg`'s which the governance module will attempt +to resolve and then execute if the proposal passes. `Proposal`'s are identified by a +unique id and contains a series of timestamps: `submit_time`, `deposit_end_time`, +`voting_start_time`, `voting_end_time` which track the lifecycle of a proposal -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L51-L99 ``` -A proposal will generally require more than just a set of messages to explain its\ -purpose but need some greater justification and allow a means for interested participants\ -to discuss and debate the proposal.\ -In most cases, **it is encouraged to have an off-chain system that supports the on-chain governance process**.\ -To accommodate for this, a proposal contains a special **`metadata`** field, a string,\ -which can be used to add context to the proposal. The `metadata` field allows custom use for networks,\ -however, it is expected that the field contains a URL or some form of CID using a system such as[IPFS](https://docs.ipfs.io/concepts/content-addressing/). To support the case of\ -interoperability across networks, the SDK recommends that the `metadata` represents\ +A proposal will generally require more than just a set of messages to explain its +purpose but need some greater justification and allow a means for interested participants +to discuss and debate the proposal. +In most cases, **it is encouraged to have an off-chain system that supports the on-chain governance process**. +To accommodate for this, a proposal contains a special **`metadata`** field, a string, +which can be used to add context to the proposal. The `metadata` field allows custom use for networks, +however, it is expected that the field contains a URL or some form of CID using a system such as +[IPFS](https://docs.ipfs.io/concepts/content-addressing/). To support the case of +interoperability across networks, the SDK recommends that the `metadata` represents the following `JSON` template: ```json @@ -301,40 +308,41 @@ the following `JSON` template: This makes it far easier for clients to support multiple networks. -The metadata has a maximum length that is chosen by the app developer, and\ +The metadata has a maximum length that is chosen by the app developer, and passed into the gov keeper as a config. The default maximum length in the SDK is 255 characters. #### Writing a module that uses governance -There are many aspects of a chain, or of the individual modules that you may want to\ -use governance to perform such as changing various parameters. This is very simple\ -to do. First, write out your message types and `MsgServer` implementation. Add an`authority` field to the keeper which will be populated in the constructor with the\ -governance module account: `govKeeper.GetGovernanceAccount().GetAddress()`. Then for\ -the methods in the `msg_server.go`, perform a check on the message that the signer\ +There are many aspects of a chain, or of the individual modules that you may want to +use governance to perform such as changing various parameters. This is very simple +to do. First, write out your message types and `MsgServer` implementation. Add an +`authority` field to the keeper which will be populated in the constructor with the +governance module account: `govKeeper.GetGovernanceAccount().GetAddress()`. Then for +the methods in the `msg_server.go`, perform a check on the message that the signer matches `authority`. This will prevent any user from executing that message. ### Parameters and base types -`Parameters` define the rules according to which votes are run. There can only\ -be one active parameter set at any given time. If governance wants to change a\ -parameter set, either to modify a value or add/remove a parameter field, a new\ +`Parameters` define the rules according to which votes are run. There can only +be one active parameter set at any given time. If governance wants to change a +parameter set, either to modify a value or add/remove a parameter field, a new parameter set has to be created and the previous one rendered inactive. #### DepositParams -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L152-L162 ``` #### VotingParams -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L164-L168 ``` #### TallyParams -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L170-L182 ``` @@ -374,7 +382,7 @@ const ( ### Deposit -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/gov.proto#L38-L49 ``` @@ -391,21 +399,21 @@ This type is used in a temp map when tallying ## Stores -:::note\ -Stores are KVStores in the multi-store. The key to find the store is the first parameter in the list\ +:::note +Stores are KVStores in the multi-store. The key to find the store is the first parameter in the list ::: We will use one KVStore `Governance` to store four mappings: * A mapping from `proposalID|'proposal'` to `Proposal`. -* A mapping from `proposalID|'addresses'|address` to `Vote`. This mapping allows\ - us to query all addresses that voted on the proposal along with their vote by\ +* A mapping from `proposalID|'addresses'|address` to `Vote`. This mapping allows + us to query all addresses that voted on the proposal along with their vote by doing a range query on `proposalID:addresses`. -* A mapping from `ParamsKey|'Params'` to `Params`. This map allows to query all\ +* A mapping from `ParamsKey|'Params'` to `Params`. This map allows to query all x/gov params. -* A mapping from `VotingPeriodProposalKeyPrefix|proposalID` to a single byte. This allows\ +* A mapping from `VotingPeriodProposalKeyPrefix|proposalID` to a single byte. This allows us to know if a proposal is in the voting period or not with very low gas cost. - + For pseudocode purposes, here are the two function we will use to read or write in stores: * `load(StoreKey, Key)`: Retrieve item stored at key `Key` in store found at key `StoreKey` in the multistore @@ -415,11 +423,12 @@ For pseudocode purposes, here are the two function we will use to read or write **Store:** -* `ProposalProcessingQueue`: A queue `queue[proposalID]` containing all the`ProposalIDs` of proposals that reached `MinDeposit`. During each `EndBlock`,\ - all the proposals that have reached the end of their voting period are processed.\ - To process a finished proposal, the application tallies the votes, computes the\ - votes of each validator and checks if every validator in the validator set has\ - voted. If the proposal is accepted, deposits are refunded. Finally, the proposal\ +* `ProposalProcessingQueue`: A queue `queue[proposalID]` containing all the + `ProposalIDs` of proposals that reached `MinDeposit`. During each `EndBlock`, + all the proposals that have reached the end of their voting period are processed. + To process a finished proposal, the application tallies the votes, computes the + votes of each validator and checks if every validator in the validator set has + voted. If the proposal is accepted, deposits are refunded. Finally, the proposal content `Handler` is executed. And the pseudocode for the `ProposalProcessingQueue`: @@ -485,15 +494,15 @@ And the pseudocode for the `ProposalProcessingQueue`: ### Legacy Proposal -:::warning\ -Legacy proposals are deprecated. Use the new proposal flow by granting the governance module the right to execute the message.\ +:::warning +Legacy proposals are deprecated. Use the new proposal flow by granting the governance module the right to execute the message. ::: -A legacy proposal is the old implementation of governance proposal.\ -Contrary to proposal that can contain any messages, a legacy proposal allows to submit a set of pre-defined proposals.\ +A legacy proposal is the old implementation of governance proposal. +Contrary to proposal that can contain any messages, a legacy proposal allows to submit a set of pre-defined proposals. These proposals are defined by their types and handled by handlers that are registered in the gov v1beta1 router. -More information on how to submit proposals in the [client section](./#client). +More information on how to submit proposals in the [client section](#client). ## Messages @@ -501,14 +510,14 @@ More information on how to submit proposals in the [client section](./#client). Proposals can be submitted by any account via a `MsgSubmitProposal` transaction. -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.proto#L42-L69 ``` -All `sdk.Msgs` passed into the `messages` field of a `MsgSubmitProposal` message\ -must be registered in the app's `MsgServiceRouter`. Each of these messages must\ -have one signer, namely the gov module account. And finally, the metadata length\ -must not be larger than the `maxMetadataLen` config passed into the gov keeper.\ +All `sdk.Msgs` passed into the `messages` field of a `MsgSubmitProposal` message +must be registered in the app's `MsgServiceRouter`. Each of these messages must +have one signer, namely the gov module account. And finally, the metadata length +must not be larger than the `maxMetadataLen` config passed into the gov keeper. The `initialDeposit` must be strictly positive and conform to the accepted denom of the `MinDeposit` param. **State modifications:** @@ -518,12 +527,13 @@ The `initialDeposit` must be strictly positive and conform to the accepted denom * Initialise `Proposal`'s attributes * Decrease balance of sender by `InitialDeposit` * If `MinDeposit` is reached: - * Push `proposalID` in `ProposalProcessingQueue` + * Push `proposalID` in `ProposalProcessingQueue` * Transfer `InitialDeposit` from the `Proposer` to the governance `ModuleAccount` ### Deposit -Once a proposal is submitted, if `Proposal.TotalDeposit < ActiveParam.MinDeposit`, Atom holders can send`MsgDeposit` transactions to increase the proposal's deposit. +Once a proposal is submitted, if `Proposal.TotalDeposit < ActiveParam.MinDeposit`, Atom holders can send +`MsgDeposit` transactions to increase the proposal's deposit. A deposit is accepted iff: @@ -531,7 +541,7 @@ A deposit is accepted iff: * The proposal is not in the voting period * The deposited coins are conform to the accepted denom from the `MinDeposit` param -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.proto#L134-L147 ``` @@ -541,16 +551,16 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.pro * Add `deposit` of sender in `proposal.Deposits` * Increase `proposal.TotalDeposit` by sender's `deposit` * If `MinDeposit` is reached: - * Push `proposalID` in `ProposalProcessingQueueEnd` + * Push `proposalID` in `ProposalProcessingQueueEnd` * Transfer `Deposit` from the `proposer` to the governance `ModuleAccount` ### Vote -Once `ActiveParam.MinDeposit` is reached, voting period starts. From there,\ -bonded Atom holders are able to send `MsgVote` transactions to cast their\ +Once `ActiveParam.MinDeposit` is reached, voting period starts. From there, +bonded Atom holders are able to send `MsgVote` transactions to cast their vote on the proposal. -```protobuf +```protobuf reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.proto#L92-L108 ``` @@ -558,8 +568,8 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/gov/v1/tx.pro * Record `Vote` of sender -:::note\ -Gas cost for this message has to take into account the future tallying of the vote in EndBlocker.\ +:::note +Gas cost for this message has to take into account the future tallying of the vote in EndBlocker. ::: ## Events @@ -568,84 +578,85 @@ The governance module emits the following events: ### EndBlocker -| Type | Attribute Key | Attribute Value | -| ------------------ | ---------------- | ---------------- | -| inactive\_proposal | proposal\_id | {proposalID} | -| inactive\_proposal | proposal\_result | {proposalResult} | -| active\_proposal | proposal\_id | {proposalID} | -| active\_proposal | proposal\_result | {proposalResult} | +| Type | Attribute Key | Attribute Value | +|-------------------|-----------------|------------------| +| inactive_proposal | proposal_id | `{proposalID}` | +| inactive_proposal | proposal_result | `{proposalResult}` | +| active_proposal | proposal_id | `{proposalID}` | +| active_proposal | proposal_result | `{proposalResult}` | ### Handlers #### MsgSubmitProposal -| Type | Attribute Key | Attribute Value | -| --------------------- | --------------------- | ---------------- | -| submit\_proposal | proposal\_id | {proposalID} | -| submit\_proposal \[0] | voting\_period\_start | {proposalID} | -| proposal\_deposit | amount | {depositAmount} | -| proposal\_deposit | proposal\_id | {proposalID} | -| message | module | governance | -| message | action | submit\_proposal | -| message | sender | {senderAddress} | +| Type | Attribute Key | Attribute Value | +|---------------------|---------------------|-----------------| +| submit_proposal | proposal_id | `{proposalID}` | +| submit_proposal [0] | voting_period_start | `{proposalID}` | +| proposal_deposit | amount | `{depositAmount}` | +| proposal_deposit | proposal_id | `{proposalID}` | +| message | module | `governance` | +| message | action | `submit_proposal` | +| message | sender | `{senderAddress}` | -* \[0] Event only emitted if the voting period starts during the submission. +* [0] Event only emitted if the voting period starts during the submission. #### MsgVote -| Type | Attribute Key | Attribute Value | -| -------------- | ------------- | --------------- | -| proposal\_vote | option | {voteOption} | -| proposal\_vote | proposal\_id | {proposalID} | -| message | module | governance | -| message | action | vote | -| message | sender | {senderAddress} | +| Type | Attribute Key | Attribute Value | +|---------------|---------------|-----------------| +| proposal_vote | option | `{voteOption}` | +| proposal_vote | proposal_id | `{proposalID}` | +| message | module | `governance` | +| message | action | `vote` | +| message | sender | `{senderAddress}` | #### MsgVoteWeighted -| Type | Attribute Key | Attribute Value | -| -------------- | ------------- | --------------------- | -| proposal\_vote | option | {weightedVoteOptions} | -| proposal\_vote | proposal\_id | {proposalID} | -| message | module | governance | -| message | action | vote | -| message | sender | {senderAddress} | +| Type | Attribute Key | Attribute Value | +|---------------|---------------|-----------------------| +| proposal_vote | option | `{weightedVoteOptions}` | +| proposal_vote | proposal_id | `{proposalID}` | +| message | module | `governance` | +| message | action | `vote` | +| message | sender | `{senderAddress}` | #### MsgDeposit -| Type | Attribute Key | Attribute Value | -| ---------------------- | --------------------- | --------------- | -| proposal\_deposit | amount | {depositAmount} | -| proposal\_deposit | proposal\_id | {proposalID} | -| proposal\_deposit \[0] | voting\_period\_start | {proposalID} | -| message | module | governance | -| message | action | deposit | -| message | sender | {senderAddress} | +| Type | Attribute Key | Attribute Value | +|----------------------|---------------------|-----------------| +| proposal_deposit | amount | `{depositAmount}` | +| proposal_deposit | proposal_id | `{proposalID}` | +| proposal_deposit [0] | voting_period_start | `{proposalID}` | +| message | module | `governance` | +| message | action | `deposit` | +| message | sender | `{senderAddress}` | -* \[0] Event only emitted if the voting period starts during the submission. +* [0] Event only emitted if the voting period starts during the submission. ## Parameters The governance module contains the following parameters: -| Key | Type | Example | -| -------------------------------- | ---------------- | ---------------------------------------- | -| min\_deposit | array (coins) | \[{"denom":"uatom","amount":"10000000"}] | -| max\_deposit\_period | string (time ns) | "172800000000000" (17280s) | -| voting\_period | string (time ns) | "172800000000000" (17280s) | -| quorum | string (dec) | "0.334000000000000000" | -| threshold | string (dec) | "0.500000000000000000" | -| veto | string (dec) | "0.334000000000000000" | -| expedited\_threshold | string (time ns) | "0.667000000000000000" | -| expedited\_voting\_period | string (time ns) | "86400000000000" (8600s) | -| expedited\_min\_deposit | array (coins) | \[{"denom":"uatom","amount":"50000000"}] | -| burn\_proposal\_deposit\_prevote | bool | false | -| burn\_vote\_quorum | bool | false | -| burn\_vote\_veto | bool | true | -| min\_initial\_deposit\_ratio | string | "0.1" | - -**NOTE**: The governance module contains parameters that are objects unlike other\ -modules. If only a subset of parameters are desired to be changed, only they need\ +| Key | Type | Example | +|-------------------------------|------------------|-----------------------------------------| +| min_deposit | array (coins) | `[{"denom":"uatom","amount":"10000000"}]` | +| max_deposit_period | string (time ns) | `"172800000000000"` (17280s) | +| voting_period | string (time ns) | `"172800000000000"` (17280s) | +| quorum | string (dec) | `"0.334000000000000000"` | +| threshold | string (dec) | `"0.500000000000000000"` | +| veto | string (dec) | `"0.334000000000000000"` | +| expedited_threshold | string (time ns) | `"0.667000000000000000"` | +| expedited_voting_period | string (time ns) | `"86400000000000"` (8600s) | +| expedited_min_deposit | array (coins) | `[{"denom":"uatom","amount":"50000000"}]` | +| burn_proposal_deposit_prevote | bool | `false` | +| burn_vote_quorum | bool | `false` | +| burn_vote_veto | bool | `true` | +| min_initial_deposit_ratio | string | `"0.1"` | + + +**NOTE**: The governance module contains parameters that are objects unlike other +modules. If only a subset of parameters are desired to be changed, only they need to be included and not the entire parameter object structure. ## Client @@ -662,7 +673,7 @@ The `query` commands allow users to query `gov` state. simd query gov --help ``` -**deposit** +##### deposit The `deposit` command allows users to query a deposit for a given proposal from a given depositor. @@ -686,7 +697,7 @@ depositor: cosmos1.. proposal_id: "1" ``` -**deposits** +##### deposits The `deposits` command allows users to query all deposits for a given proposal. @@ -714,7 +725,7 @@ pagination: total: "0" ``` -**param** +##### param The `param` command allows users to query a given parameter for the `gov` module. @@ -734,7 +745,7 @@ Example Output: voting_period: "172800000000000" ``` -**params** +##### params The `params` command allows users to query all parameters for the `gov` module. @@ -780,7 +791,7 @@ voting_params: voting_period: 172800s ``` -**proposal** +##### proposal The `proposal` command allows users to query a given proposal. @@ -821,7 +832,7 @@ voting_end_time: null voting_start_time: null ``` -**proposals** +##### proposals The `proposals` command allows users to query all proposals with optional filters. @@ -888,7 +899,7 @@ proposals: voting_start_time: null ``` -**proposer** +##### proposer The `proposer` command allows users to query the proposer for a given proposal. @@ -909,7 +920,7 @@ proposal_id: "1" proposer: cosmos1.. ``` -**tally** +##### tally The `tally` command allows users to query the tally of a given proposal vote. @@ -932,7 +943,7 @@ no_with_veto: "0" "yes": "1" ``` -**vote** +##### vote The `vote` command allows users to query a vote for a given proposal. @@ -957,7 +968,7 @@ proposal_id: "1" voter: cosmos1.. ``` -**votes** +##### votes The `votes` command allows users to query all votes for a given proposal. @@ -994,7 +1005,7 @@ The `tx` commands allow users to interact with the `gov` module. simd tx gov --help ``` -**deposit** +##### deposit The `deposit` command allows users to deposit tokens for a given proposal. @@ -1008,19 +1019,19 @@ Example: simd tx gov deposit 1 10000000stake --from cosmos1.. ``` -**draft-proposal** +##### draft-proposal -The `draft-proposal` command allows users to draft any type of proposal.\ -The command returns a `draft_proposal.json`, to be used by `submit-proposal` after being completed.\ -The `draft_metadata.json` is meant to be uploaded to [IPFS](./#metadata). +The `draft-proposal` command allows users to draft any type of proposal. +The command returns a `draft_proposal.json`, to be used by `submit-proposal` after being completed. +The `draft_metadata.json` is meant to be uploaded to [IPFS](#metadata). ```bash simd tx gov draft-proposal ``` -**submit-proposal** +##### submit-proposal -The `submit-proposal` command allows users to submit a governance proposal along with some messages and metadata.\ +The `submit-proposal` command allows users to submit a governance proposal along with some messages and metadata. Messages, metadata and deposit are defined in a JSON file. ```bash @@ -1052,15 +1063,15 @@ where `proposal.json` contains: } ``` -:::note\ -By default the metadata, summary and title are both limited by 255 characters, this can be overridden by the application developer.\ +:::note +By default the metadata, summary and title are both limited by 255 characters, this can be overridden by the application developer. ::: -:::tip\ -When metadata is not specified, the title is limited to 255 characters and the summary 40x the title length.\ +:::tip +When metadata is not specified, the title is limited to 255 characters and the summary 40x the title length. ::: -**submit-legacy-proposal** +##### submit-legacy-proposal The `submit-legacy-proposal` command allows users to submit a governance legacy proposal along with an initial deposit. @@ -1109,7 +1120,7 @@ Example: simd tx gov cancel-proposal 1 --from cosmos1... ``` -**vote** +##### vote The `vote` command allows users to submit a vote for a given governance proposal. @@ -1123,7 +1134,7 @@ Example: simd tx gov vote 1 yes --from cosmos1.. ``` -**weighted-vote** +##### weighted-vote The `weighted-vote` command allows users to submit a weighted vote for a given governance proposal. @@ -1537,6 +1548,8 @@ Example Output: The `Params` endpoint allows users to query all parameters for the `gov` module. +{/* TODO: #10197 Querying governance params outputs nil values */} + Using legacy v1beta1: ```bash @@ -2216,6 +2229,8 @@ Example Output: The `params` endpoint allows users to query all parameters for the `gov` module. +{/* TODO: #10197 Querying governance params outputs nil values */} + Using legacy v1beta1: ```bash @@ -2476,7 +2491,7 @@ The gov module has two locations for metadata where users can provide further co ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [group proposal](../group/#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [group proposal](../group/README.md#metadata)) ```json { @@ -2489,14 +2504,14 @@ Location: off-chain as json object stored on IPFS (mirrors [group proposal](../g } ``` -:::note\ -The `authors` field is an array of strings, this is to allow for multiple authors to be listed in the metadata.\ -In v0.46, the `authors` field is a comma-separated string. Frontends are encouraged to support both formats for backwards compatibility.\ +:::note +The `authors` field is an array of strings, this is to allow for multiple authors to be listed in the metadata. +In v0.46, the `authors` field is a comma-separated string. Frontends are encouraged to support both formats for backwards compatibility. ::: ### Vote -Location: on-chain as json within 255 character limit (mirrors [group vote](../group/#metadata)) +Location: on-chain as json within 255 character limit (mirrors [group vote](../group/README.md#metadata)) ```json { @@ -2506,21 +2521,27 @@ Location: on-chain as json within 255 character limit (mirrors [group vote](../g ## Future Improvements -The current documentation only describes the minimum viable product for the\ +The current documentation only describes the minimum viable product for the governance module. Future improvements may include: -* **`BountyProposals`:** If accepted, a `BountyProposal` creates an open\ - bounty. The `BountyProposal` specifies how many Atoms will be given upon\ - completion. These Atoms will be taken from the `reserve pool`. After a`BountyProposal` is accepted by governance, anybody can submit a`SoftwareUpgradeProposal` with the code to claim the bounty. Note that once a`BountyProposal` is accepted, the corresponding funds in the `reserve pool`\ - are locked so that payment can always be honored. In order to link a`SoftwareUpgradeProposal` to an open bounty, the submitter of the`SoftwareUpgradeProposal` will use the `Proposal.LinkedProposal` attribute.\ - If a `SoftwareUpgradeProposal` linked to an open bounty is accepted by\ - governance, the funds that were reserved are automatically transferred to the\ +* **`BountyProposals`:** If accepted, a `BountyProposal` creates an open + bounty. The `BountyProposal` specifies how many Atoms will be given upon + completion. These Atoms will be taken from the `reserve pool`. After a + `BountyProposal` is accepted by governance, anybody can submit a + `SoftwareUpgradeProposal` with the code to claim the bounty. Note that once a + `BountyProposal` is accepted, the corresponding funds in the `reserve pool` + are locked so that payment can always be honored. In order to link a + `SoftwareUpgradeProposal` to an open bounty, the submitter of the + `SoftwareUpgradeProposal` will use the `Proposal.LinkedProposal` attribute. + If a `SoftwareUpgradeProposal` linked to an open bounty is accepted by + governance, the funds that were reserved are automatically transferred to the submitter. -* **Complex delegation:** Delegators could choose other representatives than\ - their validators. Ultimately, the chain of representatives would always end\ - up to a validator, but delegators could inherit the vote of their chosen\ - representative before they inherit the vote of their validator. In other\ - words, they would only inherit the vote of their validator if their other\ +* **Complex delegation:** Delegators could choose other representatives than + their validators. Ultimately, the chain of representatives would always end + up to a validator, but delegators could inherit the vote of their chosen + representative before they inherit the vote of their validator. In other + words, they would only inherit the vote of their validator if their other appointed representative did not vote. -* **Better process for proposal review:** There would be two parts to`proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to\ +* **Better process for proposal review:** There would be two parts to + `proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to reward third party auditors. diff --git a/.gitbook/developers-native/core/group.mdx b/.gitbook/developers-native/core/group.mdx index 79e6d723..e2be16de 100644 --- a/.gitbook/developers-native/core/group.mdx +++ b/.gitbook/developers-native/core/group.mdx @@ -2,7 +2,7 @@ sidebar_position: 1 --- -# Group +# `x/group` ## Abstract @@ -12,193 +12,195 @@ This module allows the creation and management of on-chain multisig accounts and ## Contents -* [Concepts](./#concepts) - * [Group](./#group) - * [Group Policy](./#group-policy) - * [Decision Policy](./#decision-policy) - * [Proposal](./#proposal) - * [Pruning](./#pruning) -* [State](./#state) - * [Group Table](./#group-table) - * [Group Member Table](./#group-member-table) - * [Group Policy Table](./#group-policy-table) - * [Proposal Table](./#proposal-table) - * [Vote Table](./#vote-table) -* [Msg Service](./#msg-service) - * [Msg/CreateGroup](./#msgcreategroup) - * [Msg/UpdateGroupMembers](./#msgupdategroupmembers) - * [Msg/UpdateGroupAdmin](./#msgupdategroupadmin) - * [Msg/UpdateGroupMetadata](./#msgupdategroupmetadata) - * [Msg/CreateGroupPolicy](./#msgcreategrouppolicy) - * [Msg/CreateGroupWithPolicy](./#msgcreategroupwithpolicy) - * [Msg/UpdateGroupPolicyAdmin](./#msgupdategrouppolicyadmin) - * [Msg/UpdateGroupPolicyDecisionPolicy](./#msgupdategrouppolicydecisionpolicy) - * [Msg/UpdateGroupPolicyMetadata](./#msgupdategrouppolicymetadata) - * [Msg/SubmitProposal](./#msgsubmitproposal) - * [Msg/WithdrawProposal](./#msgwithdrawproposal) - * [Msg/Vote](./#msgvote) - * [Msg/Exec](./#msgexec) - * [Msg/LeaveGroup](./#msgleavegroup) -* [Events](./#events) - * [EventCreateGroup](./#eventcreategroup) - * [EventUpdateGroup](./#eventupdategroup) - * [EventCreateGroupPolicy](./#eventcreategrouppolicy) - * [EventUpdateGroupPolicy](./#eventupdategrouppolicy) - * [EventCreateProposal](./#eventcreateproposal) - * [EventWithdrawProposal](./#eventwithdrawproposal) - * [EventVote](./#eventvote) - * [EventExec](./#eventexec) - * [EventLeaveGroup](./#eventleavegroup) - * [EventProposalPruned](./#eventproposalpruned) -* [Client](./#client) - * [CLI](./#cli) - * [gRPC](./#grpc) - * [REST](./#rest) -* [Metadata](./#metadata) +* [Concepts](#concepts) + * [Group](#group) + * [Group Policy](#group-policy) + * [Decision Policy](#decision-policy) + * [Proposal](#proposal) + * [Pruning](#pruning) +* [State](#state) + * [Group Table](#group-table) + * [Group Member Table](#group-member-table) + * [Group Policy Table](#group-policy-table) + * [Proposal Table](#proposal-table) + * [Vote Table](#vote-table) +* [Msg Service](#msg-service) + * [Msg/CreateGroup](#msgcreategroup) + * [Msg/UpdateGroupMembers](#msgupdategroupmembers) + * [Msg/UpdateGroupAdmin](#msgupdategroupadmin) + * [Msg/UpdateGroupMetadata](#msgupdategroupmetadata) + * [Msg/CreateGroupPolicy](#msgcreategrouppolicy) + * [Msg/CreateGroupWithPolicy](#msgcreategroupwithpolicy) + * [Msg/UpdateGroupPolicyAdmin](#msgupdategrouppolicyadmin) + * [Msg/UpdateGroupPolicyDecisionPolicy](#msgupdategrouppolicydecisionpolicy) + * [Msg/UpdateGroupPolicyMetadata](#msgupdategrouppolicymetadata) + * [Msg/SubmitProposal](#msgsubmitproposal) + * [Msg/WithdrawProposal](#msgwithdrawproposal) + * [Msg/Vote](#msgvote) + * [Msg/Exec](#msgexec) + * [Msg/LeaveGroup](#msgleavegroup) +* [Events](#events) + * [EventCreateGroup](#eventcreategroup) + * [EventUpdateGroup](#eventupdategroup) + * [EventCreateGroupPolicy](#eventcreategrouppolicy) + * [EventUpdateGroupPolicy](#eventupdategrouppolicy) + * [EventCreateProposal](#eventcreateproposal) + * [EventWithdrawProposal](#eventwithdrawproposal) + * [EventVote](#eventvote) + * [EventExec](#eventexec) + * [EventLeaveGroup](#eventleavegroup) + * [EventProposalPruned](#eventproposalpruned) +* [Client](#client) + * [CLI](#cli) + * [gRPC](#grpc) + * [REST](#rest) +* [Metadata](#metadata) ## Concepts ### Group -A group is simply an aggregation of accounts with associated weights. It is not\ -an account and doesn't have a balance. It doesn't in and of itself have any\ -sort of voting or decision weight. It does have an "administrator" which has\ -the ability to add, remove and update members in the group. Note that a\ -group policy account could be an administrator of a group, and that the\ +A group is simply an aggregation of accounts with associated weights. It is not +an account and doesn't have a balance. It doesn't in and of itself have any +sort of voting or decision weight. It does have an "administrator" which has +the ability to add, remove and update members in the group. Note that a +group policy account could be an administrator of a group, and that the administrator doesn't necessarily have to be a member of the group. ### Group Policy -A group policy is an account associated with a group and a decision policy.\ -Group policies are abstracted from groups because a single group may have\ -multiple decision policies for different types of actions. Managing group\ -membership separately from decision policies results in the least overhead\ -and keeps membership consistent across different policies. The pattern that\ -is recommended is to have a single master group policy for a given group,\ -and then to create separate group policies with different decision policies\ -and delegate the desired permissions from the master account to\ +A group policy is an account associated with a group and a decision policy. +Group policies are abstracted from groups because a single group may have +multiple decision policies for different types of actions. Managing group +membership separately from decision policies results in the least overhead +and keeps membership consistent across different policies. The pattern that +is recommended is to have a single master group policy for a given group, +and then to create separate group policies with different decision policies +and delegate the desired permissions from the master account to those "sub-accounts" using the `x/authz` module. ### Decision Policy -A decision policy is the mechanism by which members of a group can vote on\ -proposals, as well as the rules that dictate whether a proposal should pass\ +A decision policy is the mechanism by which members of a group can vote on +proposals, as well as the rules that dictate whether a proposal should pass or not based on its tally outcome. -All decision policies generally would have a mininum execution period and a\ -maximum voting window. The minimum execution period is the minimum amount of time\ -that must pass after submission in order for a proposal to potentially be executed, and it may\ -be set to 0. The maximum voting window is the maximum time after submission that a proposal may\ +All decision policies generally would have a mininum execution period and a +maximum voting window. The minimum execution period is the minimum amount of time +that must pass after submission in order for a proposal to potentially be executed, and it may +be set to 0. The maximum voting window is the maximum time after submission that a proposal may be voted on before it is tallied. -The chain developer also defines an app-wide maximum execution period, which is\ -the maximum amount of time after a proposal's voting period end where users are\ +The chain developer also defines an app-wide maximum execution period, which is +the maximum amount of time after a proposal's voting period end where users are allowed to execute a proposal. -The current group module comes shipped with two decision policies: threshold\ -and percentage. Any chain developer can extend upon these two, by creating\ -custom decision policies, as long as they adhere to the `DecisionPolicy`\ +The current group module comes shipped with two decision policies: threshold +and percentage. Any chain developer can extend upon these two, by creating +custom decision policies, as long as they adhere to the `DecisionPolicy` interface: -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/types.go#L27-L45 ``` #### Threshold decision policy -A threshold decision policy defines a threshold of yes votes (based on a tally\ -of voter weights) that must be achieved in order for a proposal to pass. For\ +A threshold decision policy defines a threshold of yes votes (based on a tally +of voter weights) that must be achieved in order for a proposal to pass. For this decision policy, abstain and veto are simply treated as no's. -This decision policy also has a VotingPeriod window and a MinExecutionPeriod\ -window. The former defines the duration after proposal submission where members\ -are allowed to vote, after which tallying is performed. The latter specifies\ -the minimum duration after proposal submission where the proposal can be\ -executed. If set to 0, then the proposal is allowed to be executed immediately\ -on submission (using the `TRY_EXEC` option). Obviously, MinExecutionPeriod\ -cannot be greater than VotingPeriod+MaxExecutionPeriod (where MaxExecution is\ -the app-defined duration that specifies the window after voting ended where a\ +This decision policy also has a VotingPeriod window and a MinExecutionPeriod +window. The former defines the duration after proposal submission where members +are allowed to vote, after which tallying is performed. The latter specifies +the minimum duration after proposal submission where the proposal can be +executed. If set to 0, then the proposal is allowed to be executed immediately +on submission (using the `TRY_EXEC` option). Obviously, MinExecutionPeriod +cannot be greater than VotingPeriod+MaxExecutionPeriod (where MaxExecution is +the app-defined duration that specifies the window after voting ended where a proposal can be executed). #### Percentage decision policy -A percentage decision policy is similar to a threshold decision policy, except\ -that the threshold is not defined as a constant weight, but as a percentage.\ -It's more suited for groups where the group members' weights can be updated, as\ -the percentage threshold stays the same, and doesn't depend on how those member\ +A percentage decision policy is similar to a threshold decision policy, except +that the threshold is not defined as a constant weight, but as a percentage. +It's more suited for groups where the group members' weights can be updated, as +the percentage threshold stays the same, and doesn't depend on how those member weights get updated. -Same as the Threshold decision policy, the percentage decision policy has the\ +Same as the Threshold decision policy, the percentage decision policy has the two VotingPeriod and MinExecutionPeriod parameters. ### Proposal -Any member(s) of a group can submit a proposal for a group policy account to decide upon.\ -A proposal consists of a set of messages that will be executed if the proposal\ +Any member(s) of a group can submit a proposal for a group policy account to decide upon. +A proposal consists of a set of messages that will be executed if the proposal passes as well as any metadata associated with the proposal. #### Voting -There are four choices to choose while voting - yes, no, abstain and veto. Not\ -all decision policies will take the four choices into account. Votes can contain some optional metadata.\ -In the current implementation, the voting window begins as soon as a proposal\ +There are four choices to choose while voting - yes, no, abstain and veto. Not +all decision policies will take the four choices into account. Votes can contain some optional metadata. +In the current implementation, the voting window begins as soon as a proposal is submitted, and the end is defined by the group policy's decision policy. #### Withdrawing Proposals -Proposals can be withdrawn any time before the voting period end, either by the\ -admin of the group policy or by one of the proposers. Once withdrawn, it is\ -marked as `PROPOSAL_STATUS_WITHDRAWN`, and no more voting or execution is\ +Proposals can be withdrawn any time before the voting period end, either by the +admin of the group policy or by one of the proposers. Once withdrawn, it is +marked as `PROPOSAL_STATUS_WITHDRAWN`, and no more voting or execution is allowed on it. #### Aborted Proposals -If the group policy is updated during the voting period of the proposal, then\ -the proposal is marked as `PROPOSAL_STATUS_ABORTED`, and no more voting or\ -execution is allowed on it. This is because the group policy defines the rules\ -of proposal voting and execution, so if those rules change during the lifecycle\ +If the group policy is updated during the voting period of the proposal, then +the proposal is marked as `PROPOSAL_STATUS_ABORTED`, and no more voting or +execution is allowed on it. This is because the group policy defines the rules +of proposal voting and execution, so if those rules change during the lifecycle of a proposal, then the proposal should be marked as stale. #### Tallying -Tallying is the counting of all votes on a proposal. It happens only once in\ -the lifecycle of a proposal, but can be triggered by two factors, whichever\ +Tallying is the counting of all votes on a proposal. It happens only once in +the lifecycle of a proposal, but can be triggered by two factors, whichever happens first: -* either someone tries to execute the proposal (see next section), which can\ - happen on a `Msg/Exec` transaction, or a `Msg/{SubmitProposal,Vote}`\ - transaction with the `Exec` field set. When a proposal execution is attempted,\ +* either someone tries to execute the proposal (see next section), which can + happen on a `Msg/Exec` transaction, or a `Msg/{SubmitProposal,Vote}` + transaction with the `Exec` field set. When a proposal execution is attempted, a tally is done first to make sure the proposal passes. * or on `EndBlock` when the proposal's voting period end just passed. -If the tally result passes the decision policy's rules, then the proposal is\ -marked as `PROPOSAL_STATUS_ACCEPTED`, or else it is marked as`PROPOSAL_STATUS_REJECTED`. In any case, no more voting is allowed anymore, and the tally\ +If the tally result passes the decision policy's rules, then the proposal is +marked as `PROPOSAL_STATUS_ACCEPTED`, or else it is marked as +`PROPOSAL_STATUS_REJECTED`. In any case, no more voting is allowed anymore, and the tally result is persisted to state in the proposal's `FinalTallyResult`. #### Executing Proposals -Proposals are executed only when the tallying is done, and the group account's\ -decision policy allows the proposal to pass based on the tally outcome. They\ -are marked by the status `PROPOSAL_STATUS_ACCEPTED`. Execution must happen\ -before a duration of `MaxExecutionPeriod` (set by the chain developer) after\ +Proposals are executed only when the tallying is done, and the group account's +decision policy allows the proposal to pass based on the tally outcome. They +are marked by the status `PROPOSAL_STATUS_ACCEPTED`. Execution must happen +before a duration of `MaxExecutionPeriod` (set by the chain developer) after each proposal's voting period end. -Proposals will not be automatically executed by the chain in this current design,\ -but rather a user must submit a `Msg/Exec` transaction to attempt to execute the\ -proposal based on the current votes and decision policy. Any user (not only the\ -group members) can execute proposals that have been accepted, and execution fees are\ -paid by the proposal executor.\ -It's also possible to try to execute a proposal immediately on creation or on\ -new votes using the `Exec` field of `Msg/SubmitProposal` and `Msg/Vote` requests.\ -In the former case, proposers signatures are considered as yes votes.\ -In these cases, if the proposal can't be executed (i.e. it didn't pass the\ -decision policy's rules), it will still be opened for new votes and\ +Proposals will not be automatically executed by the chain in this current design, +but rather a user must submit a `Msg/Exec` transaction to attempt to execute the +proposal based on the current votes and decision policy. Any user (not only the +group members) can execute proposals that have been accepted, and execution fees are +paid by the proposal executor. +It's also possible to try to execute a proposal immediately on creation or on +new votes using the `Exec` field of `Msg/SubmitProposal` and `Msg/Vote` requests. +In the former case, proposers signatures are considered as yes votes. +In these cases, if the proposal can't be executed (i.e. it didn't pass the +decision policy's rules), it will still be opened for new votes and could be tallied and executed later on. -A successful proposal execution will have its `ExecutorResult` marked as`PROPOSAL_EXECUTOR_RESULT_SUCCESS`. The proposal will be automatically pruned\ -after execution. On the other hand, a failed proposal execution will be marked\ -as `PROPOSAL_EXECUTOR_RESULT_FAILURE`. Such a proposal can be re-executed\ -multiple times, until it expires after `MaxExecutionPeriod` after voting period\ +A successful proposal execution will have its `ExecutorResult` marked as +`PROPOSAL_EXECUTOR_RESULT_SUCCESS`. The proposal will be automatically pruned +after execution. On the other hand, a failed proposal execution will be marked +as `PROPOSAL_EXECUTOR_RESULT_FAILURE`. Such a proposal can be re-executed +multiple times, until it expires after `MaxExecutionPeriod` after voting period end. ### Pruning @@ -207,8 +209,9 @@ Proposals and votes are automatically pruned to avoid state bloat. Votes are pruned: -* either after a successful tally, i.e. a tally whose result passes the decision\ - policy's rules, which can be trigged by a `Msg/Exec` or a`Msg/{SubmitProposal,Vote}` with the `Exec` field set, +* either after a successful tally, i.e. a tally whose result passes the decision + policy's rules, which can be trigged by a `Msg/Exec` or a + `Msg/{SubmitProposal,Vote}` with the `Exec` field set, * or on `EndBlock` right after the proposal's voting period end. This applies to proposals with status `aborted` or `withdrawn` too. whichever happens first. @@ -217,13 +220,14 @@ Proposals are pruned: * on `EndBlock` whose proposal status is `withdrawn` or `aborted` on proposal's voting period end before tallying, * and either after a successful proposal execution, -* or on `EndBlock` right after the proposal's `voting_period_end` +`max_execution_period` (defined as an app-wide configuration) is passed, +* or on `EndBlock` right after the proposal's `voting_period_end` + + `max_execution_period` (defined as an app-wide configuration) is passed, whichever happens first. ## State -The `group` module uses the `orm` package which provides table storage with support for\ +The `group` module uses the `orm` package which provides table storage with support for primary keys and secondary indexes. `orm` also defines `Sequence` which is a persistent unique key generator based on a counter that can be used along with `Table`s. Here's the list of tables and associated sequences and indexes stored as part of the `group` module. @@ -240,41 +244,49 @@ The second `0x1` corresponds to the ORM `sequenceStorageKey`. #### groupByAdminIndex -`groupByAdminIndex` allows to retrieve groups by admin address:`0x2 | len([]byte(group.Admin)) | []byte(group.Admin) | BigEndian(GroupId) -> []byte()`. +`groupByAdminIndex` allows to retrieve groups by admin address: +`0x2 | len([]byte(group.Admin)) | []byte(group.Admin) | BigEndian(GroupId) -> []byte()`. ### Group Member Table The `groupMemberTable` stores `GroupMember`s: `0x10 | BigEndian(GroupId) | []byte(member.Address) -> ProtocolBuffer(GroupMember)`. -The `groupMemberTable` is a primary key table and its `PrimaryKey` is given by`BigEndian(GroupId) | []byte(member.Address)` which is used by the following indexes. +The `groupMemberTable` is a primary key table and its `PrimaryKey` is given by +`BigEndian(GroupId) | []byte(member.Address)` which is used by the following indexes. #### groupMemberByGroupIndex -`groupMemberByGroupIndex` allows to retrieve group members by group id:`0x11 | BigEndian(GroupId) | PrimaryKey -> []byte()`. +`groupMemberByGroupIndex` allows to retrieve group members by group id: +`0x11 | BigEndian(GroupId) | PrimaryKey -> []byte()`. #### groupMemberByMemberIndex -`groupMemberByMemberIndex` allows to retrieve group members by member address:`0x12 | len([]byte(member.Address)) | []byte(member.Address) | PrimaryKey -> []byte()`. +`groupMemberByMemberIndex` allows to retrieve group members by member address: +`0x12 | len([]byte(member.Address)) | []byte(member.Address) | PrimaryKey -> []byte()`. ### Group Policy Table The `groupPolicyTable` stores `GroupPolicyInfo`: `0x20 | len([]byte(Address)) | []byte(Address) -> ProtocolBuffer(GroupPolicyInfo)`. -The `groupPolicyTable` is a primary key table and its `PrimaryKey` is given by`len([]byte(Address)) | []byte(Address)` which is used by the following indexes. +The `groupPolicyTable` is a primary key table and its `PrimaryKey` is given by +`len([]byte(Address)) | []byte(Address)` which is used by the following indexes. #### groupPolicySeq -The value of `groupPolicySeq` is incremented when creating a new group policy and is used to generate the new group policy account `Address`:`0x21 | 0x1 -> BigEndian`. +The value of `groupPolicySeq` is incremented when creating a new group policy and is used to generate the new group policy account `Address`: +`0x21 | 0x1 -> BigEndian`. The second `0x1` corresponds to the ORM `sequenceStorageKey`. #### groupPolicyByGroupIndex -`groupPolicyByGroupIndex` allows to retrieve group policies by group id:`0x22 | BigEndian(GroupId) | PrimaryKey -> []byte()`. +`groupPolicyByGroupIndex` allows to retrieve group policies by group id: +`0x22 | BigEndian(GroupId) | PrimaryKey -> []byte()`. #### groupPolicyByAdminIndex -`groupPolicyByAdminIndex` allows to retrieve group policies by admin address:`0x23 | len([]byte(Address)) | []byte(Address) | PrimaryKey -> []byte()`. +`groupPolicyByAdminIndex` allows to retrieve group policies by admin address: +`0x23 | len([]byte(Address)) | []byte(Address) | PrimaryKey -> []byte()`. ### Proposal Table @@ -288,11 +300,13 @@ The second `0x1` corresponds to the ORM `sequenceStorageKey`. #### proposalByGroupPolicyIndex -`proposalByGroupPolicyIndex` allows to retrieve proposals by group policy account address:`0x32 | len([]byte(account.Address)) | []byte(account.Address) | BigEndian(ProposalId) -> []byte()`. +`proposalByGroupPolicyIndex` allows to retrieve proposals by group policy account address: +`0x32 | len([]byte(account.Address)) | []byte(account.Address) | BigEndian(ProposalId) -> []byte()`. #### ProposalsByVotingPeriodEndIndex -`proposalsByVotingPeriodEndIndex` allows to retrieve proposals sorted by chronological `voting_period_end`:`0x33 | sdk.FormatTimeBytes(proposal.VotingPeriodEnd) | BigEndian(ProposalId) -> []byte()`. +`proposalsByVotingPeriodEndIndex` allows to retrieve proposals sorted by chronological `voting_period_end`: +`0x33 | sdk.FormatTimeBytes(proposal.VotingPeriodEnd) | BigEndian(ProposalId) -> []byte()`. This index is used when tallying the proposal votes at the end of the voting period, and for pruning proposals at `VotingPeriodEnd + MaxExecutionPeriod`. @@ -300,15 +314,18 @@ This index is used when tallying the proposal votes at the end of the voting per The `voteTable` stores `Vote`s: `0x40 | BigEndian(ProposalId) | []byte(voter.Address) -> ProtocolBuffer(Vote)`. -The `voteTable` is a primary key table and its `PrimaryKey` is given by`BigEndian(ProposalId) | []byte(voter.Address)` which is used by the following indexes. +The `voteTable` is a primary key table and its `PrimaryKey` is given by +`BigEndian(ProposalId) | []byte(voter.Address)` which is used by the following indexes. #### voteByProposalIndex -`voteByProposalIndex` allows to retrieve votes by proposal id:`0x41 | BigEndian(ProposalId) | PrimaryKey -> []byte()`. +`voteByProposalIndex` allows to retrieve votes by proposal id: +`0x41 | BigEndian(ProposalId) | PrimaryKey -> []byte()`. #### voteByVoterIndex -`voteByVoterIndex` allows to retrieve votes by voter address:`0x42 | len([]byte(voter.Address)) | []byte(voter.Address) | PrimaryKey -> []byte()`. +`voteByVoterIndex` allows to retrieve votes by voter address: +`0x42 | len([]byte(voter.Address)) | []byte(voter.Address) | PrimaryKey -> []byte()`. ## Msg Service @@ -316,10 +333,10 @@ The `voteTable` is a primary key table and its `PrimaryKey` is given by`BigEndia A new group can be created with the `MsgCreateGroup`, which has an admin address, a list of members and some optional metadata. -The metadata has a maximum length that is chosen by the app developer, and\ +The metadata has a maximum length that is chosen by the app developer, and passed into the group keeper as a config. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L67-L80 ``` @@ -332,7 +349,7 @@ It's expected to fail if Group members can be updated with the `UpdateGroupMembers`. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L88-L102 ``` @@ -347,7 +364,7 @@ It's expected to fail if: The `UpdateGroupAdmin` can be used to update a group admin. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L107-L120 ``` @@ -357,7 +374,7 @@ It's expected to fail if the signer is not the admin of the group. The `UpdateGroupMetadata` can be used to update a group metadata. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L125-L138 ``` @@ -370,7 +387,7 @@ It's expected to fail if: A new group policy can be created with the `MsgCreateGroupPolicy`, which has an admin address, a group id, a decision policy and some optional metadata. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L147-L165 ``` @@ -384,7 +401,7 @@ It's expected to fail if: A new group with policy can be created with the `MsgCreateGroupWithPolicy`, which has an admin address, a list of members, a decision policy, a `group_policy_as_admin` field to optionally set group and group policy admin with group policy address and some optional metadata for group and group policy. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L191-L215 ``` @@ -394,7 +411,7 @@ It's expected to fail for the same reasons as `Msg/CreateGroup` and `Msg/CreateG The `UpdateGroupPolicyAdmin` can be used to update a group policy admin. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L173-L186 ``` @@ -404,7 +421,7 @@ It's expected to fail if the signer is not the admin of the group policy. The `UpdateGroupPolicyDecisionPolicy` can be used to update a decision policy. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L226-L241 ``` @@ -417,7 +434,7 @@ It's expected to fail if: The `UpdateGroupPolicyMetadata` can be used to update a group policy metadata. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L246-L259 ``` @@ -428,10 +445,10 @@ It's expected to fail if: ### Msg/SubmitProposal -A new proposal can be created with the `MsgSubmitProposal`, which has a group policy account address, a list of proposers addresses, a list of messages to execute if the proposal is accepted and some optional metadata.\ +A new proposal can be created with the `MsgSubmitProposal`, which has a group policy account address, a list of proposers addresses, a list of messages to execute if the proposal is accepted and some optional metadata. An optional `Exec` value can be provided to try to execute the proposal immediately after proposal creation. Proposers signatures are considered as yes votes in this case. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L281-L315 ``` @@ -444,7 +461,7 @@ It's expected to fail if: A proposal can be withdrawn using `MsgWithdrawProposal` which has an `address` (can be either a proposer or the group policy admin) and a `proposal_id` (which has to be withdrawn). -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L323-L333 ``` @@ -455,10 +472,10 @@ It's expected to fail if: ### Msg/Vote -A new vote can be created with the `MsgVote`, given a proposal id, a voter address, a choice (yes, no, veto or abstain) and some optional metadata.\ +A new vote can be created with the `MsgVote`, given a proposal id, a voter address, a choice (yes, no, veto or abstain) and some optional metadata. An optional `Exec` value can be provided to try to execute the proposal immediately after voting. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L338-L358 ``` @@ -471,7 +488,7 @@ It's expected to fail if: A proposal can be executed with the `MsgExec`. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L363-L373 ``` @@ -484,7 +501,7 @@ The messages that are part of this proposal won't be executed if: The `MsgLeaveGroup` allows group member to leave a group. -```go +```go reference https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/v1/tx.proto#L381-L391 ``` @@ -501,75 +518,76 @@ The group module emits the following events: | Type | Attribute Key | Attribute Value | | -------------------------------- | ------------- | -------------------------------- | -| message | action | /cosmos.group.v1.Msg/CreateGroup | -| cosmos.group.v1.EventCreateGroup | group\_id | {groupId} | +| message | action | `/cosmos.group.v1.Msg/CreateGroup` | +| cosmos.group.v1.EventCreateGroup | group_id | `{groupId}` | ### EventUpdateGroup | Type | Attribute Key | Attribute Value | | -------------------------------- | ------------- | ---------------------------------------------------------- | -| message | action | /cosmos.group.v1.Msg/UpdateGroup{Admin\|Metadata\|Members} | -| cosmos.group.v1.EventUpdateGroup | group\_id | {groupId} | +| message | action | `/cosmos.group.v1.Msg/UpdateGroup{Admin\|Metadata\|Members}` | +| cosmos.group.v1.EventUpdateGroup | group_id | `{groupId}` | ### EventCreateGroupPolicy | Type | Attribute Key | Attribute Value | | -------------------------------------- | ------------- | -------------------------------------- | -| message | action | /cosmos.group.v1.Msg/CreateGroupPolicy | -| cosmos.group.v1.EventCreateGroupPolicy | address | {groupPolicyAddress} | +| message | action | `/cosmos.group.v1.Msg/CreateGroupPolicy` | +| cosmos.group.v1.EventCreateGroupPolicy | address | `{groupPolicyAddress}` | ### EventUpdateGroupPolicy | Type | Attribute Key | Attribute Value | | -------------------------------------- | ------------- | ----------------------------------------------------------------------- | -| message | action | /cosmos.group.v1.Msg/UpdateGroupPolicy{Admin\|Metadata\|DecisionPolicy} | -| cosmos.group.v1.EventUpdateGroupPolicy | address | {groupPolicyAddress} | +| message | action | `/cosmos.group.v1.Msg/UpdateGroupPolicy{Admin\|Metadata\|DecisionPolicy}` | +| cosmos.group.v1.EventUpdateGroupPolicy | address | `{groupPolicyAddress}` | ### EventCreateProposal | Type | Attribute Key | Attribute Value | | ----------------------------------- | ------------- | ----------------------------------- | -| message | action | /cosmos.group.v1.Msg/CreateProposal | -| cosmos.group.v1.EventCreateProposal | proposal\_id | {proposalId} | +| message | action | `/cosmos.group.v1.Msg/CreateProposal` | +| cosmos.group.v1.EventCreateProposal | proposal_id | `{proposalId}` | ### EventWithdrawProposal | Type | Attribute Key | Attribute Value | | ------------------------------------- | ------------- | ------------------------------------- | -| message | action | /cosmos.group.v1.Msg/WithdrawProposal | -| cosmos.group.v1.EventWithdrawProposal | proposal\_id | {proposalId} | +| message | action | `/cosmos.group.v1.Msg/WithdrawProposal` | +| cosmos.group.v1.EventWithdrawProposal | proposal_id | `{proposalId}` | ### EventVote | Type | Attribute Key | Attribute Value | | ------------------------- | ------------- | ------------------------- | -| message | action | /cosmos.group.v1.Msg/Vote | -| cosmos.group.v1.EventVote | proposal\_id | {proposalId} | +| message | action | `/cosmos.group.v1.Msg/Vote` | +| cosmos.group.v1.EventVote | proposal_id | `{proposalId}` | ## EventExec | Type | Attribute Key | Attribute Value | | ------------------------- | ------------- | ------------------------- | -| message | action | /cosmos.group.v1.Msg/Exec | -| cosmos.group.v1.EventExec | proposal\_id | {proposalId} | -| cosmos.group.v1.EventExec | logs | {logs\_string} | +| message | action | `/cosmos.group.v1.Msg/Exec` | +| cosmos.group.v1.EventExec | proposal_id | `{proposalId}` | +| cosmos.group.v1.EventExec | logs | `{logs_string}` | ### EventLeaveGroup | Type | Attribute Key | Attribute Value | | ------------------------------- | ------------- | ------------------------------- | -| message | action | /cosmos.group.v1.Msg/LeaveGroup | -| cosmos.group.v1.EventLeaveGroup | proposal\_id | {proposalId} | -| cosmos.group.v1.EventLeaveGroup | address | {address} | +| message | action | `/cosmos.group.v1.Msg/LeaveGroup` | +| cosmos.group.v1.EventLeaveGroup | proposal_id | `{proposalId}` | +| cosmos.group.v1.EventLeaveGroup | address | `{address}` | ### EventProposalPruned | Type | Attribute Key | Attribute Value | -| ----------------------------------- | ------------- | ------------------------------- | -| message | action | /cosmos.group.v1.Msg/LeaveGroup | -| cosmos.group.v1.EventProposalPruned | proposal\_id | {proposalId} | -| cosmos.group.v1.EventProposalPruned | status | {ProposalStatus} | -| cosmos.group.v1.EventProposalPruned | tally\_result | {TallyResult} | +|-------------------------------------|---------------|---------------------------------| +| message | action | `/cosmos.group.v1.Msg/LeaveGroup` | +| cosmos.group.v1.EventProposalPruned | proposal_id | `{proposalId}` | +| cosmos.group.v1.EventProposalPruned | status | `{ProposalStatus}` | +| cosmos.group.v1.EventProposalPruned | tally_result | `{TallyResult}` | + ## Client @@ -585,7 +603,7 @@ The `query` commands allow users to query `group` state. simd query group --help ``` -**group-info** +##### group-info The `group-info` command allows users to query for group info by given group id. @@ -609,7 +627,7 @@ total_weight: "3" version: "1" ``` -**group-policy-info** +##### group-policy-info The `group-policy-info` command allows users to query for group policy info by account address of group policy . @@ -639,7 +657,7 @@ metadata: AQ== version: "1" ``` -**group-members** +##### group-members The `group-members` command allows users to query for group members by group id with pagination flags. @@ -672,7 +690,7 @@ pagination: total: "2" ``` -**groups-by-admin** +##### groups-by-admin The `groups-by-admin` command allows users to query for groups by admin account address with pagination flags. @@ -705,7 +723,7 @@ pagination: total: "2" ``` -**group-policies-by-group** +##### group-policies-by-group The `group-policies-by-group` command allows users to query for group policies by group id with pagination flags. @@ -750,7 +768,7 @@ pagination: total: "2" ``` -**group-policies-by-admin** +##### group-policies-by-admin The `group-policies-by-admin` command allows users to query for group policies by admin account address with pagination flags. @@ -795,7 +813,7 @@ pagination: total: "2" ``` -**proposal** +##### proposal The `proposal` command allows users to query for proposal by id. @@ -843,7 +861,7 @@ proposal: title: "Title" ``` -**proposals-by-group-policy** +##### proposals-by-group-policy The `proposals-by-group-policy` command allows users to query for proposals by account address of group policy with pagination flags. @@ -894,7 +912,7 @@ proposals: title: "Title" ``` -**vote** +##### vote The `vote` command allows users to query for vote by proposal id and voter account address. @@ -919,7 +937,7 @@ vote: voter: cosmos1.. ``` -**votes-by-proposal** +##### votes-by-proposal The `votes-by-proposal` command allows users to query for votes by proposal id with pagination flags. @@ -947,7 +965,7 @@ votes: voter: cosmos1.. ``` -**votes-by-voter** +##### votes-by-voter The `votes-by-voter` command allows users to query for votes by voter account address with pagination flags. @@ -985,7 +1003,7 @@ simd tx group --help #### create-group -The `create-group` command allows users to create a group which is an aggregation of member accounts with associated weights and\ +The `create-group` command allows users to create a group which is an aggregation of member accounts with associated weights and an administrator account. ```bash @@ -2095,7 +2113,7 @@ The group module has four locations for metadata where users can provide further ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [gov proposal](../gov/#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [gov proposal](../gov/README.md#metadata)) ```json { @@ -2108,14 +2126,14 @@ Location: off-chain as json object stored on IPFS (mirrors [gov proposal](../gov } ``` -:::note\ -The `authors` field is an array of strings, this is to allow for multiple authors to be listed in the metadata.\ -In v0.46, the `authors` field is a comma-separated string. Frontends are encouraged to support both formats for backwards compatibility.\ +:::note +The `authors` field is an array of strings, this is to allow for multiple authors to be listed in the metadata. +In v0.46, the `authors` field is a comma-separated string. Frontends are encouraged to support both formats for backwards compatibility. ::: ### Vote -Location: on-chain as json within 255 character limit (mirrors [gov vote](../gov/#metadata)) +Location: on-chain as json within 255 character limit (mirrors [gov vote](../gov/README.md#metadata)) ```json { diff --git a/.gitbook/developers-native/injective/evm/01_concepts.mdx b/.gitbook/developers-native/injective/evm/01_concepts.mdx index 121ecb65..80bf858e 100644 --- a/.gitbook/developers-native/injective/evm/01_concepts.mdx +++ b/.gitbook/developers-native/injective/evm/01_concepts.mdx @@ -1,7 +1,3 @@ - - # Concepts ## EVM diff --git a/.gitbook/developers-native/injective/evm/02_state.mdx b/.gitbook/developers-native/injective/evm/02_state.mdx index c3e7e2fa..7cf0d6e2 100644 --- a/.gitbook/developers-native/injective/evm/02_state.mdx +++ b/.gitbook/developers-native/injective/evm/02_state.mdx @@ -1,7 +1,3 @@ - - # State This section gives you an overview of the objects stored in the `x/evm` module state, functionalities that are derived from the go-ethereum `StateDB` interface, and its implementation through the Keeper as well as the state implementation at genesis. diff --git a/.gitbook/developers-native/injective/evm/03_state_transitions.mdx b/.gitbook/developers-native/injective/evm/03_state_transitions.mdx index b72d8fb0..fcdc9cfd 100644 --- a/.gitbook/developers-native/injective/evm/03_state_transitions.mdx +++ b/.gitbook/developers-native/injective/evm/03_state_transitions.mdx @@ -1,7 +1,3 @@ - - # State Transitions The `x/evm` module allows for users to submit Ethereum transactions (`Tx`) and execute their containing messages to evoke state transitions on the given state. diff --git a/.gitbook/developers-native/injective/evm/04_transactions.mdx b/.gitbook/developers-native/injective/evm/04_transactions.mdx index 9d9bf319..662f60b7 100644 --- a/.gitbook/developers-native/injective/evm/04_transactions.mdx +++ b/.gitbook/developers-native/injective/evm/04_transactions.mdx @@ -1,7 +1,3 @@ - - # Transactions This section defines the `sdk.Msg` concrete types that result in the state transitions defined on the previous section. diff --git a/.gitbook/developers-native/injective/evm/05_abci.mdx b/.gitbook/developers-native/injective/evm/05_abci.mdx index cd66ff28..9e1b3bf5 100644 --- a/.gitbook/developers-native/injective/evm/05_abci.mdx +++ b/.gitbook/developers-native/injective/evm/05_abci.mdx @@ -1,7 +1,3 @@ - - # ABCI The Application Blockchain Interface (ABCI) allows the application to interact with the Tendermint Consensus engine. The application maintains several separate ABCI connections with Tendermint. The most relevant for the `x/evm` is the [Consensus connection at Commit](https://docs.tendermint.com/v0.35/spec/abci/apps.html#consensus-connection). This connection is responsible for block execution and calls the fuctions `InitChain` (containing `InitGenesis`), `BeginBlock`, `DeliverTx`, `EndBlock`, `Commit` . `InitChain` is only called the first time a new blockchain is started and `DeliverTx` is called for each transaction in the block. diff --git a/.gitbook/developers-native/injective/evm/06_hooks.mdx b/.gitbook/developers-native/injective/evm/06_hooks.mdx index 5604a793..42f4edba 100644 --- a/.gitbook/developers-native/injective/evm/06_hooks.mdx +++ b/.gitbook/developers-native/injective/evm/06_hooks.mdx @@ -1,7 +1,3 @@ - - # Hooks The `x/evm` module implements an `EvmHooks` interface that extend and customize the `Tx` processing logic externally. diff --git a/.gitbook/developers-native/injective/evm/07_events.mdx b/.gitbook/developers-native/injective/evm/07_events.mdx index 8e93e3b6..b2bd4503 100644 --- a/.gitbook/developers-native/injective/evm/07_events.mdx +++ b/.gitbook/developers-native/injective/evm/07_events.mdx @@ -1,7 +1,3 @@ - - # Events The `x/evm` module emits the Cosmos SDK events after a state execution. The EVM module emits events of the relevant transaction fields, as well as the transaction logs (ethereum events). diff --git a/.gitbook/developers-native/injective/evm/08_params.mdx b/.gitbook/developers-native/injective/evm/08_params.mdx index a7afe612..36dd8d46 100644 --- a/.gitbook/developers-native/injective/evm/08_params.mdx +++ b/.gitbook/developers-native/injective/evm/08_params.mdx @@ -1,7 +1,3 @@ - - # Parameters The evm module contains the following parameters: diff --git a/.gitbook/developers-native/injective/evm/09_client.mdx b/.gitbook/developers-native/injective/evm/09_client.mdx index 7884b5e5..12f14a17 100644 --- a/.gitbook/developers-native/injective/evm/09_client.mdx +++ b/.gitbook/developers-native/injective/evm/09_client.mdx @@ -1,7 +1,3 @@ - - # Client A user can query and interact with the `evm` module using the CLI, JSON-RPC, gRPC or REST. diff --git a/.gitbook/developers.mdx b/.gitbook/developers.mdx index 8cee5bc9..f256b862 100644 --- a/.gitbook/developers.mdx +++ b/.gitbook/developers.mdx @@ -2,7 +2,6 @@ description: >- The goal of this section is to help developers build their projects on Injective -icon: laptop-code --- # Developers diff --git a/.gitbook/developers/modules/injective/evm/01_concepts.md b/.gitbook/developers/modules/injective/evm/01_concepts.md index 121ecb65..80bf858e 100644 --- a/.gitbook/developers/modules/injective/evm/01_concepts.md +++ b/.gitbook/developers/modules/injective/evm/01_concepts.md @@ -1,7 +1,3 @@ - - # Concepts ## EVM diff --git a/.gitbook/developers/modules/injective/evm/02_state.md b/.gitbook/developers/modules/injective/evm/02_state.md index c3e7e2fa..7cf0d6e2 100644 --- a/.gitbook/developers/modules/injective/evm/02_state.md +++ b/.gitbook/developers/modules/injective/evm/02_state.md @@ -1,7 +1,3 @@ - - # State This section gives you an overview of the objects stored in the `x/evm` module state, functionalities that are derived from the go-ethereum `StateDB` interface, and its implementation through the Keeper as well as the state implementation at genesis. diff --git a/.gitbook/developers/modules/injective/evm/03_state_transitions.md b/.gitbook/developers/modules/injective/evm/03_state_transitions.md index b72d8fb0..fcdc9cfd 100644 --- a/.gitbook/developers/modules/injective/evm/03_state_transitions.md +++ b/.gitbook/developers/modules/injective/evm/03_state_transitions.md @@ -1,7 +1,3 @@ - - # State Transitions The `x/evm` module allows for users to submit Ethereum transactions (`Tx`) and execute their containing messages to evoke state transitions on the given state. diff --git a/.gitbook/developers/modules/injective/evm/04_transactions.md b/.gitbook/developers/modules/injective/evm/04_transactions.md index 9d9bf319..662f60b7 100644 --- a/.gitbook/developers/modules/injective/evm/04_transactions.md +++ b/.gitbook/developers/modules/injective/evm/04_transactions.md @@ -1,7 +1,3 @@ - - # Transactions This section defines the `sdk.Msg` concrete types that result in the state transitions defined on the previous section. diff --git a/.gitbook/developers/modules/injective/evm/05_abci.md b/.gitbook/developers/modules/injective/evm/05_abci.md index cd66ff28..9e1b3bf5 100644 --- a/.gitbook/developers/modules/injective/evm/05_abci.md +++ b/.gitbook/developers/modules/injective/evm/05_abci.md @@ -1,7 +1,3 @@ - - # ABCI The Application Blockchain Interface (ABCI) allows the application to interact with the Tendermint Consensus engine. The application maintains several separate ABCI connections with Tendermint. The most relevant for the `x/evm` is the [Consensus connection at Commit](https://docs.tendermint.com/v0.35/spec/abci/apps.html#consensus-connection). This connection is responsible for block execution and calls the fuctions `InitChain` (containing `InitGenesis`), `BeginBlock`, `DeliverTx`, `EndBlock`, `Commit` . `InitChain` is only called the first time a new blockchain is started and `DeliverTx` is called for each transaction in the block. diff --git a/.gitbook/developers/modules/injective/evm/06_hooks.md b/.gitbook/developers/modules/injective/evm/06_hooks.md index 5604a793..42f4edba 100644 --- a/.gitbook/developers/modules/injective/evm/06_hooks.md +++ b/.gitbook/developers/modules/injective/evm/06_hooks.md @@ -1,7 +1,3 @@ - - # Hooks The `x/evm` module implements an `EvmHooks` interface that extend and customize the `Tx` processing logic externally. diff --git a/.gitbook/developers/modules/injective/evm/07_events.md b/.gitbook/developers/modules/injective/evm/07_events.md index 8e93e3b6..b2bd4503 100644 --- a/.gitbook/developers/modules/injective/evm/07_events.md +++ b/.gitbook/developers/modules/injective/evm/07_events.md @@ -1,7 +1,3 @@ - - # Events The `x/evm` module emits the Cosmos SDK events after a state execution. The EVM module emits events of the relevant transaction fields, as well as the transaction logs (ethereum events). diff --git a/.gitbook/developers/modules/injective/evm/08_params.md b/.gitbook/developers/modules/injective/evm/08_params.md index a7afe612..36dd8d46 100644 --- a/.gitbook/developers/modules/injective/evm/08_params.md +++ b/.gitbook/developers/modules/injective/evm/08_params.md @@ -1,7 +1,3 @@ - - # Parameters The evm module contains the following parameters: diff --git a/.gitbook/developers/modules/injective/evm/09_client.md b/.gitbook/developers/modules/injective/evm/09_client.md index 7884b5e5..12f14a17 100644 --- a/.gitbook/developers/modules/injective/evm/09_client.md +++ b/.gitbook/developers/modules/injective/evm/09_client.md @@ -1,7 +1,3 @@ - - # Client A user can query and interact with the `evm` module using the CLI, JSON-RPC, gRPC or REST. diff --git a/.gitbook/docs.json b/.gitbook/docs.json index b08b4566..cd37e250 100644 --- a/.gitbook/docs.json +++ b/.gitbook/docs.json @@ -12,12 +12,17 @@ }, "navigation": { "groups": [ - { - "group": "Injective", - "pages": [ - "README", + { + "group": "Start here", + "expanded": true, + "pages": [ + "README" + ] + }, { "group": "DeFi", + "expanded": false, + "icon": "coins", "pages": [ "defi", { @@ -98,6 +103,8 @@ }, { "group": "Infrastructure", + "expanded": false, + "icon": "network-wired", "pages": [ "infra", "infra/interact-node-command-line", @@ -156,6 +163,8 @@ }, { "group": "Developers", + "expanded": false, + "icon": "laptop-code", "pages": [ "developers", "developers/convert-addresses", @@ -219,6 +228,8 @@ }, { "group": "EVM Developers", + "expanded": false, + "icon": "rectangle-code", "pages": [ "developers-evm", "developers-evm/network-information", @@ -259,6 +270,8 @@ }, { "group": "Cosmwasm Developers", + "expanded": false, + "icon": "comet", "pages": [ "developers-cosmwasm", { @@ -283,6 +296,8 @@ }, { "group": "DeFi Developers", + "expanded": false, + "icon": "money-bill-transfer", "pages": [ "developers-defi", "developers-defi/calculate-min-price-tick-size", @@ -297,6 +312,8 @@ }, { "group": "Native Developers", + "expanded": false, + "icon": "microchip", "pages": [ "developers-native", { @@ -588,11 +605,15 @@ } ] }, - "faq", - "glossary", - "references" - ] - } + { + "group": "More", + "expanded": true, + "pages": [ + "faq", + "glossary", + "references" + ] + } ] } } \ No newline at end of file diff --git a/.gitbook/infra.mdx b/.gitbook/infra.mdx index ab6cd0fc..011a95ed 100644 --- a/.gitbook/infra.mdx +++ b/.gitbook/infra.mdx @@ -2,7 +2,6 @@ description: >- This section helps node operators and validators to run, upgrade and maintain their sentry/validator nodes. -icon: network-wired --- # Infrastructure diff --git a/scripts/copy-injective-docs.sh b/scripts/copy-injective-docs.sh new file mode 100755 index 00000000..8e613c78 --- /dev/null +++ b/scripts/copy-injective-docs.sh @@ -0,0 +1,84 @@ +#!/usr/bin/env bash +injective_core_branch=master +cosmos_sdk_branch=v0.50.x-inj +BUILD_DIR=./temp +STUB_DIR=./scripts/stub +CORE_DIR=./.gitbook/developers-native/core +INJECTIVE_DIR=./.gitbook/developers-native/injective + +mkdir -p $BUILD_DIR +rm -rf $CORE_DIR +rm -rf $INJECTIVE_DIR +mkdir -p $CORE_DIR +mkdir -p $INJECTIVE_DIR + +if [ "$GH_CORE_USER" ] && [ "$GH_CORE_TOKEN" ]; then + echo "Using GitHub credentials for cloning injective-core" + INJ_CORE_GIT_URL="https://${GH_CORE_USER}:${GH_CORE_TOKEN}@github.com/InjectiveLabs/injective-core.git" +else + echo "Using org access to clone injective-core" + INJ_CORE_GIT_URL="org-44571224@github.com:InjectiveLabs/injective-core.git" +fi +git clone "${INJ_CORE_GIT_URL}" "${BUILD_DIR}/injective-core" \ + -b "${injective_core_branch}" \ + --depth 1 \ + --single-branch > /dev/null + +echo "Cloning cosmos-sdk..." +git clone "https://github.com/InjectiveLabs/cosmos-sdk.git" "${BUILD_DIR}/cosmos-sdk" \ + -b "${cosmos_sdk_branch}" \ + --depth 1 \ + --single-branch > /dev/null + +## Generate errors docs +./$BUILD_DIR/injective-core/scripts/docs/generate_errors_docs.sh + +# copy from the cosmos-sdk repo files x/*/README.md into this repo +for D in ./$BUILD_DIR/cosmos-sdk/x/*; do + if [ -d "${D}" ]; then + mkdir -p "$CORE_DIR/$(echo $D | awk -F/ '{print $NF}')" && cp -r $D/README.md "$_" + fi +done + +# copy from the injective-core repo files injective-chain/modules/*/spec/* into this repo +for D in ./$BUILD_DIR/injective-core/injective-chain/modules/*; do + if [ -d "${D}" ]; then + mkdir -p "$INJECTIVE_DIR/$(echo $D | awk -F/ '{print $NF}')" && cp -r $D/spec/* "$_" + fi +done + +## txfees +cp $BUILD_DIR/injective-core/injective-chain/modules/txfees/README.md $INJECTIVE_DIR/txfees/README.md +## lanes +mkdir -p $INJECTIVE_DIR/lanes +cp $BUILD_DIR/injective-core/injective-chain/lanes/spec/README.md $INJECTIVE_DIR/lanes/README.md + +cp $STUB_DIR/core.modules.md.stub $CORE_DIR/README.md +cp $STUB_DIR/injective.modules.md.stub $INJECTIVE_DIR/README.md + +## 1. Manually replace wrong import paths +## authz +search1="(../modules/auth/)" +replace1="(../auth/)" + +FILES=$( find $CORE_DIR/authz -type f ) + +for file in $FILES +do + sed -ie "s/${search1//\//\\/}/${replace1//\//\\/}/g" $file +done + +## auth +search2="(../modules/authz/)" +replace2="(../authz/)" + +FILES=$( find $CORE_DIR/auth -type f ) + +for file in $FILES +do + sed -ie "s/${search2//\//\\/}/${replace2//\//\\/}/g" $file +done + +rm $CORE_DIR/authz/README.mde +rm $CORE_DIR/auth/README.mde +rm -rf $BUILD_DIR