Grouping Destination-Chain Transactions

[LayneHaber]

Motivation

Right now, having both the ReceiverPrepare and the ReceiverFulfill in separate transactions have a couple of downsides:

• Arbitrageurs wanting to use the system need to have the funds moved across chains within a single block on the chain where the opportunity is spotted to be competitive. Having 2-step process on the receiving chain makes this difficult
• Routers can be griefed for cancellation fees on the receiving chain. Senders can prepare for some amount, routers will pick it up, and sender could simply not fulfill. If the sender is going from a cheap chain (i.e. polygon) to a more expensive one (i.e. mainnet) then their gas costs for SenderPrepare / SenderCancel are negligible if they don't mind leaving the capital locked for the expiry. The router, on the other hand, would have their funds locked up as well and pay substantial gas fees for ReceiverPrepare / ReceiverCancel. If you bundled the prepare and completion transaction, this risk would be eliminated.

Considerations

Pros:

• Routers could not be griefed
• It is much faster for the user to execute the onchain operations
• Overall gas savings on the receiving chain by bundling both transactions

Cons:

• The user doesn't know the router ahead of time, this means they have to have some message delivered to them with the router info to put onchain
• Users have to be assured the fulfill and prepare work, otherwise they reveal the unlock data and could be rugged by the router. This is difficult as prepare liquidity could be race-y with overbidding

Key Questions

1. How can users be assured both the prepare and fulfill will succeed onchain?
2. Is there any way to make this work without adding an additional roundtrip message to the user?

Potential Solutions

If the true security risk is the receiver won't prepare properly, then perhaps routers could stop overbidding in attempts to alleviate the griefing vectors. Auctioneers could invalidate bids using this condition and knowledge of what has been put onchain.

Still unclear on how to do this without adding an auctioneer <> user message. Either the user discloses the fulfill information to the auctioneer, who bundles both receiver transactions or the auctioneer returns the information to the user. If we were able to penalize if the router never provably did a receiver prepare, perhaps we could prevent this collusion.

Open to suggestions here!

[jakekidd]

Well, let's review the reason why we need to have a ReceiverPrepare (in a separate block) the first place. Stating the obvi, but whatevs:

• It locks up the liquidity promised to the user.
• It attaches the appropriate transfer data to this locked liquidity, enabling that user and only that user to call ReceiverFulfill.
• It functions as a data availability layer; or at least, the prepare event leads to data availability on the subgraph.

Let's say the user basically submits a SenderPrepare with a certain defined slippage, minimum received, etc. The router assigned that transfer via auctionless could then submit a ReceiverFulfill that fits the conditions laid out by the user (it's within slippage range, minimum received, etc.).

Auctions on tendermint functions as the thing that guarantees that that particular router was the one assigned the transaction, and that it was (provably) because it was the best bid.

However, the only way the router is going to do ReceiverFulfill is if they are guaranteed to be able to use it to SenderFulfill on the sending chain for the full amount. We can't produce a natural chain-agnostic proof that "I am the router that did ReceiverFulfill for this transfer, for the proper amount".

I see a couple options atm:

• We could use Nomad as a transport layer to convey the proof that the ReceiverFulfill occurred, along with its attached transfer data (e.g. who fulfilled, for how much, etc.) back to the sending chain.

• Or you could use the fractional pools / warrants proposal (the "ReceiverPrepare ahead of time" idea). You actually don't necessarily need the user to validate in that case (due to warrants filling in for that), but it does mean that we rely on a watcher network continuing to be active.

Personally I would advocate for the former of these two ^. Nomad seems an elegant solution because we could price in the 30 min wait times that detract from capital efficiency and make it so the user has no dependency on the Nomad network.

[LayneHaber]

This is no longer relevant with the new direction.