ICS20-2: Add Token Forwarding ability to ICS20-2 #1090

AdityaSripal · 2024-03-28T16:00:21Z

Allows users to atomically route their tokens through a series of paths with a single packet.

Desired properties:

Atomicity: Tokens either get fully sent to final destination chain and receiver or they return to original sender chain/sender. This means that on error or timeout, the intermediate chains must revert state such that there is no difference between their current state and their state prior to the original send (modulo unrelated state changes)
Correctness: The token denoms and all the escrow accounts across the path must be the exact same as it would be if the tokens travelled through each hop with a separate packet

Special thanks to the @strangelove-ventures team for working on the PFM middleware which serves as a precursor to this feature

jtieri · 2024-03-29T22:01:44Z

One important aspect of PFM is the ability to compose more complex user experiences by integrating multiple middleware in the stack together, so that you can essentially receive an ICS-20 transfer, perform some action on the intermediate chain, and then forward tokens to the destination

Example: A user wants to send tokens from a source chain to an intermediate chain. On the intermediate chain the funds will be received via OnRecvPacket, now that the funds are in the user account the tokens will be swapped in a liquidity pool for a new asset. If the swap is successful, forward the tokens received from the swap to a different account on a destination chain

With middleware this flow would involve wiring up the stack like this:

channel.OnRecvPacket
swap.OnRecvPacket
forward.OnRecvPacket
transfer.OnRecvPacket

Then when a packet comes in for an ICS-20 transfer, the swap middleware would call into the underlying app and that call would fall through to the transfer module so that the appropriate bookkeeping could take place to get funds into the user controlled account. Control would then be passed back up to the swap middleware where the swap could take place, the middleware would mutate the FungibleTokenPacketData so that the token denom and amount refer to the token that was received from the swap. Then control is passed to the forward middleware to initiate the forward.

Swap middleware

Bringing token forwarding into the ICS-20 protocol is amazing to hear, but I think preserving this type of composability for developers to build these more complicated experiences is an important aspect; otherwise, it becomes a bit less appealing.

crodriguezvega

Thank you for the quick turnaround with the changes, @AdityaSripal.

I did a first pass and left a few comments. I think my biggest gap of understanding at the moment is in the usage of channelForwardingAddresses (I think there might be some logic errors with that).

To help with the reasoning I tried to make a coupe of diagrams. Both go through the scenario where and error ack is written on the destination chain, but in one of them the middle hop is the source of the token and in the other one it is not.

(excalidraw link)

The diagram is not completely correct, because I think the logic to transfer/burn token on the middle hop needs to be adjusted a bit.

crodriguezvega · 2024-04-02T20:23:30Z

spec/app/ics-020-fungible-token-transfer/README.md

