Liquidity and Relayer Fees

[LayneHaber]

Summary

Users should pay the costs associated with the onchain transactions for their crosschain transfer. They should be able to specify these fees upfront, separately from the bridged asset amount and possible liquidity fee, so it is easy to include the amount in the calldata as needed as shown in the below picture:

Motivation

There are costs associated with sending a transaction across chains, especially when arbitrary calldata is executed. The sequencer will be responsible for submitting these transactions via a relayer network (i.e. Gelato), but the user should be responsible for paying the incurred fees.

Charging for relaying transactions is notoriously difficult, as the fees are assessed in a dynamic environment and only the submitter is able to alter the actual costs paid. In an asynchronous, cross-domain environment this problem is compounded. Not only does gas work very differently in each domain, but when using permissioned calls the gas estimate on the destination domain must be made far in advance of when the call is executed. These calls will use slow-liquidity and must wait the nomad optimistic timeout (currently 30 minutes) to ensure only the correct data is used.

You can see a breakdown of alternative solutions here.

Needs

• Ability to get exact amount that will be transferred on the destination domain
  • This will allow users to interact with contracts that need an exact amount for functions executed on the destination domain (usually needs to be included in encoded calldata)
• Ability to separate liquidity and relayer fees

Wants

• Ability for user to pay relayer funds in the asset they are transferring or the native asset of the origin domain
• Ability for user to either (a) overpay relayer fee and get reimbursed or (b) send along an additional fee to “bump” the transaction

Proposed Solution

A step-by-step breakdown of this proposal is:

1. User decides they want to create a crosschain transaction, and must determine the relayerFee.

   1. If the user can calculate the gas costs on the frontend (i.e. offchain), they call sdk.estimateCost(). This function will:

      1. Get the gas used for the function via provider.estimateGas
      2. Get the price of the destination domain native asset via the ConnextOracle (can use the oracle with the best pricing)
      3. Get the price of the origin domain native asset via the ConnextOracle (can use the oracle with the best pricing)
      4. Convert estimated destination domain gas to origin domain native asset
      5. Increase estimated amount by percentage to account for (1) safe gasLimit buffer and (2) provide incentive for relayer

      NOTE: It will not be possible to calculate gas fees offchain if you are using the slow-liquidity path because the permissioned requires will fail without the properties set

   2. If the user must calculate the gas costs onchain, they will need to use an onchain library that will provide the following utility functions to calculate appropriate fees based on a provided amount of gas:

      interface ILibEstimates {
        // Called if you have oracles for origin (current) domain native asset
        // and the destination domain native asset. 
        function estimate(uint256 _gas) external returns (uint256);
      
        // Called if you have oracles for the origin (current) domain native asset
        // but not the destination domain native asset
        function estimate(uint256 _gas, uint256 _destinationPrice) external returns (uint256);
      
        // Called if you have no oracles on either domain. Prices in USD.
        function estimate(uint256 _gas, uint256 _destinationPrice, uint256 _originPrice); external returns (uint256);
      }

      These functions will return an appropriate amount of native asset to send along as a relayerFee for the transaction, including a bump for fees.

2. User gets relayerFee amount of native origin asset

   1. If the user needs to swap for relayerFee from the transacting asset to the origin asset, then there should be a library for doing that (in DAO cases, they likely start with some starting amount of their treasury, for example):

      interface ILibEstimates {
        // ... see above ...
      
        // Called when you have oracles for native asset <> transacting asset
      	function swapForNative(uint256 _amount, address _asset) returns (uint256);
      }

3. User calls xcall with amount of transacting asset and relayerFee of origin domain native asset

   1. The amount is sent across chains via nomad
   2. The relayerFee is custodied on the origin domain Connext.sol (but included in the ExecuteArgs that are forwarded to the destination domain)

