From cedc20594c92a6185537e919e9344c1e82fd253e Mon Sep 17 00:00:00 2001 From: Odys Date: Fri, 4 Oct 2024 01:57:22 +0800 Subject: [PATCH] fix more typos --- docs/docs/03-light-clients/05-tendermint/01-overview.md | 2 +- .../03-light-clients/05-tendermint/01-overview.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/03-light-clients/05-tendermint/01-overview.md b/docs/docs/03-light-clients/05-tendermint/01-overview.md index 9f94d77980a..1a09c64e79f 100644 --- a/docs/docs/03-light-clients/05-tendermint/01-overview.md +++ b/docs/docs/03-light-clients/05-tendermint/01-overview.md @@ -23,7 +23,7 @@ The Tendermint client consists of two important structs that keep track of the s Each Tendermint Client is composed of a single `ClientState` keyed on the client ID, and multiple consensus states which are keyed on both the clientID and header height. Relayers can use the consensus states to verify merkle proofs of packet commitments, acknowledgements, and receipts against the `AppHash` of the counterparty chain in order to enable verified packet flow. -If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occuring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred. +If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occurring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred. ## Initialization diff --git a/docs/versioned_docs/version-v9.0.x/03-light-clients/05-tendermint/01-overview.md b/docs/versioned_docs/version-v9.0.x/03-light-clients/05-tendermint/01-overview.md index 9f94d77980a..1a09c64e79f 100644 --- a/docs/versioned_docs/version-v9.0.x/03-light-clients/05-tendermint/01-overview.md +++ b/docs/versioned_docs/version-v9.0.x/03-light-clients/05-tendermint/01-overview.md @@ -23,7 +23,7 @@ The Tendermint client consists of two important structs that keep track of the s Each Tendermint Client is composed of a single `ClientState` keyed on the client ID, and multiple consensus states which are keyed on both the clientID and header height. Relayers can use the consensus states to verify merkle proofs of packet commitments, acknowledgements, and receipts against the `AppHash` of the counterparty chain in order to enable verified packet flow. -If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occuring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred. +If a counterparty chain violates the CometBFT protocol in a way that is detectable to off-chain light clients, this misbehaviour can also be submitted to an IBC client by any off-chain actor. Upon verification of this misbehaviour, the Tendermint IBC Client will freeze, preventing any further packet flow from this malicious chain from occurring. Governance or some other out-of-band protocol may then be used to unwind any damage that has already occurred. ## Initialization