docs: Path unwinding and forwarding requirements #6027
Conversation
womensrights
requested review from
colin-axner,
AdityaSripal,
crodriguezvega,
charleenfei,
damiannolan,
chatton,
DimitrisJim and
srdtrk
as code owners
WalkthroughThe recent update enhances the inter-blockchain communication (IBC) system by automating path unwinding and token forwarding for fungible tokens. This streamlines token transfers across blockchains, automatically finding optimal routes and enabling token forwarding to improve user experience. Changes
Recent Review DetailsConfiguration used: CodeRabbit UI Files selected for processing (1)
Files not reviewed due to errors (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/requirements/path-unwinding-forwarding -requirements.md (1 hunks)
Files not reviewed due to errors (1)
- docs/requirements/path-unwinding-forwarding-requirements.md (no review received)
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/requirements/path-unwinding-forwarding -requirements.md (1 hunks)
Files not reviewed due to errors (1)
- docs/requirements/path-unwinding-forwarding-requirements.md (no review received)
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/requirements/path-unwinding-forwarding -requirements.md (1 hunks)
Files not reviewed due to errors (1)
- docs/requirements/path-unwinding-forwarding-requirements.md (no review received)
| 3. The feature will have no impact on the existing function of a typical ICS-20 transfer where a native token is sent to another chain. | ||
| 4. Fees will be treated the same as with other IBC applications. | ||
| 5. The functionality to enable a specific action before forwarding is not in scope of these requirements. | ||
| 6. If a transfer contains multiple unique tokens, the unwinding functionality only needs to support a single denom, i.e. if there is a transfer containing a native token and 1 hop denom being sent from source to destination, unwinding should support unwinding the 1 hop denom and sending the native token directly to the destination. Support for transfer and unwind for native token and 2+ 1 hop denoms is not required. |
There was a problem hiding this comment.
Checking if I understood this correctly:
- If the transfer contains more than one denom (native and/or with >1 hops) and the user wants to do unwinding + forwarding, should we return an error and let the user know that the transfer should include only one denom?
- If the transfer contains more than one denom (native and/or with >1 hops) and the user wants to do forwarding, should we just forward all denoms through the same forwarding path?
There was a problem hiding this comment.
apologies for the delay, completely missed the notification
My thinking is that we want to be able to support the use case of transfer + supply liquidity and typically pools are 2 sided, maybe we could stretch to 3 asset pools but I think 2 asset pools should be sufficient to support initially. Therefore what I was hoping is that if you are on chain A, with token A and token C going to chain B, you would be able to send A and C to B, but C will route back from A -> C -> B so when it arrives it is still a 1 hop denom. I was hoping that you would be able to specify the forwarding path for up to 2 denoms but more its likely getting quite chaotic and messy I would assume and you only really need 2 typically for transfer + supply liquidity.
so in case 1, it should be ok with up to 2 different denoms.
case 2, the forwarding path should be specified per denom
happy to make some changes to clarify this
Description
This pr details the token path unwinding and token forwarding requirements document
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/).godoccomments.Files changedin the GitHub PR explorer.SonarCloud Reportin the comment section below once CI passes.Summary by CodeRabbit