From 04e14a7079e18323c64d4e00e12cf77708d24701 Mon Sep 17 00:00:00 2001 From: vuittont60 <81072379+vuittont60@users.noreply.github.com> Date: Tue, 9 Jan 2024 17:04:29 +0800 Subject: [PATCH] docs: fix typos (#5552) --- docs/docs/01-ibc/04-middleware/02-develop.md | 2 +- docs/docs/01-ibc/05-upgrades/00-intro.md | 2 +- docs/requirements/channel-upgradability-requirements.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/docs/01-ibc/04-middleware/02-develop.md b/docs/docs/01-ibc/04-middleware/02-develop.md index 5ce750058e1..0f6ad9ea01c 100644 --- a/docs/docs/01-ibc/04-middleware/02-develop.md +++ b/docs/docs/01-ibc/04-middleware/02-develop.md @@ -32,7 +32,7 @@ type IBCMiddleware struct { keeper keeper.Keeper } -// NewIBCMiddleware creates a new IBCMiddlware given the keeper and underlying application +// NewIBCMiddleware creates a new IBCMiddleware given the keeper and underlying application func NewIBCMiddleware(app porttypes.IBCModule, k keeper.Keeper) IBCMiddleware { return IBCMiddleware{ app: app, diff --git a/docs/docs/01-ibc/05-upgrades/00-intro.md b/docs/docs/01-ibc/05-upgrades/00-intro.md index 386a0ebfe73..61711d35f01 100644 --- a/docs/docs/01-ibc/05-upgrades/00-intro.md +++ b/docs/docs/01-ibc/05-upgrades/00-intro.md @@ -9,7 +9,7 @@ slug: /ibc/upgrades/intro This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/requirements/channel-upgradability-requirements.md b/docs/requirements/channel-upgradability-requirements.md index 78cf9e6bdb3..87093b989b6 100644 --- a/docs/requirements/channel-upgradability-requirements.md +++ b/docs/requirements/channel-upgradability-requirements.md @@ -129,7 +129,7 @@ Sample exception flows: | ID | Description | Verification | Status | | -- | ----------- | ------------ | ------ | -| 1.01 | An on-chain parameter keeps a list of all connection IDs (e.g. [`connection-0`, `connection-1`]) for which channels are allowed to be upgraded for an upgrade proposed on a counterpary chain | TBD | `Drafted` | +| 1.01 | An on-chain parameter keeps a list of all connection IDs (e.g. [`connection-0`, `connection-1`]) for which channels are allowed to be upgraded for an upgrade proposed on a counterparty chain | TBD | `Drafted` | | 1.02 | The on-chain parameter of connection IDs can only be updated by an authorized actor (e.g. governance) | TBD | `Drafted` | ### 2 - Initiation @@ -138,7 +138,7 @@ Sample exception flows: | -- | ----------- | ------------ | ------ | | 2.01 | An upgrade initiated by an authorized actor (e.g. governance) is always allowed | TBD | `Drafted` | | 2.02 | A chain can configure a channel upgrade to be initiated automatically after a successful governance proposal | TBD | `Drafted` | -| 2.03 | After permission is granted for channels in a given connection to be upgraded, any relayer can continue the upgrade proposed on a counterpary chain | TBD |`Drafted` | +| 2.03 | After permission is granted for channels in a given connection to be upgraded, any relayer can continue the upgrade proposed on a counterparty chain | TBD |`Drafted` | | 2.04 | A channel upgrade will be initiated when both `ChannelEnd`s are in the `OPEN` state | TBD | `Drafted` | | 2.05 | In the case of a crossing hello, a channel upgrade can be initiated when the counterparty has also executed the `ChanUpgradeInit` datagram with compatible parameters in the case of a crossing hello | TBD | `Drafted` |