chore: upate documenation from cosmos-sdk/docs

docs/build/abci/00-introduction.md

@@ -2,7 +2,7 @@
 
 ## What is ABCI?
 
-ABCI, Application Blockchain Interface is the interface between CometBFT and the application. More information about ABCI can be found in the specs [here](https://docs.cometbft.com/v0.38/spec/abci/). Within the release of ABCI 2.0 for the 0.38 CometBFT release there were additional methods introduced.
+ABCI, Application Blockchain Interface is the interface between CometBFT and the application. More information about ABCI can be found in the specs [here](https://docs.cometbft.com/v1.0/spec/abci/). Within the release of ABCI 2.0 for the 0.38 CometBFT release there were additional methods introduced.
 
 The 5 methods introduced during ABCI 2.0 (compared to ABCI v0) are:
 
@@ -41,7 +41,7 @@ If vote extensions are enabled, `ExtendVote` will be called on every validator a
 
 `VerifyVoteExtensions` is performed on every validator multiple times in order to verify other validators' vote extensions. This check is submitted to validate the integrity and validity of the vote extensions preventing malicious or invalid vote extensions.
 
-Additionally, applications must keep the vote extension data concise as it can degrade the performance of their chain, see testing results [here](https://docs.cometbft.com/v0.38/qa/cometbft-qa-38#vote-extensions-testbed).
+Additionally, applications must keep the vote extension data concise as it can degrade the performance of their chain, see testing results [here](https://docs.cometbft.com/v1.0/references/qa/cometbft-qa-38#vote-extensions-testbed).
 
 `VerifyVoteExtensions` MUST be deterministic.
 

docs/build/abci/03-vote-extensions.md

@@ -11,21 +11,21 @@ ABCI2.0 (colloquially called ABCI++) allows an application to extend a pre-commi
 validator process. The Cosmos SDK defines [`baseapp.ExtendVoteHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L26-L27):
 
 ```go
-type ExtendVoteHandler func(Context, *abci.RequestExtendVote) (*abci.ResponseExtendVote, error)
+type ExtendVoteHandler func(Context, *abci.ExtendVoteRequest) (*abci.ExtendVoteResponse, error)
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetExtendVoteHandler`
 `BaseApp` option function. The `sdk.ExtendVoteHandler`, if defined, is called during
 the `ExtendVote` ABCI method. Note, if an application decides to implement
 `baseapp.ExtendVoteHandler`, it MUST return a non-nil `VoteExtension`. However, the vote
-extension can be empty. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/spec/abci/abci++_methods.md#extendvote)
+extension can be empty. See [here](https://docs.cometbft.com/v1.0/spec/abci/abci++_methods#extendvote)
 for more details.
 
 There are many decentralized censorship-resistant use cases for vote extensions.
 For example, a validator may want to submit prices for a price oracle or encryption
 shares for an encrypted transaction mempool. Note, an application should be careful
 to consider the size of the vote extensions as they could increase latency in block
-production. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/docs/qa/CometBFT-QA-38.md#vote-extensions-testbed)
+production. See [here](https://docs.cometbft.com/v1.0/references/qa/cometbft-qa-38#vote-extensions-testbed)
 for more details.
 
 Click [here](https://docs.cosmos.network/main/build/abci/vote-extensions) if you would like a walkthrough of how to implement vote extensions.
@@ -38,18 +38,18 @@ other validators when validating their pre-commits. For a given vote extension,
 this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L29-L31):
 
 ```go
-type VerifyVoteExtensionHandler func(Context, *abci.RequestVerifyVoteExtension) (*abci.ResponseVerifyVoteExtension, error)
+type VerifyVoteExtensionHandler func(Context, *abci.VerifyVoteExtensionRequest) (*abci.VerifyVoteExtensionResponse, error)
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetVerifyVoteExtensionHandler`
 `BaseApp` option function. The `sdk.VerifyVoteExtensionHandler`, if defined, is called
 during the `VerifyVoteExtension` ABCI method. If an application defines a vote
 extension handler, it should also define a verification handler. Note, not all
 validators will share the same view of what vote extensions they verify depending
-on how votes are propagated. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/spec/abci/abci++_methods.md#verifyvoteextension)
+on how votes are propagated. See [here](https://docs.cometbft.com/v1.0/spec/abci/abci++_methods#verifyvoteextension)
 for more details.
 
-Additionally, please keep in mind that performance can be degraded if vote extensions are too big (https://docs.cometbft.com/v0.38/qa/cometbft-qa-38#vote-extensions-testbed), so we highly recommend a size validation in `VerifyVoteExtensions`.
+Additionally, please keep in mind that performance can be degraded if vote extensions are too big ([see vote extension testbed](https://docs.cometbft.com/v1.0/references/qa/cometbft-qa-38#vote-extensions-testbed)), so we highly recommend a size validation in `VerifyVoteExtensions`.
 
 
 ## Vote Extension Propagation

docs/build/architecture/PROCESS.md

@@ -49,7 +49,7 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
 * `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
 * `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
 * `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
-* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
+* `SUPERSEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
 * `ABANDONED`: the ADR is no longer pursued by the original authors.
 
 ## Language used in ADR

docs/build/architecture/adr-034-account-rekeying.md

@@ -68,7 +68,7 @@ Breaks the current assumed relationship between address and pubkeys as H(pubkey)
 
 ### Neutral
 
-* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner.  For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens.  However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accouns with Vesting tokens to use this feature.
+* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner.  For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens.  However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accounts with Vesting tokens to use this feature.
 * Will require that PubKeys for an account are included in the genesis exports.
 
 ## References

docs/build/architecture/adr-043-nft-module.md

@@ -156,7 +156,7 @@ message MsgSend {
   string class_id = 1;
   string id       = 2;
   string sender   = 3;
-  string reveiver = 4;
+  string receiver = 4;
 }
 message MsgSendResponse {}
 ```

docs/build/architecture/adr-050-sign-mode-textual.md

@@ -285,7 +285,7 @@ Moreover, the renderer must provide 2 functions: one for formatting from Protobu
 
 ### Require signing over the `TxBody` and `AuthInfo` raw bytes
 
-Recall that the transaction bytes merklelized on chain are the Protobuf binary serialization of [TxRaw](hhttps://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.tx.v1beta1#cosmos.tx.v1beta1.TxRaw), which contains the `body_bytes` and `auth_info_bytes`. Moreover, the transaction hash is defined as the SHA256 hash of the `TxRaw` bytes. We require that the user signs over these bytes in SIGN_MODE_TEXTUAL, more specifically over the following string:
+Recall that the transaction bytes merklelized on chain are the Protobuf binary serialization of [TxRaw](https://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.tx.v1beta1#cosmos.tx.v1beta1.TxRaw), which contains the `body_bytes` and `auth_info_bytes`. Moreover, the transaction hash is defined as the SHA256 hash of the `TxRaw` bytes. We require that the user signs over these bytes in SIGN_MODE_TEXTUAL, more specifically over the following string:
 
 ```
 *Hash of raw bytes: <HEX(sha256(len(body_bytes) ++ body_bytes ++ len(auth_info_bytes) ++ auth_info_bytes))>

docs/build/architecture/adr-062-collections-state-layer.md

@@ -78,7 +78,7 @@ These default implementations also offer safety around proper lexicographic orde
 
 Examples of the collections API can be found here:
 - introduction: https://github.com/NibiruChain/collections/tree/main/examples
-- usage in nibiru: [x/oracle](https://github.com/NibiruChain/nibiru/blob/master/x/oracle/keeper/keeper.go#L32), [x/perp](https://github.com/NibiruChain/nibiru/blob/main/x/perp/v2/keeper/keeper.go)
+- usage in nibiru: [x/oracle](https://github.com/NibiruChain/nibiru/blob/master/x/oracle/keeper/keeper.go#L32), [x/epoch](https://github.com/NibiruChain/nibiru/blob/4566d9f6d22807abbd78c01454664d64f6e108e0/x/epochs/keeper/epoch.go)
 - cosmos-sdk's x/staking migrated: https://github.com/testinginprod/cosmos-sdk/pull/22
 
 

docs/build/architecture/adr-063-core-module-api.md

@@ -199,7 +199,7 @@ func NewKeeper(logger log.Logger) Keeper {
 
 Modules will provide their core services to the runtime module via extension interfaces built on top of the
 `cosmossdk.io/core/appmodule.AppModule` tag interface. This tag interface requires only two empty methods which
-allow `depinject` to identify implementors as `depinject.OnePerModule` types and as app module implementations:
+allow `depinject` to identify implementers as `depinject.OnePerModule` types and as app module implementations:
 
 ```go
 type AppModule interface {
@@ -330,7 +330,7 @@ Header Service defines a way to get header information about a block. This infor
 ```go 
 
 type Service interface {
-	GetHeaderInfo(context.Context) Info
+	HeaderInfo(context.Context) Info
 }
 
 type Info struct {
@@ -463,6 +463,7 @@ module manager and follow the Cosmos SDK's existing [0-based versioning](https:/
 versioning as well as runtime modularity, new officially supported runtime modules will be created under the
 `cosmossdk.io/runtime` prefix. For each supported consensus engine a semantically-versioned go module should be created
 with a runtime implementation for that consensus engine. For example:
+
 * `cosmossdk.io/runtime/comet`
 * `cosmossdk.io/runtime/comet/v2`
 * `cosmossdk.io/runtime/rollkit`

docs/build/architecture/adr-064-abci-2.0.md

@@ -401,7 +401,7 @@ in both `BeginBlock` and `EndBlock` events`.
 
 ### Upgrading
 
-CometBFT defines a consensus parameter, [`VoteExtensionsEnableHeight`](https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/spec/abci/abci%2B%2B_app_requirements.md#abciparamsvoteextensionsenableheight),
+CometBFT defines a consensus parameter, [`VoteExtensionsEnableHeight`](https://docs.cometbft.com/v1.0/spec/abci/abci++_app_requirements#featureparamsvoteextensionsenableheight),
 which specifies the height at which vote extensions are enabled and **required**.
 If the value is set to zero, which is the default, then vote extensions are
 disabled and an application is not required to implement and use vote extensions.

docs/build/building-apps/02-app-mempool.md

@@ -10,7 +10,7 @@ This sections describes how the app-side mempool can be used and replaced.
 
 Since `v0.47` the application has its own mempool to allow much more granular
 block building than previous versions. This change was enabled by
-[ABCI 1.0](https://github.com/cometbft/cometbft/blob/v0.37.0/spec/abci).
+[ABCI 1.0](https://docs.cometbft.com/v0.37/spec/abci/).
 Notably it introduces the `PrepareProposal` and `ProcessProposal` steps of ABCI++. For more information please see [here](../abci/00-introduction.md)
 
 :::note Pre-requisite Readings