Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional field to specify relayer address for recv packet delivery #1099

Open
womensrights opened this issue Apr 30, 2024 · 3 comments
Open
Labels
app Application layer. feature Possible future feature.

Comments

@womensrights
Copy link
Contributor

Problem

Using custom middleware in combination with ICS-20 has enabled cross-chain swap workflows where all of the swap instructions are encoded in the initial packet commitment for the workflow, which is plainly visible. A malicious actor - a relayer or block proposer, could take advantage of this and perform a sandwich attack by inserting a transaction before and after the Recv packet swap transaction to profit from their own trade through artificial price manipulation.

This problem is present in both single hop and multi-hop workflows - e.g. 1 hop example: swap ATOM on the Hub to OSMO on Osmosis, multi-hop example: swap ATOM on the Hub for TIA on Celestia, routing through Osmosis.

There is already a substantial volume of sandwichable flow in the ecosystem, which is likely to grow. A rough estimate today lies in the order of magnitude of 10s of millions of dollars.

Proposed Solution

Add in an optional field to IBC Recv packets, that can specify the relayer address that has to deliver the packet. This should be possible to add to all applications using unordered channels.

@hxrts
Copy link

hxrts commented Apr 30, 2024

Thanks for this @womensrights! I think it may make sense to add the acknowledgment as well. Then a single relayer would responsible for the entire happy path and payment could encompass that entire flow. Timeout, however, should be permissionless.

@crodriguezvega
Copy link
Contributor

crodriguezvega commented Apr 30, 2024

Adding for reference cosmos/ibc-go#1835, where basically the same functionality was requested.

@AdityaSripal
Copy link
Member

Then a single relayer would responsible for the entire happy path and payment could encompass that entire flow. Timeout, however, should be permissionless.

A single relayer still could. However, if we only allow Acknowledgement to be done by single relayer and that relayer goes down the acknowledgement will never get processed or timed out.

So we possibly have the packet lifecycle permanently frozen just as we had before.

Relayer software can choose to ignore acknowledgements that have an intended relayer. But in-protocol enforcement of this could lead to issues

@crodriguezvega crodriguezvega added app Application layer. feature Possible future feature. labels May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app Application layer. feature Possible future feature.
Projects
Status: No status
Development

No branches or pull requests

4 participants