diff --git a/docs/architecture/adr-043-nft-module.md b/docs/architecture/adr-043-nft-module.md
index 814be6cb18..8c2f967b16 100644
--- a/docs/architecture/adr-043-nft-module.md
+++ b/docs/architecture/adr-043-nft-module.md
@@ -281,6 +281,15 @@ message QueryClassesResponse {
 }
 ```
 
+
+### Interoperability
+
+Interoperability is all about reusing assets between modules and chains. The former one is achieved by ADR-33: Protobuf client - server communication. At the time of writing ADR-33 is not finalized. The latter is achieved by IBC. Here we will focus on the IBC side.
+IBC is implemented per module. Here, we aligned that NFTs will be recorded and managed in the x/nft. This requires creation of a new IBC standard and implementation of it.
+
+For IBC interoperability, NFT custom modules MUST use the NFT object type understood by the IBC client. So, for x/nft interoperability, custom NFT implementations (example: x/cryptokitty) should use the canonical x/nft module and proxy all NFT balance keeping functionality to x/nft or else re-implement all functionality using the NFT object type understood by the IBC client. In other words: x/nft becomes the standard NFT registry for all Cosmos NFTs (example: x/cryptokitty will register a kitty NFT in x/nft and use x/nft for book keeping). This was [discussed](https://github.com/cosmos/cosmos-sdk/discussions/9065#discussioncomment-873206) in the context of using x/bank as a general asset balance book. Not using x/nft will require implementing another module for IBC.
+
+
 ## Consequences
 
 ### Backward Compatibility
@@ -299,6 +308,7 @@ This specification conforms to the ERC-721 smart contract specification for NFT
 
 ### Negative
 
++ New IBC app is required for x/nft
 
 ### Neutral