diff --git a/docs/docs/adrs/adr-008-throttle-retries.md b/docs/docs/adrs/adr-008-throttle-retries.md
index 134214fffb..1faf7bd7ee 100644
--- a/docs/docs/adrs/adr-008-throttle-retries.md
+++ b/docs/docs/adrs/adr-008-throttle-retries.md
@@ -9,6 +9,7 @@ title: Throttle with retries
 
 * 6/9/23: Initial draft
 * 6/22/23: added note on consumer pending packets storage optimization
+* 7/14/23: Added note on upgrade order
 
 ## Status
 
@@ -47,6 +48,8 @@ With the behavior described, we maintain very similar behavior to the current th
 
 In the normal case, when no or a few slash packets are being sent, the VSCMaturedPackets will not be delayed, and hence unbonding will not be delayed.
 
+For implementation of this design, see [throttle_retry.go](../../../x/ccv/consumer/keeper/throttle_retry.go).
+
 ### Consumer pending packets storage optimization
 
 In addition to the mentioned consumer changes above. An optimization will need to be made to the consumer's pending packets storage to properly implement the feature from this ADR.
@@ -86,9 +89,11 @@ If a consumer sends VSCMatured packets too leniently: The consumer is malicious
 
 If a consumer blocks the sending of VSCMatured packets: The consumer is malicious and blocking vsc matured packets that should have been sent. This will block unbonding only up until the VSC timeout period has elapsed. At that time, the consumer is removed. Again the malicious behavior only creates a negative outcome for the chain that is being malicious.
 
-### Splitting of PRs
+### Splitting of PRs and Upgrade Order
+
+This feature will implement consumer changes in [#1024](https://github.com/cosmos/interchain-security/pull/1024). Note these changes should be deployed to prod for all consumers before the provider changes are deployed to prod. That is the consumer changes in #1024 are compatible with the current ("v1") provider implementation of throttling that's running on the Cosmos Hub as of July 2023.
 
-We could split this feature into two PRs, one affecting the consumer and one affecting the provider, along with a third PR which could setup a clever way to upgrade the provider in multiple steps, ensuring that queued slash packets at upgrade time are handled properly.
+Once all consumers have deployed the changes in #1024, the provider changes from (TBD) can be deployed to prod, fully enabling v2 throttling.
 
 ## Consequences
 
diff --git a/x/ccv/consumer/keeper/throttle_retry.go b/x/ccv/consumer/keeper/throttle_retry.go
index ef41872ebf..128bc53bad 100644
--- a/x/ccv/consumer/keeper/throttle_retry.go
+++ b/x/ccv/consumer/keeper/throttle_retry.go
@@ -26,7 +26,6 @@ import (
 // - If the consumer receives a V1Result ack from the provider, the consumer checks for a slash record,
 // and if found, the consumer transitions from "Standby" to "No Slash". The slash record is cleared upon this transition,
 // and the slash packet is popped from the pending packets queue.
-// TODO: Make note of above design for v1 throttling providers in the ADR, and explain that consumers must upgrade first in prod (where double queueing may exist for some time).
 //
 // - Else if the consumer receives a reply from the provider that the slash packet was successfully handled,
 // the consumer transitions from "Standby" to "No Slash". The slash record is cleared upon this transition,