4. Relayer sees gets the payload and independently determines if the relayerFee is sufficient

   1. If the fee is sufficient, the relayers submit the transaction and the sum total of the relayer fees earned per domain is incremented (this would be in a mapping(address => mapping(uint32 => uint256) relayerFees mapping stored onchain). The transferId the relayer supported is stored onchain.
   2. If the relayer fee is insufficient (e.g. because gas prices have gone up), user has two options:
      1. Call execute on the destination domain themselves and keep the relayer fee
      2. Call bump(transferId) on the origin domain to add value to their relayer fee

5. When a relayer decides to claim their fees they call initiateClaim(uint32 domain), which will use the following nomad router to send a claim to the specified domain:

   contract RelayerFeeRouter extends Router {
   
     // Constructs message and sends it out via local Home contract
     // Should only be callable by connext contract
     function send(uint32 domain, address recipient, uint256 earned, bytes32[] transactionIds) public { ... }
   }

   1. The initiateClaim function must use the msg.sender to track the earned relayer fees.

6. The handle function on the RelayerFeeRouter would call claimRelayerFee which would tally all of the additional bumps and transfer the amounts to the specified recipient.

Domain Requirements

1. AMM for native asset <> transacting asset on the origin domain
2. Wrapped version of the native asset on the destination domain. Using nomad asset is fine, but in that case it may make more sense for relayers to send it back
3. Nomad RelayerFeeRouter
4. (optional) Oracle for origin <> destination native asset

Test Cases

// ========= Connext.t.sol =========

// Should fail if msg.value is != relayer fee on xcall
function testRevertIfNotIncluded() public { ... }

// Should fail if wrong fee passed in on execute
function testRevertWrongFee() public { ... }

// Should send specified amount to relayer on execute
function testRelayerFeeWorks() public { ... }

// ========= LibFeeEstimate.t.sol =========

// Should work when gas provided
function testGasProvided() public { ... }

// Should work when gas and dest price provided
function testGasAndDestinationPriceProvided() public { ... }

// Should work when gas, dest, and origin price provided
function testGasAndBothPriceProvided() public { ... }

// Should swap for the exact calculated relayer fee
function testSwapForRelayerFee() public { ... }

Outstanding Questions

• How should this be extended to batching?

Tasks

• Create a LibFeeEstimates with the following interface:

library LibFeeEstimates {
  // Called if you have oracles for origin (current) domain native asset
  // and the destination domain native asset. 
 function estimate(uint256 _gas) external returns (uint256);

  // Called if you have oracles for the origin (current) domain native asset
  // but not the destination domain native asset
  function estimate(uint256 _gas, uint256 _destinationPrice) external returns (uint256);

  // Called if you have no oracles on either domain. Prices in USD.
  function estimate(uint256 _gas, uint256 _destinationPrice, uint256 _originPrice) external returns (uint256);

  // Called when you must swap for transacting asset for native asset
  function swapForExactNativeOut(...)
}

• Add logic to bridge + mint the relayerFee of native asset to BridgeMessage / BridgeRouter
• Add logic to include relayerFee amount in the CallParams, and debit the amount on xcall
• Add logic to send relayerFee to msg.sender on execute
• Create the nomad router + message
• Add logic to bump fee on origin domain

[jakekidd]

One potential thought I had here was - what if we optionally allowed a library for on-chain gas usage metering (using the gasLeft method) to be plugged in to the execute contract on the destination domain? gasLeft doesn't work on all chains, but it does work on eth mainnet, where the increased precision could significantly contribute to savings for the user. The Library contract could be deployed with the regular contract set, but just remain inactive for chains that don't support that feature (and/or chains where fees are low enough that it actually makes no difference).

Leftover gas funds could either be refunded to the user directly after paying out the relayer, or they could be stored in a Leftovers contract where those funds would be stored with ownership mapped to the user (like router relayer fees), so that they can re-use them for future transfers - which would directly contribute to future fee savings for repeat users.

[LayneHaber]

Think the idea of a Leftovers contract would add a decent amount of overhead (how do I handle the case where I have some amount of left overs but not enough for the fee? how can we ensure users can withdraw their leftovers if there are transactions in flight that allegedly depend on them?), but rebating the user directly could be interesting.

The problem is the asset they get rebated and where. If it sends the origin domain native asset through to the destination domain, then what they get rebated is the nomad representation of the destination domain asset, which they almost certainly don't want. When you do this to the relayers, you're doing it in bulk so they are able to send the funds back through which they can do without any slippage since they are sending through the nomad representation to get the adopted version on the origin.

Alternatively, if you use the destination domain native asset when you send from the origin domain, you're requiring that you have a way to swap for the destination native asset from either your transacting asset or your origin domain native asset so you can send that across domains. Here slippage is a concern since it's not a stable swap, and it's very unlikely this will work on new domains. You also add this AMM requirement for every origin domain <> destination domain combination, making it very unfriendly to new domains. You also have the user potentially facing 2x slippage for this as they swap to the nomad representation from the adopted representation.

If you just pass back the gas used and pay out in the origin domain asset, you end up looking like this spec, which has a lot of complexity for the relayer.

[jakekidd]

Think the idea of a Leftovers contract would add a decent amount of overhead

youre probs right lol

If it sends the origin domain native asset

Still not sure why this is on the table - it makes just as much sense to send the origin domain native asset as it does to send the transacting asset (shitcoin, stable, whatever) as far as I can tell. It's not like the value of one native token must necessarily track the value of another chain's native token - so it seems like this would just add 1 additional unnecessary swap to perform.

I would much rather send the destination native asset if it's possible - so some portion of the transfer carries with it a position valued in terms of ETH/MATIC/BSC/whatever token that will actually be used to pay for gas on the destination domain. If it's not possible, I really feel like we should just send the transacting asset as-is and use that to cover the relayer fees.

[LayneHaber]

To clarify that was always what was on the table ;)

