From bcc952f4beff71c1e052f060c68748fa92d2a8ea Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 21:09:44 +0300 Subject: [PATCH] typo README.md --- x/tokenfilter/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/tokenfilter/README.md b/x/tokenfilter/README.md index 2792ab70e2..ca7a51b397 100644 --- a/x/tokenfilter/README.md +++ b/x/tokenfilter/README.md @@ -7,7 +7,7 @@ their native token within their state machine. ## Context -When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholdent to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholden to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`. +When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholden to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholden to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`. This context is important in recognising when a native token is returning to its origin state machine. Each IBC packet contains metadata including the source port and channel. Therefore if the denomination of the token is prefixed with the same source port and channel as detailed in the packet, we can conclude that the denomination originally came from the receiving chain.