diff --git a/docs/architecture/adr-002-go-module-versioning.md b/docs/architecture/adr-002-go-module-versioning.md index 62e4a47c835..2b3e41a9d19 100644 --- a/docs/architecture/adr-002-go-module-versioning.md +++ b/docs/architecture/adr-002-go-module-versioning.md @@ -47,7 +47,7 @@ Thus, bumping the import versioning causes the protobuf definitions to be genera When registering these types at compile time, the go compiler will panic. The generated types need to be registered against the proto codec, but there exist two definitions for the same name. -The protobuf conflict policy can be overriden via the environment variable `GOLANG_PROTOBUF_REGISTRATION_CONFLICT`, but it is possible this could lead to various runtime errors or unexpected behaviour (see [here](https://github.com/protocolbuffers/protobuf-go/blob/master/reflect/protoregistry/registry.go#L46)). +The protobuf conflict policy can be overridden via the environment variable `GOLANG_PROTOBUF_REGISTRATION_CONFLICT`, but it is possible this could lead to various runtime errors or unexpected behaviour (see [here](https://github.com/protocolbuffers/protobuf-go/blob/master/reflect/protoregistry/registry.go#L46)). More information [here](https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict) on namespace conflicts for protobuf versioning. ### Potential solutions diff --git a/docs/architecture/adr-003-ics27-acknowledgement.md b/docs/architecture/adr-003-ics27-acknowledgement.md index 635d5e8fc12..560f3b58116 100644 --- a/docs/architecture/adr-003-ics27-acknowledgement.md +++ b/docs/architecture/adr-003-ics27-acknowledgement.md @@ -88,7 +88,7 @@ If the `sdk.TxMsgData.Data` field is not empty then the format for v0.45 was use #### Decision -Replicate the transaction response format as provided by the current SDK verison. +Replicate the transaction response format as provided by the current SDK version. When the SDK version changes, adjust the transaction response format to use the updated transaction response format. Include the transaction response bytes in the result channel acknowledgement. diff --git a/docs/architecture/adr-009-v6-ics27-msgserver.md b/docs/architecture/adr-009-v6-ics27-msgserver.md index 7a60d1fcaed..cfcbfade7d2 100644 --- a/docs/architecture/adr-009-v6-ics27-msgserver.md +++ b/docs/architecture/adr-009-v6-ics27-msgserver.md @@ -27,7 +27,7 @@ To minimize disruption to developers working on the original design of the ICS 2 ### Msg server -To acheive this, as stated by [@damiannolan](https://github.com/cosmos/ibc-go/issues/2026#issue-1341640594), it was proposed to: +To achieve this, as stated by [@damiannolan](https://github.com/cosmos/ibc-go/issues/2026#issue-1341640594), it was proposed to: > Add a new `MsgServer` to `27-interchain-accounts` which exposes two distinct rpc endpoints: > @@ -78,9 +78,9 @@ See issue [#2145](https://github.com/cosmos/ibc-go/issues/2145) ### Future considerations [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) proposes the creation of a middleware which enables callers of an IBC packet send to perform application logic in conjunction with the IBC application. -The underlying application can be removed at the availablity of such a middleware as that will be the preferred method for executing application logic upon a ICS 27 packet send. +The underlying application can be removed at the availability of such a middleware as that will be the preferred method for executing application logic upon a ICS 27 packet send. -### Miscellanous +### Miscellaneous In order to avoid import cycles, the genesis types have been moved to their own directory. A new protobuf package has been created for the genesis types. diff --git a/docs/architecture/adr-010-light-clients-as-sdk-modules.md b/docs/architecture/adr-010-light-clients-as-sdk-modules.md index 83140973376..b2459fce722 100644 --- a/docs/architecture/adr-010-light-clients-as-sdk-modules.md +++ b/docs/architecture/adr-010-light-clients-as-sdk-modules.md @@ -93,7 +93,7 @@ Once it is possible to route to SDK modules, a `ClientState` type could expose t ### Positive - use a single approach for interacting with callbacks -- greater flexibilty and control for IBC light clients +- greater flexibility and control for IBC light clients - does not require developing another routing system ### Negative diff --git a/docs/architecture/adr-015-ibc-packet-receiver.md b/docs/architecture/adr-015-ibc-packet-receiver.md index 08264c6d2ee..d9d673a8470 100644 --- a/docs/architecture/adr-015-ibc-packet-receiver.md +++ b/docs/architecture/adr-015-ibc-packet-receiver.md @@ -176,7 +176,7 @@ logic, whereas application can misbehave(in terms of IBC protocol) by mistake. The `ProofVerificationDecorator` should come right after the default sybil attack -resistent layer from the current `auth.NewAnteHandler`: +resistant layer from the current `auth.NewAnteHandler`: ```go // add IBC ProofVerificationDecorator to the Chain of diff --git a/docs/architecture/adr-025-ibc-passive-channels.md b/docs/architecture/adr-025-ibc-passive-channels.md index 35449185a1b..ce3f1e96db8 100644 --- a/docs/architecture/adr-025-ibc-passive-channels.md +++ b/docs/architecture/adr-025-ibc-passive-channels.md @@ -138,4 +138,4 @@ More IBC events are exposed. ## References -- The Agoric VM's IBC handler currently [accomodates `attemptChanOpenTry`](https://github.com/Agoric/agoric-sdk/blob/904b3a0423222a1b32893453e44bbde598473960/packages/cosmic-swingset/lib/ag-solo/vats/ibc.js#L546) +- The Agoric VM's IBC handler currently [accommodates `attemptChanOpenTry`](https://github.com/Agoric/agoric-sdk/blob/904b3a0423222a1b32893453e44bbde598473960/packages/cosmic-swingset/lib/ag-solo/vats/ibc.js#L546) diff --git a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md index 05f615a7aaf..a77fc97f8ae 100644 --- a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md +++ b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md @@ -54,11 +54,11 @@ We elect not to deal with chains which have actually halted, which is necessaril Previously, `AllowUpdateAfterExpiry` and `AllowUpdateAfterMisbehaviour` were used to signal the recovery options for an expired or frozen client, and governance proposals were not allowed to overwrite the client if these parameters were set to false. However, this has now been deprecated because a code migration can overwrite the client and consensus states regardless of the value of these parameters. If governance would vote to overwrite a client or consensus state, it is likely that governance would also be willing to perform a code migration to do the same. - In addition, `TrustingPeriod` was initally not allowed to be updated by a client upgrade proposal. However, due to the number of situations experienced in production where the `TrustingPeriod` of a client should be allowed to be updated because of ie: initial misconfiguration for a canonical channel, governance should be allowed to update this client parameter. + In addition, `TrustingPeriod` was initially not allowed to be updated by a client upgrade proposal. However, due to the number of situations experienced in production where the `TrustingPeriod` of a client should be allowed to be updated because of ie: initial misconfiguration for a canonical channel, governance should be allowed to update this client parameter. In versions older than ibc-go v8, `MsgRecoverClient` was a governance proposal type `ClientUpdateProposal`. It has been removed and replaced by `MsgRecoverClient` in the migration from governance v1beta1 to governance v1. - Note that this should NOT be lightly updated, as there may be a gap in time between when misbehaviour has occured and when the evidence of misbehaviour is submitted. For example, if the `UnbondingPeriod` is 2 weeks and the `TrustingPeriod` has also been set to two weeks, a validator could wait until right before `UnbondingPeriod` finishes, submit false information, then unbond and exit without being slashed for misbehaviour. Therefore, we recommend that the trusting period for the 07-tendermint client be set to 2/3 of the `UnbondingPeriod`. + Note that this should NOT be lightly updated, as there may be a gap in time between when misbehaviour has occurred and when the evidence of misbehaviour is submitted. For example, if the `UnbondingPeriod` is 2 weeks and the `TrustingPeriod` has also been set to two weeks, a validator could wait until right before `UnbondingPeriod` finishes, submit false information, then unbond and exit without being slashed for misbehaviour. Therefore, we recommend that the trusting period for the 07-tendermint client be set to 2/3 of the `UnbondingPeriod`. Note that clients frozen due to misbehaviour must wait for the evidence to expire to avoid becoming refrozen. diff --git a/docs/architecture/adr-027-ibc-wasm.md b/docs/architecture/adr-027-ibc-wasm.md index 3e1f155f3b6..6c8adedb5fa 100644 --- a/docs/architecture/adr-027-ibc-wasm.md +++ b/docs/architecture/adr-027-ibc-wasm.md @@ -129,7 +129,7 @@ func (c *ClientState) CheckProposedHeaderAndUpdateState(context sdk.Context, mar return nil, nil, sdkerrors.Wrapf(ErrUnableToUnmarshalPayload, fmt.Sprintf("underlying error: %s", err.Error())) } if !output.Result.IsValid { - return nil, nil, fmt.Errorf("%s error ocurred while updating client state", output.Result.ErrorMsg) + return nil, nil, fmt.Errorf("%s error occurred while updating client state", output.Result.ErrorMsg) } output.resetImmutables(c) return output.NewClientState, output.NewConsensusState, nil diff --git a/docs/dev/release-management.md b/docs/dev/release-management.md index 8e168e38d11..ec366d84bbf 100644 --- a/docs/dev/release-management.md +++ b/docs/dev/release-management.md @@ -32,7 +32,7 @@ In order to alleviate the burden for a single person to have to cherry-pick and Current release is `v1.0.2`. We then maintain a (living) branch `release/v1.0.x`, given `x` as the next patch release number (currently `v1.0.3`) for the `v1.0` release series. As bugs are fixed and PRs are merged into `main`, if a contributor wishes the PR to be released into the `v1.0.x` point release, the contributor must: 1. Add the `backport-to-v1.0x` label to the PR. -2. Once the PR is merged, the Mergify GitHub application will automatically copy the changes into another branch and open a new PR agains the desired `release/v1.0.x` branch. +2. Once the PR is merged, the Mergify GitHub application will automatically copy the changes into another branch and open a new PR against the desired `release/v1.0.x` branch. 3. If the following has not been discussed in the original PR, then update the backport PR's description and ensure it contains the following information: - **[Impact]** explanation of how the bug affects users or developers. diff --git a/docs/docs/01-ibc/03-apps/05-packets_acks.md b/docs/docs/01-ibc/03-apps/05-packets_acks.md index 9f7f76614ac..66a1710ecbc 100644 --- a/docs/docs/01-ibc/03-apps/05-packets_acks.md +++ b/docs/docs/01-ibc/03-apps/05-packets_acks.md @@ -27,7 +27,7 @@ channel, as well as how they will encode/decode it. This process is not specifie to each application module to determine how to implement this agreement. However, for most applications this will happen as a version negotiation during the channel handshake. While more complex version negotiation is possible to implement inside the channel opening handshake, a very -simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). +simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). Thus, a module must define its custom packet data structure, along with a well-defined way to encode and decode it to and from `[]byte`. diff --git a/docs/docs/02-apps/01-transfer/08-authorizations.md b/docs/docs/02-apps/01-transfer/08-authorizations.md index 2bd4920f945..bd7a5b9269c 100644 --- a/docs/docs/02-apps/01-transfer/08-authorizations.md +++ b/docs/docs/02-apps/01-transfer/08-authorizations.md @@ -18,7 +18,7 @@ It takes: - a `SourcePort` and a `SourceChannel` which together comprise the unique transfer channel identifier over which authorized funds can be transferred. -- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transfered, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes. +- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transferred, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes. - an `AllowList` list that specifies the list of addresses that are allowed to receive funds. If this list is empty, then all addresses are allowed to receive funds from the `TransferAuthorization`. diff --git a/docs/docs/02-apps/02-interchain-accounts/02-development.md b/docs/docs/02-apps/02-interchain-accounts/02-development.md index eb2aaa1f90a..720527b4693 100644 --- a/docs/docs/02-apps/02-interchain-accounts/02-development.md +++ b/docs/docs/02-apps/02-interchain-accounts/02-development.md @@ -22,7 +22,7 @@ If you wish to consume and execute custom logic in the packet callbacks, then pl ## Redirection to a smart contract It may be desirable to allow smart contracts to control an interchain account. -To faciliate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers. +To facilitate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers. An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementors of this use case are recommended to follow the ADR 008 approach. diff --git a/docs/docs/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md b/docs/docs/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md index 70cc36b8a69..96aca51c763 100644 --- a/docs/docs/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md +++ b/docs/docs/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md @@ -134,7 +134,7 @@ func (im IBCModule) OnChanCloseInit( } // OnRecvPacket implements the IBCModule interface. A successful acknowledgement -// is returned if the packet data is succesfully decoded and the receive application +// is returned if the packet data is successfully decoded and the receive application // logic returns without error. func (im IBCModule) OnRecvPacket( ctx sdk.Context, diff --git a/docs/docs/04-middleware/01-ics29-fee/01-overview.md b/docs/docs/04-middleware/01-ics29-fee/01-overview.md index 7a34adec74e..5b576061a04 100644 --- a/docs/docs/04-middleware/01-ics29-fee/01-overview.md +++ b/docs/docs/04-middleware/01-ics29-fee/01-overview.md @@ -35,7 +35,7 @@ To achieve the stated requirements, the **fee middleware module has two main gro This is described in the [Fee messages section](03-msgs.md). -We complete the introduction by giving a list of definitions of relevant terminolgy. +We complete the introduction by giving a list of definitions of relevant terminology. `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain). diff --git a/docs/docs/04-middleware/02-callbacks/03-interfaces.md b/docs/docs/04-middleware/02-callbacks/03-interfaces.md index 0c05b1bb27b..566e4ebb4e2 100644 --- a/docs/docs/04-middleware/02-callbacks/03-interfaces.md +++ b/docs/docs/04-middleware/02-callbacks/03-interfaces.md @@ -66,7 +66,7 @@ Since middlewares do not have packet types, they do not need to implement this i ### `ContractKeeper` -The callbacks middleware requires the secondary application to implement the [`ContractKeeper`](https://github.com/cosmos/ibc-go/blob/v7.3.0/modules/apps/callbacks/types/expected_keepers.go#L11-L83) interface. The contract keeper will be invoked at each step of the packet lifecycle. When a packet is sent, if callback information is provided, the contract keeper will be invoked via the `IBCSendPacketCallback`. This allows the contract keeper to prevent packet sends when callback information is provided, for example if the sender is unauthroized to perform callbacks on the given information. If the packet send is successful, the contract keeper on the destination (if present) will be invoked when a packet has been received and the acknowledgement is written, this will occur via `IBCReceivePacketCallback`. At the end of the packet lifecycle, when processing acknowledgements or timeouts, the source contract keeper will be invoked either via `IBCOnAcknowledgementPacket` or `IBCOnTimeoutPacket`. Once a packet has been sent, each step of the packet lifecycle can be processed given that a relayer sets the gas limit to be more than or equal to the required `CommitGasLimit`. State changes performed in the callback will only be committed upon successful execution. +The callbacks middleware requires the secondary application to implement the [`ContractKeeper`](https://github.com/cosmos/ibc-go/blob/v7.3.0/modules/apps/callbacks/types/expected_keepers.go#L11-L83) interface. The contract keeper will be invoked at each step of the packet lifecycle. When a packet is sent, if callback information is provided, the contract keeper will be invoked via the `IBCSendPacketCallback`. This allows the contract keeper to prevent packet sends when callback information is provided, for example if the sender is unauthorized to perform callbacks on the given information. If the packet send is successful, the contract keeper on the destination (if present) will be invoked when a packet has been received and the acknowledgement is written, this will occur via `IBCReceivePacketCallback`. At the end of the packet lifecycle, when processing acknowledgements or timeouts, the source contract keeper will be invoked either via `IBCOnAcknowledgementPacket` or `IBCOnTimeoutPacket`. Once a packet has been sent, each step of the packet lifecycle can be processed given that a relayer sets the gas limit to be more than or equal to the required `CommitGasLimit`. State changes performed in the callback will only be committed upon successful execution. ```go // ContractKeeper defines the entry points exposed to the VM module which invokes a smart contract diff --git a/docs/docs/05-migrations/04-v2-to-v3.md b/docs/docs/05-migrations/04-v2-to-v3.md index 9c6433e0e49..280f5340fbe 100644 --- a/docs/docs/05-migrations/04-v2-to-v3.md +++ b/docs/docs/05-migrations/04-v2-to-v3.md @@ -136,7 +136,7 @@ type AnteDecorator struct { The `OnChanOpenTry` application callback has been modified. The return signature now includes the application version. -IBC applications must perform application version negoitation in `OnChanOpenTry` using the counterparty version. +IBC applications must perform application version negotiation in `OnChanOpenTry` using the counterparty version. The negotiated application version then must be returned in `OnChanOpenTry` to core IBC. Core IBC will set this version in the TRYOPEN channel. diff --git a/docs/docs/05-migrations/07-v5-to-v6.md b/docs/docs/05-migrations/07-v5-to-v6.md index 4c7df21335a..4fc777e6cd9 100644 --- a/docs/docs/05-migrations/07-v5-to-v6.md +++ b/docs/docs/05-migrations/07-v5-to-v6.md @@ -97,7 +97,7 @@ app.UpgradeKeeper.SetUpgradeHandler( In previous releases of ibc-go, chain developers integrating the ICS27 interchain accounts controller functionality were expected to create a custom `Base Application` referred to as an authentication module, see the section [Building an authentication module](../02-apps/02-interchain-accounts/03-auth-modules.md) from the documentation. -The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and faciliate many forms of message authentication depending on a chain's particular use case. +The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and facilitate many forms of message authentication depending on a chain's particular use case. Prior to ibc-go v6 the controller submodule exposed only these two functions (to which we will refer as the legacy APIs): diff --git a/docs/events/events.md b/docs/events/events.md index 0d4cdb842f8..47e507a438e 100644 --- a/docs/events/events.md +++ b/docs/events/events.md @@ -5,7 +5,7 @@ This document is unmaintained and may be out of date! ::: The IBC module emits the following events. It can be expected that the type `message`, -with an attirbute key of `action` will represent the first event for each message +with an attribute key of `action` will represent the first event for each message being processed as emitted by the SDK's baseapp. Each IBC TAO message will also emit its module name in the format 'ibc_sub-modulename'. diff --git a/docs/requirements/ics29-v1-requirements.md b/docs/requirements/ics29-v1-requirements.md index 65c76dc4cc9..ddbf9a475cb 100644 --- a/docs/requirements/ics29-v1-requirements.md +++ b/docs/requirements/ics29-v1-requirements.md @@ -103,7 +103,7 @@ See section [Definitions](https://github.com/cosmos/ibc/tree/main/spec/app/ics-0 | ID | Description | Verification | Status | | --- | ----------- | ------------ | ------ | -| 5.01 | Fee distribution shall occurr on the source chain from which packets originate. | Either in [`OnAcknowledgementPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L288) or in [`OnTimeoutPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L330). | `Verified` | +| 5.01 | Fee distribution shall occur on the source chain from which packets originate. | Either in [`OnAcknowledgementPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L288) or in [`OnTimeoutPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L330). | `Verified` | #### `OnAcknowledgementPacket` diff --git a/docs/src/css/custom.css b/docs/src/css/custom.css index fc03ea47108..a828fb7256b 100644 --- a/docs/src/css/custom.css +++ b/docs/src/css/custom.css @@ -1,5 +1,5 @@ /* - Slighlty modified version of https://github.com/ignite/cli/blob/develop/docs/src/css/custom.css + Slightly modified version of https://github.com/ignite/cli/blob/develop/docs/src/css/custom.css */ @import "tailwindcss/base"; diff --git a/docs/versioned_docs/version-v4.5.x/01-ibc/03-apps/05-packets_acks.md b/docs/versioned_docs/version-v4.5.x/01-ibc/03-apps/05-packets_acks.md index 95bec486255..c5c0e5daa65 100644 --- a/docs/versioned_docs/version-v4.5.x/01-ibc/03-apps/05-packets_acks.md +++ b/docs/versioned_docs/version-v4.5.x/01-ibc/03-apps/05-packets_acks.md @@ -27,7 +27,7 @@ channel, as well as how they will encode/decode it. This process is not specifie to each application module to determine how to implement this agreement. However, for most applications this will happen as a version negotiation during the channel handshake. While more complex version negotiation is possible to implement inside the channel opening handshake, a very -simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). +simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). Thus, a module must define its custom packet data structure, along with a well-defined way to encode and decode it to and from `[]byte`. diff --git a/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/02-auth-modules.md b/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/02-auth-modules.md index 26014bc286a..cf3b2417af4 100644 --- a/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/02-auth-modules.md +++ b/docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/02-auth-modules.md @@ -141,7 +141,7 @@ func (im IBCModule) OnChanCloseInit( } // OnRecvPacket implements the IBCModule interface. A successful acknowledgement -// is returned if the packet data is succesfully decoded and the receive application +// is returned if the packet data is successfully decoded and the receive application // logic returns without error. func (im IBCModule) OnRecvPacket( ctx sdk.Context, diff --git a/docs/versioned_docs/version-v4.5.x/03-middleware/01-ics29-fee/01-overview.md b/docs/versioned_docs/version-v4.5.x/03-middleware/01-ics29-fee/01-overview.md index b1e85bfb9eb..631e28bff55 100644 --- a/docs/versioned_docs/version-v4.5.x/03-middleware/01-ics29-fee/01-overview.md +++ b/docs/versioned_docs/version-v4.5.x/03-middleware/01-ics29-fee/01-overview.md @@ -35,7 +35,7 @@ To achieve the stated requirements, the **fee middleware module has two main gro This is described in the [Fee messages section](03-msgs.md). -We complete the introduction by giving a list of definitions of relevant terminolgy. +We complete the introduction by giving a list of definitions of relevant terminology. `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain). diff --git a/docs/versioned_docs/version-v4.5.x/04-migrations/04-v2-to-v3.md b/docs/versioned_docs/version-v4.5.x/04-migrations/04-v2-to-v3.md index fca445b0554..54a5bd47f8e 100644 --- a/docs/versioned_docs/version-v4.5.x/04-migrations/04-v2-to-v3.md +++ b/docs/versioned_docs/version-v4.5.x/04-migrations/04-v2-to-v3.md @@ -136,7 +136,7 @@ type AnteDecorator struct { The `OnChanOpenTry` application callback has been modified. The return signature now includes the application version. -IBC applications must perform application version negoitation in `OnChanOpenTry` using the counterparty version. +IBC applications must perform application version negotiation in `OnChanOpenTry` using the counterparty version. The negotiated application version then must be returned in `OnChanOpenTry` to core IBC. Core IBC will set this version in the TRYOPEN channel. diff --git a/docs/versioned_docs/version-v5.3.x/01-ibc/03-apps/05-packets_acks.md b/docs/versioned_docs/version-v5.3.x/01-ibc/03-apps/05-packets_acks.md index 95bec486255..c5c0e5daa65 100644 --- a/docs/versioned_docs/version-v5.3.x/01-ibc/03-apps/05-packets_acks.md +++ b/docs/versioned_docs/version-v5.3.x/01-ibc/03-apps/05-packets_acks.md @@ -27,7 +27,7 @@ channel, as well as how they will encode/decode it. This process is not specifie to each application module to determine how to implement this agreement. However, for most applications this will happen as a version negotiation during the channel handshake. While more complex version negotiation is possible to implement inside the channel opening handshake, a very -simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). +simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). Thus, a module must define its custom packet data structure, along with a well-defined way to encode and decode it to and from `[]byte`. diff --git a/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/02-auth-modules.md b/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/02-auth-modules.md index 34b75c2f8d8..08ca8528a59 100644 --- a/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/02-auth-modules.md +++ b/docs/versioned_docs/version-v5.3.x/02-apps/02-interchain-accounts/02-auth-modules.md @@ -141,7 +141,7 @@ func (im IBCModule) OnChanCloseInit( } // OnRecvPacket implements the IBCModule interface. A successful acknowledgement -// is returned if the packet data is succesfully decoded and the receive application +// is returned if the packet data is successfully decoded and the receive application // logic returns without error. func (im IBCModule) OnRecvPacket( ctx sdk.Context, diff --git a/docs/versioned_docs/version-v5.3.x/03-middleware/01-ics29-fee/01-overview.md b/docs/versioned_docs/version-v5.3.x/03-middleware/01-ics29-fee/01-overview.md index f6edae76ceb..3dbd44664bf 100644 --- a/docs/versioned_docs/version-v5.3.x/03-middleware/01-ics29-fee/01-overview.md +++ b/docs/versioned_docs/version-v5.3.x/03-middleware/01-ics29-fee/01-overview.md @@ -36,7 +36,7 @@ To achieve the stated requirements, the **fee middleware module has two main gro This is described in the [Fee messages section](03-msgs.md). -We complete the introduction by giving a list of definitions of relevant terminolgy. +We complete the introduction by giving a list of definitions of relevant terminology. `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain). diff --git a/docs/versioned_docs/version-v5.3.x/04-migrations/04-v2-to-v3.md b/docs/versioned_docs/version-v5.3.x/04-migrations/04-v2-to-v3.md index 34d87b46862..62bc3972095 100644 --- a/docs/versioned_docs/version-v5.3.x/04-migrations/04-v2-to-v3.md +++ b/docs/versioned_docs/version-v5.3.x/04-migrations/04-v2-to-v3.md @@ -136,7 +136,7 @@ type AnteDecorator struct { The `OnChanOpenTry` application callback has been modified. The return signature now includes the application version. -IBC applications must perform application version negoitation in `OnChanOpenTry` using the counterparty version. +IBC applications must perform application version negotiation in `OnChanOpenTry` using the counterparty version. The negotiated application version then must be returned in `OnChanOpenTry` to core IBC. Core IBC will set this version in the TRYOPEN channel. diff --git a/docs/versioned_docs/version-v6.2.x/01-ibc/03-apps/05-packets_acks.md b/docs/versioned_docs/version-v6.2.x/01-ibc/03-apps/05-packets_acks.md index fc6070e6ea6..7990a195de8 100644 --- a/docs/versioned_docs/version-v6.2.x/01-ibc/03-apps/05-packets_acks.md +++ b/docs/versioned_docs/version-v6.2.x/01-ibc/03-apps/05-packets_acks.md @@ -27,7 +27,7 @@ channel, as well as how they will encode/decode it. This process is not specifie to each application module to determine how to implement this agreement. However, for most applications this will happen as a version negotiation during the channel handshake. While more complex version negotiation is possible to implement inside the channel opening handshake, a very -simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). +simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). Thus, a module must define its custom packet data structure, along with a well-defined way to encode and decode it to and from `[]byte`. diff --git a/docs/versioned_docs/version-v6.2.x/02-apps/01-transfer/08-authorizations.md b/docs/versioned_docs/version-v6.2.x/02-apps/01-transfer/08-authorizations.md index 4efa9d749e7..bc6ff59d424 100644 --- a/docs/versioned_docs/version-v6.2.x/02-apps/01-transfer/08-authorizations.md +++ b/docs/versioned_docs/version-v6.2.x/02-apps/01-transfer/08-authorizations.md @@ -19,7 +19,7 @@ It takes: - a `SourcePort` and a `SourceChannel` which together comprise the unique transfer channel identifier over which authorized funds can be transferred. -- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transfered, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes. +- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transferred, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes. - an `AllowList` list that specifies the list of addresses that are allowed to receive funds. If this list is empty, then all addresses are allowed to receive funds from the `TransferAuthorization`. diff --git a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md index d2c7345ae79..06b292d7954 100644 --- a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md +++ b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md @@ -22,7 +22,7 @@ If you wish to consume and execute custom logic in the packet callbacks, then pl ## Redirection to a smart contract It may be desirable to allow smart contracts to control an interchain account. -To faciliate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers. +To facilitate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers. An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementors of this use case are recommended to follow the ADR 008 approach. diff --git a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/09-legacy/01-auth-modules.md b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/09-legacy/01-auth-modules.md index 5903f81e6a2..89db42d321f 100644 --- a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/09-legacy/01-auth-modules.md +++ b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/09-legacy/01-auth-modules.md @@ -134,7 +134,7 @@ func (im IBCModule) OnChanCloseInit( } // OnRecvPacket implements the IBCModule interface. A successful acknowledgement -// is returned if the packet data is succesfully decoded and the receive application +// is returned if the packet data is successfully decoded and the receive application // logic returns without error. func (im IBCModule) OnRecvPacket( ctx sdk.Context, diff --git a/docs/versioned_docs/version-v6.2.x/03-middleware/01-ics29-fee/01-overview.md b/docs/versioned_docs/version-v6.2.x/03-middleware/01-ics29-fee/01-overview.md index f6edae76ceb..3dbd44664bf 100644 --- a/docs/versioned_docs/version-v6.2.x/03-middleware/01-ics29-fee/01-overview.md +++ b/docs/versioned_docs/version-v6.2.x/03-middleware/01-ics29-fee/01-overview.md @@ -36,7 +36,7 @@ To achieve the stated requirements, the **fee middleware module has two main gro This is described in the [Fee messages section](03-msgs.md). -We complete the introduction by giving a list of definitions of relevant terminolgy. +We complete the introduction by giving a list of definitions of relevant terminology. `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain). diff --git a/docs/versioned_docs/version-v6.2.x/04-migrations/04-v2-to-v3.md b/docs/versioned_docs/version-v6.2.x/04-migrations/04-v2-to-v3.md index cf4e1c1b8e3..8cef606a1ad 100644 --- a/docs/versioned_docs/version-v6.2.x/04-migrations/04-v2-to-v3.md +++ b/docs/versioned_docs/version-v6.2.x/04-migrations/04-v2-to-v3.md @@ -136,7 +136,7 @@ type AnteDecorator struct { The `OnChanOpenTry` application callback has been modified. The return signature now includes the application version. -IBC applications must perform application version negoitation in `OnChanOpenTry` using the counterparty version. +IBC applications must perform application version negotiation in `OnChanOpenTry` using the counterparty version. The negotiated application version then must be returned in `OnChanOpenTry` to core IBC. Core IBC will set this version in the TRYOPEN channel. diff --git a/docs/versioned_docs/version-v6.2.x/04-migrations/07-v5-to-v6.md b/docs/versioned_docs/version-v6.2.x/04-migrations/07-v5-to-v6.md index 93f955568e3..ae398a45c7c 100644 --- a/docs/versioned_docs/version-v6.2.x/04-migrations/07-v5-to-v6.md +++ b/docs/versioned_docs/version-v6.2.x/04-migrations/07-v5-to-v6.md @@ -97,7 +97,7 @@ app.UpgradeKeeper.SetUpgradeHandler( In previous releases of ibc-go, chain developers integrating the ICS27 interchain accounts controller functionality were expected to create a custom `Base Application` referred to as an authentication module, see the section [Building an authentication module](../02-apps/02-interchain-accounts/03-auth-modules.md) from the documentation. -The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and faciliate many forms of message authentication depending on a chain's particular use case. +The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and facilitate many forms of message authentication depending on a chain's particular use case. Prior to ibc-go v6 the controller submodule exposed only these two functions (to which we will refer as the legacy APIs): diff --git a/docs/versioned_docs/version-v7.3.x/01-ibc/03-apps/05-packets_acks.md b/docs/versioned_docs/version-v7.3.x/01-ibc/03-apps/05-packets_acks.md index c6bf0e51cfc..07e29d74d51 100644 --- a/docs/versioned_docs/version-v7.3.x/01-ibc/03-apps/05-packets_acks.md +++ b/docs/versioned_docs/version-v7.3.x/01-ibc/03-apps/05-packets_acks.md @@ -28,7 +28,7 @@ channel, as well as how they will encode/decode it. This process is not specifie to each application module to determine how to implement this agreement. However, for most applications this will happen as a version negotiation during the channel handshake. While more complex version negotiation is possible to implement inside the channel opening handshake, a very -simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). +simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go). Thus, a module must define its custom packet data structure, along with a well-defined way to encode and decode it to and from `[]byte`. diff --git a/docs/versioned_docs/version-v7.3.x/02-apps/01-transfer/08-authorizations.md b/docs/versioned_docs/version-v7.3.x/02-apps/01-transfer/08-authorizations.md index 0519e63d556..1f207c0fa35 100644 --- a/docs/versioned_docs/version-v7.3.x/02-apps/01-transfer/08-authorizations.md +++ b/docs/versioned_docs/version-v7.3.x/02-apps/01-transfer/08-authorizations.md @@ -20,7 +20,7 @@ It takes: - a `SourcePort` and a `SourceChannel` which together comprise the unique transfer channel identifier over which authorized funds can be transferred. -- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transfered, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes. +- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transferred, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes. - an `AllowList` list that specifies the list of addresses that are allowed to receive funds. If this list is empty, then all addresses are allowed to receive funds from the `TransferAuthorization`. diff --git a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md index 4b640e2b10c..c0893883017 100644 --- a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md +++ b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md @@ -22,7 +22,7 @@ If you wish to consume and execute custom logic in the packet callbacks, then pl ## Redirection to a smart contract It may be desirable to allow smart contracts to control an interchain account. -To faciliate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers. +To facilitate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers. An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementors of this use case are recommended to follow the ADR 008 approach. diff --git a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md index 70cc36b8a69..96aca51c763 100644 --- a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md +++ b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md @@ -134,7 +134,7 @@ func (im IBCModule) OnChanCloseInit( } // OnRecvPacket implements the IBCModule interface. A successful acknowledgement -// is returned if the packet data is succesfully decoded and the receive application +// is returned if the packet data is successfully decoded and the receive application // logic returns without error. func (im IBCModule) OnRecvPacket( ctx sdk.Context, diff --git a/docs/versioned_docs/version-v7.3.x/04-middleware/01-ics29-fee/01-overview.md b/docs/versioned_docs/version-v7.3.x/04-middleware/01-ics29-fee/01-overview.md index b1e85bfb9eb..631e28bff55 100644 --- a/docs/versioned_docs/version-v7.3.x/04-middleware/01-ics29-fee/01-overview.md +++ b/docs/versioned_docs/version-v7.3.x/04-middleware/01-ics29-fee/01-overview.md @@ -35,7 +35,7 @@ To achieve the stated requirements, the **fee middleware module has two main gro This is described in the [Fee messages section](03-msgs.md). -We complete the introduction by giving a list of definitions of relevant terminolgy. +We complete the introduction by giving a list of definitions of relevant terminology. `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain). diff --git a/docs/versioned_docs/version-v7.3.x/04-middleware/02-callbacks/03-interfaces.md b/docs/versioned_docs/version-v7.3.x/04-middleware/02-callbacks/03-interfaces.md index 0c05b1bb27b..566e4ebb4e2 100644 --- a/docs/versioned_docs/version-v7.3.x/04-middleware/02-callbacks/03-interfaces.md +++ b/docs/versioned_docs/version-v7.3.x/04-middleware/02-callbacks/03-interfaces.md @@ -66,7 +66,7 @@ Since middlewares do not have packet types, they do not need to implement this i ### `ContractKeeper` -The callbacks middleware requires the secondary application to implement the [`ContractKeeper`](https://github.com/cosmos/ibc-go/blob/v7.3.0/modules/apps/callbacks/types/expected_keepers.go#L11-L83) interface. The contract keeper will be invoked at each step of the packet lifecycle. When a packet is sent, if callback information is provided, the contract keeper will be invoked via the `IBCSendPacketCallback`. This allows the contract keeper to prevent packet sends when callback information is provided, for example if the sender is unauthroized to perform callbacks on the given information. If the packet send is successful, the contract keeper on the destination (if present) will be invoked when a packet has been received and the acknowledgement is written, this will occur via `IBCReceivePacketCallback`. At the end of the packet lifecycle, when processing acknowledgements or timeouts, the source contract keeper will be invoked either via `IBCOnAcknowledgementPacket` or `IBCOnTimeoutPacket`. Once a packet has been sent, each step of the packet lifecycle can be processed given that a relayer sets the gas limit to be more than or equal to the required `CommitGasLimit`. State changes performed in the callback will only be committed upon successful execution. +The callbacks middleware requires the secondary application to implement the [`ContractKeeper`](https://github.com/cosmos/ibc-go/blob/v7.3.0/modules/apps/callbacks/types/expected_keepers.go#L11-L83) interface. The contract keeper will be invoked at each step of the packet lifecycle. When a packet is sent, if callback information is provided, the contract keeper will be invoked via the `IBCSendPacketCallback`. This allows the contract keeper to prevent packet sends when callback information is provided, for example if the sender is unauthorized to perform callbacks on the given information. If the packet send is successful, the contract keeper on the destination (if present) will be invoked when a packet has been received and the acknowledgement is written, this will occur via `IBCReceivePacketCallback`. At the end of the packet lifecycle, when processing acknowledgements or timeouts, the source contract keeper will be invoked either via `IBCOnAcknowledgementPacket` or `IBCOnTimeoutPacket`. Once a packet has been sent, each step of the packet lifecycle can be processed given that a relayer sets the gas limit to be more than or equal to the required `CommitGasLimit`. State changes performed in the callback will only be committed upon successful execution. ```go // ContractKeeper defines the entry points exposed to the VM module which invokes a smart contract diff --git a/docs/versioned_docs/version-v7.3.x/05-migrations/04-v2-to-v3.md b/docs/versioned_docs/version-v7.3.x/05-migrations/04-v2-to-v3.md index d32237692ae..8bd1455f8dd 100644 --- a/docs/versioned_docs/version-v7.3.x/05-migrations/04-v2-to-v3.md +++ b/docs/versioned_docs/version-v7.3.x/05-migrations/04-v2-to-v3.md @@ -136,7 +136,7 @@ type AnteDecorator struct { The `OnChanOpenTry` application callback has been modified. The return signature now includes the application version. -IBC applications must perform application version negoitation in `OnChanOpenTry` using the counterparty version. +IBC applications must perform application version negotiation in `OnChanOpenTry` using the counterparty version. The negotiated application version then must be returned in `OnChanOpenTry` to core IBC. Core IBC will set this version in the TRYOPEN channel. diff --git a/docs/versioned_docs/version-v7.3.x/05-migrations/07-v5-to-v6.md b/docs/versioned_docs/version-v7.3.x/05-migrations/07-v5-to-v6.md index 93f955568e3..ae398a45c7c 100644 --- a/docs/versioned_docs/version-v7.3.x/05-migrations/07-v5-to-v6.md +++ b/docs/versioned_docs/version-v7.3.x/05-migrations/07-v5-to-v6.md @@ -97,7 +97,7 @@ app.UpgradeKeeper.SetUpgradeHandler( In previous releases of ibc-go, chain developers integrating the ICS27 interchain accounts controller functionality were expected to create a custom `Base Application` referred to as an authentication module, see the section [Building an authentication module](../02-apps/02-interchain-accounts/03-auth-modules.md) from the documentation. -The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and faciliate many forms of message authentication depending on a chain's particular use case. +The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and facilitate many forms of message authentication depending on a chain's particular use case. Prior to ibc-go v6 the controller submodule exposed only these two functions (to which we will refer as the legacy APIs):