Multipath

[LayneHaber]

Summary

This feature refers to the process of routing the same payment through multiple routers, and is extremely useful for allowing large payments through the network.

Motivation

To facilitate large payments in the network, we need the ability to break up payments so they are spread across multiple routers and may all be fulfilled atomically. If this is not allowed, the network will either require extremely large routers or be unable to support large payments.

Proposed Solution

The FulfilledTransaction implemented here should be updated to include a Route[] object. This can be pulled on reconcile.

struct RouteData {
  address router; // router putting up liquidity
  uint256 amount; // amount router is putting up
}

struct FulfilledTransaction {
  ...
  RouteData[] route; // Hardcap number of routers able to be included in multipath
}

The TransactionManager will also need to set a configurable MAX_ROUTERS variable to check the length of the RoutingData[] supplied and prevent unbounded gas usage. An owner-only setMaxRouters function will also have to be exposed.

Then in the core functions:

function fulfill(...) {
  // Verify the transaction
  
   // Store the route onchain

  // Deduct funds from each router in the route
  
  // Send funds to user
 }

function reconcile(CancelArgs args) {
  // Get the stored route

  // For each router in the route
  // - refund locked funds
}

Test Cases

The following tests should be implemented:

it("should work with multiple routers in the path", () => { ... })
it("should work with a single router in the path", () => { ... })
it("should fail if any of the routers do not have enough liquidity", () => { ... })
it("should fail if the user did not sign the correct route", () => { ... })

Outstanding Questions

• How exactly this would integrate with Multihop #761 remains a bit unclear. Presumably, the router on the intermediary chain is able to prepare same as a user (without specifying route), but the following transaction cannot be a multihop transaction. It's possible the boolean flag will be sufficient within the RoutingData, but could be different.

Tasks

[sanchaymittal]

• How will the Transaction Data for multipath look like? Can we map the router with the price(via VAmm) they are offering?
  Considering all the fee calculation happens onChain then only unique data associated with each router will be price & expiry.
  ref: Improve Event Data #753 (comment)

• Do we really need to Balance[] to be returned by MultipathConditionInterpreter, Can't we use it directly from txData?

[ArjunBhuptani]

Instead of using a specific interpreter/verifier for this, @LayneHaber and I discussed having multipath/multihop be built directly into the contracts given that it likely makes sense to separate the routing logic from the core security mechanisms enforced via verifiers.

A high level offchain spec for multipath probably looks like the following:

1. At time t, a user calls prepare on the origin chain with a large amount A of funds to send to a destination.
2. On the next "round", the auctioneer sees this transaction and begins accepting bids for it. Let us assume that there are no routers capable of executing the user's transfer within some defined slippage range.
3. At time t+d, where d is a fixed number of "rounds" that can be defined in terms of blocks/block time on the origin chain, the auctioneer now begins to accept bids for A/3 amount for the same transfer. Because d is independently determinable by routers, we can also assume that they make the switch to bidding for A/3 at the same time.
4. At time t+2d, routers now begin to bid A/5. If the auctioneer now receives 5 equal bids on the transaction, it can ship them off to Gelato as a single tx so that prepare can be called with all 5 signed bids in the same transaction.

Note: we likely don't want to split a tx beyond 5 paths because of gas cost limitations + complexity.
Note 2: if A is not evenly divisible, we can follow some basic heuristic like flooring to the nearest whole wei unit and taking the difference as additional (negligible) router fees.

If we assume the above offchain spec, this means that the txManager must:

• Allow for calling prepare with an array of signatures from routers (up to 5)
• Split the proceeds from the fulfill on origin chain to up to 5 routers

[jakekidd]

As a side-note I really like the idea of having auction rounds.

(Really activates my D&D brain)

[jakekidd]

Made a note here: #761 (comment)

on the additional consideration of "how does a user know whether a transfer is possible before doing sender prepare"?

[LayneHaber]

Updated the spec to reflect current thinking

[LayneHaber]

How could we do this without an EOA?

It seems like the only way to do this would be to rely on either (a) a signature by the end user needed on receiver fulfill or (b) some generic message relay back to the sending chain to put the provided route onchain for disbursing funds.

Is there a way to do this? Callers should know up front if they will be able to generate a signature, and they can put this into the TransactionData on SenderPrepare

[LayneHaber]

Contract changes done! Archiving