As a smart contract integrator, I need to calculate relayer fees on chain

[rhlsthrm]

Problem A fully smart-contract based integration needs to encapsulate all external calls into onchain calls. This includes relayer fee calculations. The issue: https://github.com/connext/nxtp/issues/1483 provides a solution for the offchain case. This issue encapsulates the need to have this calculation onchain.

Ideas to solve this We need an onchain oracle on each origin chain that is capable of providing price info for gas tokens on all destination chains. The oracle needs to convert gas token price to USD so that we can use the following formula:

(gas amount origin side) = (gas amount destination side) * (price conversion to usd) * (price conversion from usd to origin gas)

Acceptance Criteria

• [ ] Override xcall method onchain to allow pointing at an oracle.
• [ ] Overridden method calls oracle and calculates gas required and takes from the method (can we do this? how do we dynamically add value into the tx??)

Other

[0xGorilla]

We see that this issue could be divided into two problems to solve:

Token price bridging

The price of each token relative to a desired stable coin could be bridge from mainnet taking as an oracle source their respective Uniswap V3 pools.

For example, if Ethereum Mainnet, Polygon and Avalanche would be supported: ETH/DAI, MATIC/DAI and AVAX/DAI quotes (or pool observations) should be bridged from mainnet to polygon and avalanche.

This is something that, as Wonderland, we are trying to create and standarize for the everyone but it might take some time.

This has a moderate cost over time to mantain, since you could decide to batch and brige quotes every once in a while.

Gas pricing on every chain (destination / origin)

In order to provide the user with an estimation cost of their transaction on the target chain, the gas price should be taken into account.

In EIP1559 supported chains: The basefee of every chain should be broadcasted to all of the other chains.

In non-EIP1559 supported chains: An Oracle would be needed with regular commits to the chain.

This has a very high maintaince cost and complexity. You would as well need to use each chain as source of truth for their respective gas pricing.

---

Concluding, the cost of maintaining both of these services would be outrageous, and we do believe that they would not make much sense for the early stage we are currently on.

We suggest that we keep an eye on the ecosystem development on this topic, in order to see if there is a more scalable and sophisticated solution that arises with time.

[rhlsthrm]

@0xGorilla this is correct, and is indeed a very expensive service to maintain. Here's another approach that might fix it:

• Users have a "gas tank" in the contract that they can pre-fill to fund their transactions.
• Now there's no need to calculate anything up front, the relayer just needs to check the gas tank and make sure there's enough for that transaction.

However this brings up a new set of issues:

• Race conditions around claiming. I.e. the gas tank looks full, but claims are "in flight" through Nomad and will be settled before my claim goes through, removing the gas from the tank, and I've already relayed the tx.
• User removes tank before the tx goes through.
• How to key the tank? We could do it by EOA but we want to support DAO-only interactions. We would need a key on the gas tank to be something that is authenticated by a trusted party, I don't there's a way around checking a signature from an EOA (or EIP712 but still that needs an EOA).

[0xGorilla]

We have been discussing this with @vPEPO:

The gas tank might be an interesting approach.

In order to solve the issue of the user emptying the tank before the tx goes through, you could implement some locking mechanism until the relayers are being paid. For example, let's say the relayers get paid every 7 days for all the transactions that went through, then the user would have a 7 day unbond period in order to withdraw funds from the gas tank.

Taking all of this into account, don't you think that the gas tank solution would significantly worsen the UX?

[rhlsthrm]

In order to solve the issue of the user emptying the tank before the tx goes through, you could implement some locking mechanism until the relayers are being paid. For example, let's say the relayers get paid every 7 days for all the transactions that went through, then the user would have a 7 day unbond period in order to withdraw funds from the gas tank.

This is a good idea actually, we could have these windows and that ensures funds are available.

Taking all of this into account, don't you think that the gas tank solution would significantly worsen the UX?

Absolutely it would and that's why there's always an option to fund the gas tank immediately for a specific tx. This is for the situation where a DAO has connected contracts directly to the bridge and needs to initiate txs through governance or another protocol. i.e. if a keeper needs to initiate the bridge tx on some schedule.

[vPEPO]

Also, another approach could be making a system in which gas wars are enabled (in order to provide pricing benefits for users) together with a round-robin-like feature to solving the centralization concerns.

The idea would be as following:

• Relayers settle a pricing (modifiable) for relaying to different destination chains
• Slots are based on the amount of active relayers (bidding relayers)
• Auctioneer considers a combination of the pricing of the liquidity + gas (instead of simply considering liquidity pricing)
• Users request relayers slot for execution (locking the gas cost on the origin chain), which makes the selected relayer unavailable until completition

Example: the slots on Polygon are composed of 10 relayers, each of their relayers would have their position available for execution on that particular slot, as slots are being requested, the relayers become unavailable. The only way to make them available again is by submitting a proof that the relay was fulfilled correctly on the destination chain (and by so, claiming the balance that the user locked on that slot)

On a particular period, there are 25 transactions coming to Amarok:

• Slot 0, completely requested (10 relayers = 10 requested)
• Slot 1, completely requested (10 relayers = 10 requested)
• Slot 2, partially requested (10 relayers = 5 requested + 5 available)

An hour goes by, and fulfillment proofs for 5 relays arrive on the origin chain, so Slot 0 starts to become available again for the relayers that already fulfilled the whole interaction.

• Slot 0, partially requested (10 relayers = 5 "requested" + 5 available)
• Slot 1, completely requested (10 relayers = 10 requested)
• Slot 2, partially requested (10 relayers = 5 requested + 5 available)

After this, 5 more transactions are requested, those transactions would go to Slot 0 because its the first position available compared to the whole "mempool" of transactions requested.

So basically it becomes a system like FCFS (ensuring the quickest execution for the best pricing as they are competing for their Slot 0 to be available as soon as possible) and a better way to ensure UX of payment for the user (users lock payment on request and its only available for the relayer after fulfillment or disputable by the user -- all through proofs).

Advantages of this model:

• FCFS-like interaction (gas wars)
• maintaining UX flow
• oracle-less system (there is no need to ensure pricing because its on the best interest of the relayer to do so)
• can be implemented together with the current model of data-transfer between chains (it would be more data, but at practically the same cost)

Cons of this model:

• relayer can have a malicious behaviour by waiting for the last position of the Slot 0 (or whatever slot) in order to overcharge the user (Slash-able behaviour)
• there are probably more cons to this model, but can't think of anything else at this moment as I'm not really that technically knowledgeable about Amarok's infra