Using the origin native asset puts a floor on the value of the coins you're transferring -- if we want to support any random shitcoin, I think it's difficult for the relayer to handle and we've had relayer networks confirm they would take origin domain native asset over random transacting asset.

As far as destination domain native asset goes, the main concern is getting access to all our supported destination domain native assets in situations where you are the default bridge/it's a new chain. Take milkomeda for instance. I don't think they have deep liquidity pools for FUSE, nor do I think it's reasonable to assume they will for a while.

Using origin domain native asset is:

• easier for user to get
• means no amm
• harder for relayer to handle (as they would get nomad flavor origin domain asset on the destination domain, but could easily port it back in bulk without facing slippage)

Using the destination domain asset is:

• a pain because user will definitely not have it, so means you have to seed an amm with that liquidity (and it would not be a stable swap so slippage is an issue)
• institutes a stricter AMM requirement on new chains
• much easier for relayer to reason about (native asset on destination domain)

[LayneHaber]

I do agree it's not ideal, especially since you're delivering an asset that could come from a chain the relayer doesn't support. However, I'm more comfortable (1) getting rid of the AMM requirements, (2) allowing the relayer to bridge back in bulk for no fees, and (3) relying on there being the most liquid pools for native asset<>stable coin pairs on the sending domain

[LayneHaber]

Updated

[jakekidd]

Ik it's just an example, but for 2.i, it should be a sep. lib, not ILibEstimates...

I'm wondering if you meant "there should be a separate library" as "they should have a separate library" or "we should implement one"?

[jakekidd]

For 4. we'll obviously have to have a discussion with gelato about this pattern, as they'll have to implement some off-chain stuff on their side for:

• a separate API for connext transfers that checks the origin chain's relayer fee bid
• some logic to handle the claiming at regular intervals (e.g. 24hrs)

However, we also need to discuss the fact that we'll basically be having the sequencer blindly submitting meta txs to gelato. I say 'blindly' because the alternative is that the sequencer does some awkward 'gatekeeping' and determines whether a user has posted enough relayer fee to merit relaying the tx.

