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/tutorials/02-channel-upgrades/05-upgrade-channel.md b/docs/tutorials/02-channel-upgrades/05-upgrade-channel.md
index 421c9fafb6e..d9addbacc10 100644
--- a/docs/tutorials/02-channel-upgrades/05-upgrade-channel.md
+++ b/docs/tutorials/02-channel-upgrades/05-upgrade-channel.md
@@ -122,7 +122,7 @@ proposals:
 
 Now we wait for the relayer to complete the upgrade handshake.
 
-## Check ugprade completed
+## Check upgrade completed
 
 Once the handshake has completed we verify that the channel has successfully upgraded:
 
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