docs: fix typos (cosmos#5930)

* fix typo * fix typos * fix typo * fix typos --------- Co-authored-by: DimitrisJim <[email protected]>
notional-labs · Mar 7, 2024 · b49b39d · b49b39d
1 parent 6c8c50c
commit b49b39d
Show file tree

Hide file tree

Showing 4 changed files with 9 additions and 9 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -183,7 +183,7 @@ Technically, there are four docs being maintained in this repo:
 
 When referencing a markdown file, you should use relative file paths if they are in the same docs directory from above. For example, if you are in `docs/docs/01-ibc` and want to link to `docs/docs/02-apps/01-transfer/01-overview.md`, you should use the relative link `../02-apps/01-transfer/01-overview.md`.
 
-If the file you are referencing is in a different docs directory, you should use a absolute URL. For example, if you are in `docs/docs/01-ibc` and want to link to `docs/architecture/adr-001-coin-source-tracing.md`, you should use the absolute URL (not absolute file path), in this case `/architecture/adr-001-coin-source-tracing`. You can find the absolute URL by looking at the slug in the frontmatter of the markdown file you want to link to. If the frontmatter slug is not set (such as in `docs/architecture/adr-001-coin-source-tracing.md`), you should use the url that docusaurus generates for it. You can find this by looking at the url of the page in the browser.
+If the file you are referencing is in a different docs directory, you should use an absolute URL. For example, if you are in `docs/docs/01-ibc` and want to link to `docs/architecture/adr-001-coin-source-tracing.md`, you should use the absolute URL (not absolute file path), in this case `/architecture/adr-001-coin-source-tracing`. You can find the absolute URL by looking at the slug in the frontmatter of the markdown file you want to link to. If the frontmatter slug is not set (such as in `docs/architecture/adr-001-coin-source-tracing.md`), you should use the url that docusaurus generates for it. You can find this by looking at the url of the page in the browser.
 
 Note that when referencing any file outside of the parent `docs/` directory, you should always use a hyperlink.
 

diff --git a/docs/requirements/channel-upgradability-requirements.md b/docs/requirements/channel-upgradability-requirements.md
@@ -152,7 +152,7 @@ Sample exception flows:
 | 3.04 | The `ChanUpgradeAck` datagram informs the chain of the timeout period specified by the counterparty for the upgrade process to complete | TBD | `Drafted` |
 | 3.05 | When channel is in `FLUSHING` state, no new packets are allowed to be sent | TBD | `Drafted` |
 | 3.06 | When channel is in `FLUSHING` state, it is only allowed to receive packets with sequence number smaller or equal than the sequence number of the last packet sent on the counterparty when the channel moved to `FLUSHING` state | TBD | `Drafted` |
-| 3.07 | When channel is in `FLUSHING` state and packets are acknowledged or timed out, if the counterparty-specified timeoud is reached, then the channel will be restored to its initial state, an error receipt will be written and the upgrade will be aborted | TBD | `Drafted` |
+| 3.07 | When channel is in `FLUSHING` state and packets are acknowledged or timed out, if the counterparty-specified timeout is reached, then the channel will be restored to its initial state, an error receipt will be written and the upgrade will be aborted | TBD | `Drafted` |
 | 3.08 | Once in-flight packets have been flushed, the channel state shall change from `FLUSHING` to `FLUSHCOMPLETE` | TBD | `Drafted` |
 | 3.09 | A relayer must initiate the `ChanUpgradeConfirm` datagram on the counterparty to inform of the timeout period specified by the counterparty for the upgrade process to complete | TBD | `Drafted` |
 | 3.10 | Successful execution of the `ChanUpgradeConfirm` datagram when the channel state is `FLUSHCOMPLETE` changes the channel state to `OPEN` | TBD | `Drafted` |

diff --git a/docs/requirements/ics08-requirements.md b/docs/requirements/ics08-requirements.md
@@ -32,19 +32,19 @@ it becomes a proper solution to port the code for ibc-go to interpret without re
 
 ## Objectives
 
-The objective of this module is to have allow two chains with heterogenous consensus algorithms being connected through light clients that are not necesarily written in Go, but compiled to Wasm instead.
+The objective of this module is to have allow two chains with heterogenous consensus algorithms being connected through light clients that are not necessarily written in Go, but compiled to Wasm instead.
 
 ## Scope
 
-The scope of this feature is to allow any implemention written in Wasm to be compliant with the interface 
+The scope of this feature is to allow any implementation written in Wasm to be compliant with the interface 
 expressed in [02-client `ClientState` interface](https://github.com/cosmos/ibc-go/blob/main/modules/core/exported/client.go#L44-L139).
 
 | Features               | Release |
 | ---------------------- | ------- |
 | Store light client contract bytecode by means of a governance proposal. | v1 |
 | Dispatch messages to a light client written in Wasm following the `ClientState` interface. | v1 |
 | Migrate the contract instance of a light client to a newer contract bytecode. | v1 |
-| Remove checksums from the list of allowed checksums to dissalow contract instantiation. | v1 |
+| Remove checksums from the list of allowed checksums to disallow contract instantiation. | v1 |
 | Support GRANDPA light client. | v1 |
 
 # User requirements
@@ -108,7 +108,7 @@ The first use case that this module will enable is the connection between GRANDP
 
 | ID | Description | Verification | Status | Release |
 | -- | ----------- | ------------ | ------ | ------- |
-| 6.01 | The 08-wasm module must ensure that the contracts do not remove or corrupt the the stored client state state. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/types/vm.go#L227). | `Verified` | v0.1.0 | 
+| 6.01 | The 08-wasm module must ensure that the contracts do not remove or corrupt the stored client state state. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/types/vm.go#L227). | `Verified` | v0.1.0 | 
 | 6.02 | The 08-wasm module must ensure that the contracts do not include in the response to sudo, instantiate or migrate calls messages, events or attributes. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/types/vm.go#L300). |  `Verified` | v0.1.0 | 
 
 # External interface requirements
@@ -121,4 +121,4 @@ The first use case that this module will enable is the connection between GRANDP
 | -- | ----------- | ------------ | ------ | ------- |
 | 6.01 | There shall be a CLI command available to query the bytecode of a light client Wasm contract by checksum. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/keeper/grpc_query.go#L23). | `Verified` | v0.1.0 |
 | 7.02 | There shall be a CLI command available to query the checksums for all deployed light client Wasm contracts. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/keeper/grpc_query.go#L49). | `Verified` | v0.1.0 |
-<!-- markdown-link-check-enable-->
+<!-- markdown-link-check-enable-->
diff --git a/docs/requirements/ics27-v2-requirements.md b/docs/requirements/ics27-v2-requirements.md
@@ -4,7 +4,7 @@
 
 ## Problem
 
-We believe that the lack of controller chains so far have been because:
+We believe that the lack of controller chains so far has been because:
 
 - We did not develop a standardized authentication module, which created a bottleneck for chains looking to integrate the controller submodule.
 - We did not have a clear understanding of all the use cases ICA would facilitate.
@@ -66,7 +66,7 @@ See section [Definitions](https://github.com/cosmos/ibc/blob/main/spec/app/ics-0
 
 | ID  | Description | Verification | Status | Release |
 | --- | ----------- | ------------ | ------ | ------- |
-| 2.01 | An application shall have the ability to use an RPC endpoint to submit transactions to be executed on the host chain on the behalf of the interchain account. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v6.0.0/modules/apps/27-interchain-accounts/controller/keeper/msg_server_test.go#L31) | `Verified` | v6.0.0 |
+| 2.01 | An application shall have the ability to use an RPC endpoint to submit transactions to be executed on the host chain on behalf of the interchain account. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v6.0.0/modules/apps/27-interchain-accounts/controller/keeper/msg_server_test.go#L31) | `Verified` | v6.0.0 |
 
 # Non-functional requirements