@@ -51,6 +51,7 @@ interface FungibleTokenPacketDataV2 {
 sender: string
 receiver: string
 memo: string
+ forwardingPath: []string


I think it would be nice to add some context and sample usages for this field in a paragraph below? I understand from the code below that this is a list of elements of the form {source port ID}/{source channel ID}, right?

It would also be good to update the sentence "and receiving account or FungibleTokenPacketDataV2 which specifies multiple tokens being sent between sender and receiver" on line 38 that v2 also support the forwarding path.

spec/app/ics-020-fungible-token-transfer/README.md

crodriguezvega · 2024-04-03T08:18:58Z

spec/app/ics-020-fungible-token-transfer/README.md

@@ -92,6 +93,7 @@ The fungible token transfer bridge module tracks escrow addresses associated wit
 ```typescript
 interface ModuleState {
 channelEscrowAddresses: Map<Identifier, string>
+ channelForwardingAddresses: Map<Identifier, string>


Is this actually needed? It seems like we could manage by using channelEscrowAddresses only?

Unless I am missing something about the reasoning behind the separation

channelEscrowAddresses: Map<Identifier, string> channelForwardingAddresses: Map<Identifier, string>

I agree we could use directly channelEscrowAddresses. The channelEscrowAddresses mapping is populated during onChanOpenInit at line 157 or onChainOpenTry at line 181. That means we could potentially access this mapping at line 331 using the packet.destintionChannel as identifier.
Instead the channelForwardingAddresses is never set. Thus the read we do at line 331 may be illegal.

note cosmos/cosmos-sdk#7737 (comment)

If the only reason for using this is a logical separation, I think I would be in favour of simply using the escrow address. Having this other set of addresses adds to the overall complexity without adding a huge amount of value IMO.

And like @damiannolan is linking, the existing escrow address has already been reasoned about in terms of collisions.

spec/app/ics-020-fungible-token-transfer/README.md

sangier · 2024-04-04T09:37:47Z

spec/app/ics-020-fungible-token-transfer/README.md

+ // send the tokens we received above to the next port and channel
+ // on the forwarding path
+ // and reduce the forwardingPath by the first element
+ nextSequence = sendFungibleTokens(


Suggested change

nextSequence = sendFungibleTokens(

nextPacketSequence = sendFungibleTokens(

sangier

Hello guys and thank you for the great work!

I have done a first review pass and left some comments and suggestions.
Overall, I found a bit complicated reasoning by hand on certain specific scenarios, thus I agree having quint spec would be much helpful to ensure certain properties are respected.

To analyse the function flows I derived with the help of GPT4 and this app.code2flow website some flowcharts diagrams that I repost here for reference in case they can be useful for others.

crodriguezvega

These diagrams helped me personally to reason through the flow of an error acknowledgement with a middle hop for the 4 scenarios that are handled in revertInFlightChanges.

(excalidraw link)

When doing this exercise, I noticed a couple of things that I left as comments.

spec/app/ics-020-fungible-token-transfer/README.md

Co-authored-by: Carlos Rodriguez <[email protected]>

crodriguezvega

Did another review, and left a couple of small comments, but this looks good to me now. Thank you @AdityaSripal for the specification and @sangier for reviewing and all the work on the quint spec.

spec/app/ics-020-fungible-token-transfer/README.md

sangier

I have updated the quint spec with multidenoms logic + tests and a couple of invariants. Note that timeout tests are skipped in quint as they would trigger the same refund/revert logic as the error acknowledgements tests.

After testing spec looks good to me!

Thanks @AdityaSripal and @crodriguezvega for all the work!

sangier

Hey guys, I have done another review pass for the latest changes and left some comments.

sangier · 2024-05-07T14:09:59Z

spec/app/ics-020-fungible-token-transfer/README.md

 sourcePort: string,
 sourceChannel: string,
 timeoutHeight: Height,
 timeoutTimestamp: uint64, // in unix nanoseconds
 ): uint64 {
+ // memo and forwardingPath cannot both be non-empty
+ abortTransactionUnless(memo != "" && forwardingPath != nil)


If my understanding is correct, with this check we want to ensure that the memo is not set if a forwardingPath exist.

However, if want to use ics20v2 with a multidenom packet from A to B without further actions required, kind like:

FungibleTokenPacketDataV2 { tokens: [ Token{ denom: uatom, amount: 500, trace: ["transfer/channel-1", "transfer/channel-4"], }, Token{ denom: btc, amount: 7, trace: ["transfer/channel-3"], } ], sender: cosmosexampleaddr1A, receiver: cosmosexampleaddr2B, memo: "", forwardingPath: {nil, ""}

This packet wouldn't pass this check, right?

Given:
abortUnless(True) = Pass
abortUnless(False) = Fail
The truth table, where 0 means empty, should be like this:

Memo ForwardingPath Result Case

0 0 Pass No Memo and No Forwarding

0 1 Pass Final Hop Memo eventually indicated in the Forwarding

1 0 Pass Memo indicated in the First Hop and No Forwarding

1 1 Fail Memo indicated in both First Hop and Forwarding

Shouldn't the expression be like:
abortTransactionUnless(memo != "" NAND forwardingPath.Hops != nil)?

Yes, I think you're right.

Actually, couldn't we get rid of one of of the two memos? If the memo supposed to trigger an action on the final destination of the tokens, why cannot we have something like this?

interface FungibleTokenPacketDataV2 { tokens: []Token sender: string receiver: string memo: string forwardingPath: ForwardingInfo } interface ForwardingInfo { hops: []Hop }

But then it would not be possible to trigger any action on intermediary hops. Is that desired behaviour?

spec/app/ics-020-fungible-token-transfer/README.md

sangier · 2024-05-07T14:21:27Z

spec/app/ics-020-fungible-token-transfer/README.md

 //check that next channel supports token forwarding
- channel = publicStore.get(forwardingPath[0].portID, forwardingPath[0].channelID)
- if channel.version != "ics20-2" && len(forwardingPath) > 1 {
+ channel = publicStore.get(forwardingPath.hops[0].portID, forwardingPath.hops[0].channelID)


Should this line be channel = provableStore.get(channelPath(forwardingPath.hops[0].portID, forwardingPath.hops[0].channelID)) ?

spec/app/ics-020-fungible-token-transfer/README.md

crodriguezvega

I think I don't understand yet the reason for having two memo fields, one in FungibleTokenPacketDataV2 and one in ForwardingInfo, if the memo is only going to trigger an action on the receiving chain...

crodriguezvega · 2024-05-14T10:56:32Z

spec/app/ics-020-fungible-token-transfer/README.md

 sourcePort: string,
 sourceChannel: string,
 timeoutHeight: Height,
 timeoutTimestamp: uint64, // in unix nanoseconds
 ): uint64 {
+ // memo and forwardingPath cannot both be non-empty
+ abortTransactionUnless(memo != "" && forwardingPath != nil)


Yes, I think you're right.

spec/app/ics-020-fungible-token-transfer/README.md

crodriguezvega · 2024-05-14T11:18:54Z

spec/app/ics-020-fungible-token-transfer/README.md

 sourcePort: string,
 sourceChannel: string,
 timeoutHeight: Height,
 timeoutTimestamp: uint64, // in unix nanoseconds
 ): uint64 {
+ // memo and forwardingPath cannot both be non-empty
+ abortTransactionUnless(memo != "" && forwardingPath != nil)


Actually, couldn't we get rid of one of of the two memos? If the memo supposed to trigger an action on the final destination of the tokens, why cannot we have something like this?

interface FungibleTokenPacketDataV2 { tokens: []Token sender: string receiver: string memo: string forwardingPath: ForwardingInfo } interface ForwardingInfo { hops: []Hop }

But then it would not be possible to trigger any action on intermediary hops. Is that desired behaviour?

spec/app/ics-020-fungible-token-transfer/README.md

crodriguezvega · 2024-05-27T07:30:31Z

spec/app/ics-020-fungible-token-transfer/README.md

+ // before propogating the error acknowledgement back to original sender chain
+ revertInFlightChanges(packet, prevPacket)
+ // write error acknowledgement
+ FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet failed"}


Probably this is fine, but just wanted to comment that in case of time out, the middle chains will propagate an error ack back to the sending chain. Would there be any implications for applications or middleware on the sending chain if the packet is error acknowledged instead of timed out?

Maybe change the message to make it more specific?

Suggested change

FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet failed"}

FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet timed out"}

spec/app/ics-020-fungible-token-transfer/README.md

gjermundgaraba · 2024-06-05T09:17:55Z

spec/app/ics-020-fungible-token-transfer/README.md

+ if len(forwardingPath.hops) > 0 {
+ //check that next channel supports token forwarding
+ channel = provableStore.get(channelPath(forwardingPath.hops[0].portID, forwardingPath.hops[0].channelID))
+ if channel.version != "ics20-2" && len(forwardingPath.hops) > 1 {


Does all the previous minting / transfer need to be reverted here, or is it implicit?

Yes, it's kinda implicit: if an error ack is returned then the datagram handler should not commit any state changes. But I agree, that maybe it would be good to mention this explicitly in the specs (maybe in ICS26? I cannot remember from the top of my head if we already do that...

gjermundgaraba · 2024-06-05T10:27:09Z

spec/app/ics-020-fungible-token-transfer/README.md

- // the packet timed-out, so refund the tokens
- refundTokens(packet)
+ // check if the packet sent is from a previously forwarded packet
+ prevPacket = privateStore.get(packetForwardPath(packet.sourcePort, packet.sourceChannel, packet.sequence))


I have an observation on the naming here from reading this quite fresh:
It took me quite a bit of time and mental gymnastic to get the packets straight in my head here (to be fair, this could just be because I am not so used to this).
In particular, I found it tricky to map all these names to the right context:

Forwarded packet

Previous packet

Sent packet

Received packet

Packet (in the context of onTimeout, onAck, OnRecv)

At first I thought it was an error that the timeout packet was sent in to revertInFlightChanges as sentPacket, because "surely the forwarded packet, aka prevPacket was the one we sent". But after rereading, I realized that forwardedPacket was not actually received packet. So it is correct, of course, but with all these names it was not so easy to make a mental model of the different packets.

Not sure what the best way to deal with this is, but perhaps there is a way we could tweak the names to make it a bit easier to grasp on first read.

This is good feedback; thanks, @gjermundgaraba. Maybe a diagram would also help; I can try to draw something in the next couple of days.

Thank you for the feedback @gjermundgaraba . Will mull over better naming, but if you have some suggestions feel free to share!

damiannolan · 2024-06-10T08:56:42Z

spec/app/ics-020-fungible-token-transfer/README.md

@@ -35,7 +35,7 @@ The IBC handler interface & IBC routing module interface are as defined in [ICS

 ### Data Structures

-Only one packet data type is required: `FungibleTokenPacketData`, which specifies the denomination, amount, sending account, and receiving account or `FungibleTokenPacketDataV2` which specifies multiple tokens being sent between sender and receiver. A v2 supporting chain can optionally convert a v1 packet for channels that are still on version 1.
+Only one packet data type is required: `FungibleTokenPacketData`, which specifies the denomination, amount, sending account, and receiving account or `FungibleTokenPacketDataV2` which specifies multiple tokens being sent between sender and receiver along with a forwarding path that can forward tokens further beyond the initial receiving chain. A v2 supporting chain can optionally convert a v1 packet for channels that are still on version 1.


I think we should state that this is optional explicitly.

Suggested change

Only one packet data type is required: `FungibleTokenPacketData`, which specifies the denomination, amount, sending account, and receiving account or `FungibleTokenPacketDataV2` which specifies multiple tokens being sent between sender and receiver along with a forwarding path that can forward tokens further beyond the initial receiving chain. A v2 supporting chain can optionally convert a v1 packet for channels that are still on version 1.

Only one packet data type is required: `FungibleTokenPacketData`, which specifies the denomination, amount, sending account, and receiving account or `FungibleTokenPacketDataV2` which specifies multiple tokens being sent between sender and receiver along with an optional forwarding path that can forward tokens further beyond the initial receiving chain. A v2 supporting chain can optionally convert a v1 packet for channels that are still on version 1.

damiannolan · 2024-06-10T09:00:34Z

spec/app/ics-020-fungible-token-transfer/README.md

+interface ForwardingInfo {
+ hops: []Hop
+ memo: string,
+}


Personally, I feel like the memo in FungibleTokenPacketData should cover this, and that we should not include a memo field in this data structure.

There would also be overlap between ForwardingInfo / Hop and the Trace type which includes the port id and channel id tuple.

Personally, I feel like the memo in FungibleTokenPacketData should cover this, and that we should not include a memo field in this data structure.

I understand the concern here is preventing unintentional middleware invocation from source chain or intermediary recving chain, but also thought about what if you can rather have a memo attached to each individual hop.

Spoke about this with @colin-axner and fine to keep this structure as introducing this on a per-hop basis is opening up a big rabbit hole of potential issues.

chatton

This is looking great! Had just a few small questions/comments

chatton · 2024-06-05T14:14:04Z

spec/app/ics-020-fungible-token-transfer/README.md

+ Token{
+ denom: uatom,
+ amount: 500,
+ trace: ["transfer/channel-1", "transfer/channel-4"],


I believe the trace needs to be updated to the new type trace

[ { "portID": "transfer", "channelID": "channel-1" }, { "portID": "transfer", "channelID": "channel-4" }, ]

The Hop type I guess could also be replaced with this type as it is functionally the same.

chatton · 2024-06-05T14:19:40Z

spec/app/ics-020-fungible-token-transfer/README.md

+
+#### Packet forward path
+
+Those `v2` packets that have non-empty forwarding information and should thus be forwarded, must be stored in the private store, so that an acknowledgement can be written for them when receiving an acknowledgement or timeout for the forwarded packet.


Suggested change

Those `v2` packets that have non-empty forwarding information and should thus be forwarded, must be stored in the private store, so that an acknowledgement can be written for them when receiving an acknowledgement or timeout for the forwarded packet.

The `v2` packets that have non-empty forwarding information and should thus be forwarded, must be stored in the private store, so that an acknowledgement can be written for them when receiving an acknowledgement or timeout for the forwarded packet.

chatton · 2024-06-05T14:40:50Z

spec/app/ics-020-fungible-token-transfer/README.md

+ hops: forwardingPath.hops[1:]
+ memo: forwardingPath.memo
+ }
+ if forwardingPath.hops == 1 {


Suggested change

if forwardingPath.hops == 1 {

if len(forwardingPath.hops) == 1 {

chatton · 2024-06-05T14:45:23Z

spec/app/ics-020-fungible-token-transfer/README.md

+ // we're on the last hop, we can set memo and clear
+ // the next forwardingPath
+ memo = forwardingPath.memo
+ nextForwardingPath = nil


stylistic nit here, rather than re-assigning to nil and using that as a special value, I think it would be a bit nicer to always have a non nil type here, and have something like a forwardingPath.hasNext() or forwardingPath.lastHop() or some sort of other mechanism which examines the state of the hops and can be used.

chatton · 2024-06-12T09:01:19Z

spec/app/ics-020-fungible-token-transfer/README.md

@@ -92,6 +93,7 @@ The fungible token transfer bridge module tracks escrow addresses associated wit
 ```typescript
 interface ModuleState {
 channelEscrowAddresses: Map<Identifier, string>
+ channelForwardingAddresses: Map<Identifier, string>


If the only reason for using this is a logical separation, I think I would be in favour of simply using the escrow address. Having this other set of addresses adds to the overall complexity without adding a huge amount of value IMO.

And like @damiannolan is linking, the existing escrow address has already been reasoned about in terms of collisions.

AdityaSripal added 2 commits March 26, 2024 14:52

add recv logic and revert logic on error ack/timeout

a40890b

multiple denoms but still support forwarding

b10ba74

AdityaSripal marked this pull request as ready for review March 28, 2024 16:01

AdityaSripal requested review from colin-axner, damiannolan and sangier as code owners March 28, 2024 16:01

crodriguezvega mentioned this pull request Mar 28, 2024

Add Token Forwarding to ICS20 #988

Closed

lint

1de6ca0

crodriguezvega reviewed Apr 3, 2024

View reviewed changes

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 3, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

sangier reviewed Apr 4, 2024

View reviewed changes

sangier requested changes Apr 4, 2024

View reviewed changes

crodriguezvega reviewed Apr 4, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

Apply suggestions from code review

675ccd8

Co-authored-by: Carlos Rodriguez <[email protected]>

make same changes for timeout

a42ea6e

This was referenced Apr 18, 2024

ics20v2-tokenForwarding cosmos/quint#1

Closed

ics20v2-tokenForwarding cosmos/quint#3

Open

AdityaSripal and others added 3 commits April 22, 2024 17:38

forwarding info struct, individual memos

2d98d83

fail early since forwarding must be atomic

eb6fbf5

address some small review comments

ab34a49

crodriguezvega approved these changes May 2, 2024

View reviewed changes

sangier approved these changes May 2, 2024

View reviewed changes

AdityaSripal added 2 commits May 7, 2024 11:46

only set memo on last hop

055ae83

fix merge

2e0f5da

sangier reviewed May 7, 2024

View reviewed changes

crodriguezvega reviewed May 14, 2024

View reviewed changes

sangier reviewed May 14, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed May 16, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

sangier reviewed May 16, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Outdated Show resolved Hide resolved

crodriguezvega reviewed May 27, 2024

View reviewed changes

address Stefano's and my review comments

a759ca6

gjermundgaraba reviewed Jun 5, 2024

View reviewed changes

spec/app/ics-020-fungible-token-transfer/README.md Show resolved Hide resolved

gjermundgaraba reviewed Jun 5, 2024

View reviewed changes

crodriguezvega mentioned this pull request Jun 5, 2024

Release v9 cosmos/ibc-go#6497

Open

24 tasks

gjermundgaraba reviewed Jun 5, 2024

View reviewed changes

cosmos deleted a comment from Vedat7711 Jun 5, 2024

missing bracket

2a71fbd

This was referenced Jun 6, 2024

ICS20, ICS27: Allow applications to propose version in onChanOpenTry #1108

Open

ICS20 v2 Support for path forwarding cosmos/ibc-go#6536

Open

Path forwarding: delete previous packet after packet lifecycle completes for next packet cosmos/ibc-go#6546

Open

damiannolan reviewed Jun 10, 2024

View reviewed changes

crodriguezvega mentioned this pull request Jun 10, 2024

ICS20v2 path forwarding: simplify revert in-flight changes #1110

Open

destinationChannel -> destChannel

0b4f63f

chatton reviewed Jun 12, 2024

View reviewed changes

	nextSequence = sendFungibleTokens(
	nextPacketSequence = sendFungibleTokens(

Memo	ForwardingPath	Result	Case
0	0	Pass	No Memo and No Forwarding
0	1	Pass	Final Hop Memo eventually indicated in the Forwarding
1	0	Pass	Memo indicated in the First Hop and No Forwarding
1	1	Fail	Memo indicated in both First Hop and Forwarding

	FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet failed"}
	FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet timed out"}


		#### Packet forward path

		Those `v2` packets that have non-empty forwarding information and should thus be forwarded, must be stored in the private store, so that an acknowledgement can be written for them when receiving an acknowledgement or timeout for the forwarded packet.

	Those `v2` packets that have non-empty forwarding information and should thus be forwarded, must be stored in the private store, so that an acknowledgement can be written for them when receiving an acknowledgement or timeout for the forwarded packet.
	The `v2` packets that have non-empty forwarding information and should thus be forwarded, must be stored in the private store, so that an acknowledgement can be written for them when receiving an acknowledgement or timeout for the forwarded packet.

	if forwardingPath.hops == 1 {
	if len(forwardingPath.hops) == 1 {

ICS20-2: Add Token Forwarding ability to ICS20-2 #1090

Are you sure you want to change the base?

ICS20-2: Add Token Forwarding ability to ICS20-2 #1090

Conversation

AdityaSripal commented Mar 28, 2024

jtieri commented Mar 29, 2024

crodriguezvega left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crodriguezvega Apr 2, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sangier Apr 3, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sangier left a comment

Choose a reason for hiding this comment

crodriguezvega left a comment • edited

Choose a reason for hiding this comment

crodriguezvega left a comment

Choose a reason for hiding this comment

sangier left a comment • edited

Choose a reason for hiding this comment

sangier left a comment

Choose a reason for hiding this comment

sangier May 7, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crodriguezvega left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chatton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crodriguezvega Apr 2, 2024 •

edited

sangier Apr 3, 2024 •

edited

crodriguezvega left a comment •

edited

sangier left a comment •

edited

sangier May 7, 2024 •

edited