Optional field to specify relayer address for recv packet delivery

[womensrights]

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]

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]

Adding for reference https://github.com/cosmos/ibc-go/issues/1835, where basically the same functionality was requested.

[AdityaSripal]

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