Third Party Sponsoring Fees

[LayneHaber]

Summary

Third parties (i.e. chain teams) can fund a Vault that will pay the liquidity and relayer fee (up to a cap) in for each transfer. This will allow them to create free onboarding onto their chain via subsidies, and give our users a better UX by (1) covering fees and (2) providing them with gas on the chain immediately.

Motivation

Allowing third parties to sponsor transfers would create an opportunity for domain teams to support free bridging. Coupled with providing liquidity incentives for routers who support the domain, this creates an easy onboarding incentive program and experience.

With nomad, we are able to be the default bridge on many new domains as they launch, and allowing domain teams to sponsor transfers and liquidity would be the base for a great incentive program.

Design Requirements

• Must allow third parties to sponsor relayerFee for each transfer
• Must allow third parties to sponsor liquidityFee for each transfer
• Should be easy to fund on the destination domain only
• Should not require origin domain changes (contracts shouldn’t need to upgrade to have their transfers sponsored)

Proposed Solution

There is a whitelist that contains a Vault address on the domain. The Vault is a contract that can be funded by the sponsor, and has the following interface:

interface IVault {
  // Should be callable by the Connext contract only. Should:
  // - call `addLiquidityFor` to send the calculated fee to the router
  // - return the amount of liquidity router was reimbursed
  function reimburseLiquidityFees(uint256 fee, address asset, address router) public returns (uint256);

  // Should be callable by the Connext contract only. Should:
  // - take in an amount of relayer fee specified on origin chain
  // - convert that amount to destination domain gas
  // - send the user the destination domain gas
  // - 
  function reimburseRelayerFees(uint256 relayerFee) public;
}

Then, a crosschain transfer would look like:

1. User makes an xcall with a specified destination domain (domain is offering rewards)
   1. relayerFee is specified
2. Router sees transaction, bid is selected, execute is called on destination domain
3. Within execute, a whitelist is checked to see if the current domain is offering rebates. The whitelist is a mapping(uint32 => Vault)
   1. This whitelist is set by an onlyOwner function
4. If it is not whitelisted for rewards, deduct liquidity fees and send relayer fees to relayer
5. If it is whitelisted for rewards:
   1. Calculate the liquidity fee
   2. Call reimburseLiquidityFees that sends that amount to the routers liquidity if the asset is supported. If not, this fee is still levied against the user.
   3. Call reimburseRelayerFees that converts the specified relayerFee provided by the user into the native asset of the destination domain and sends it back to the to
6. relayerFee is still sent to the relayer in the expected asset

Pseudocode of execute:

function execute(ExecuteArgs _args) public {
  // Get the adopted asset
  // calculate liquidity fee
  uint256 fee = getLiquidityFee(_args.amount);

  uint256 amount;
  uint256 relayerFee;
  // Is the domain sponsor
  if (sponsorVault != address(0)) {
    // Vault will return the amount of the fee they sponsored in the native fee
    // NOTE: some considerations here around fee on transfer tokens and ensuring
    // there are no malicious `Vaults` that do not transfer the correct amount. Should likely do a
    // balance read about it 
    uint256 sponsored = IVault(sponsorVault).reimburseLiquidityFees(adopted, _args.amount);
    amount = _args.amount + sponsored - fee;

    // Should dust the recipient with the lesser of a vault-defined cap or the converted relayer fee
    // If there is no conversion available (i.e. no oracles for origin domain asset <> dest asset pair),
    // then the vault should just pay out the configured constant
    IVault(sponsorVault).reimburseRelayerFees(_args.originDomain, _args.to, _args.relayerFee);
  } else {
    // Here, there is no sponsor. handle funds and relayers
    // in the same way as previously
    amount = _args.amount - fee;
  }

  // Handle relayer fee normally after (potentially) dusting `to`
  
  // ....rest....
}

Domain Requirements

• (optional) Oracle for origin native asset <> destination domain native asset. If not available, can use a preconfigured constant
• (optional) DEX to swap for some vault-liquidity asset to the transacting asset. If not available, must supply liquidity in the
• A funder 🤤

Test Cases

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

// Should work with a vault
function test_Connext__execute_shouldUseVaultIfAvailable() public { ... }

// Should add vault
function test_Connext__addVault_shouldWork() public { ... }

// Should fail to add vault if not owner
function test_Connext__addVault_shouldFailIfNotOwner() public { ... }

// Should remove vault
function test_Connext__removeVault_shouldWork() public { ... }

// Should fail to remove vault if not owner
function test_Connext__removeVault_shouldFailIfNotOwner() public { ... }

// ========= Vault.t.sol =========

// Should reimburse liquidity fee if asset is supported
function test_Vault__ reimburseLiquidityFees_shouldWorkIfAssetSupported() public { ... }

// Should reimburse liquidity fee if asset is not supported BUT there is a dex available
function test_Vault__reimburseLiquidityFees_shouldWorkForAnyAssetIfDex() public { ... }

// Should not reimburse liquidity fee if asset is not supported and there is a dex available
function test_Vault__reimburseLiquidityFees_shouldWorkForAnyAssetIfDex() public { ... }

// Should reimburse just the ceiling if relayerFee is higher than ceiling and an oracle is available 
function test_Vault__reimburseRelayerFee_shouldChooseMinimum() public { ... }

// Should reimburse the relayerFee if it is lower than the ceiling and an oracle is available 
function test_Vault__reimburseRelayerFee_shouldReimburseFee() public { ... }

// Should reimburse the ceiling if no oracle is available
function test_Vault__reimburseRelayerFee_shouldReimburseCeilingIfNoOracle() public { ... }

// Should be able to add a dex
function test_Vault__addDex_works() public { ... }

// Should fail to add a dex if not owner
function test_Vault__addDex_failIfNotOwner() public { ... }

// Should be able to add an oracle
function test_Vault__addOracle_works() public { ... }

// Should fail to add an oracle if not owner
function test_Vault__addOracle_failIfNotOwner() public { ... }

Open Questions

• If this is a contract call, how can they receive their reimbursement without altering the amount? Would they need to put in a different address to the interface or should we just give up and use middleware?
• Calling to the Vault adds gas that will be paid by the relayer, should the vaults be aware of this and add a premium on top of the estimated fees?

Tasks

• Create Vault with logic for reimbursements, ability to fund, and ability to configure dexes/oracles
• Update logic in execute
• Tests

[lmcorbalan]

I think It may not be a good idea to sponsor the relayer fee with the current relayer fee approach.
Currently the user sets the relayer fee on the origin domain which get locked in the Connext contract until a relayer claims it after executing the transfer in the destination domain, so the user could choose a really high fee, knowing that it is sponsored, which may end emptying the Vault.

[LayneHaber]

That's a really good point, I hadn't considered that in the idea.

I wonder if then its okay to just subsidize any router-level fees. Alternatively, you could always have the vault hard-cap how much it will reimburse the user. Curious what your thoughts are on the impacts of this on the user-story @ArjunBhuptani

[LayneHaber]

I think we should just have the teams put in a standardized dust amount, then the Vault could pay the minimum of the calculated rate or the max amount. if there is no oracle, it could always just pay the specified max.

Going to convert this to a spec with this in mind

[LayneHaber]

I think what I'm most concerned about is how to handle the amount consistency in this paradigm. We should make sure we consider this as we continue to noodle on #937 . One option is to have an address on that chain that can accept these rebates defined in the interface directly. That way this should have no impact on the amount the calldata is executed with, but that could be unintuitive