diff --git a/EIPS/eip-7281.md b/EIPS/eip-7281.md
index ce4dd57c441f58..f1d0bbbcfb02da 100644
--- a/EIPS/eip-7281.md
+++ b/EIPS/eip-7281.md
@@ -329,7 +329,8 @@ Case (3) is the most challenging to solve for as issuers may not have sovereign
 3. Deploy a lockbox on the home domain which locks the home canonical token and mints a new xERC-20.
 4. Allowlist all desired bridges *including* the canonical bridge that owns the legacy implementation, mapping the xERC-20 representation on the home domain to the xERC-20 representation on the remote.
 5. At this point, it is fully possible for users to begin transferring the token across all bridges as would be expected from the xERC-20 standard. However, note that the canonical bridge connecting home to remote will now have two bridge paths: (a) ERC-20→ERC-20 (locking the ERC-20 at home), and (b) xERC-20→xERC-20. Now, the issuer can begin the process of sunsetting the legacy canonical ERC-20 on the remote domain.
-6. The issuer should at this point disallow minting *new* legacy canonical ERC-20s on the remote domain and only allow users to bridge ERC-20s *back* to the home domain (by unwrapping xERC-20 on the remote). This would organically & gradually lead to the ERC-20 on the home chain becoming unlocked from the home<>remote canonical bridge, but token issuers can also incentivize this behavior if there is a desire for it to occur more quickly.
+6. The issuer should at this point disallow minting *new* legacy canonical ERC-20s on the remote domain. This would organically & gradually lead to the legacy ERC-20s on the remote chain to become locked into the lockbox.
+7. At any point in the future, the token issuer can then use their own treasury to unwrap xERC-20s on the remote domain into legacy ERC-20s and send them back to the home chain, incurring the latency of this on behalf of users.
 
 ### Compatibility with Bridges