diff --git a/cometbft/v0.38/spec/abci/Outline.mdx b/cometbft/v0.38/spec/abci/Outline.mdx index 16105925f..4d87ced05 100644 --- a/cometbft/v0.38/spec/abci/Outline.mdx +++ b/cometbft/v0.38/spec/abci/Outline.mdx @@ -65,7 +65,7 @@ The first time a new blockchain is started, CometBFT calls `InitChain`. From the state. During the execution of an instance of consensus, which decides the block for a given height, and before method `FinalizeBlock` is called, methods `PrepareProposal`, `ProcessProposal`, `ExtendVote`, and `VerifyVoteExtension` may be called several times. See -[CometBFT's expected behavior](./CometBFTs-expected-behavior.mdx) for details on the possible +[CometBFT's expected behavior](./CometBFTs-expected-behavior) for details on the possible call sequences of these methods. - [**InitChain:**](./Methods.mdx#initchain) This method initializes the blockchain. @@ -156,7 +156,7 @@ call sequences of these methods. State sync allows new nodes to rapidly bootstrap by discovering, fetching, and applying state machine (application) snapshots instead of replaying historical blocks. For more details, see the -[state sync documentation](../p2p/legacy-docs/messages/state-sync.mdx). +[state sync documentation](../p2p/legacy-docs/messages/state-sync). New nodes discover and request snapshots from other nodes in the P2P network. A CometBFT node that receives a request for snapshots from a peer will call @@ -180,7 +180,7 @@ application with `ApplySnapshotChunk`. When all chunks have been applied, the Application's `AppHash` is retrieved via an `Info` query. To ensure that the sync proceeded correctly, CometBFT compares the local Application's `AppHash` to the `AppHash` stored on the blockchain (verified via -[light client verification](../light-client/verification.mdx)). +[light client verification](../light-client/verification)). In summary: @@ -377,8 +377,8 @@ passed on to the Application through ABCI++. It is the responsibility of the Application to handle evidence of misbehavior and exercise punishment. There are two forms of evidence: Duplicate Vote and Light Client Attack. More -information can be found in either [data structures](../core/Data_structures.mdx) -or [accountability](../light-client/Accountability.mdx). +information can be found in either [data structures](../core/Data_structures) +or [accountability](../light-client/Accountability). EvidenceType has the following protobuf format: diff --git a/cometbft/v0.38/spec/core/Data_structures.mdx b/cometbft/v0.38/spec/core/Data_structures.mdx index fecff3cbd..2a277e901 100644 --- a/cometbft/v0.38/spec/core/Data_structures.mdx +++ b/cometbft/v0.38/spec/core/Data_structures.mdx @@ -123,7 +123,7 @@ the data in the current block, the previous block, and the results returned by t | Version | [Version](#version) | Version defines the application and block versions being used. | Must adhere to the validation rules of [Version](#version) | | ChainID | String | ChainID is the ID of the chain. This must be unique to your chain. | ChainID must be less than 50 bytes. | | Height | uint64 | Height is the height for this header. | Must be > 0, >= initialHeight, and == previous Height+1 | -| Time | [Time](#time) | The timestamp is equal to the weighted median of validators present in the last commit. Read more on time in the [BFT-time section](../consensus/BFT-Time.mdx). Note: the timestamp of a vote must be greater by at least one millisecond than that of the block being voted on. | Time must be >= previous header timestamp + consensus parameters TimeIotaMs. The timestamp of the first block must be equal to the genesis time (since there's no votes to compute the median). | +| Time | [Time](#time) | The timestamp is equal to the weighted median of validators present in the last commit. Read more on time in the [BFT-time section](../consensus/BFT-Time). Note: the timestamp of a vote must be greater by at least one millisecond than that of the block being voted on. | Time must be >= previous header timestamp + consensus parameters TimeIotaMs. The timestamp of the first block must be equal to the genesis time (since there's no votes to compute the median). | | LastBlockID | [BlockID](#blockid) | BlockID of the previous block. | Must adhere to the validation rules of [blockID](#blockid). The first block has `block.Header.LastBlockID == BlockID{}`. | | LastCommitHash | slice of bytes (`[]byte`) | MerkleRoot of the lastCommit's signatures. The signatures represent the validators that committed to the last block. The first block has an empty slices of bytes for the hash. | Must be of length 32 | | DataHash | slice of bytes (`[]byte`) | MerkleRoot of the hash of transactions. **Note**: The transactions are hashed before being included in the merkle tree, the leaves of the Merkle tree are the hashes, not the transactions themselves. | Must be of length 32 | @@ -373,7 +373,7 @@ EvidenceList is a simple wrapper for a list of evidence: Evidence in CometBFT is used to indicate breaches in the consensus by a validator. -More information on how evidence works in CometBFT can be found [here](../consensus/Evidence.mdx) +More information on how evidence works in CometBFT can be found [here](../consensus/Evidence) ### DuplicateVoteEvidence @@ -405,11 +405,11 @@ and Amnesia. These attacks are exhaustive. You can find a more detailed overview ## LightBlock -LightBlock is the core data structure of the [light client](../light-client/Light-Client-Specification.mdx). It combines two data structures needed for verification ([signedHeader](#signedheader) & [validatorSet](#validatorset)). +LightBlock is the core data structure of the [light client](../light-client/Light-Client-Specification). It combines two data structures needed for verification ([signedHeader](#signedheader) & [validatorSet](#validatorset)). | Name | Type | Description | Validation | |--------------|-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------| -| SignedHeader | [SignedHeader](#signedheader) | The header and commit, these are used for verification purposes. To find out more visit [light client docs](../light-client/Light-Client-Specification.mdx) | Must not be nil and adhere to the validation rules of [signedHeader](#signedheader) | +| SignedHeader | [SignedHeader](#signedheader) | The header and commit, these are used for verification purposes. To find out more visit [light client docs](../light-client/Light-Client-Specification) | Must not be nil and adhere to the validation rules of [signedHeader](#signedheader) | | ValidatorSet | [ValidatorSet](#validatorset) | The validatorSet is used to help with verify that the validators in that committed the infraction were truly in the validator set. | Must not be nil and adhere to the validation rules of [validatorSet](#validatorset) | The `SignedHeader` and `ValidatorSet` are linked by the hash of the validator set(`SignedHeader.ValidatorsHash == ValidatorSet.Hash()`. diff --git a/cometbft/v0.38/spec/light-client/verification.mdx b/cometbft/v0.38/spec/light-client/verification.mdx index 99efdb3f5..2b14be2ea 100644 --- a/cometbft/v0.38/spec/light-client/verification.mdx +++ b/cometbft/v0.38/spec/light-client/verification.mdx @@ -27,7 +27,7 @@ Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`. *Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time), -while `Header.Time` corresponds to the [BFT time](../consensus/BFT-Time.mdx). In this note, we assume that clocks of correct processes +while `Header.Time` corresponds to the [BFT time](../consensus/BFT-Time). In this note, we assume that clocks of correct processes are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`, @@ -47,7 +47,7 @@ Mechanisms like `fork accountability` and `evidence submission` are defined in t they incentivize validators to follow the protocol specification defined in this document. If they don't, and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is to *detect* these cases (after the fact), and take suitable repair actions (automatic and social). -This is discussed in document on [Fork accountability](./Accountability.mdx). +This is discussed in document on [Fork accountability](./Accountability). The term "trusted" above indicates that the correctness of the protocol depends on this assumption. It is in the responsibility of the user that runs the light client to make sure that the risk diff --git a/evm/next/api-reference/ethereum-json-rpc/index.mdx b/evm/next/api-reference/ethereum-json-rpc/index.mdx index 643cef75c..81acceaf8 100644 --- a/evm/next/api-reference/ethereum-json-rpc/index.mdx +++ b/evm/next/api-reference/ethereum-json-rpc/index.mdx @@ -37,7 +37,7 @@ More on Ethereum JSON-RPC: * All `trace_*` methods - Parity/OpenEthereum trace namespace * All `engine_*` methods - Post-merge Engine API - See the [methods page](./methods) for complete details. + See the [methods page](/evm/next/api-reference/ethereum-json-rpc/methods) for complete details. ## Enabling the JSON-RPC Server @@ -119,19 +119,19 @@ Response: ### Namespaces supported on Cosmos EVM -See the [methods](./methods) page for an exhaustive list and working examples. +See the [methods](/evm/next/api-reference/ethereum-json-rpc/methods) page for an exhaustive list and working examples. | Namespace | Description | Supported | Enabled by Default | |-----------|-------------|-----------|-------------------| -| [`eth`](./methods#eth-methods) | Core Ethereum JSON-RPC methods for interacting with the EVM | Y | Y | -| [`web3`](./methods#web3-methods) | Utility functions for the web3 client | Y | Y | -| [`net`](./methods#net-methods) | Network information about the node | Y | Y | -| [`txpool`](./methods#txpool-methods) | Transaction pool inspection | Y | N | -| [`debug`](./methods#debug-methods) | Debugging and tracing functionality | Y | N | -| [`personal`](./methods#personal-methods) | Private key management | Y | N | -| [`admin`](./methods#admin-methods) | Node administration | Y | N | -| [`miner`](./methods#miner-methods) | Mining operations (stub for PoS) | Y | N | +| [`eth`](/evm/next/api-reference/ethereum-json-rpc/methods#eth-methods) | Core Ethereum JSON-RPC methods for interacting with the EVM | Y | Y | +| [`web3`](/evm/next/api-reference/ethereum-json-rpc/methods#web3-methods) | Utility functions for the web3 client | Y | Y | +| [`net`](/evm/next/api-reference/ethereum-json-rpc/methods#net-methods) | Network information about the node | Y | Y | +| [`txpool`](/evm/next/api-reference/ethereum-json-rpc/methods#txpool-methods) | Transaction pool inspection | Y | N | +| [`debug`](/evm/next/api-reference/ethereum-json-rpc/methods#debug-methods) | Debugging and tracing functionality | Y | N | +| [`personal`](/evm/next/api-reference/ethereum-json-rpc/methods#personal-methods) | Private key management | Y | N | +| [`admin`](/evm/next/api-reference/ethereum-json-rpc/methods#admin-methods) | Node administration | Y | N | +| [`miner`](/evm/next/api-reference/ethereum-json-rpc/methods#miner-methods) | Mining operations (stub for PoS) | Y | N | | `clique` | Proof-of-Authority consensus | N | N | | `les` | Light Ethereum Subprotocol | N | N | @@ -143,7 +143,7 @@ See the [methods](./methods) page for an exhaustive list and working examples. ### Filters[​](#filters "Direct link to Filters") -Cosmos EVM also supports the Ethereum [JSON-RPC](./methods) filters calls to subscribe to [state logs](https://eth.wiki/json-rpc/API#eth_newfilter), [blocks](https://eth.wiki/json-rpc/API#eth_newblockfilter) or [pending transactions](https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter) changes. +Cosmos EVM also supports the Ethereum [JSON-RPC](/evm/next/api-reference/ethereum-json-rpc/methods) filters calls to subscribe to [state logs](https://eth.wiki/json-rpc/API#eth_newfilter), [blocks](https://eth.wiki/json-rpc/API#eth_newblockfilter) or [pending transactions](https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter) changes. Under the hood, it uses the CometBFT RPC client's event system to process subscriptions that are then formatted to Ethereum-compatible events. @@ -258,11 +258,11 @@ Examples: Several methods that query the state of the EVM accept a default block parameter. This allows you to specify the block height at which to perform the query. Methods supporting block parameter: -* [`eth_getBalance`](./methods#eth_getbalance) -* [`eth_getCode`](./methods#eth_getcode) -* [`eth_getTransactionCount`](./methods#eth_gettransactioncount) -* [`eth_getStorageAt`](./methods#eth_getstorageat) -* [`eth_call`](./methods#eth_call) +* [`eth_getBalance`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_getbalance) +* [`eth_getCode`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_getcode) +* [`eth_getTransactionCount`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_gettransactioncount) +* [`eth_getStorageAt`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_getstorageat) +* [`eth_call`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_call) The possible values for the `defaultBlock` parameter: * **Hex String** - A specific block number (e.g., `0xC9B3C0`) diff --git a/evm/next/documentation/concepts/pending-state.mdx b/evm/next/documentation/concepts/pending-state.mdx index 5100089a9..b50b7d380 100644 --- a/evm/next/documentation/concepts/pending-state.mdx +++ b/evm/next/documentation/concepts/pending-state.mdx @@ -148,4 +148,4 @@ const fasterTx = await wallet.sendTransaction({ For a detailed understanding of how the pending state is managed: - See [Mempool Architecture](/evm/next/documentation/concepts/mempool#architecture) for the two-tier system design - Review [Transaction Flow](/evm/next/documentation/concepts/mempool#transaction-flow) for state transitions -- Check [Integration Guide](/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx) for implementation details \ No newline at end of file +- Check [Integration Guide](/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration) for implementation details \ No newline at end of file diff --git a/evm/next/documentation/concepts/predeployed-contracts.mdx b/evm/next/documentation/concepts/predeployed-contracts.mdx index 4e41f6753..ae013dc3a 100644 --- a/evm/next/documentation/concepts/predeployed-contracts.mdx +++ b/evm/next/documentation/concepts/predeployed-contracts.mdx @@ -106,7 +106,7 @@ For comprehensive information on each contract including usage examples and inte ## Related Concepts - [Precompiles](/evm/next/documentation/smart-contracts/precompiles/overview) - Native chain implementations exposed as smart contracts -- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls +- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls - [Building Your Chain](/evm/next/documentation/getting-started/build-a-chain/overview) - Complete guide to chain setup ## Implementation Guides diff --git a/evm/next/documentation/concepts/replay-protection.mdx b/evm/next/documentation/concepts/replay-protection.mdx index 1d5c56017..9e0cf3aad 100644 --- a/evm/next/documentation/concepts/replay-protection.mdx +++ b/evm/next/documentation/concepts/replay-protection.mdx @@ -162,4 +162,4 @@ grep allow-unprotected-txs $HOME/.evmd/config/config.toml - [EIP-155 Specification](https://eips.ethereum.org/EIPS/eip-155) - [Chain ID Configuration](/evm/next/documentation/concepts/chain-id) - [Transaction Types](/evm/next/documentation/concepts/transactions#ethereum-tx-type) -- [EVM Module Parameters](evm/next/documentation/cosmos-sdk/modules/vm#parameters) \ No newline at end of file +- [EVM Module Parameters](/evm/next/documentation/cosmos-sdk/modules/vm#parameters) \ No newline at end of file diff --git a/evm/next/documentation/cosmos-sdk/modules/erc20.mdx b/evm/next/documentation/cosmos-sdk/modules/erc20.mdx index 13afd1acc..a90bfcf81 100644 --- a/evm/next/documentation/cosmos-sdk/modules/erc20.mdx +++ b/evm/next/documentation/cosmos-sdk/modules/erc20.mdx @@ -523,7 +523,7 @@ evmd tx erc20 register-coin --from mykey ## Related Documentation - [Building Your Chain Guide](/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration +- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration - [IBC Module](/evm/next/documentation/cosmos-sdk/modules/ibc) - IBC token handling --- diff --git a/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx b/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx index c49ea14cf..d4c099388 100644 --- a/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx +++ b/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx @@ -848,7 +848,7 @@ evmd tx gov submit-proposal param-change proposal.json --from validator --chain- ## Related Documentation - [Building Your Chain Guide](/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration +- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration - [EIP-1559 Specification](https://eips.ethereum.org/EIPS/eip-1559) - Original Ethereum proposal --- diff --git a/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx b/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx index 0a4b6f69d..df75867cd 100644 --- a/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx +++ b/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx @@ -641,7 +641,7 @@ REMAINDER=$(evmd query precisebank remainder -o json | jq -r '.remainder') ## Related Documentation - [Building Your Chain Guide](/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup +- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup - [ERC20 Module](/evm/next/documentation/cosmos-sdk/modules/erc20) - Token pair configuration --- diff --git a/evm/next/documentation/cosmos-sdk/protocol.mdx b/evm/next/documentation/cosmos-sdk/protocol.mdx index f3ec61f79..95561b8c8 100644 --- a/evm/next/documentation/cosmos-sdk/protocol.mdx +++ b/evm/next/documentation/cosmos-sdk/protocol.mdx @@ -35,7 +35,7 @@ Cosmos EVM enables EVM compatibility by implementing various components that tog * `StateDB` interface for state updates and queries * [JSON-RPC](/evm/next/api-reference/ethereum-json-rpc) client for interacting with the EVM -Most components are implemented in the [VM module](evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module. +Most components are implemented in the [VM module](/evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module. To learn more about how Cosmos EVM achieves EVM compatibility as a Cosmos chain, explore the following concepts: diff --git a/evm/next/documentation/evm-compatibility/overview.mdx b/evm/next/documentation/evm-compatibility/overview.mdx index 1a69ec1bc..677735ea6 100644 --- a/evm/next/documentation/evm-compatibility/overview.mdx +++ b/evm/next/documentation/evm-compatibility/overview.mdx @@ -223,7 +223,7 @@ Key breaking changes when migrating: ## Resources - + Add EVM support to your Cosmos chain diff --git a/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx b/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx index 1d048f3e2..22fe6e7d3 100644 --- a/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx +++ b/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx @@ -397,5 +397,5 @@ Use the [txpool RPC methods](/evm/next/api-reference/ethereum-json-rpc/methods#t ## Related Documentation - [Mempool Concepts](/evm/next/documentation/concepts/mempool) - Understanding mempool behavior and design -- [EVM Module Integration](/evm/next/documentation/getting-started/build-a-chain/overview.mdx) - Prerequisites for mempool integration +- [EVM Module Integration](/evm/next/documentation/getting-started/build-a-chain/overview) - Prerequisites for mempool integration - [JSON-RPC Methods](/evm/next/api-reference/ethereum-json-rpc/methods#txpool-methods) - Mempool query methods diff --git a/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx b/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx index b3d3b7655..7b8f53087 100644 --- a/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx +++ b/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx @@ -365,4 +365,4 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) - [Safe Contracts](https://github.com/safe-global/safe-contracts) - Safe multisig implementation ### Cosmos EVM Resources -- [VM Module Reference](evm/next/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration \ No newline at end of file +- [VM Module Reference](/evm/next/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration \ No newline at end of file diff --git a/evm/next/documentation/getting-started/tooling-and-resources/development-environment.mdx b/evm/next/documentation/getting-started/tooling-and-resources/development-environment.mdx index 0183dfd6d..1fccb7a20 100644 --- a/evm/next/documentation/getting-started/tooling-and-resources/development-environment.mdx +++ b/evm/next/documentation/getting-started/tooling-and-resources/development-environment.mdx @@ -10,7 +10,7 @@ Each person has their own preference and different tasks or scopes of work may c [Remix](https://remix.ethereum.org) is a full-feature IDE in a web-app supporting all EVM compatible networks out of the box. A convenient option For quick testing, or as a self-contained smart contract depoyment interface. -[Read more..](/evm/next/documentation/getting-started/tooling-and-resources/remix.mdx) +[Read more..](/evm/next/documentation/getting-started/tooling-and-resources/remix) diff --git a/evm/v0.4.x/documentation/getting-started/development-environment.mdx b/evm/v0.4.x/documentation/getting-started/development-environment.mdx index f6086646d..baff652b3 100644 --- a/evm/v0.4.x/documentation/getting-started/development-environment.mdx +++ b/evm/v0.4.x/documentation/getting-started/development-environment.mdx @@ -10,7 +10,7 @@ Each person has their own preference and different tasks or scopes of work may c [Remix](https://remix.org) is a full-feature IDE in a web-app supporting all EVM compatible networks out of the box. A convenient option For quick testing, or as a self-contained smart contract depoyment interface. -[Read more..](/evm/v0.4.x/documentation/getting-started/tooling-and-resources/remix.mdx) +[Read more..](/evm/v0.4.x/documentation/getting-started/tooling-and-resources/remix) diff --git a/evm/v0.5.0/api-reference/ethereum-json-rpc/index.mdx b/evm/v0.5.0/api-reference/ethereum-json-rpc/index.mdx index 5406b594b..ce54e049f 100644 --- a/evm/v0.5.0/api-reference/ethereum-json-rpc/index.mdx +++ b/evm/v0.5.0/api-reference/ethereum-json-rpc/index.mdx @@ -37,7 +37,7 @@ More on Ethereum JSON-RPC: * All `trace_*` methods - Parity/OpenEthereum trace namespace * All `engine_*` methods - Post-merge Engine API - See the [methods page](./methods) for complete details. + See the [methods page](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods) for complete details. ## Enabling the JSON-RPC Server @@ -119,19 +119,19 @@ Response: ### Namespaces supported on Cosmos EVM -See the [methods](./methods) page for an exhaustive list and working examples. +See the [methods](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods) page for an exhaustive list and working examples. | Namespace | Description | Supported | Enabled by Default | |-----------|-------------|-----------|-------------------| -| [`eth`](./methods#eth-methods) | Core Ethereum JSON-RPC methods for interacting with the EVM | Y | Y | -| [`web3`](./methods#web3-methods) | Utility functions for the web3 client | Y | Y | -| [`net`](./methods#net-methods) | Network information about the node | Y | Y | -| [`txpool`](./methods#txpool-methods) | Transaction pool inspection | Y | N | -| [`debug`](./methods#debug-methods) | Debugging and tracing functionality | Y | N | -| [`personal`](./methods#personal-methods) | Private key management | Y | N | -| [`admin`](./methods#admin-methods) | Node administration | Y | N | -| [`miner`](./methods#miner-methods) | Mining operations (stub for PoS) | Y | N | +| [`eth`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#eth-methods) | Core Ethereum JSON-RPC methods for interacting with the EVM | Y | Y | +| [`web3`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#web3-methods) | Utility functions for the web3 client | Y | Y | +| [`net`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#net-methods) | Network information about the node | Y | Y | +| [`txpool`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#txpool-methods) | Transaction pool inspection | Y | N | +| [`debug`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#debug-methods) | Debugging and tracing functionality | Y | N | +| [`personal`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#personal-methods) | Private key management | Y | N | +| [`admin`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#admin-methods) | Node administration | Y | N | +| [`miner`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#miner-methods) | Mining operations (stub for PoS) | Y | N | | `clique` | Proof-of-Authority consensus | N | N | | `les` | Light Ethereum Subprotocol | N | N | @@ -143,7 +143,7 @@ See the [methods](./methods) page for an exhaustive list and working examples. ### Filters[​](#filters "Direct link to Filters") -Cosmos EVM also supports the Ethereum [JSON-RPC](./methods) filters calls to subscribe to [state logs](https://eth.wiki/json-rpc/API#eth_newfilter), [blocks](https://eth.wiki/json-rpc/API#eth_newblockfilter) or [pending transactions](https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter) changes. +Cosmos EVM also supports the Ethereum [JSON-RPC](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods) filters calls to subscribe to [state logs](https://eth.wiki/json-rpc/API#eth_newfilter), [blocks](https://eth.wiki/json-rpc/API#eth_newblockfilter) or [pending transactions](https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter) changes. Under the hood, it uses the CometBFT RPC client's event system to process subscriptions that are then formatted to Ethereum-compatible events. @@ -258,11 +258,11 @@ Examples: Several methods that query the state of the EVM accept a default block parameter. This allows you to specify the block height at which to perform the query. Methods supporting block parameter: -* [`eth_getBalance`](./methods#eth_getbalance) -* [`eth_getCode`](./methods#eth_getcode) -* [`eth_getTransactionCount`](./methods#eth_gettransactioncount) -* [`eth_getStorageAt`](./methods#eth_getstorageat) -* [`eth_call`](./methods#eth_call) +* [`eth_getBalance`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#eth_getbalance) +* [`eth_getCode`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#eth_getcode) +* [`eth_getTransactionCount`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#eth_gettransactioncount) +* [`eth_getStorageAt`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#eth_getstorageat) +* [`eth_call`](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#eth_call) The possible values for the `defaultBlock` parameter: * **Hex String** - A specific block number (e.g., `0xC9B3C0`) diff --git a/evm/v0.5.0/documentation/concepts/mempool.mdx b/evm/v0.5.0/documentation/concepts/mempool.mdx index 98de3f3d0..bd51a913e 100644 --- a/evm/v0.5.0/documentation/concepts/mempool.mdx +++ b/evm/v0.5.0/documentation/concepts/mempool.mdx @@ -182,7 +182,7 @@ You can also explore these methods interactively using the [RPC Explorer](/evm/v ## Integration -For chain developers looking to integrate the mempool into their Cosmos SDK chain, see the [EVM Mempool Integration Guide](/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx) for complete setup instructions. +For chain developers looking to integrate the mempool into their Cosmos SDK chain, see the [EVM Mempool Integration Guide](/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration) for complete setup instructions. ## Configuration @@ -531,4 +531,4 @@ The mempool behavior can be verified using the test scripts provided in the [cos ## Integration -For step-by-step instructions on integrating the EVM mempool into your chain, see the [EVM Mempool Integration](/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx) guide. +For step-by-step instructions on integrating the EVM mempool into your chain, see the [EVM Mempool Integration](/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration) guide. diff --git a/evm/v0.5.0/documentation/concepts/pending-state.mdx b/evm/v0.5.0/documentation/concepts/pending-state.mdx index 587dea3ac..239a32201 100644 --- a/evm/v0.5.0/documentation/concepts/pending-state.mdx +++ b/evm/v0.5.0/documentation/concepts/pending-state.mdx @@ -148,4 +148,4 @@ const fasterTx = await wallet.sendTransaction({ For a detailed understanding of how the pending state is managed: - See [Mempool Architecture](/evm/v0.5.0/documentation/concepts/mempool#architecture) for the two-tier system design - Review [Transaction Flow](/evm/v0.5.0/documentation/concepts/mempool#transaction-flow) for state transitions -- Check [Integration Guide](/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx) for implementation details \ No newline at end of file +- Check [Integration Guide](/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration) for implementation details \ No newline at end of file diff --git a/evm/v0.5.0/documentation/evm-compatibility/overview.mdx b/evm/v0.5.0/documentation/evm-compatibility/overview.mdx index 9dcd630f5..c9966cab0 100644 --- a/evm/v0.5.0/documentation/evm-compatibility/overview.mdx +++ b/evm/v0.5.0/documentation/evm-compatibility/overview.mdx @@ -223,7 +223,7 @@ Key breaking changes when migrating: ## Resources - + Add EVM support to your Cosmos chain diff --git a/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx b/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx index 0d1c53bbf..e8d2ac671 100644 --- a/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx +++ b/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx @@ -397,5 +397,5 @@ Use the [txpool RPC methods](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods ## Related Documentation - [Mempool Concepts](/evm/v0.5.0/documentation/concepts/mempool) - Understanding mempool behavior and design -- [EVM Module Integration](/evm/v0.5.0/documentation/getting-started/build-a-chain/overview.mdx) - Prerequisites for mempool integration +- [EVM Module Integration](/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Prerequisites for mempool integration - [JSON-RPC Methods](/evm/v0.5.0/api-reference/ethereum-json-rpc/methods#txpool-methods) - Mempool query methods diff --git a/evm/v0.5.0/documentation/getting-started/tooling-and-resources/development-environment.mdx b/evm/v0.5.0/documentation/getting-started/tooling-and-resources/development-environment.mdx index 2267152b3..77d60b650 100644 --- a/evm/v0.5.0/documentation/getting-started/tooling-and-resources/development-environment.mdx +++ b/evm/v0.5.0/documentation/getting-started/tooling-and-resources/development-environment.mdx @@ -10,7 +10,7 @@ Each person has their own preference and different tasks or scopes of work may c [Remix](https://remix.org) is a full-feature IDE in a web-app supporting all EVM compatible networks out of the box. A convenient option For quick testing, or as a self-contained smart contract depoyment interface. -[Read more..](/evm/v0.5.0/documentation/getting-started/tooling-and-resources/remix.mdx) +[Read more..](/evm/v0.5.0/documentation/getting-started/tooling-and-resources/remix) diff --git a/ibc/v8.5.x/ibc/middleware/overview.mdx b/ibc/v8.5.x/ibc/middleware/overview.mdx index 338d44777..d88ff11d6 100644 --- a/ibc/v8.5.x/ibc/middleware/overview.mdx +++ b/ibc/v8.5.x/ibc/middleware/overview.mdx @@ -17,7 +17,7 @@ After going through the overview they can consult respectively: ## Pre-requisite readings -- [IBC Overview](ibc/v8.5.x/ibc/overview) +- [IBC Overview](/ibc/v8.5.x/ibc/overview) - [IBC Integration](/ibc/v8.5.x/light-clients/wasm/integration) - [IBC Application Developer Guide](/ibc/v8.5.x/ibc/apps/apps) diff --git a/sdk/v0.47/learn/advanced/cli.mdx b/sdk/v0.47/learn/advanced/cli.mdx index 5102c8ede..f3b6a5150 100644 --- a/sdk/v0.47/learn/advanced/cli.mdx +++ b/sdk/v0.47/learn/advanced/cli.mdx @@ -23,7 +23,7 @@ The first four strings specify the command: * The root command for the entire application `simd`. * The subcommand `tx`, which contains all commands that let users create transactions. -* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/sdk/v0.47/build/modules/bank/README.mdx) module in this case). +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/sdk/v0.47/build/modules/bank/README) module in this case). * The type of transaction `send`. The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). diff --git a/sdk/v0.47/learn/advanced/events.mdx b/sdk/v0.47/learn/advanced/events.mdx index 20cbe745c..36d927629 100644 --- a/sdk/v0.47/learn/advanced/events.mdx +++ b/sdk/v0.47/learn/advanced/events.mdx @@ -59,7 +59,7 @@ The following examples show how to query Events using the Cosmos SDK. | `tx.height=23` | Query all transactions at height 23 | | `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/sdk/v0.47/build/building-modules/msg-services). Note the `'`s around the value. | | `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | -| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/sdk/v0.47/build/modules/staking/README.mdx). | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/sdk/v0.47/build/modules/staking/README). | ## EventManager diff --git a/sdk/v0.47/learn/beginner/query-lifecycle.mdx b/sdk/v0.47/learn/beginner/query-lifecycle.mdx index b6ba4a358..b4c0e169a 100644 --- a/sdk/v0.47/learn/beginner/query-lifecycle.mdx +++ b/sdk/v0.47/learn/beginner/query-lifecycle.mdx @@ -18,7 +18,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr A [**query**](/sdk/v0.47/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/sdk/v0.47/learn/advanced/transactions) (view the lifecycle [here](/sdk/v0.47/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/sdk/v0.47/build/modules/staking/README.mdx) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/sdk/v0.47/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -28,7 +28,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](/sdk/v0.47/build/modules/staking/README.mdx) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](/sdk/v0.47/build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: diff --git a/sdk/v0.50/build/packages.mdx b/sdk/v0.50/build/packages.mdx index d99783fb4..37655f1b5 100644 --- a/sdk/v0.50/build/packages.mdx +++ b/sdk/v0.50/build/packages.mdx @@ -18,7 +18,7 @@ The Cosmos SDK is a collection of Go modules. This section provides documentatio ## State Management[​](#state-management "Direct link to State Management") * [Collections](/sdk/v0.50/build/packages/collections) - State management library -* [ORM](sdk/v0.50/build/packages/README#orm) - State management library +* [ORM](/sdk/v0.50/build/packages/README#orm) - State management library ## Automation[​](#automation "Direct link to Automation") diff --git a/sdk/v0.50/changelog/release-notes.mdx b/sdk/v0.50/changelog/release-notes.mdx index 399a732b2..6dc391dc4 100644 --- a/sdk/v0.50/changelog/release-notes.mdx +++ b/sdk/v0.50/changelog/release-notes.mdx @@ -243,7 +243,7 @@ mode: "wide" - [#14860](https://github.com/cosmos/cosmos-sdk/pull/14860) (core) Add `Precommit` and `PrepareCheckState` AppModule callbacks. - [#14720](https://github.com/cosmos/cosmos-sdk/pull/14720) (x/gov) Upstream expedited proposals from Osmosis. - [#14659](https://github.com/cosmos/cosmos-sdk/pull/14659) (cli) Added ability to query blocks by events with queries directly passed to Tendermint, which will allow for full query operator support, e.g. `>`. -- [#14650](https://github.com/cosmos/cosmos-sdk/pull/14650) (x/auth) Add Textual SignModeHandler. Enable `SIGN_MODE_TEXTUAL` by following the [upgrading guide](../build/migrations/upgrading.mdx) instructions. +- [#14650](https://github.com/cosmos/cosmos-sdk/pull/14650) (x/auth) Add Textual SignModeHandler. Enable `SIGN_MODE_TEXTUAL` by following the [upgrading guide](../build/migrations/upgrading) instructions. - [#14588](https://github.com/cosmos/cosmos-sdk/pull/14588) (x/crisis) Use CacheContext() in AssertInvariants(). - [#14484](https://github.com/cosmos/cosmos-sdk/pull/14484) (mempool) Add priority nonce mempool option for transaction replacement. - [#14468](https://github.com/cosmos/cosmos-sdk/pull/14468) (query) Implement pagination for collections. diff --git a/sdk/v0.50/learn/advanced/cli.mdx b/sdk/v0.50/learn/advanced/cli.mdx index e72be2a34..4fb39ab6f 100644 --- a/sdk/v0.50/learn/advanced/cli.mdx +++ b/sdk/v0.50/learn/advanced/cli.mdx @@ -23,7 +23,7 @@ The first four strings specify the command: * The root command for the entire application `simd`. * The subcommand `tx`, which contains all commands that let users create transactions. -* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/sdk/v0.50/build/modules/bank/README.mdx) module in this case). +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/sdk/v0.50/build/modules/bank/README) module in this case). * The type of transaction `send`. The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). diff --git a/sdk/v0.50/learn/advanced/events.mdx b/sdk/v0.50/learn/advanced/events.mdx index cc5a53122..ad2717af3 100644 --- a/sdk/v0.50/learn/advanced/events.mdx +++ b/sdk/v0.50/learn/advanced/events.mdx @@ -58,7 +58,7 @@ The following examples show how to query Events using the Cosmos SDK. | `tx.height=23` | Query all transactions at height 23 | | `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/sdk/v0.50/build/building-modules/msg-services). Note the `'`s around the value. | | `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | -| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/sdk/v0.50/build/modules/staking/README.mdx). | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/sdk/v0.50/build/modules/staking/README). | ## EventManager diff --git a/sdk/v0.50/learn/beginner/query-lifecycle.mdx b/sdk/v0.50/learn/beginner/query-lifecycle.mdx index 68e3de30e..99fc041b1 100644 --- a/sdk/v0.50/learn/beginner/query-lifecycle.mdx +++ b/sdk/v0.50/learn/beginner/query-lifecycle.mdx @@ -17,7 +17,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr A [**query**](/sdk/v0.50/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/sdk/v0.50/learn/advanced/transactions) (view the lifecycle [here](/sdk/v0.50/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/sdk/v0.50/build/modules/staking/README.mdx) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/sdk/v0.50/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -27,7 +27,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](/sdk/v0.50/build/modules/staking/README.mdx) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](/sdk/v0.50/build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: diff --git a/sdk/v0.53/learn/advanced/cli.mdx b/sdk/v0.53/learn/advanced/cli.mdx index 7fbe1b119..cf33f572e 100644 --- a/sdk/v0.53/learn/advanced/cli.mdx +++ b/sdk/v0.53/learn/advanced/cli.mdx @@ -23,7 +23,7 @@ The first four strings specify the command: * The root command for the entire application `simd`. * The subcommand `tx`, which contains all commands that let users create transactions. -* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/sdk/v0.53/build/modules/bank/README.mdx) module in this case). +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/sdk/v0.53/build/modules/bank/README) module in this case). * The type of transaction `send`. The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). diff --git a/sdk/v0.53/learn/advanced/events.mdx b/sdk/v0.53/learn/advanced/events.mdx index 728685980..13ba24fac 100644 --- a/sdk/v0.53/learn/advanced/events.mdx +++ b/sdk/v0.53/learn/advanced/events.mdx @@ -59,7 +59,7 @@ The following examples show how to query Events using the Cosmos SDK. | `tx.height=23` | Query all transactions at height 23 | | `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing an x/bank `Send` [Service `Msg`](/sdk/v0.53/build/building-modules/msg-services). Note the `'`s around the value. | | `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | -| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/sdk/v0.53/build/modules/staking/README.mdx). | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/sdk/v0.53/build/modules/staking/README). | ## EventManager diff --git a/sdk/v0.53/learn/beginner/query-lifecycle.mdx b/sdk/v0.53/learn/beginner/query-lifecycle.mdx index 2841aa59a..73a9d91b8 100644 --- a/sdk/v0.53/learn/beginner/query-lifecycle.mdx +++ b/sdk/v0.53/learn/beginner/query-lifecycle.mdx @@ -17,7 +17,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr A [**query**](/sdk/v0.53/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/sdk/v0.53/learn/advanced/transactions) (view the lifecycle [here](/sdk/v0.53/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say `MyQuery` is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As expected, the [`staking`](/sdk/v0.53/build/modules/staking/README.mdx) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say `MyQuery` is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As expected, the [`staking`](/sdk/v0.53/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -27,7 +27,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](/sdk/v0.53/build/modules/staking/README.mdx) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](/sdk/v0.53/build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: