From 20728b1be56d192899795766a8eef9c4328d8dfe Mon Sep 17 00:00:00 2001 From: Evan <87997759+evanorti@users.noreply.github.com> Date: Fri, 20 Feb 2026 13:42:32 -0500 Subject: [PATCH 1/2] fix links --- cometbft/v0.37/docs/guides/go-built-in.mdx | 2 +- .../v0.37/spec/abci/abci++_client_server.mdx | 3 +- .../docs/app-dev/Indexing-Transactions.mdx | 2 +- cometbft/v0.38/docs/core/RPC.mdx | 2 +- .../v0.38/docs/core/Running-in-production.mdx | 2 +- cometbft/v0.38/docs/core/mempool.mdx | 4 +- .../Creating-a-built-in-application-in-Go.mdx | 2 +- .../v0.38/spec/abci/Client-and-server.mdx | 5 +- cometbft/v0.38/spec/abci/Methods.mdx | 10 ++-- cometbft/v0.38/spec/abci/Outline.mdx | 46 +++++++++---------- .../abci/Requirements-for-the-Application.mdx | 8 ++-- .../Byzantine-Consensus-Algorithm.mdx | 6 +-- cometbft/v0.38/spec/core/Data_structures.mdx | 20 ++++---- .../v0.38/spec/light-client/verification.mdx | 4 +- .../spec/p2p/reactor-api/API-for-Reactors.mdx | 8 ++-- .../interoperability/deployment.mdx | 2 +- .../custom-improvement-proposals.mdx | 3 -- .../smart-contracts/precompiles/overview.mdx | 1 - .../documentation/concepts/accounts.mdx | 2 +- .../custom-improvement-proposals.mdx | 3 -- .../smart-contracts/precompiles/p256.mdx | 1 - .../implementation-guide.mdx | 2 +- .../predeployed-contracts/permit2.mdx | 2 +- .../documentation/concepts/accounts.mdx | 2 +- .../custom-improvement-proposals.mdx | 3 -- .../predeployed-contracts.mdx | 2 +- .../smart-contracts/precompiles/overview.mdx | 1 - .../predeployed-contracts/permit2.mdx | 2 +- hub/v25/hub-tutorials/join-testnet.mdx | 4 +- hub/v25/index.mdx | 5 -- sdk/v0.53/build/tooling/cosmovisor.mdx | 2 +- sdk/v0.53/security/bug-bounty.mdx | 3 +- skip-go/widget/configuration.mdx | 2 +- 33 files changed, 73 insertions(+), 93 deletions(-) diff --git a/cometbft/v0.37/docs/guides/go-built-in.mdx b/cometbft/v0.37/docs/guides/go-built-in.mdx index f45e39cda..c59a1e127 100644 --- a/cometbft/v0.37/docs/guides/go-built-in.mdx +++ b/cometbft/v0.37/docs/guides/go-built-in.mdx @@ -639,7 +639,7 @@ Next, we initialize the Badger database and create an app instance. We use `FilePV`, which is a private validator (i.e. thing which signs consensus messages). Normally, you would use `SignerRemote` to connect to an external -[HSM](https://kb.certus.one/hsm.html). +[HSM](https://pkg.go.dev/github.com/certusone/yubihsm-go). ```go pv := privval.LoadFilePV( diff --git a/cometbft/v0.37/spec/abci/abci++_client_server.mdx b/cometbft/v0.37/spec/abci/abci++_client_server.mdx index 5b340e261..10009a2e5 100644 --- a/cometbft/v0.37/spec/abci/abci++_client_server.mdx +++ b/cometbft/v0.37/spec/abci/abci++_client_server.mdx @@ -40,8 +40,7 @@ the `--abci` flag appropriately. See examples, in various stages of maintenance, in [Go](https://github.com/cometbft/cometbft/tree/v0.37.x/abci/server), -[JavaScript](https://github.com/tendermint/js-abci), -[C++](https://github.com/mdyring/cpp-tmsp), and +[JavaScript](https://github.com/tendermint/js-abci), and [Java](https://github.com/jTendermint/jabci). ### In Process diff --git a/cometbft/v0.38/docs/app-dev/Indexing-Transactions.mdx b/cometbft/v0.38/docs/app-dev/Indexing-Transactions.mdx index a08da40ce..df524b8ad 100644 --- a/cometbft/v0.38/docs/app-dev/Indexing-Transactions.mdx +++ b/cometbft/v0.38/docs/app-dev/Indexing-Transactions.mdx @@ -301,4 +301,4 @@ digit, as well as the following characters: `.` (dot), `-` (dash), `_` ^[\w]+[\.-\w]?$ ``` -[abci-events]: ../spec/abci/abci++_basic_concepts.md#events +[abci-events]: /cometbft/v0.38/spec/abci/abci++_basic_concepts#events diff --git a/cometbft/v0.38/docs/core/RPC.mdx b/cometbft/v0.38/docs/core/RPC.mdx index 9819f61b3..f922cda3e 100644 --- a/cometbft/v0.38/docs/core/RPC.mdx +++ b/cometbft/v0.38/docs/core/RPC.mdx @@ -47,4 +47,4 @@ cors_allowed_origins = [] max_open_connections = 900 ``` -See the [Configuration](./configuration) page for more details on RPC configuration options. +See the [Configuration](/cometbft/v0.38/docs/core/configuration) page for more details on RPC configuration options. diff --git a/cometbft/v0.38/docs/core/Running-in-production.mdx b/cometbft/v0.38/docs/core/Running-in-production.mdx index 64850eb93..99e659ae1 100644 --- a/cometbft/v0.38/docs/core/Running-in-production.mdx +++ b/cometbft/v0.38/docs/core/Running-in-production.mdx @@ -383,7 +383,7 @@ give you a limited number of file descriptors. If you want to accept a greater number of connections, you will need to increase these limits. -[Sysctls to tune the system to be able to open more connections](https://github.com/satori-com/tcpkali/blob/master/doc/tcpkali.man.md#sysctls-to-tune-the-system-to-be-able-to-open-more-connections) +[Sysctls to tune the system to be able to open more connections](https://github.com/satori-com/tcpkali/blob/main/doc/tcpkali.man.md#sysctls-to-tune-the-system-to-be-able-to-open-more-connections) The process file limits must also be increased, e.g. via `ulimit -n 8192`. diff --git a/cometbft/v0.38/docs/core/mempool.mdx b/cometbft/v0.38/docs/core/mempool.mdx index d873b97ba..7e1f7c759 100644 --- a/cometbft/v0.38/docs/core/mempool.mdx +++ b/cometbft/v0.38/docs/core/mempool.mdx @@ -98,5 +98,5 @@ The ABCI application becomes responsible for storing, disseminating, and proposing transactions using [`PrepareProposal`][2]. The concrete design is up to the ABCI application developers. -[1]: ../../spec/abci/abci++_methods.md#checktx -[2]: ../../spec/abci/abci++_methods.md#prepareproposal +[1]: /cometbft/v0.38/spec/abci/abci++_methods#checktx +[2]: /cometbft/v0.38/spec/abci/abci++_methods#prepareproposal diff --git a/cometbft/v0.38/docs/guides/Creating-a-built-in-application-in-Go.mdx b/cometbft/v0.38/docs/guides/Creating-a-built-in-application-in-Go.mdx index e041735a5..b40811a87 100644 --- a/cometbft/v0.38/docs/guides/Creating-a-built-in-application-in-Go.mdx +++ b/cometbft/v0.38/docs/guides/Creating-a-built-in-application-in-Go.mdx @@ -641,7 +641,7 @@ app := NewKVStoreApplication(db) We use `FilePV`, which is a private validator (i.e., a thing which signs consensus messages). Normally, you would use `SignerRemote` to connect to an external -[HSM](https://kb.certus.one/hsm.html). +[HSM](https://pkg.go.dev/github.com/certusone/yubihsm-go). ```go pv := privval.LoadFilePV( diff --git a/cometbft/v0.38/spec/abci/Client-and-server.mdx b/cometbft/v0.38/spec/abci/Client-and-server.mdx index 0eb94c25f..8b40b2c04 100644 --- a/cometbft/v0.38/spec/abci/Client-and-server.mdx +++ b/cometbft/v0.38/spec/abci/Client-and-server.mdx @@ -24,7 +24,7 @@ For more details on protobuf, see the [documentation](https://developers.google. {/* As of v0.36 requests are synchronous. For each of ABCI++'s four connections (see -[Connections](./abci%2B%2B_app_requirements.md)), when CometBFT issues a request to the +[Connections](/cometbft/v0.38/spec/abci/abci++_app_requirements)), when CometBFT issues a request to the Application, it will wait for the response before continuing execution. As a side effect, requests and responses are ordered for each connection, but not necessarily across connections. */} @@ -45,8 +45,7 @@ the `--abci` flag appropriately. See examples, in various stages of maintenance, in [Go](https://github.com/cometbft/cometbft/tree/master/abci/server), -[JavaScript](https://github.com/tendermint/js-abci), -[C++](https://github.com/mdyring/cpp-tmsp), and +[JavaScript](https://github.com/tendermint/js-abci), and [Java](https://github.com/jTendermint/jabci). ### In Process diff --git a/cometbft/v0.38/spec/abci/Methods.mdx b/cometbft/v0.38/spec/abci/Methods.mdx index e1861104a..cd06958b5 100644 --- a/cometbft/v0.38/spec/abci/Methods.mdx +++ b/cometbft/v0.38/spec/abci/Methods.mdx @@ -310,7 +310,7 @@ title: Methods | height | int64 | The height of the block that will be proposed. | 5 | | time | [google.protobuf.Timestamp][protobuf-timestamp] | Timestamp of the block that that will be proposed. | 6 | | next_validators_hash | bytes | Merkle root of the next validator set. | 7 | - | proposer_address | bytes | [Address](../core/Data_structures.mdx#address) of the validator that is creating the proposal. | 8 | + | proposer_address | bytes | [Address](/cometbft/v0.38/spec/core/Data_structures#address) of the validator that is creating the proposal. | 8 | * **Response**: @@ -531,13 +531,13 @@ then _p_ locks _v_ and sends a Precommit message in the following way and signs the populated data structure. 5. _p_ constructs and signs the [CanonicalVote](/cometbft/v0.38/spec/core/Data_structures#canonicalvote) structure. 6. _p_ constructs the Precommit message (i.e. [Vote](/cometbft/v0.38/spec/core/Data_structures#vote) structure) - using [CanonicalVoteExtension](../core/Data_structures.mdx#canonicalvoteextension) + using [CanonicalVoteExtension](/cometbft/v0.38/spec/core/Data_structures#canonicalvoteextension) and [CanonicalVote](/cometbft/v0.38/spec/core/Data_structures#canonicalvoteextension). 7. _p_ broadcasts the Precommit message. In the cases when _p_ is to broadcast `precommit nil` messages (either _2f+1_ `prevote nil` messages received, or _timeoutPrevote_ triggered), _p_'s CometBFT does **not** call `RequestExtendVote` and will not include -a [CanonicalVoteExtension](../core/Data_structures.mdx#canonicalvoteextension) field in the `precommit nil` message. +a [CanonicalVoteExtension](/cometbft/v0.38/spec/core/Data_structures#canonicalvoteextension) field in the `precommit nil` message. ### VerifyVoteExtension @@ -805,7 +805,7 @@ Most of the data structures used in ABCI are shared [common data structures](/co | Name | Type | Description | Field Number | |---------------|-------------------------------------------------------|------------------------------------------------------------------------------------------|--------------| | validator | [Validator](#validator) | The validator that sent the vote. | 1 | - | block_id_flag | [BlockIDFlag](../core/Data_structures.mdx#blockidflag) | Indicates whether the validator voted the last block, nil, or its vote was not received. | 3 | + | block_id_flag | [BlockIDFlag](/cometbft/v0.38/spec/core/Data_structures#blockidflag) | Indicates whether the validator voted the last block, nil, or its vote was not received. | 3 | * **Usage**: * Indicates whether a validator signed the last block, allowing for rewards based on validator availability. @@ -820,7 +820,7 @@ Most of the data structures used in ABCI are shared [common data structures](/co | validator | [Validator](#validator) | The validator that sent the vote. | 1 | | vote_extension | bytes | Non-deterministic extension provided by the sending validator's Application. | 3 | | extension_signature | bytes | Signature of the vote extension produced by the sending validator and verified by CometBFT. | 4 | - | block_id_flag | [BlockIDFlag](../core/Data_structures.mdx#blockidflag) | Indicates whether the validator voted the last block, nil, or its vote was not received. | 5 | + | block_id_flag | [BlockIDFlag](/cometbft/v0.38/spec/core/Data_structures#blockidflag) | Indicates whether the validator voted the last block, nil, or its vote was not received. | 5 | * **Usage**: * Indicates whether a validator signed the last block, allowing for rewards based on validator availability. diff --git a/cometbft/v0.38/spec/abci/Outline.mdx b/cometbft/v0.38/spec/abci/Outline.mdx index 16105925f..5206ed5c8 100644 --- a/cometbft/v0.38/spec/abci/Outline.mdx +++ b/cometbft/v0.38/spec/abci/Outline.mdx @@ -65,13 +65,13 @@ 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](/cometbft/v0.38/spec/abci/CometBFTs-expected-behavior) for details on the possible call sequences of these methods. -- [**InitChain:**](./Methods.mdx#initchain) This method initializes the blockchain. +- [**InitChain:**](/cometbft/v0.38/spec/abci/Methods#initchain) This method initializes the blockchain. CometBFT calls it once upon genesis. -- [**PrepareProposal:**](./Methods.mdx#prepareproposal) It allows the block +- [**PrepareProposal:**](/cometbft/v0.38/spec/abci/Methods#prepareproposal) It allows the block proposer to perform application-dependent work in a block before proposing it. This enables, for instance, batch optimizations to a block, which has been empirically demonstrated to be a key component for improved performance. Method `PrepareProposal` is called @@ -83,7 +83,7 @@ call sequences of these methods. (potentially) modified proposal, called *prepared proposal* in the `ResponsePrepareProposal`. The logic modifying the raw proposal MAY be non-deterministic. -- [**ProcessProposal:**](./Methods.mdx#processproposal) It allows a validator to +- [**ProcessProposal:**](/cometbft/v0.38/spec/abci/Methods#processproposal) It allows a validator to perform application-dependent work in a proposed block. This enables features such as immediate block execution, and allows the Application to reject invalid blocks. @@ -96,7 +96,7 @@ call sequences of these methods. ignore the invalid part of the prepared proposal at block execution time. The logic in `ProcessProposal` MUST be deterministic. -- [**ExtendVote:**](./Methods.mdx#extendvote) It allows applications to let their +- [**ExtendVote:**](/cometbft/v0.38/spec/abci/Methods#extendvote) It allows applications to let their validators do more than just validate within consensus. `ExtendVote` allows applications to include non-deterministic data, opaque to the consensus algorithm, to precommit messages (the final round of voting). The data, called *vote extension*, will be broadcast and received together with the @@ -107,7 +107,7 @@ call sequences of these methods. a 0-length byte array as its vote extension. The logic in `ExtendVote` MAY be non-deterministic. -- [**VerifyVoteExtension:**](./Methods.mdx#verifyvoteextension) It allows +- [**VerifyVoteExtension:**](/cometbft/v0.38/spec/abci/Methods#verifyvoteextension) It allows validators to validate the vote extension data attached to a precommit message. If the validation fails, the whole precommit message will be deemed invalid and ignored by consensus algorithm. This has a negative impact on liveness, i.e., if vote extensions repeatedly cannot be @@ -119,7 +119,7 @@ call sequences of these methods. a process receives a precommit message with a (possibly empty) vote extension, for the current height. It is not called for precommit votes received after the height is concluded but while waiting to accumulate more precommit votes. The logic in `VerifyVoteExtension` MUST be deterministic. -- [**FinalizeBlock:**](./Methods.mdx#finalizeblock) It delivers a decided block to the +- [**FinalizeBlock:**](/cometbft/v0.38/spec/abci/Methods#finalizeblock) It delivers a decided block to the Application. The Application must execute the transactions in the block deterministically and update its state accordingly. Cryptographic commitments to the block and transaction results, returned via the corresponding parameters in `ResponseFinalizeBlock`, are included in the header @@ -127,7 +127,7 @@ call sequences of these methods. When calling `FinalizeBlock` with a block, the consensus algorithm run by CometBFT guarantees that at least one non-byzantine validator has run `ProcessProposal` on that block. -- [**Commit:**](./Methods.mdx#commit) Instructs the Application to persist its +- [**Commit:**](/cometbft/v0.38/spec/abci/Methods#commit) Instructs the Application to persist its state. It is a fundamental part of CometBFT's crash-recovery mechanism that ensures the synchronization between CometBFT and the Application upon recovery. CometBFT calls it just after having persisted the data returned by calls to `ResponseFinalizeBlock`. The Application can now discard @@ -135,7 +135,7 @@ call sequences of these methods. ### Mempool methods -- [**CheckTx:**](./Methods.mdx#checktx) This method allows the Application to validate +- [**CheckTx:**](/cometbft/v0.38/spec/abci/Methods#checktx) This method allows the Application to validate transactions. Validation can be stateless (e.g., checking signatures ) or stateful (e.g., account balances). The type of validation performed is up to the application. If a transaction passes the validation, then CometBFT adds it to the mempool; otherwise the @@ -146,17 +146,17 @@ call sequences of these methods. ### Info methods -- [**Info:**](./Methods.mdx#info) Used to sync CometBFT with the Application during a +- [**Info:**](/cometbft/v0.38/spec/abci/Methods#info) Used to sync CometBFT with the Application during a handshake that happens upon recovery, or on startup when state-sync is used. -- [**Query:**](./Methods.mdx#query) This method can be used to query the Application for +- [**Query:**](/cometbft/v0.38/spec/abci/Methods#query) This method can be used to query the Application for information about the application state. ### State-sync 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](/cometbft/v0.38/spec/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 @@ -164,7 +164,7 @@ A CometBFT node that receives a request for snapshots from a peer will call snapshots. Note that the list does not contain the actual snapshots but metadata about them: height at which the snapshot was taken, application-specific verification data and more (see -[snapshot data type](./Methods.mdx#snapshot) for more details). After receiving a +[snapshot data type](/cometbft/v0.38/spec/abci/Methods#snapshot) for more details). After receiving a list of available snapshots from a peer, the new node can offer any of the snapshots in the list to its local Application via the `OfferSnapshot` method. The Application can check at this point the validity of the snapshot metadata. @@ -180,29 +180,29 @@ 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](/cometbft/v0.38/spec/light-client/verification)). In summary: -- [**ListSnapshots:**](./Methods.mdx#listsnapshots) Used by nodes to discover available +- [**ListSnapshots:**](/cometbft/v0.38/spec/abci/Methods#listsnapshots) Used by nodes to discover available snapshots on peers. -- [**OfferSnapshot:**](./Methods.mdx#offersnapshot) When a node receives a snapshot from a +- [**OfferSnapshot:**](/cometbft/v0.38/spec/abci/Methods#offersnapshot) When a node receives a snapshot from a peer, CometBFT uses this method to offer the snapshot to the Application. -- [**LoadSnapshotChunk:**](./Methods.mdx#loadsnapshotchunk) Used by CometBFT to retrieve +- [**LoadSnapshotChunk:**](/cometbft/v0.38/spec/abci/Methods#loadsnapshotchunk) Used by CometBFT to retrieve snapshot chunks from the Application to send to peers. -- [**ApplySnapshotChunk:**](./Methods.mdx#applysnapshotchunk) Used by CometBFT to hand +- [**ApplySnapshotChunk:**](/cometbft/v0.38/spec/abci/Methods#applysnapshotchunk) Used by CometBFT to hand snapshot chunks to the Application. ### Other methods -Additionally, there is a [**Flush**](./Methods.mdx#flush) method that is called on every connection, -and an [**Echo**](./Methods.mdx#echo) method that is used for debugging. +Additionally, there is a [**Flush**](/cometbft/v0.38/spec/abci/Methods#flush) method that is called on every connection, +and an [**Echo**](/cometbft/v0.38/spec/abci/Methods#echo) method that is used for debugging. More details on managing state across connections can be found in the section on -[Managing Application State](./Requirements-for-the-Application.mdx#managing-the-application-state-and-related-topics). +[Managing Application State](/cometbft/v0.38/spec/abci/Requirements-for-the-Application#managing-the-application-state-and-related-topics). ## Proposal timeout @@ -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](/cometbft/v0.38/spec/core/Data_structures) +or [accountability](/cometbft/v0.38/spec/light-client/Accountability). EvidenceType has the following protobuf format: diff --git a/cometbft/v0.38/spec/abci/Requirements-for-the-Application.mdx b/cometbft/v0.38/spec/abci/Requirements-for-the-Application.mdx index bce3d3efb..e5a7d8871 100644 --- a/cometbft/v0.38/spec/abci/Requirements-for-the-Application.mdx +++ b/cometbft/v0.38/spec/abci/Requirements-for-the-Application.mdx @@ -433,7 +433,7 @@ The Application is expected to return a list of results MUST respect the same order as the list of transactions delivered via [`RequestFinalizeBlock`](/cometbft/v0.38/spec/abci/Methods#finalizeblock). This section discusses the fields inside this structure, along with the fields in -[`ResponseCheckTx`](./Methods.mdx#checktx), +[`ResponseCheckTx`](/cometbft/v0.38/spec/abci/Methods#checktx), whose semantics are similar. The `Info` and `Log` fields are @@ -619,7 +619,7 @@ the header, the validator set, and any included evidence in the block. The Application should be aware that honest validators *may* produce and broadcast blocks with up to the configured `MaxBytes` size. As a result, the consensus -[timeout parameters](../../docs/core/configuration.md#consensus-timeouts-explained) +[timeout parameters](/cometbft/v0.38/docs/core/configuration#consensus-timeouts-explained) adopted by nodes should be configured so as to account for the worst-case latency for the delivery of a full block with `MaxBytes` size to all validators. @@ -1022,7 +1022,7 @@ from the genesis file and light client RPC servers. It also calls `Info` to veri Once the state machine has been restored and CometBFT has gathered this additional information, it transitions to consensus. As of ABCI 2.0, CometBFT ensures the necessary conditions -to switch are met [RFC-100](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/rfc/rfc-100-abci-vote-extension-propag.md#base-implementation-persist-and-propagate-extended-commit-history). +to switch are met [RFC-100](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/rfc/rfc-100-abci-vote-extension-propag#base-implementation-persist-and-propagate-extended-commit-history). From the application's point of view, these operations are transparent, unless the application has just upgraded to ABCI 2.0. In that case, the application needs to be properly configured and aware of certain constraints in terms of when to provide vote extensions. More details can be found in the section below. @@ -1035,7 +1035,7 @@ Introducing vote extensions requires changes to the configuration of the applica First of all, switching to a version of CometBFT with vote extensions, requires a coordinated upgrade. For a detailed description on the upgrade path, please refer to the corresponding -[section](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/rfc/rfc-100-abci-vote-extension-propag.md#upgrade-path) in RFC-100. +[section](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/rfc/rfc-100-abci-vote-extension-propag#upgrade-path) in RFC-100. There is a newly introduced [**consensus parameter**](/cometbft/v0.38/spec/abci/Requirements-for-the-Application#consensus-parameters): `VoteExtensionsEnableHeight`. This parameter represents the height at which vote extensions are diff --git a/cometbft/v0.38/spec/consensus/Byzantine-Consensus-Algorithm.mdx b/cometbft/v0.38/spec/consensus/Byzantine-Consensus-Algorithm.mdx index c09287340..a0b4939e5 100644 --- a/cometbft/v0.38/spec/consensus/Byzantine-Consensus-Algorithm.mdx +++ b/cometbft/v0.38/spec/consensus/Byzantine-Consensus-Algorithm.mdx @@ -18,7 +18,7 @@ order: 1 or precommit [vote](https://github.com/cometbft/cometbft/blob/af3bc47df982e271d4d340a3c5e0d773e440466d/types/vote.go#L50) for something. - A vote _at_ `(H,R)` is a vote signed with the bytes for `H` and `R` - included in its [sign-bytes](../core/Data_structures.mdx#vote). + included in its [sign-bytes](/cometbft/v0.38/spec/core/Data_structures#vote). - _+2/3_ is short for "more than 2/3" - _1/3+_ is short for "1/3 or more" - A set of +2/3 of prevotes for a particular block or `` at @@ -252,7 +252,7 @@ commit-set) are each justified in the JSet with no duplicitous vote signatures (by the committers). - **Lemma**: When a fork is detected by the existence of two - conflicting [commits](../core/Data_structures.mdx#commit), the + conflicting [commits](/cometbft/v0.38/spec/core/Data_structures#commit), the union of the JSets for both commits (if they can be compiled) must include double-signing by at least 1/3+ of the validator set. **Proof**: The commit cannot be at the same round, because that @@ -293,7 +293,7 @@ may make JSet verification/gossip logic easier to implement. ### Censorship Attacks Due to the definition of a block -[commit](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/core/validators.md), any 1/3+ coalition of +[commit](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/core/validators), any 1/3+ coalition of validators can halt the blockchain by not broadcasting their votes. Such a coalition can also censor particular transactions by rejecting blocks that include these transactions, though this would result in a diff --git a/cometbft/v0.38/spec/core/Data_structures.mdx b/cometbft/v0.38/spec/core/Data_structures.mdx index fecff3cbd..6dbcba40d 100644 --- a/cometbft/v0.38/spec/core/Data_structures.mdx +++ b/cometbft/v0.38/spec/core/Data_structures.mdx @@ -50,7 +50,7 @@ and a list of evidence of malfeasance (ie. signing conflicting votes). | Name | Type | Description | Validation | |--------|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------| | Header | [Header](#header) | Header corresponding to the block. This field contains information used throughout consensus and other areas of the protocol. To find out what it contains, visit [header](#header) | Must adhere to the validation rules of [header](#header) | -| Data | [Data](#data) | Data contains a list of transactions. The contents of the transaction is unknown to CometBFT. | This field can be empty or populated, but no validation is performed. Applications can perform validation on individual transactions prior to block creation using [checkTx](https://github.com/cometbft/cometbft/blob/v0.38.x/spec/abci/abci%2B%2B_methods.mdx#checktx). +| Data | [Data](#data) | Data contains a list of transactions. The contents of the transaction is unknown to CometBFT. | This field can be empty or populated, but no validation is performed. Applications can perform validation on individual transactions prior to block creation using [checkTx](https://github.com/cometbft/cometbft/blob/v0.38.x/spec/abci/abci%2B%2B_methods#checktx). | Evidence | [EvidenceList](#evidencelist) | Evidence contains a list of infractions committed by validators. | Can be empty, but when populated the validations rules from [evidenceList](#evidencelist) apply | | LastCommit | [Commit](#commit) | `LastCommit` includes one vote for every validator. All votes must either be for the previous block, nil or absent. If a vote is for the previous block it must have a valid signature from the corresponding validator. The sum of the voting power of the validators that voted must be greater than 2/3 of the total voting power of the complete validator set. The number of votes in a commit is limited to 10000 (see `types.MaxVotesCount`). | Must be empty for the initial height and must adhere to the validation rules of [commit](#commit). | @@ -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](/cometbft/v0.38/spec/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 | @@ -144,7 +144,7 @@ versioning that this can refer to) | Name | type | Description | Validation | |-------|--------|---------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------| | Block | uint64 | This number represents the block version and must be the same throughout an operational network | Must be equal to block version being used in a network (`block.Version.Block == state.Version.Consensus.Block`) | -| App | uint64 | App version is decided on by the application. Read [here](https://github.com/cometbft/cometbft/blob/v0.38.x/spec/abci/abci++_app_requirements.md) | `block.Version.App == state.Version.Consensus.App` | +| App | uint64 | App version is decided on by the application. Read [here](https://github.com/cometbft/cometbft/blob/v0.38.x/spec/abci/abci++_app_requirements) | `block.Version.App == state.Version.Consensus.App` | ## BlockID @@ -155,7 +155,7 @@ The `BlockID` contains two distinct Merkle roots of the block. The `BlockID` inc | Hash | slice of bytes (`[]byte`) | MerkleRoot of all the fields in the header (ie. `MerkleRoot(header)`. | hash must be of length 32 | | PartSetHeader | [PartSetHeader](#partsetheader) | Used for secure gossiping of the block during consensus, is the MerkleRoot of the complete serialized block cut into parts (ie. `MerkleRoot(MakeParts(block))`). | Must adhere to the validation rules of [PartSetHeader](#partsetheader) | -See [MerkleRoot](./encoding.md#merkleroot) for details. +See [MerkleRoot](/cometbft/v0.38/spec/core/encoding#merkleroot) for details. ## PartSetHeader @@ -224,7 +224,7 @@ to reconstruct the vote set given the validator set. | Signature | [Signature](#signature) | Signature corresponding to the validators participation in consensus. | The length of the signature must be > 0 and < than 64 | NOTE: `ValidatorAddress` and `Timestamp` fields may be removed in the future -(see [ADR-25](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/architecture/tendermint-core/adr-025-commit.md)). +(see [ADR-25](https://github.com/cometbft/cometbft/blob/v0.38.x/docs/architecture/tendermint-core/adr-025-commit)). ## ExtendedCommitSig @@ -359,7 +359,7 @@ enum SignedMsgType { Signatures in CometBFT are raw bytes representing the underlying signature. -See the [signature spec](./encoding.md#key-types) for more. +See the [signature spec](/cometbft/v0.38/spec/core/encoding#key-types) for more. ## EvidenceList @@ -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](/cometbft/v0.38/spec/consensus/Evidence) ### DuplicateVoteEvidence @@ -393,7 +393,7 @@ in the same round of the same height. Votes are lexicographically sorted on `Blo `LightClientAttackEvidence` is a generalized evidence that captures all forms of known attacks on a light client such that a full node can verify, propose and commit the evidence on-chain for punishment of the malicious validators. There are three forms of attacks: Lunatic, Equivocation -and Amnesia. These attacks are exhaustive. You can find a more detailed overview of this [here](../light-client/Accountability.mdx#the-misbehavior-of-faulty-validators) +and Amnesia. These attacks are exhaustive. You can find a more detailed overview of this [here](/cometbft/v0.38/spec/light-client/Accountability#the-misbehavior-of-faulty-validators) | Name | Type | Description | Validation | |----------------------|------------------------------------|----------------------------------------------------------------------|------------------------------------------------------------------| @@ -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](/cometbft/v0.38/spec/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](/cometbft/v0.38/spec/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..cf36bf0ca 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](/cometbft/v0.38/spec/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](/cometbft/v0.38/spec/light-client/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/cometbft/v0.38/spec/p2p/reactor-api/API-for-Reactors.mdx b/cometbft/v0.38/spec/p2p/reactor-api/API-for-Reactors.mdx index e4b2910bc..3b6954df3 100644 --- a/cometbft/v0.38/spec/p2p/reactor-api/API-for-Reactors.mdx +++ b/cometbft/v0.38/spec/p2p/reactor-api/API-for-Reactors.mdx @@ -328,7 +328,7 @@ The `TrySend()` method is a _non-blocking_ method, it _immediately_ returns [switch-type]: https://github.com/cometbft/cometbft/blob/v0.38.x/p2p/switch.go [reactor-interface]: https://github.com/cometbft/cometbft/blob/v0.38.x/p2p/base_reactor.go -[reactor-registration]: ./reactor.md#registration -[reactor-channels]: ./reactor.md#registration -[reactor-addpeer]: ./reactor.md#peer-management -[reactor-removepeer]: ./reactor.md#stop-peer +[reactor-registration]: /cometbft/v0.38/spec/p2p/reactor-api/reactor#registration +[reactor-channels]: /cometbft/v0.38/spec/p2p/reactor-api/reactor#registration +[reactor-addpeer]: /cometbft/v0.38/spec/p2p/reactor-api/reactor#peer-management +[reactor-removepeer]: /cometbft/v0.38/spec/p2p/reactor-api/reactor#stop-peer diff --git a/enterprise/components/interoperability/deployment.mdx b/enterprise/components/interoperability/deployment.mdx index 6d77f02c2..6ad7af9c2 100644 --- a/enterprise/components/interoperability/deployment.mdx +++ b/enterprise/components/interoperability/deployment.mdx @@ -42,7 +42,7 @@ This document explains how an IBC v2 deployment works end-to-end to support mint - Implementation: [cosmos/solidity-ibc-eureka attestation](https://github.com/cosmos/solidity-ibc-eureka/tree/main/contracts/light-clients/attestation) - **Interchain Fungible Token (IFT)** — A set of rules and interfaces for creating and managing fungible tokens that can be transferred across different blockchain networks using ICS-27 GMP. - - Implementation: [cosmos/solidity-ibc-eureka IFTBase.sol](https://github.com/cosmos/solidity-ibc-eureka/blob/mariuszzak/ift/contracts/IFTBase.sol) + - Implementation: [cosmos/solidity-ibc-eureka IFTBase.sol](https://github.com/cosmos/solidity-ibc-eureka/blob/815ddaf194c81f2098c88afb9d73108687bb48eb/contracts/utils/IFTBaseUpgradeable.sol) ### Off-Chain diff --git a/evm/next/documentation/custom-improvement-proposals.mdx b/evm/next/documentation/custom-improvement-proposals.mdx index 81650adce..c69c3015c 100644 --- a/evm/next/documentation/custom-improvement-proposals.mdx +++ b/evm/next/documentation/custom-improvement-proposals.mdx @@ -53,7 +53,4 @@ Due to continuous changes in the users' interaction with the protocol, and to in This approach gives developers the ability to react to security issues or market conditions, while keeping the chain's participants in the loop. -## Additional Resources[​](#additional-resources "Direct link to Additional Resources") - -1. [Cosmos EVM Custom EIPs](https://github.com/cosmos/evm/blob/main/app/eips/README.md): please refer to this document for a detailed description of how opcodes and custom improvement proposals have to be used in the Cosmos EVM framework. diff --git a/evm/next/documentation/smart-contracts/precompiles/overview.mdx b/evm/next/documentation/smart-contracts/precompiles/overview.mdx index 3d812bfcb..9f6f56f95 100644 --- a/evm/next/documentation/smart-contracts/precompiles/overview.mdx +++ b/evm/next/documentation/smart-contracts/precompiles/overview.mdx @@ -110,7 +110,6 @@ bankPrecompile, err := bankprecompile.NewPrecompile( ) ``` -**Source:** [`evmd/precompiles.go:122`](https://github.com/cosmos/evm/blob/main/evmd/precompiles.go#L122) ### Required Interfaces diff --git a/evm/v0.4.x/documentation/concepts/accounts.mdx b/evm/v0.4.x/documentation/concepts/accounts.mdx index a2a206bd2..fd193f051 100644 --- a/evm/v0.4.x/documentation/concepts/accounts.mdx +++ b/evm/v0.4.x/documentation/concepts/accounts.mdx @@ -39,7 +39,7 @@ Cosmos EVM defines its own custom `Account` type to implement a HD wallet that i The root HD path for EVM-based accounts is `m/44'/60'/0'/0`. It is recommended to use the Coin type `60` to support Ethereum type accounts, unlike many other Cosmos chains that use Coin type `118` ([list of coin types](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) -The custom Cosmos EVM [EthAccount](https://github.com/cosmos/evm/blob/v0.4.1/types/account.go#L28-L33) satisfies the `AccountI` interface from the Cosmos SDK auth module and includes additional fields that are required for Ethereum type addresses: +The custom Cosmos EVM EthAccount satisfies the `AccountI` interface from the Cosmos SDK auth module and includes additional fields that are required for Ethereum type addresses: ``` // EthAccountI represents the interface of an EVM compatible accounttype EthAccountI interface { authtypes.AccountI // EthAddress returns the ethereum Address representation of the AccAddress EthAddress() common.Address // CodeHash is the keccak256 hash of the contract code (if any) GetCodeHash() common.Hash // SetCodeHash sets the code hash to the account fields SetCodeHash(code common.Hash) error // Type returns the type of Ethereum Account (EOA or Contract) Type() int8} diff --git a/evm/v0.4.x/documentation/custom-improvement-proposals.mdx b/evm/v0.4.x/documentation/custom-improvement-proposals.mdx index b881e32cd..8728aa000 100644 --- a/evm/v0.4.x/documentation/custom-improvement-proposals.mdx +++ b/evm/v0.4.x/documentation/custom-improvement-proposals.mdx @@ -53,7 +53,4 @@ Due to continuous changes in the users' interaction with the protocol, and to in This approach gives developers the ability to react to security issues or market conditions, while keeping the chain's participants in the loop. -## Additional Resources[​](#additional-resources "Direct link to Additional Resources") - -1. [Cosmos EVM Custom EIPs](https://github.com/cosmos/evm/blob/main/app/eips/README.md): please refer to this document for a detailed description of how opcodes and custom improvement proposals have to be used in the Cosmos EVM framework. diff --git a/evm/v0.4.x/documentation/smart-contracts/precompiles/p256.mdx b/evm/v0.4.x/documentation/smart-contracts/precompiles/p256.mdx index b6054e73f..5d4a94ed5 100644 --- a/evm/v0.4.x/documentation/smart-contracts/precompiles/p256.mdx +++ b/evm/v0.4.x/documentation/smart-contracts/precompiles/p256.mdx @@ -11,7 +11,6 @@ The P256 precompile provides native support for verifying secp256r1 (P-256) elli **Address**: `0x0000000000000000000000000000000000000100` -**Related Standards**: [EIP-7212](https://eips.ethereum.org/EIPS/eip-7212) ## Gas Costs diff --git a/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/implementation-guide.mdx b/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/implementation-guide.mdx index 5da47d6b3..8c4c79f86 100644 --- a/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/implementation-guide.mdx +++ b/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/implementation-guide.mdx @@ -301,5 +301,5 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) - [EIP-1014: CREATE2 Specification](https://eips.ethereum.org/EIPS/eip-1014) - Understanding deterministic deployment - [Multicall3 Documentation](https://github.com/mds1/multicall) - Official Multicall3 repository -- [Permit2 Introduction](https://blog.uniswap.org/permit2) - Uniswap's Permit2 design +- [Permit2 Introduction](https://blog.uniswap.org/permit2-and-universal-router) - Uniswap's Permit2 design - [Safe Contracts](https://github.com/safe-global/safe-contracts) - Safe multisig implementation \ No newline at end of file diff --git a/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/permit2.mdx b/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/permit2.mdx index e4ba41cf4..676d2d3e3 100644 --- a/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/permit2.mdx +++ b/evm/v0.4.x/documentation/smart-contracts/predeployed-contracts/permit2.mdx @@ -409,7 +409,7 @@ class PaymentProcessor { ## Further Reading -- [Permit2 Introduction Blog](https://blog.uniswap.org/permit2) +- [Permit2 Introduction Blog](https://blog.uniswap.org/permit2-and-universal-router) - [Permit2 GitHub Repository](https://github.com/Uniswap/permit2) - [EIP-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) - [Security Best Practices](https://github.com/Uniswap/permit2/blob/main/v0.4.x/security.md) \ No newline at end of file diff --git a/evm/v0.5.0/documentation/concepts/accounts.mdx b/evm/v0.5.0/documentation/concepts/accounts.mdx index 4448c363a..0b6585dba 100644 --- a/evm/v0.5.0/documentation/concepts/accounts.mdx +++ b/evm/v0.5.0/documentation/concepts/accounts.mdx @@ -39,7 +39,7 @@ Cosmos EVM defines its own custom `Account` type to implement a HD wallet that i The root HD path for EVM-based accounts is `m/44'/60'/0'/0`. It is recommended to use the Coin type `60` to support Ethereum type accounts, unlike many other Cosmos chains that use Coin type `118` ([list of coin types](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)). -The custom Cosmos EVM [EthAccount](https://github.com/cosmos/evm/blob/v0.4.1/types/account.go#L28-L33) satisfies the `AccountI` interface from the Cosmos SDK auth module and includes additional fields that are required for Ethereum type addresses: +The custom Cosmos EVM EthAccount satisfies the `AccountI` interface from the Cosmos SDK auth module and includes additional fields that are required for Ethereum type addresses: ```go "EthAccountI Interface" expandable // EthAccountI represents the interface of an EVM compatible account diff --git a/evm/v0.5.0/documentation/custom-improvement-proposals.mdx b/evm/v0.5.0/documentation/custom-improvement-proposals.mdx index 1af2c3fca..8d04560fd 100644 --- a/evm/v0.5.0/documentation/custom-improvement-proposals.mdx +++ b/evm/v0.5.0/documentation/custom-improvement-proposals.mdx @@ -53,7 +53,4 @@ Due to continuous changes in the users' interaction with the protocol, and to in This approach gives developers the ability to react to security issues or market conditions, while keeping the chain's participants in the loop. -## Additional Resources[​](#additional-resources "Direct link to Additional Resources") - -1. [Cosmos EVM Custom EIPs](https://github.com/cosmos/evm/blob/main/app/eips/README.md): please refer to this document for a detailed description of how opcodes and custom improvement proposals have to be used in the Cosmos EVM framework. diff --git a/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx b/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx index 3d9fdd863..f71cfac82 100644 --- a/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx +++ b/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx @@ -361,7 +361,7 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) ### Contract Documentation - [Multicall3 Documentation](https://github.com/mds1/multicall) - Official Multicall3 repository -- [Permit2 Introduction](https://blog.uniswap.org/permit2) - Uniswap's Permit2 design +- [Permit2 Introduction](https://blog.uniswap.org/permit2-and-universal-router) - Uniswap's Permit2 design - [Safe Contracts](https://github.com/safe-global/safe-contracts) - Safe multisig implementation ### Cosmos EVM Resources diff --git a/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx b/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx index 6d2b29750..4d4eba597 100644 --- a/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx +++ b/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx @@ -110,7 +110,6 @@ bankPrecompile, err := bankprecompile.NewPrecompile( ) ``` -**Source:** [`evmd/precompiles.go:122`](https://github.com/cosmos/evm/blob/main/evmd/precompiles.go#L122) ### Required Interfaces diff --git a/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx b/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx index c528571d3..683d96c6c 100644 --- a/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx +++ b/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx @@ -409,7 +409,7 @@ class PaymentProcessor { ## Further Reading -- [Permit2 Introduction Blog](https://blog.uniswap.org/permit2) +- [Permit2 Introduction Blog](https://blog.uniswap.org/permit2-and-universal-router) - [Permit2 GitHub Repository](https://github.com/Uniswap/permit2) - [EIP-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) - [Security Best Practices](https://github.com/Uniswap/permit2/blob/main/docs/security.md) \ No newline at end of file diff --git a/hub/v25/hub-tutorials/join-testnet.mdx b/hub/v25/hub-tutorials/join-testnet.mdx index a86273c33..52275d864 100644 --- a/hub/v25/hub-tutorials/join-testnet.mdx +++ b/hub/v25/hub-tutorials/join-testnet.mdx @@ -6,7 +6,7 @@ description: >- --- Visit the [testnets repo](https://github.com/cosmos/testnets) for the most up-to-date information on the currently available public testnets: -* Interchain Security (ICS) Testnet: [`provider`](https://github.com/cosmos/testnets/blob/master/interchain-security/provider/README.md) +* Interchain Security (ICS) Testnet: [`provider`](https://github.com/cosmos/testnets/tree/master/interchain-security) * Release Testnet: [`theta-testnet-001`](https://github.com/cosmos/testnets/blob/master/legacy/theta-testnet-001/README.md) ## How to Join @@ -22,7 +22,7 @@ You can set up a testnet node with a single command using one of the options bel ## Create a Validator (Optional) -If you want to create a validator in either testnet, request tokens through the [faucet Discord channel](https://discord.com/channels/669268347736686612/953697793476821092) and follow the [this guide](https://github.com/cosmos/testnets/blob/master/interchain-security/VALIDATOR_JOINING_GUIDE.md#creating-a-validator-on-the-provider-chain). If you are creating a validator in the Release Testnet, you can disregard the instructions about joining live consumer chains. +If you want to create a validator in either testnet, request tokens through the [faucet Discord channel](https://discord.com/channels/669268347736686612/953697793476821092) and follow the [this guide](https://github.com/cosmos/testnets/blob/master/interchain-security/pion-1/README.md#creating-a-validator-on-the-provider-chain). If you are creating a validator in the Release Testnet, you can disregard the instructions about joining live consumer chains. ## Upgrading Your Node diff --git a/hub/v25/index.mdx b/hub/v25/index.mdx index 9e2aca4b6..9478967b9 100644 --- a/hub/v25/index.mdx +++ b/hub/v25/index.mdx @@ -27,18 +27,15 @@ These community-maintained web and mobile wallets allow you to store & transfer * [Citadel.One](https://citadel.one/#mobile) - Android, iOS * [Cobo](https://cobo.com/) - Android, iOS * [Crypto.com](https://crypto.com/) - Android, iOS -* [Huobi Wallet](https://www.huobiwallet.com/) - Android, iOS * [ShapeShift](https://app.shapeshift.com/) - Android, iOS, Web * imToken - Android, iOS * [Math Wallet](https://www.mathwallet.org/en/) - Android, iOS, Web -* [Rainbow Wallet](https://www.rainbow.one) - Android, iOS * Trust Wallet - Android, iOS * [Komodo Wallet](https://komodoplatform.com/en/wallets) ## Metamask Snaps * [Leap Wallet](https://www.leapwallet.io/snaps) -* [Mystic Lab](https://metamask.mysticlabs.xyz/) ## Cosmos Hub Explorers @@ -47,10 +44,8 @@ These block explorers allow you to search, view and analyze Cosmos Hub data—li * [Mintscan](https://mintscan.io) * [Numia](https://www.datalenses.zone/chain/cosmos) * [ATOMScan](https://atomscan.com) -* [IOBScan](https://cosmoshub.iobscan.io/) * [Ping.Pub](https://ping.pub/cosmos) * [BronBro](https://monitor.bronbro.io/d/cosmos-stats/cosmos) -* [SmartStake](https://cosmos.smartstake.io/stats) ## Cosmos Hub CLI diff --git a/sdk/v0.53/build/tooling/cosmovisor.mdx b/sdk/v0.53/build/tooling/cosmovisor.mdx index 96c67d9cf..f5afe4226 100644 --- a/sdk/v0.53/build/tooling/cosmovisor.mdx +++ b/sdk/v0.53/build/tooling/cosmovisor.mdx @@ -374,7 +374,7 @@ Update app to the latest version (e.g. v0.50.0). -Migration plans are defined using the `x/upgrade` module and described in [In-Place Store Migrations](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/15-upgrade.md). Migrations can perform any deterministic state change. +Migration plans are defined using the `x/upgrade` module and described in [In-Place Store Migrations](sdk/v0.53/learn/advanced/upgrade). Migrations can perform any deterministic state change. The migration plan to upgrade the simapp from v0.47 to v0.50 is defined in `simapp/upgrade.go`. diff --git a/sdk/v0.53/security/bug-bounty.mdx b/sdk/v0.53/security/bug-bounty.mdx index 56450693b..012dbc2c0 100644 --- a/sdk/v0.53/security/bug-bounty.mdx +++ b/sdk/v0.53/security/bug-bounty.mdx @@ -98,8 +98,7 @@ public disclosure. This approach aligns with practices used by other major protocols, such as **Ethereum's Geth** (see https://geth.ethereum.org/docs/developers/geth-developer/disclosures), -**Bitcoin Core** (see https://bitcoincore.org/en/security-advisories/), -and **Zcash** (see https://z.cash/technology/security-advisories/). +**Bitcoin Core** (see https://bitcoincore.org/en/security-advisories/). Premature disclosure can place unpatched networks at risk. Silent remediation allows operators time to upgrade before vulnerability diff --git a/skip-go/widget/configuration.mdx b/skip-go/widget/configuration.mdx index d80e84b4c..63e5d5eee 100644 --- a/skip-go/widget/configuration.mdx +++ b/skip-go/widget/configuration.mdx @@ -357,7 +357,7 @@ onDestinationAssetUpdated?: (props: { If your application has already connected to a user's wallet (e.g., via MetaMask for EVM networks, Phantom for Solana, or Keplr for Cosmos), you **must provide both** the `connectedAddresses` and corresponding signer functions in order to enable the widget's injected wallet functionality. See an implementation example [here](https://github.com/skip-mev/skip-go/tree/staging/examples/nextjs/src/app/injected/page.tsx). -`WalletClient` comes from the [`viem` package](https://viem.sh/docs/clients/wallet.html). `Adapter` comes from the [`@solana/wallet-adapter-base` package](https://solana.com/developers/cookbook/wallets/connect-wallet-react). And `OfflineSigner` comes from the [`@cosmjs` package](https://github.com/cosmos/cosmjs). +`WalletClient` comes from the [`viem` package](https://viem.sh/docs/clients/wallet). `Adapter` comes from the [`@solana/wallet-adapter-base` package](https://solana.com/developers/cookbook/wallets/connect-wallet-react). And `OfflineSigner` comes from the [`@cosmjs` package](https://github.com/cosmos/cosmjs). - **Type:** `Record` From ee09dc8ee9d59ad80ed97518a61795947d7efbcf Mon Sep 17 00:00:00 2001 From: Evan <87997759+evanorti@users.noreply.github.com> Date: Fri, 20 Feb 2026 15:13:07 -0500 Subject: [PATCH 2/2] fix links --- cometbft/v0.38/docs/qa/CometBFT-QA-38.mdx | 2 +- cometbft/v0.38/docs/qa/TMCore-QA-34.mdx | 2 +- cometbft/v0.38/docs/qa/TMCore-QA-37.mdx | 2 +- .../smart-contracts/predeployed-contracts/permit2.mdx | 4 ++-- hub/v25/governance/formatting.mdx | 2 +- .../governance/proposal-types/community-pool-spend.mdx | 2 +- hub/v25/resources/archives.mdx | 2 +- ibc/v10.1.x/migrations/sdk-to-v1.mdx | 6 +++--- ibc/v4.6.x/ibc/proto-docs.mdx | 2 +- ibc/v4.6.x/migrations/sdk-to-v1.mdx | 6 +++--- ibc/v5.4.x/migrations/sdk-to-v1.mdx | 6 +++--- ibc/v6.3.x/ibc/proto-docs.mdx | 2 +- ibc/v6.3.x/migrations/sdk-to-v1.mdx | 6 +++--- ibc/v7.8.x/middleware/ics29-fee/fee-distribution.mdx | 4 ++-- ibc/v7.8.x/migrations/sdk-to-v1.mdx | 6 +++--- ibc/v8.5.x/migrations/sdk-to-v1.mdx | 6 +++--- sdk/next/changelog/release-notes.mdx | 2 +- .../adr-016-validator-consensus-key-rotation.mdx | 2 +- .../adr-033-protobuf-inter-module-comm.mdx | 2 +- .../adr-040-storage-and-smt-state-commitments.mdx | 4 ++-- .../build/architecture/adr-049-state-sync-hooks.mdx | 2 +- .../architecture/adr-054-semver-compatible-modules.mdx | 2 +- sdk/v0.47/build/architecture/adr-059-test-scopes.mdx | 10 +++++----- sdk/v0.47/build/migrations/upgrading.mdx | 2 +- sdk/v0.47/build/spec/addresses/bech32.mdx | 2 +- sdk/v0.47/build/tooling/cosmovisor.mdx | 2 +- sdk/v0.47/build/tooling/hubl.mdx | 2 +- sdk/v0.47/learn/intro/overview.mdx | 2 +- sdk/v0.47/user/run-node/keyring.mdx | 4 ++-- sdk/v0.47/user/run-node/run-production.mdx | 2 +- sdk/v0.50/build/abci/introduction.mdx | 2 +- .../adr-016-validator-consensus-key-rotation.mdx | 2 +- .../adr-033-protobuf-inter-module-comm.mdx | 2 +- .../adr-040-storage-and-smt-state-commitments.mdx | 2 +- .../build/architecture/adr-049-state-sync-hooks.mdx | 2 +- .../architecture/adr-054-semver-compatible-modules.mdx | 2 +- sdk/v0.50/build/architecture/adr-059-test-scopes.mdx | 10 +++++----- .../build/architecture/adr-076-tx-malleability.mdx | 6 +++--- sdk/v0.50/build/building-modules/simulator.mdx | 6 +++--- sdk/v0.50/build/migrations/upgrade-reference.mdx | 2 +- sdk/v0.50/build/tooling/cosmovisor.mdx | 2 +- sdk/v0.50/build/tooling/hubl.mdx | 2 +- sdk/v0.50/learn/intro/overview.mdx | 2 +- sdk/v0.50/user/run-node/keyring.mdx | 4 ++-- sdk/v0.50/user/run-node/run-production.mdx | 2 +- .../adr-016-validator-consensus-key-rotation.mdx | 2 +- .../adr-033-protobuf-inter-module-comm.mdx | 4 ++-- .../adr-040-storage-and-smt-state-commitments.mdx | 2 +- .../build/architecture/adr-049-state-sync-hooks.mdx | 2 +- .../architecture/adr-054-semver-compatible-modules.mdx | 2 +- sdk/v0.53/build/architecture/adr-059-test-scopes.mdx | 10 +++++----- .../build/architecture/adr-076-tx-malleability.mdx | 6 +++--- sdk/v0.53/build/migrations/upgrade-reference.mdx | 2 +- sdk/v0.53/user/run-node/keyring.mdx | 4 ++-- 54 files changed, 91 insertions(+), 91 deletions(-) diff --git a/cometbft/v0.38/docs/qa/CometBFT-QA-38.mdx b/cometbft/v0.38/docs/qa/CometBFT-QA-38.mdx index 85abd142d..92820b60e 100644 --- a/cometbft/v0.38/docs/qa/CometBFT-QA-38.mdx +++ b/cometbft/v0.38/docs/qa/CometBFT-QA-38.mdx @@ -41,7 +41,7 @@ is described [here](/cometbft/v0.38/docs/qa/TMCore-QA-37#finding-the-saturation- The following table summarizes the results for the different experiments (extracted from -[`v038_report_tabbed.txt`](/cometbft/v0.38/docs/qa/img38/200nodes/v038_report_tabbed.txt)). The X axis +[`v038_report_tabbed.txt`](https://raw.githubusercontent.com/cometbft/cometbft/v0.38.x/docs/qa/img38/200nodes/v038_report_tabbed.txt)). The X axis (`c`) is the number of connections created by the load runner process to the target node. The Y axis (`r`) is the rate or number of transactions issued per second. diff --git a/cometbft/v0.38/docs/qa/TMCore-QA-34.mdx b/cometbft/v0.38/docs/qa/TMCore-QA-34.mdx index 5313047b1..4aebd68d1 100644 --- a/cometbft/v0.38/docs/qa/TMCore-QA-34.mdx +++ b/cometbft/v0.38/docs/qa/TMCore-QA-34.mdx @@ -18,7 +18,7 @@ from being stable: the load runner tries to produce slightly more transactions t be processed by the testnet. The following table summarizes the results for v0.34.x for the different experiments -(extracted from file [`v034_report_tabbed.txt`](https://github.com/cometbft/cometbft/blob/main/docs/references/qa//cometbft/v0.38/docs/qa/img34/v034_report_tabbed.txt)). +(extracted from file [`v034_report_tabbed.txt`](https://raw.githubusercontent.com/cometbft/cometbft/v0.38.x/docs/qa/img34/v034_report_tabbed.txt)). The X axis of this table is `c`, the number of connections created by the load runner process to the target node. The Y axis of this table is `r`, the rate or number of transactions issued per second. diff --git a/cometbft/v0.38/docs/qa/TMCore-QA-37.mdx b/cometbft/v0.38/docs/qa/TMCore-QA-37.mdx index ec543c6f8..3b6358eee 100644 --- a/cometbft/v0.38/docs/qa/TMCore-QA-37.mdx +++ b/cometbft/v0.38/docs/qa/TMCore-QA-37.mdx @@ -36,7 +36,7 @@ For further details, see [this paragraph](/cometbft/v0.38/docs/qa/TMCore-QA-34#f in the baseline version. The following table summarizes the results for v0.37.x for the different experiments -(extracted from file [`v037_report_tabbed.txt`](https://github.com/cometbft/cometbft/blob/main/docs/references/qa//cometbft/v0.38/docs/qa/img37/200nodes_tm037/v037_report_tabbed.txt)). +(extracted from file [`v037_report_tabbed.txt`](https://raw.githubusercontent.com/cometbft/cometbft/v0.38.x/docs/qa/img37/200nodes_tm037/v037_report_tabbed.txt)). The X axis of this table is `c`, the number of connections created by the load runner process to the target node. The Y axis of this table is `r`, the rate or number of transactions issued per second. diff --git a/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx b/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx index 683d96c6c..167eaef74 100644 --- a/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx +++ b/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/permit2.mdx @@ -405,11 +405,11 @@ class PaymentProcessor { - [Permit2 SDK](https://github.com/Uniswap/permit2-sdk) - Official TypeScript SDK - [Permit2 Universal Router](https://github.com/Uniswap/universal-router) - Integration example -- [Permit2 Periphery](https://github.com/Uniswap/permit2-periphery) - Helper contracts +- Permit2 Periphery - Helper contracts ## Further Reading - [Permit2 Introduction Blog](https://blog.uniswap.org/permit2-and-universal-router) - [Permit2 GitHub Repository](https://github.com/Uniswap/permit2) - [EIP-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) -- [Security Best Practices](https://github.com/Uniswap/permit2/blob/main/docs/security.md) \ No newline at end of file +- Security Best Practices \ No newline at end of file diff --git a/hub/v25/governance/formatting.mdx b/hub/v25/governance/formatting.mdx index c763ab75b..b8c1e8854 100644 --- a/hub/v25/governance/formatting.mdx +++ b/hub/v25/governance/formatting.mdx @@ -116,7 +116,7 @@ that changes more parameters than was intended. The parameters that you do not w ### Real example -This example is 'real', because it was put on-chain using the Theta testnet and can be seen in the block explorer [here](https://explorer.theta-testnet.polypore.xyz/proposals/87). +This example is 'real', because it was put on-chain using the Theta testnet and can be seen. Not all explorers will show the proposed parameter changes that are coded into the proposal, so ensure that you verify that the description aligns with what the governance proposal is programmed to enact. If the description says that a certain parameter will be increased, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise). diff --git a/hub/v25/governance/proposal-types/community-pool-spend.mdx b/hub/v25/governance/proposal-types/community-pool-spend.mdx index 71afce139..8c18cdb5f 100644 --- a/hub/v25/governance/proposal-types/community-pool-spend.mdx +++ b/hub/v25/governance/proposal-types/community-pool-spend.mdx @@ -27,7 +27,7 @@ You may directly query the Cosmos Hub 4 for the balance of the Community Pool: `gaiad q distribution community-pool --chain-id cosmoshub-4 --node ` -Alternatively, popular Cosmos explorers such as [Big Dipper](https://cosmos.bigdipper.live) and [Mintscan](https://www.mintscan.io/cosmos) display the ongoing Community Pool balance. +Alternatively, popular Cosmos explorers such as [Mintscan](https://www.mintscan.io/cosmos) display the ongoing Community Pool balance. ### How can funds from the Community Pool be spent? diff --git a/hub/v25/resources/archives.mdx b/hub/v25/resources/archives.mdx index 386942442..67fb996e9 100644 --- a/hub/v25/resources/archives.mdx +++ b/hub/v25/resources/archives.mdx @@ -9,7 +9,7 @@ With each breaking upgrade of the Cosmos Hub, the network is restarted at height As a result, the blocks of the previous networks are not downloaded by new clients (as they sync from the new genesis state), and may be deleted by existing full-nodes. -In an effort to maintain transparency, the interchain hosts archives of the previous versions of the Cosmos Hub network. These archives can be found [here](https://archive.interchain.io/). +Historical snapshots are available from community snapshot providers such as [Quicksync](https://quicksync.io/cosmos) and [Polkachu](https://polkachu.com/networks/cosmos). Always do your own research before trusting a third-party snapshot provider. If you would like to search explorers for previous hub data, these are some links where you can find the information: diff --git a/ibc/v10.1.x/migrations/sdk-to-v1.mdx b/ibc/v10.1.x/migrations/sdk-to-v1.mdx index f245d91dc..fe82a9d2c 100644 --- a/ibc/v10.1.x/migrations/sdk-to-v1.mdx +++ b/ibc/v10.1.x/migrations/sdk-to-v1.mdx @@ -46,7 +46,7 @@ Both in-place store migrations and genesis migrations will: * prune all solo machine consensus states * prune all expired tendermint consensus states -Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2) for more information. +Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2) for more information. ### In-Place Store Migrations @@ -58,7 +58,7 @@ Ex: app.UpgradeKeeper.SetUpgradeHandler("my-upgrade-proposal", func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) { / set max expected block time parameter. Replace the default with your expected value - / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 + / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 app.IBCKeeper.ConnectionKeeper.SetParams(ctx, ibcconnectiontypes.DefaultParams()) fromVM := map[string]uint64{ ... / other modules @@ -86,7 +86,7 @@ import ( / add in migrate cmd function / expectedTimePerBlock is a new connection parameter -/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 +/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 newGenState, err = ibcv100.MigrateGenesis(newGenState, clientCtx, *genDoc, expectedTimePerBlock) if err != nil { return err diff --git a/ibc/v4.6.x/ibc/proto-docs.mdx b/ibc/v4.6.x/ibc/proto-docs.mdx index c0882d05b..d6f7f3d07 100644 --- a/ibc/v4.6.x/ibc/proto-docs.mdx +++ b/ibc/v4.6.x/ibc/proto-docs.mdx @@ -3,4 +3,4 @@ title: Protobuf Documentation description: See ibc-go v4.4.x Buf Protobuf documentation. --- -See [ibc-go v4.4.x Buf Protobuf documentation](https://github.com/cosmos/ibc-go/blob/release/v4.4.x/ibc/proto-docs.md). +See [ibc-go v4.4.x Buf Protobuf documentation](https://github.com/cosmos/ibc-go/blob/release/v4.4.x/docs/ibc/proto-docs.md). diff --git a/ibc/v4.6.x/migrations/sdk-to-v1.mdx b/ibc/v4.6.x/migrations/sdk-to-v1.mdx index 2ea8d2af6..19cb78989 100644 --- a/ibc/v4.6.x/migrations/sdk-to-v1.mdx +++ b/ibc/v4.6.x/migrations/sdk-to-v1.mdx @@ -46,7 +46,7 @@ Both in-place store migrations and genesis migrations will: * prune all solo machine consensus states * prune all expired tendermint consensus states -Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2) for more information. +Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2) for more information. ### In-Place Store Migrations @@ -58,7 +58,7 @@ Ex: app.UpgradeKeeper.SetUpgradeHandler("my-upgrade-proposal", func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) { / set max expected block time parameter. Replace the default with your expected value - / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 + / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 app.IBCKeeper.ConnectionKeeper.SetParams(ctx, ibcconnectiontypes.DefaultParams()) fromVM := map[string]uint64{ ... / other modules @@ -86,7 +86,7 @@ import ( / add in migrate cmd function / expectedTimePerBlock is a new connection parameter -/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 +/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 newGenState, err = ibcv100.MigrateGenesis(newGenState, clientCtx, *genDoc, expectedTimePerBlock) if err != nil { return err diff --git a/ibc/v5.4.x/migrations/sdk-to-v1.mdx b/ibc/v5.4.x/migrations/sdk-to-v1.mdx index f78708c16..5559d0928 100644 --- a/ibc/v5.4.x/migrations/sdk-to-v1.mdx +++ b/ibc/v5.4.x/migrations/sdk-to-v1.mdx @@ -46,7 +46,7 @@ Both in-place store migrations and genesis migrations will: * prune all solo machine consensus states * prune all expired tendermint consensus states -Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2) for more information. +Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2) for more information. ### In-Place Store Migrations @@ -58,7 +58,7 @@ Ex: app.UpgradeKeeper.SetUpgradeHandler("my-upgrade-proposal", func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) { / set max expected block time parameter. Replace the default with your expected value - / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 + / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 app.IBCKeeper.ConnectionKeeper.SetParams(ctx, ibcconnectiontypes.DefaultParams()) fromVM := map[string]uint64{ ... / other modules @@ -86,7 +86,7 @@ import ( / add in migrate cmd function / expectedTimePerBlock is a new connection parameter -/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 +/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 newGenState, err = ibcv100.MigrateGenesis(newGenState, clientCtx, *genDoc, expectedTimePerBlock) if err != nil { return err diff --git a/ibc/v6.3.x/ibc/proto-docs.mdx b/ibc/v6.3.x/ibc/proto-docs.mdx index ccb53f0b9..75a9b9c5f 100644 --- a/ibc/v6.3.x/ibc/proto-docs.mdx +++ b/ibc/v6.3.x/ibc/proto-docs.mdx @@ -3,4 +3,4 @@ title: Protobuf Documentation description: See ibc-go v6.2.x Buf Protobuf documentation. --- -See [ibc-go v6.2.x Buf Protobuf documentation](https://github.com/cosmos/ibc-go/blob/release/v6.2.x/ibc/proto-docs.md). +See [ibc-go v6.2.x Buf Protobuf documentation](https://github.com/cosmos/ibc-go/blob/release/v6.2.x/docs/ibc/proto-docs.md). diff --git a/ibc/v6.3.x/migrations/sdk-to-v1.mdx b/ibc/v6.3.x/migrations/sdk-to-v1.mdx index 622b1de86..1a19c3e3c 100644 --- a/ibc/v6.3.x/migrations/sdk-to-v1.mdx +++ b/ibc/v6.3.x/migrations/sdk-to-v1.mdx @@ -46,7 +46,7 @@ Both in-place store migrations and genesis migrations will: * prune all solo machine consensus states * prune all expired tendermint consensus states -Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2) for more information. +Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2) for more information. ### In-Place Store Migrations @@ -58,7 +58,7 @@ Ex: app.UpgradeKeeper.SetUpgradeHandler("my-upgrade-proposal", func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) { / set max expected block time parameter. Replace the default with your expected value - / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 + / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 app.IBCKeeper.ConnectionKeeper.SetParams(ctx, ibcconnectiontypes.DefaultParams()) fromVM := map[string]uint64{ ... / other modules @@ -86,7 +86,7 @@ import ( / add in migrate cmd function / expectedTimePerBlock is a new connection parameter -/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 +/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 newGenState, err = ibcv100.MigrateGenesis(newGenState, clientCtx, *genDoc, expectedTimePerBlock) if err != nil { return err diff --git a/ibc/v7.8.x/middleware/ics29-fee/fee-distribution.mdx b/ibc/v7.8.x/middleware/ics29-fee/fee-distribution.mdx index d9dcb3045..a3fa26f61 100644 --- a/ibc/v7.8.x/middleware/ics29-fee/fee-distribution.mdx +++ b/ibc/v7.8.x/middleware/ics29-fee/fee-distribution.mdx @@ -95,8 +95,8 @@ type MsgRegisterPayee struct { > > - `PortId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators). > - `ChannelId` is invalid (see [24-host naming requirements](https://github.com/cosmos/ibc/blob/master/spec/core/ics-024-host-requirements/README.md#paths-identifiers-separators)). -> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/beginner/03-accounts.md#addresses)). -> - `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/beginner/03-accounts.md#addresses)). +> - `Relayer` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/learn/beginner/03-accounts.md#addresses)). +> - `Payee` is an invalid address (see [Cosmos SDK Addresses](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/learn/beginner/03-accounts.md#addresses)). See below for an example CLI command: diff --git a/ibc/v7.8.x/migrations/sdk-to-v1.mdx b/ibc/v7.8.x/migrations/sdk-to-v1.mdx index bfb15cab8..a271ae98a 100644 --- a/ibc/v7.8.x/migrations/sdk-to-v1.mdx +++ b/ibc/v7.8.x/migrations/sdk-to-v1.mdx @@ -46,7 +46,7 @@ Both in-place store migrations and genesis migrations will: * prune all solo machine consensus states * prune all expired tendermint consensus states -Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2) for more information. +Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2) for more information. ### In-Place Store Migrations @@ -58,7 +58,7 @@ Ex: app.UpgradeKeeper.SetUpgradeHandler("my-upgrade-proposal", func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) { / set max expected block time parameter. Replace the default with your expected value - / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 + / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 app.IBCKeeper.ConnectionKeeper.SetParams(ctx, ibcconnectiontypes.DefaultParams()) fromVM := map[string]uint64{ ... / other modules @@ -86,7 +86,7 @@ import ( / add in migrate cmd function / expectedTimePerBlock is a new connection parameter -/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 +/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 newGenState, err = ibcv100.MigrateGenesis(newGenState, clientCtx, *genDoc, expectedTimePerBlock) if err != nil { return err diff --git a/ibc/v8.5.x/migrations/sdk-to-v1.mdx b/ibc/v8.5.x/migrations/sdk-to-v1.mdx index 67373b0fd..8750c700d 100644 --- a/ibc/v8.5.x/migrations/sdk-to-v1.mdx +++ b/ibc/v8.5.x/migrations/sdk-to-v1.mdx @@ -46,7 +46,7 @@ Both in-place store migrations and genesis migrations will: * prune all solo machine consensus states * prune all expired tendermint consensus states -Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2) for more information. +Chains must set a new connection parameter during either in place store migrations or genesis migration. The new parameter, max expected block time, is used to enforce packet processing delays on the receiving end of an IBC packet flow. Checkout the [docs](https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2) for more information. ### In-Place Store Migrations @@ -58,7 +58,7 @@ Ex: app.UpgradeKeeper.SetUpgradeHandler("my-upgrade-proposal", func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) { / set max expected block time parameter. Replace the default with your expected value - / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 + / https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 app.IBCKeeper.ConnectionKeeper.SetParams(ctx, ibcconnectiontypes.DefaultParams()) fromVM := map[string]uint64{ ... / other modules @@ -86,7 +86,7 @@ import ( / add in migrate cmd function / expectedTimePerBlock is a new connection parameter -/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/ibc/proto-docs.md#params-2 +/ https://github.com/cosmos/ibc-go/blob/release/v1.0.x/docs/ibc/proto-docs.md#params-2 newGenState, err = ibcv100.MigrateGenesis(newGenState, clientCtx, *genDoc, expectedTimePerBlock) if err != nil { return err diff --git a/sdk/next/changelog/release-notes.mdx b/sdk/next/changelog/release-notes.mdx index b2a091d2f..a52dedb1f 100644 --- a/sdk/next/changelog/release-notes.mdx +++ b/sdk/next/changelog/release-notes.mdx @@ -325,7 +325,7 @@ mode: "wide" - (core) [#14860](https://github.com/cosmos/cosmos-sdk/pull/14860) Add `Precommit` and `PrepareCheckState` AppModule callbacks. - (x/gov) [#14720](https://github.com/cosmos/cosmos-sdk/pull/14720) Upstream expedited proposals from Osmosis. - (cli) [#14659](https://github.com/cosmos/cosmos-sdk/pull/14659) Added ability to query blocks by events with queries directly passed to Tendermint, which will allow for full query operator support, e.g. `>`. -- (x/auth) [#14650](https://github.com/cosmos/cosmos-sdk/pull/14650) Add Textual SignModeHandler. Enable `SIGN_MODE_TEXTUAL` by following the [UPGRADING.mdx](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.mdx) instructions. +- (x/auth) [#14650](https://github.com/cosmos/cosmos-sdk/pull/14650) Add Textual SignModeHandler. Enable `SIGN_MODE_TEXTUAL` by following the [UPGRADING.mdx](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.md) instructions. - (x/crisis) [#14588](https://github.com/cosmos/cosmos-sdk/pull/14588) Use CacheContext() in AssertInvariants(). - (mempool) [#14484](https://github.com/cosmos/cosmos-sdk/pull/14484) Add priority nonce mempool option for transaction replacement. - (query) [#14468](https://github.com/cosmos/cosmos-sdk/pull/14468) Implement pagination for collections. diff --git a/sdk/v0.47/build/architecture/adr-016-validator-consensus-key-rotation.mdx b/sdk/v0.47/build/architecture/adr-016-validator-consensus-key-rotation.mdx index f8e5161f9..c69d3ef2a 100644 --- a/sdk/v0.47/build/architecture/adr-016-validator-consensus-key-rotation.mdx +++ b/sdk/v0.47/build/architecture/adr-016-validator-consensus-key-rotation.mdx @@ -116,7 +116,7 @@ Proposed ### Positive * Validators can immediately or periodically rotate their consensus key to have better security policy -* improved security against Long-Range attacks ([Link](https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule)) given a validator throws away the old consensus key(s) +* improved security against Long-Range attacks given a validator throws away the old consensus key(s) ### Negative diff --git a/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 486c4de6d..dd8f7c9a4 100644 --- a/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -452,4 +452,4 @@ replacing `Keeper` interfaces altogether. * [ADR 031](/sdk/v0.47/build/architecture/adr-031-msg-service) * [ADR 028](/sdk/v0.47/build/architecture/adr-028-public-key-addresses) * [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105) -* [Object-Capability Model](https://docs.network.com/main/core/ocap) +* [Object-Capability Model](/sdk/v0.47/learn/advanced/ocap) diff --git a/sdk/v0.47/build/architecture/adr-040-storage-and-smt-state-commitments.mdx b/sdk/v0.47/build/architecture/adr-040-storage-and-smt-state-commitments.mdx index 2d0e4683e..392d2867b 100644 --- a/sdk/v0.47/build/architecture/adr-040-storage-and-smt-state-commitments.mdx +++ b/sdk/v0.47/build/architecture/adr-040-storage-and-smt-state-commitments.mdx @@ -26,7 +26,7 @@ In the current design, IAVL is used for both data storage and as a Merkle Tree f * Each edge traversal requires a DB query. * Creating snapshots is [expensive](https://github.com/cosmos/cosmos-sdk/issues/7215#issuecomment-684804950). It takes about 30 seconds to export less than 100 MB of state (as of March 2020). * Updates in IAVL may trigger tree reorganization and possible O(log(n)) hashes re-computation, which can become a CPU bottleneck. -* The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/03-node.md). +* The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/node.md). Moreover, the IAVL project lacks support and a maintainer and we already see better and well-established alternatives. Instead of optimizing the IAVL, we are looking into other solutions for both storage and state commitments. @@ -293,5 +293,5 @@ We were discussing use case where modules can use a support database, which is n * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf) * [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf). * Design and implementation [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297). -* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/ibc/upgrades/quick-guide.md) +* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/docs/docs/01-ibc/05-upgrades/01-quick-guide.md) * [ADR-40 Effect on IBC](https://github.com/cosmos/ibc-go/discussions/256) diff --git a/sdk/v0.47/build/architecture/adr-049-state-sync-hooks.mdx b/sdk/v0.47/build/architecture/adr-049-state-sync-hooks.mdx index 6553dd4c1..e684d5198 100644 --- a/sdk/v0.47/build/architecture/adr-049-state-sync-hooks.mdx +++ b/sdk/v0.47/build/architecture/adr-049-state-sync-hooks.mdx @@ -194,4 +194,4 @@ Test cases for an implementation are mandatory for ADRs that are affecting conse * [Link](https://github.com/cosmos/cosmos-sdk/pull/10961) * [Link](https://github.com/cosmos/cosmos-sdk/issues/7340) -* [Link](https://hackmd.io/gJoyev6DSmqqkO667WQlGw) + diff --git a/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx b/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx index 9b9521cc2..b04e8c93c 100644 --- a/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.47/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.47.12/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/sdk/v0.47/build/architecture/adr-059-test-scopes.mdx b/sdk/v0.47/build/architecture/adr-059-test-scopes.mdx index 903c8c2ab..0b68197e6 100644 --- a/sdk/v0.47/build/architecture/adr-059-test-scopes.mdx +++ b/sdk/v0.47/build/architecture/adr-059-test-scopes.mdx @@ -61,7 +61,7 @@ Tests which exercise a whole module's function with dependencies mocked, are *jo These are almost like integration tests in that they exercise many things together but still use mocks. -Example 1 journey vs illustrative tests - [depinject's BDD style tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/features/bindings.feature), show how we can +Example 1 journey vs illustrative tests - depinject's BDD style tests, show how we can rapidly build up many illustrative cases demonstrating behavioral rules without [very much code](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/binding_test.go) while maintaining high level readability. Example 2 [depinject table driven tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/provider_desc_test.go) @@ -103,7 +103,7 @@ exercises [HandleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob keeper. Example 3 - Integration suite app configurations may also be specified via golang (not -YAML as above) [statically](https://github.com/cosmos/cosmos-sdk/blob/main/x/nft/testutil/app_config.go) or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). +YAML as above) statically or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). #### Limitations @@ -141,9 +141,9 @@ managing their life cycle. #### Limitations -* [A success](https://github.com/cosmos/cosmos-sdk/runs/7606931983?check_suite_focus=true) may take a long time to run, 7-10 minutes per simulation in CI. -* [Timeouts](https://github.com/cosmos/cosmos-sdk/runs/7606932295?check_suite_focus=true) sometimes occur on apparent successes without any indication why. -* Useful error messages not provided on [failure](https://github.com/cosmos/cosmos-sdk/runs/7606932548?check_suite_focus=true) from CI, requiring a developer to run +* A success may take a long time to run, 7-10 minutes per simulation in CI. +* Timeouts sometimes occur on apparent successes without any indication why. +* Useful error messages not provided on failure from CI, requiring a developer to run the simulation locally to reproduce. ### E2E tests diff --git a/sdk/v0.47/build/migrations/upgrading.mdx b/sdk/v0.47/build/migrations/upgrading.mdx index 6b66148f6..e68c92f18 100644 --- a/sdk/v0.47/build/migrations/upgrading.mdx +++ b/sdk/v0.47/build/migrations/upgrading.mdx @@ -401,7 +401,7 @@ In case a module does not follow the standard message path, (e.g. IBC), it is ad The `params` module was deprecated since v0.46. The Cosmos SDK has migrated away from `x/params` for its own modules. Cosmos SDK modules now store their parameters directly in its repective modules. -The `params` module will be removed in `v0.48`, as mentioned [in v0.46 release](https://github.com/cosmos/cosmos-sdk/blob/v0.46.1/UPGRADING.mdx#xparams). It is strongly encouraged to migrate away from `x/params` before `v0.48`. +The `params` module will be removed in `v0.48`, as mentioned [in v0.46 release](https://github.com/cosmos/cosmos-sdk/blob/v0.46.1/UPGRADING.md#xparams). It is strongly encouraged to migrate away from `x/params` before `v0.48`. When performing a chain migration, the params table must be initizalied manually. This was done in the modules keepers in previous versions. Have a look at `simapp.RegisterUpgradeHandlers()` for an example. diff --git a/sdk/v0.47/build/spec/addresses/bech32.mdx b/sdk/v0.47/build/spec/addresses/bech32.mdx index ac52b2cfd..73091371e 100644 --- a/sdk/v0.47/build/spec/addresses/bech32.mdx +++ b/sdk/v0.47/build/spec/addresses/bech32.mdx @@ -20,4 +20,4 @@ While all user facing interfaces to Cosmos software should exposed Bech32 interf To covert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before Bech32 encoding. -A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/05-encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation. +A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation. diff --git a/sdk/v0.47/build/tooling/cosmovisor.mdx b/sdk/v0.47/build/tooling/cosmovisor.mdx index 36363fd04..da6548472 100644 --- a/sdk/v0.47/build/tooling/cosmovisor.mdx +++ b/sdk/v0.47/build/tooling/cosmovisor.mdx @@ -320,7 +320,7 @@ cosmovisor run start Update app to the latest version (e.g. v0.45). -Next, we can add a migration - which is defined using `x/upgrade` [upgrade plan](https://github.com/cosmos/cosmos-sdk/blob/main/docs/advanced/13-upgrade.md) (you may refer to a past version if you are using an older Cosmos SDK release). In a migration we can do any deterministic state change. +Next, we can add a migration - which is defined using `x/upgrade` [upgrade plan](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/build/building-apps/03-app-upgrade.md) (you may refer to a past version if you are using an older Cosmos SDK release). In a migration we can do any deterministic state change. Build the new version `simd` binary: diff --git a/sdk/v0.47/build/tooling/hubl.mdx b/sdk/v0.47/build/tooling/hubl.mdx index f7b193ca3..70bc5529f 100644 --- a/sdk/v0.47/build/tooling/hubl.mdx +++ b/sdk/v0.47/build/tooling/hubl.mdx @@ -3,7 +3,7 @@ title: Hubl --- `Hubl` is a tool that allows you to query any Cosmos SDK based blockchain. -It takes advantage of the new [AutoCLI](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/client/v2@v2.0.0-20220916140313-c5245716b516/cli) feature {/* TODO replace with AutoCLI docs */} of the Cosmos SDK. +It takes advantage of the new [AutoCLI](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/client/v2) feature {/* TODO replace with AutoCLI docs */} of the Cosmos SDK. ## Installation diff --git a/sdk/v0.47/learn/intro/overview.mdx b/sdk/v0.47/learn/intro/overview.mdx index 5939abbe2..4968e3e02 100644 --- a/sdk/v0.47/learn/intro/overview.mdx +++ b/sdk/v0.47/learn/intro/overview.mdx @@ -26,4 +26,4 @@ The Cosmos SDK is the most advanced framework for building custom application-sp ## Getting started with the Cosmos SDK * Learn more about the [architecture of a Cosmos SDK application](/sdk/v0.47/learn/intro/sdk-app-architecture) -* Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://cosmos.network/docs/tutorial) +* Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://tutorials.cosmos.network) diff --git a/sdk/v0.47/user/run-node/keyring.mdx b/sdk/v0.47/user/run-node/keyring.mdx index fb671aec0..c183b4441 100644 --- a/sdk/v0.47/user/run-node/keyring.mdx +++ b/sdk/v0.47/user/run-node/keyring.mdx @@ -27,7 +27,7 @@ is a list of the most popular operating systems and their respective passwords m * Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) * GNU/Linux: * [libsecret](https://gitlab.gnome.org/GNOME/libsecret) - * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + * [kwallet](https://api.kde.org/kwallet-index.html) GNU/Linux distributions that use GNOME as default desktop environment typically come with [Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are @@ -89,7 +89,7 @@ one you may want to use specifically to encrypt the password store. The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the GNU/Linux distributions that ships KDE as default desktop environment. Please refer to -[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more +[KWallet Handbook](https://userbase.kde.org/KDE_Wallet_Manager) for more information. ### The `test` backend diff --git a/sdk/v0.47/user/run-node/run-production.mdx b/sdk/v0.47/user/run-node/run-production.mdx index 812dab1d2..acd44726b 100644 --- a/sdk/v0.47/user/run-node/run-production.mdx +++ b/sdk/v0.47/user/run-node/run-production.mdx @@ -10,7 +10,7 @@ This section describes how to securely run a node in a public setting and/or on When operating a node, full node or validator, in production it is important to set your server up securely. -There are many different ways to secure a server and your node, the described steps here is one way. To see another way of setting up a server see the [run in production tutorial](https://tutorials.cosmos.network/hands-on-exercise/5-run-in-prod/1-overview.html). +There are many different ways to secure a server and your node, the described steps here is one way. To see another way of setting up a server see the [run in production tutorial](https://tutorials.cosmos.network/hands-on-exercise/4-run-in-prod). diff --git a/sdk/v0.50/build/abci/introduction.mdx b/sdk/v0.50/build/abci/introduction.mdx index 81147d009..fa6d03a7c 100644 --- a/sdk/v0.50/build/abci/introduction.mdx +++ b/sdk/v0.50/build/abci/introduction.mdx @@ -25,7 +25,7 @@ The 5 methods introduced during ABCI 2.0 are: Based on their voting power, CometBFT chooses a block proposer and calls `PrepareProposal` on the block proposer's application (Cosmos SDK). The selected block proposer is responsible for collecting outstanding transactions from the mempool, adhering to the application's specifications. The application can enforce custom transaction ordering and incorporate additional transactions, potentially generated from vote extensions in the previous block. -To perform this manipulation on the application side, a custom handler must be implemented. By default, the Cosmos SDK provides `PrepareProposalHandler`, used in conjunction with an application specific mempool. A custom handler can be written by application developer, if a noop handler provided, all transactions are considered valid. Please see [this](https://github.com/fatal-fruit/abci-workshop) tutorial for more information on custom handlers. +To perform this manipulation on the application side, a custom handler must be implemented. By default, the Cosmos SDK provides `PrepareProposalHandler`, used in conjunction with an application specific mempool. A custom handler can be written by application developer, if a noop handler provided, all transactions are considered valid. Please see this tutorial for more information on custom handlers. Please note that vote extensions will only be available on the following height in which vote extensions are enabled. More information about vote extensions can be found [here](/sdk/v0.53/build/abci/vote-extensions). diff --git a/sdk/v0.50/build/architecture/adr-016-validator-consensus-key-rotation.mdx b/sdk/v0.50/build/architecture/adr-016-validator-consensus-key-rotation.mdx index f8e5161f9..c69d3ef2a 100644 --- a/sdk/v0.50/build/architecture/adr-016-validator-consensus-key-rotation.mdx +++ b/sdk/v0.50/build/architecture/adr-016-validator-consensus-key-rotation.mdx @@ -116,7 +116,7 @@ Proposed ### Positive * Validators can immediately or periodically rotate their consensus key to have better security policy -* improved security against Long-Range attacks ([Link](https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule)) given a validator throws away the old consensus key(s) +* improved security against Long-Range attacks given a validator throws away the old consensus key(s) ### Negative diff --git a/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 140803f28..b3d389255 100644 --- a/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -452,4 +452,4 @@ replacing `Keeper` interfaces altogether. * [ADR 031](/sdk/v0.50/build/architecture/adr-031-msg-service) * [ADR 028](/sdk/v0.50/build/architecture/adr-028-public-key-addresses) * [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105) -* [Object-Capability Model](https://docs.network.com/main/core/ocap) +* [Object-Capability Model](/sdk/v0.50/learn/advanced/ocap) diff --git a/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments.mdx b/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments.mdx index 8bfb4c48c..392d2867b 100644 --- a/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments.mdx +++ b/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments.mdx @@ -293,5 +293,5 @@ We were discussing use case where modules can use a support database, which is n * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf) * [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf). * Design and implementation [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297). -* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/ibc/upgrades/quick-guide.md) +* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/docs/docs/01-ibc/05-upgrades/01-quick-guide.md) * [ADR-40 Effect on IBC](https://github.com/cosmos/ibc-go/discussions/256) diff --git a/sdk/v0.50/build/architecture/adr-049-state-sync-hooks.mdx b/sdk/v0.50/build/architecture/adr-049-state-sync-hooks.mdx index 6553dd4c1..e684d5198 100644 --- a/sdk/v0.50/build/architecture/adr-049-state-sync-hooks.mdx +++ b/sdk/v0.50/build/architecture/adr-049-state-sync-hooks.mdx @@ -194,4 +194,4 @@ Test cases for an implementation are mandatory for ADRs that are affecting conse * [Link](https://github.com/cosmos/cosmos-sdk/pull/10961) * [Link](https://github.com/cosmos/cosmos-sdk/issues/7340) -* [Link](https://hackmd.io/gJoyev6DSmqqkO667WQlGw) + diff --git a/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx b/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx index bc9d9f188..516d8827b 100644 --- a/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/sdk/v0.50/build/architecture/adr-059-test-scopes.mdx b/sdk/v0.50/build/architecture/adr-059-test-scopes.mdx index 903c8c2ab..0b68197e6 100644 --- a/sdk/v0.50/build/architecture/adr-059-test-scopes.mdx +++ b/sdk/v0.50/build/architecture/adr-059-test-scopes.mdx @@ -61,7 +61,7 @@ Tests which exercise a whole module's function with dependencies mocked, are *jo These are almost like integration tests in that they exercise many things together but still use mocks. -Example 1 journey vs illustrative tests - [depinject's BDD style tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/features/bindings.feature), show how we can +Example 1 journey vs illustrative tests - depinject's BDD style tests, show how we can rapidly build up many illustrative cases demonstrating behavioral rules without [very much code](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/binding_test.go) while maintaining high level readability. Example 2 [depinject table driven tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/provider_desc_test.go) @@ -103,7 +103,7 @@ exercises [HandleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob keeper. Example 3 - Integration suite app configurations may also be specified via golang (not -YAML as above) [statically](https://github.com/cosmos/cosmos-sdk/blob/main/x/nft/testutil/app_config.go) or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). +YAML as above) statically or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). #### Limitations @@ -141,9 +141,9 @@ managing their life cycle. #### Limitations -* [A success](https://github.com/cosmos/cosmos-sdk/runs/7606931983?check_suite_focus=true) may take a long time to run, 7-10 minutes per simulation in CI. -* [Timeouts](https://github.com/cosmos/cosmos-sdk/runs/7606932295?check_suite_focus=true) sometimes occur on apparent successes without any indication why. -* Useful error messages not provided on [failure](https://github.com/cosmos/cosmos-sdk/runs/7606932548?check_suite_focus=true) from CI, requiring a developer to run +* A success may take a long time to run, 7-10 minutes per simulation in CI. +* Timeouts sometimes occur on apparent successes without any indication why. +* Useful error messages not provided on failure from CI, requiring a developer to run the simulation locally to reproduce. ### E2E tests diff --git a/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx b/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx index 02ab032a9..1294d47c1 100644 --- a/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx +++ b/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx @@ -90,7 +90,7 @@ representation. #### Fields not covered by Amino JSON -Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). +Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/proto/cosmos/tx/v1beta1/tx.proto)). If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo` without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical @@ -169,5 +169,5 @@ or get rejected. * [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) * [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) -* [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) -* [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto) +* [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) +* [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/proto/cosmos/tx/v1beta1/tx.proto) diff --git a/sdk/v0.50/build/building-modules/simulator.mdx b/sdk/v0.50/build/building-modules/simulator.mdx index 11ffd83c0..4309759d2 100644 --- a/sdk/v0.50/build/building-modules/simulator.mdx +++ b/sdk/v0.50/build/building-modules/simulator.mdx @@ -35,7 +35,7 @@ for the key-value pairs from the stores to be decoded (*i.e* unmarshalled) to their corresponding types. In particular, it matches the key to a concrete type and then unmarshals the value from the `KVPair` to the type provided. -You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. +You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. ### Randomized genesis @@ -46,13 +46,13 @@ Once the module genesis parameter are generated randomly (or with the key and values defined in a `params` file), they are marshaled to JSON format and added to the app genesis JSON to use it on the simulations. -You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v/x/staking/simulation/genesis.go). +You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/staking/simulation/genesis.go). ### Randomized parameter changes The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan. -You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v/x/staking/simulation/params.go) +You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/staking/simulation/params.go) ### Random weighted operations diff --git a/sdk/v0.50/build/migrations/upgrade-reference.mdx b/sdk/v0.50/build/migrations/upgrade-reference.mdx index a036a6d35..c5f899d89 100644 --- a/sdk/v0.50/build/migrations/upgrade-reference.mdx +++ b/sdk/v0.50/build/migrations/upgrade-reference.mdx @@ -28,7 +28,7 @@ Clients that use this feature may now submit their transactions in a fire-and-fo To submit an unordered transaction, clients must set the `unordered` flag to `true` and ensure a reasonable `timeout_timestamp` is set. The `timeout_timestamp` is used as a TTL for the transaction and provides replay protection. Each transaction's `timeout_timestamp` must be -unique to the account; however, the difference may be as small as a nanosecond. See [ADR-070](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-070-unordered-transactions.md) for more details. +unique to the account; however, the difference may be as small as a nanosecond. See [ADR-070](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-070-unordered-account.md) for more details. Note that unordered transactions require sequence values to be zero, and will **FAIL** if a non-zero sequence value is set. Please ensure no sequence value is set when submitting an unordered transaction. diff --git a/sdk/v0.50/build/tooling/cosmovisor.mdx b/sdk/v0.50/build/tooling/cosmovisor.mdx index fcec2eb3e..7d80a79b6 100644 --- a/sdk/v0.50/build/tooling/cosmovisor.mdx +++ b/sdk/v0.50/build/tooling/cosmovisor.mdx @@ -330,7 +330,7 @@ cosmovisor run start Update app to the latest version (e.g. v0.45). -Next, we can add a migration - which is defined using `x/upgrade` [upgrade plan](https://github.com/cosmos/cosmos-sdk/blob/main/docs/core/upgrade.md) (you may refer to a past version if you are using an older Cosmos SDK release). In a migration we can do any deterministic state change. +Next, we can add a migration - which is defined using `x/upgrade` [upgrade plan](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/build/building-apps/03-app-upgrade.md) (you may refer to a past version if you are using an older Cosmos SDK release). In a migration we can do any deterministic state change. Build the new version `simd` binary: diff --git a/sdk/v0.50/build/tooling/hubl.mdx b/sdk/v0.50/build/tooling/hubl.mdx index f7b193ca3..70bc5529f 100644 --- a/sdk/v0.50/build/tooling/hubl.mdx +++ b/sdk/v0.50/build/tooling/hubl.mdx @@ -3,7 +3,7 @@ title: Hubl --- `Hubl` is a tool that allows you to query any Cosmos SDK based blockchain. -It takes advantage of the new [AutoCLI](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/client/v2@v2.0.0-20220916140313-c5245716b516/cli) feature {/* TODO replace with AutoCLI docs */} of the Cosmos SDK. +It takes advantage of the new [AutoCLI](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/client/v2) feature {/* TODO replace with AutoCLI docs */} of the Cosmos SDK. ## Installation diff --git a/sdk/v0.50/learn/intro/overview.mdx b/sdk/v0.50/learn/intro/overview.mdx index 32fd4a2e2..c4ba8c589 100644 --- a/sdk/v0.50/learn/intro/overview.mdx +++ b/sdk/v0.50/learn/intro/overview.mdx @@ -38,4 +38,4 @@ The Cosmos SDK is the most advanced framework for building custom modular applic ## Getting started with the Cosmos SDK * Learn more about the [architecture of a Cosmos SDK application](/sdk/v0.50/learn/intro/sdk-app-architecture) -* Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://cosmos.network/docs/tutorial) +* Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://tutorials.cosmos.network) diff --git a/sdk/v0.50/user/run-node/keyring.mdx b/sdk/v0.50/user/run-node/keyring.mdx index 915f8a56c..2ba463a9b 100644 --- a/sdk/v0.50/user/run-node/keyring.mdx +++ b/sdk/v0.50/user/run-node/keyring.mdx @@ -27,7 +27,7 @@ is a list of the most popular operating systems and their respective passwords m * Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) * GNU/Linux: * [libsecret](https://gitlab.gnome.org/GNOME/libsecret) - * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + * [kwallet](https://api.kde.org/kwallet-index.html) * [keyctl](https://www.kernel.org/doc/html/latest/security/keys/core.html) GNU/Linux distributions that use GNOME as default desktop environment typically come with @@ -91,7 +91,7 @@ one you may want to use specifically to encrypt the password store. The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the GNU/Linux distributions that ships KDE as default desktop environment. Please refer to -[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more +[KWallet Handbook](https://userbase.kde.org/KDE_Wallet_Manager) for more information. ### The `keyctl` backend diff --git a/sdk/v0.50/user/run-node/run-production.mdx b/sdk/v0.50/user/run-node/run-production.mdx index 02e66b691..bdb7bc3fa 100644 --- a/sdk/v0.50/user/run-node/run-production.mdx +++ b/sdk/v0.50/user/run-node/run-production.mdx @@ -10,7 +10,7 @@ This section describes how to securely run a node in a public setting and/or on When operating a node, full node or validator, in production it is important to set your server up securely. -There are many different ways to secure a server and your node, the described steps here is one way. To see another way of setting up a server see the [run in production tutorial](https://tutorials.cosmos.network/hands-on-exercise/5-run-in-prod/1-overview.html). +There are many different ways to secure a server and your node, the described steps here is one way. To see another way of setting up a server see the [run in production tutorial](https://tutorials.cosmos.network/hands-on-exercise/4-run-in-prod). diff --git a/sdk/v0.53/build/architecture/adr-016-validator-consensus-key-rotation.mdx b/sdk/v0.53/build/architecture/adr-016-validator-consensus-key-rotation.mdx index f8e5161f9..c69d3ef2a 100644 --- a/sdk/v0.53/build/architecture/adr-016-validator-consensus-key-rotation.mdx +++ b/sdk/v0.53/build/architecture/adr-016-validator-consensus-key-rotation.mdx @@ -116,7 +116,7 @@ Proposed ### Positive * Validators can immediately or periodically rotate their consensus key to have better security policy -* improved security against Long-Range attacks ([Link](https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule)) given a validator throws away the old consensus key(s) +* improved security against Long-Range attacks given a validator throws away the old consensus key(s) ### Negative diff --git a/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 140803f28..a14e343e5 100644 --- a/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -23,7 +23,7 @@ service definitions defined in [ADR 021](/sdk/v0.50/build/architecture/adr-021-p ## Context -In the current Cosmos SDK documentation on the [Object-Capability Model](/sdk/v0.50/learn/advanced/ocap), it is stated that: +In the current Cosmos SDK documentation on the [Object-Capability Model](/sdk/v0.53/learn/advanced/ocap), it is stated that: > We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. @@ -452,4 +452,4 @@ replacing `Keeper` interfaces altogether. * [ADR 031](/sdk/v0.50/build/architecture/adr-031-msg-service) * [ADR 028](/sdk/v0.50/build/architecture/adr-028-public-key-addresses) * [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105) -* [Object-Capability Model](https://docs.network.com/main/core/ocap) +* [Object-Capability Model](/sdk/v0.53/learn/advanced/ocap) diff --git a/sdk/v0.53/build/architecture/adr-040-storage-and-smt-state-commitments.mdx b/sdk/v0.53/build/architecture/adr-040-storage-and-smt-state-commitments.mdx index cce1c598d..bd628eef9 100644 --- a/sdk/v0.53/build/architecture/adr-040-storage-and-smt-state-commitments.mdx +++ b/sdk/v0.53/build/architecture/adr-040-storage-and-smt-state-commitments.mdx @@ -293,5 +293,5 @@ We were discussing use case where modules can use a support database, which is n * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf) * [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf). * Design and implementation [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297). -* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/ibc/upgrades/quick-guide.md) +* [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/docs/docs/01-ibc/05-upgrades/01-quick-guide.md) * [ADR-40 Effect on IBC](https://github.com/cosmos/ibc-go/discussions/256) diff --git a/sdk/v0.53/build/architecture/adr-049-state-sync-hooks.mdx b/sdk/v0.53/build/architecture/adr-049-state-sync-hooks.mdx index 6b7fd5a90..87986cd4d 100644 --- a/sdk/v0.53/build/architecture/adr-049-state-sync-hooks.mdx +++ b/sdk/v0.53/build/architecture/adr-049-state-sync-hooks.mdx @@ -194,4 +194,4 @@ Test cases for an implementation are mandatory for ADRs that are affecting conse * [Link](https://github.com/cosmos/cosmos-sdk/pull/10961) * [Link](https://github.com/cosmos/cosmos-sdk/issues/7340) -* [Link](https://hackmd.io/gJoyev6DSmqqkO667WQlGw) + diff --git a/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx b/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx index bc9d9f188..516d8827b 100644 --- a/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/sdk/v0.53/build/architecture/adr-059-test-scopes.mdx b/sdk/v0.53/build/architecture/adr-059-test-scopes.mdx index 903c8c2ab..0b68197e6 100644 --- a/sdk/v0.53/build/architecture/adr-059-test-scopes.mdx +++ b/sdk/v0.53/build/architecture/adr-059-test-scopes.mdx @@ -61,7 +61,7 @@ Tests which exercise a whole module's function with dependencies mocked, are *jo These are almost like integration tests in that they exercise many things together but still use mocks. -Example 1 journey vs illustrative tests - [depinject's BDD style tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/features/bindings.feature), show how we can +Example 1 journey vs illustrative tests - depinject's BDD style tests, show how we can rapidly build up many illustrative cases demonstrating behavioral rules without [very much code](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/binding_test.go) while maintaining high level readability. Example 2 [depinject table driven tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/provider_desc_test.go) @@ -103,7 +103,7 @@ exercises [HandleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob keeper. Example 3 - Integration suite app configurations may also be specified via golang (not -YAML as above) [statically](https://github.com/cosmos/cosmos-sdk/blob/main/x/nft/testutil/app_config.go) or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). +YAML as above) statically or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). #### Limitations @@ -141,9 +141,9 @@ managing their life cycle. #### Limitations -* [A success](https://github.com/cosmos/cosmos-sdk/runs/7606931983?check_suite_focus=true) may take a long time to run, 7-10 minutes per simulation in CI. -* [Timeouts](https://github.com/cosmos/cosmos-sdk/runs/7606932295?check_suite_focus=true) sometimes occur on apparent successes without any indication why. -* Useful error messages not provided on [failure](https://github.com/cosmos/cosmos-sdk/runs/7606932548?check_suite_focus=true) from CI, requiring a developer to run +* A success may take a long time to run, 7-10 minutes per simulation in CI. +* Timeouts sometimes occur on apparent successes without any indication why. +* Useful error messages not provided on failure from CI, requiring a developer to run the simulation locally to reproduce. ### E2E tests diff --git a/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx b/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx index 02ab032a9..1294d47c1 100644 --- a/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx +++ b/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx @@ -90,7 +90,7 @@ representation. #### Fields not covered by Amino JSON -Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). +Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/proto/cosmos/tx/v1beta1/tx.proto)). If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo` without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical @@ -169,5 +169,5 @@ or get rejected. * [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) * [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) -* [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) -* [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto) +* [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) +* [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.10/proto/cosmos/tx/v1beta1/tx.proto) diff --git a/sdk/v0.53/build/migrations/upgrade-reference.mdx b/sdk/v0.53/build/migrations/upgrade-reference.mdx index 728a1547a..7811a2d43 100644 --- a/sdk/v0.53/build/migrations/upgrade-reference.mdx +++ b/sdk/v0.53/build/migrations/upgrade-reference.mdx @@ -28,7 +28,7 @@ Clients that use this feature may now submit their transactions in a fire-and-fo To submit an unordered transaction, clients must set the `unordered` flag to `true` and ensure a reasonable `timeout_timestamp` is set. The `timeout_timestamp` is used as a TTL for the transaction and provides replay protection. Each transaction's `timeout_timestamp` must be -unique to the account; however, the difference may be as small as a nanosecond. See [ADR-070](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-070-unordered-transactions.md) for more details. +unique to the account; however, the difference may be as small as a nanosecond. See [ADR-070](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-070-unordered-account.md) for more details. Note that unordered transactions require sequence values to be zero, and will **FAIL** if a non-zero sequence value is set. Please ensure no sequence value is set when submitting an unordered transaction. diff --git a/sdk/v0.53/user/run-node/keyring.mdx b/sdk/v0.53/user/run-node/keyring.mdx index 6c0a02c4f..5e4fe7a6f 100644 --- a/sdk/v0.53/user/run-node/keyring.mdx +++ b/sdk/v0.53/user/run-node/keyring.mdx @@ -55,7 +55,7 @@ is a list of the most popular operating systems and their respective password ma * Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) * GNU/Linux: * [libsecret](https://gitlab.gnome.org/GNOME/libsecret) - * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + * [kwallet](https://api.kde.org/kwallet-index.html) * [keyctl](https://www.kernel.org/doc/html/latest/security/keys/core.html) GNU/Linux distributions that use GNOME as the default desktop environment typically come with @@ -119,7 +119,7 @@ one you may want to use specifically to encrypt the password store. The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the GNU/Linux distributions that ships KDE as default desktop environment. Please refer to -[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more +[KWallet Handbook](https://userbase.kde.org/KDE_Wallet_Manager) for more information. ### The `keyctl` backend