This means that we now have a hard requirement for the sequencer to cache gelato task IDs, or we risk it sending in duplicate tasks (i.e. meta txs for the same transfer) multiple times. Not a big deal, but we certainly don't want to DOS gelato with the same transfer execute call 100 times just bc the user didn't bid enough relayer fee, lol.

[jakekidd]

Also, we may want to discuss a little more with gelato about having a more 'interactive' API. Maybe the sequencer could retrieve the user's relayer fee bid and POST request that to a gelato API to determine whether it's sufficient. Maybe gelato's POST metatx/task could return an error if the current relayer fee bid is insufficient. This would actually remove any caching requirement on our side to some degree.

I'm thinking in terms of how this affects the auction cycle, as well as how this will translate to UX.

It would be cool if the sequencer API could let the user know if the relayer fee is insufficient (i.e. "last time I asked gelato, X amount was rejected, sorry").

[LayneHaber]

a separate API for connext transfers that checks the origin chain's relayer fee bid

The relayer fee will also be passed through to the destination chain but yes they would need some checks to handle that.

we may want to discuss a little more with gelato about having a more 'interactive' API

This would be cool, could also help with estimating the fee offchain via sdk. I don't like the idea of the sequencer doing those checks though, especially since they're only preventing liquidity from being made available. By the time the sequencer accepts any bids the xcall on the origin chain that defines the fee has already been performed

[jakekidd]

yeah... not ideal situation with users being kinda blind to whether their relayer fee will take... but I see a lot of ways we could come up with a temporary solution.

[jakekidd]

Finally, there is a small potential "attack" vector here.... gelato essentially has a monopoly on all our metatxs. They could potentially stonewall transfers to get users to pay higher amounts (they won't do this obvi, but we should aim for trustless-ness here lol).

How can we make it so the relayer (whoever they may be lol) has an incentive to execute as soon as they see a transfer relayer fee that's sufficient for them? How do we prevent them from "holding out" in order to get higher fees?

This could especially become problematic as a contract like a DAO might have some behavior to deterministically raise their relayer bid on an interval.... the relayer could literally just watch as the bid goes up and cash out whenever they want (or when the bid deterministically hits maximum).

Might have to be glossed over for now... in the future when we aggregate multiple relayers (adding competition), this may be a non-issue

[LayneHaber]

Finally, there is a small potential "attack" vector here.... gelato essentially has a monopoly on all our metatxs. They could potentially stonewall transfers to get users to pay higher amounts (they won't do this obvi, but we should aim for trustless-ness here lol).

We can have multiple relay networks executing these transactions, that's not a problem at all. With increased competition holding out seems less likely, but the same problem exists across any application that uses relayers.

Also keep in mind that these relayers are networks not just individuals, so it's difficult to coordinate that stonewalling on their end as well

[jakekidd]

yep, let's scratch this issue for now, i think it's fine

[jakekidd]

Don't forget to add the bump method to the Tasks list above

[jakekidd]

Make it public lol... anyone can bump a user's transfer.... maybe this could feed into the whole third-party-relayer-fee sponsorship

[LayneHaber]

Depends on which chains they want to deploy their vault to. Although this does bring up an interesting point that in that design you don't really have the ability to account for any "bumped" amounts

[jakekidd]

For 3.ii

The relayerFee is custodied on the origin domain Connext.sol (but included in the ExecuteArgs that are forwarded to the destination domain)

I'm confused. The relayerFee is forwarded to the destination? Why? It might not even be accurate if the user bumps.

[jakekidd]

To clarify, the relayerFee should still be passed in as an argument for xcall, because, for example, the user might be transferring native tokens, and the contract would need to separate out the native token for transferring vs the native token for adding to relayer fee.

[LayneHaber]

Included as an amount on the destination so you can track all fees owed. Just as a param, not as funds

[LayneHaber]

I was thinking it should be included in the transaction id hash so you need it to verify that, but maybe storing it only on xcall is preferable

[jakekidd]

yeah, that way we don't have to worry about accounting async with xcall vs bump. just claim based on transferId