[Review] MIP-69: Bridge Fees, MD-69: Bridge Fees

[franck44]

MD-69
MIP-69

See #66

Summary

First-cut of the MD for the bridge fees.

[Primata]

On how fee would be charged:
On the Layer 2, Relayer is able to specify a fee.
For a dynamic fee, we rely on the following:
0. We do have an estimation of how much gas it costs to completeBridgeTransfer on Ethereum in terms of Units of Gas to be used. If we don't want to rely on a fixed value, we take the 1. approach.

1. once the relayer runs a transaction, it receives the total Units of Gas Used. That sets the gas to be used.
2. The formula to gas cost is Units of Gas Used * Base Fee + Priority Fee
3. A fixed Priority Fee of 1.
4. All that is left is the Base Fee, which can be take from a light node using alloy's calculate_next_block_base_fee. With that we have the gas cost on Ethereum.
5. Take the exchange ratio between ETH and MOVE from a deep liquidity pool on Ethereum between ETH/MOVE. Ideally we fund this pool to assure that a liquidity provider that would own the majority of the pool cannot reduce its cost to bridge from L2->L1 by pulling liquidity and selling MOVE into it.
6. With this, we have (Units of Gas Used * Base Fee + Priority Fee) * exchange ratio. We add a 25% buffer to it to account for price hikes or momentary failures and front run the 12.5% gas estimation caused by calculate_next_block_base_fee internal logic for if the next block is full.
7. With this information, the Relayer can call setFee on L2 if following conditions are met:
   • Current fee in MOVE is 25% lower than the estimated cost.
   • Current fee in MOVE is 10% higher than the estimated cost.
8. CompleteBridgeTransfer is called in the following format:
   bridge.completeBridgeTransfer{max_fee_per_gas: ${baseFee}, max_priority_fee: 1}(bridgeTransferId, sender, receiver, amount, nonce);
   This prevents us from over spending

[apenzk]

link missing

[apenzk]

Thx @Primata, following came from yesterdays discussion

On how fee would be charged: On the Layer 2, Relayer is able to specify a fee. For a dynamic fee, we rely on the following: 0. We do have an estimation of how much gas it costs to completeBridgeTransfer on Ethereum in terms of Units of Gas to be used. If we don't want to rely on a fixed value, we take the 1. approach.

1. once the relayer runs a transaction, it receives the total Units of Gas Used. That sets the gas to be used.

The user limits the maximum L2MOVE amount that should be consumed. This is not in gas but an amount that is dedacted from the total amount transferred. This way the user knows how much maximially gets consumed.

4. All that is left is the Base Fee, which can be take from a light node using alloy's calculate_next_block_base_fee. With that we have the gas cost on Ethereum.

For reasons of cost stability and operational stability the bridge fee is set in the L2bridge contract by an operator that is different to the relayer. This entity reads the fee value from L1 and we keep this value for a certain amount of L2blocks

6. With this, we have (Units of Gas Used * Base Fee + Priority Fee) * exchange ratio. We add a 25% buffer to it to account for price hikes or momentary failures and front run the 12.5% gas estimation caused by calculate_next_block_base_fee internal logic for if the next block is full.

Since we update the value say every minute (i.e. 5 Eth blocks) we have to consider a maximal increase of 100%, not 25%

[Primata]

@apenzk

1. The user would be able to see the cost, it's a variable set on the contract and a view function would let the user know how much MOVE they would spend (X) to bridge Y amount with Z fees, X being the sum of Y + Z.

2. Setting fee on L2 will be extremely cheap, the benefits of updating it as frequently as necessary overshadows setting it on a frequency basis. It also prevents us from over setting the fee.

3. If we set the base fee too low, the only issue we will have is the bridge taking too long to complete. But we set the base fee based on the charged amount of MOVE, not just whatever fee the next block needs.

Updated comment above to reflect this information.

[franck44]

@Primata @apenzk This is an MD which sets the requirements not the implementation.
We'll discuss the implementation and possible strategies in an MIP (not written yet).

So can we first agree on the MD (requirements), without considering solutions that will be part of the corresponding MIP?

[apenzk]

@franck44 MIP-58 contained a section on bridge fee that did not belong there. i have added it as appendix with a note/task to please incorporate it into this MIP

[apenzk]

MD-69 is approved and should be merged. The status of MIP-69 is stagnant