diff --git a/spec/core/ics-004-channel-and-packet-semantics/README.md b/spec/core/ics-004-channel-and-packet-semantics/README.md
index 56b6d90f0..652a70053 100644
--- a/spec/core/ics-004-channel-and-packet-semantics/README.md
+++ b/spec/core/ics-004-channel-and-packet-semantics/README.md
@@ -599,6 +599,20 @@ connectionEnd on the misbehaving chain prior to the misbehavior submission.
 Once frozen, it is possible for a channel to be unfrozen (reactivated) via governance processes once the misbehavior in
 the channel path has been resolved. However, this process is out-of-protocol.
 
+Example:
+
+Given a multi-hop channel path over connections from chain `A` to chain `E` and misbehaving chain `C`
+
+`A <--> B <--x C x--> D <--> E`
+
+Assume any relayer submits evidence of misbehavior to chain `B` and chain `D` to freeze their respective clients for chain `C`.
+
+A relayer may then provide a multi-hop proof of the frozen client on chain `B` to chain `A` to close the channel on chain `A`, and another relayer (or the same one) may also relay a multi-hop proof of the frozen client on chain `D` to chain `E` to close the channel end on chain `E`.
+
+However, it must also be proven that the frozen client state corresponds to a specific hop in the channel path.
+
+Therefore, a proof of the connection end on chain `B` with counterparty connection end on chain `C` must also be provided along with the client state proof to prove that the `clientID` for the client state matches the `clientID` in the connection end. Furthermore, the `connectionID` for the connection end MUST match the expected ID from the channel's `connectionHops` field.
+
 ```typescript
 function chanCloseFrozen(
   portIdentifier: Identifier,
@@ -617,11 +631,11 @@ function chanCloseFrozen(
     abortTransactionUnless(connection.state === OPEN)
 
     // lookup connectionID for connectionEnd corresponding to misbehaving chain
-    let connectionIdx = proofConnection.ConsensusProofs.length + 1
+    let connectionIdx = proofConnection.ConnectionProofs.length + 1
     abortTransactionUnless(connectionIdx < hopsLength)
     let connectionID = channel.ConnectionHops[connectionIdx]
     let connectionProofKey = connectionPath(connectionID)
-    let connectionProofValue = mProof.KeyProof.Value
+    let connectionProofValue = proofConnection.KeyProof.Value
     let frozenConnectionEnd = abortTransactionUnless(Unmarshal(connectionProofValue))
 
     // the clientID in the connection end must match the clientID for the frozen client state
diff --git a/spec/core/ics-033-multi-hop/README.md b/spec/core/ics-033-multi-hop/README.md
index 160e1b763..e873294e2 100644
--- a/spec/core/ics-033-multi-hop/README.md
+++ b/spec/core/ics-033-multi-hop/README.md
@@ -59,15 +59,15 @@ In terms of connection topology, a user would be able to determine a viable chan
 
 ### Multihop Relaying
 
-Relayers would deliver channel handshake and IBC packets as they currently do except that they are required to provide proof of the channel path. Relayers would scan packet events for the connectionHops field and determine if the packet is multi-hop by checking the number of hops in the field. If the number of hops is greater than one then the packet is a multi-hop packet and will need extra proof data.
+Relayers deliver channel handshake and IBC packets as they currently do except that they are required to provide proof of the channel path. Relayers scan packet events for the connectionHops field and determine if the packet is multi-hop by checking the number of hops in the field. If the number of hops is greater than one then the packet is a multi-hop packet and will need extra proof data.
 
 For each multi-hop channel (detailed proof logic below):
 
 1. Scan source chain for IBC messages to relay.
 2. Read the connectionHops field in from the scanned message to determine the channel path.
-3. Lookup connection endpoints via chain registry configuration and update the clients associated with the connections in the channel path to reflect the latest consensus state on the sending chain including the key/value to be proven.
-4. Query for proof of connection, and consensus state for each intermediate connection in the channel path.
-5. Query proof of packet or handshake message commitments on source chain.
+3. Using connection endpoints via chain registry configuration, query for required multi-hop proof heights and update client states along the channel path as necessary (see pseudocode implementation).
+4. Query proof of packet or handshake message commitments on source chain at the proof height used in step 3.
+5. Query for proof of connection, and consensus state for each intermediate connection in the channel path using proof heights determined in step 3.
 6. Submit proofs and data to RPC endpoint on receiving chain.
 
 Relayers are connection topology aware with configurations sourced from the [chain registry](https://github.com/cosmos/chain-registry).
@@ -88,7 +88,9 @@ In the second phase of querying a multi-hop proof, the relayer queries proofs of
 Multi-hop proof query algorithm.
 
 ![proof_verification.png](proof_verification.png)
-Multi-hop proof verfication logic. Pseudocode proof generation for a channel between `N` chains `C[0] --> C[i] --> C[N]`
+Multi-hop proof verfication logic.
+
+Proof generation pseudocode proof generation for a channel path with `N` chains: `C[0] --> C[i] --> C[N]`
 
 ```go