Closed fredo closed 2 years ago
While reading through the PR I became the idea that it is actually not very user friendly that the gas reimbursement fee is in Native token and I think this can be changed!
The reasoning behind it is that the agent pays the fees in the native token and it is easier to reason about the cost to reimburse.
Nonetheless, it would be much better UX if the user only pays the fees in one currency at one go. The current problem is that at one point the agent fee becomes so small (because of the percentage fee model) that it is not worth for the agent to bridge. Other payment infrastructure typically have a fee model such that small amounts have a fixed portion and once the amount becomes larger it will be a percentage fee. (I.e. all transfers under 500$ will be 5$ fee, all others 0.1%).
I think that effort wise there is not much difference for us as the beam team because the gas reimbursement fee is based on an average gas price which we will need to update once in a while. So we already have a parameter which we need to update. We could do the same for the "fixed cliff value" once in a while taking into account the ETH/USD rate and historic gas prices of the rollups.
On the other hand, UX for the end user will significantly improve because there is a clear fee structure composing all different fees into one currency.
I had a quick chat with @LoringHarkness about it and he liked the idea, but it would also be nice to have your opinion @czepluch
The current problem is that at one point the agent fee becomes so small (because of the percentage fee model) that it is not worth for the agent to bridge.
I can confirm that I had to change many of our tests to use much larger amounts just to make sure that we get non-zero fees, to make sure fee calculation still works.
One drawback to note is that the agent will pay in ETH all the time and receive the new "reimbursement fee" in the token. Which will slowly but surely reduce the amount of ETH he has and increase the amount of token.
Once in a while he will have to swap the token to ETH to stock up his ETH. We could automate that by using uniswap or something similar.
On the other hand, UX for the end user will significantly improve because there is a clear fee structure composing all different fees into one currency.
If I'm not mistaken, this would also simplify the contract code, if only by a small amount. Not that it should be a critical factor in this decision, but it is nice.
Let me see if I understand this correctly. The proposal is to:
If above is true, I think that makes it a worse user experience for high amount since it will get quite expensive eventually. I am not a fan of this model personally, since this goes against how Ethereum works itself.
I can live with the fees being paid in tokens as long as we can still guarantee the amount that the users will receive and we make it a priority to have our UI reflect this behavior.
hmmm... I am confused now. It sounds that you are not a fan of the percentage fee in general. (0.1% fee for 1000000 results in 1000 USD fee). But that's what we have anyway right? That'S independent from how gas reimbursement fees are paid.
My latest proposal was just to change gas reimbursement fees to be paid in token instead of ETH
Yeah, okay. Might be a bit confusing. But what I was commenting on was the fact that we previously discussed to maybe have percentage for small transfers and then a fixed one for big transfers. If you want to transfer 1,000,000 in Beamer and you pay $1000 in fees, you're better off bridging back to L1 and then bridging to the desired rollup. At least if speed is not of importance. I'm just saying that $1000 for a transfer is worse than current banks.
Discussed with Fred in a call. We can go ahead with what he proposed and then once we have real world data from mainnet we can start adjusting and optimizing it.
@fredo could you then please update the description to provide details?
For mainnet we need to implement the updated fee model which will reward the agent with a percentage of the transfer amount. The model is as followed:
Fee model
Agent Fees
5e18
(to cover the costs of transactions, formerly known as Gas Reimbursement fee)lpFeeTokenPPM
,minLpFeeToken
(suggestion: since we only have one lp fee we could remove theToken
part in the variable ->lpFeePPM
,minLpFee
)Protocol Fee
Maintaining Certainty Principle
One of our main principles is to guarantee certainty. That means, if a user wants to transfer 100 Dai, he will receive 100 Dai on the target rollup. IOW, the user will always submit the amount he wants to receive.
With paying a fee in the transfer token, this means that this fee needs to be added on top of the transfer amount. This is mostly a UI/UX importance, not so much on the backend.
Open question
We need to think through if something changes if the native token of the roll up is not ETH.
Note: Please be aware that these changes have to be reflected in the docs. Frontend changes are also essential, should be outsourced into its own issue.