Fee Structure for C3Router and C3Caller
-
We have been discussing about how to implement fees in Theia. The next iteration of Theia will include liquidity pools for some assets (in addition to mint/burn tokens that are already there). In line with the original Theia proposal, there is a fixed fee payable until a user wants to use more than 80% of the liquidity pool and then the fee increases parabolicly up to a maximum of 20x to use all of the pool. So if the fixed fee is 5 USDT, the max is 100 USDT. The fee is paid on the SOURCE chain. The way we have implemented this is as follows. In the frontend, after the user has input the amount they wish to transfer, the fee is calculated by calling a function on the destination chain. This is an OFF-CHAIN calculation made by checking the size of the liquidity pool. For instance the user might be told to include a fee of 8 USDT, payable just before their transfer initiates. This is a suggestion only and they can pay more of less, but why pay more than you need to? Because that will be the correct fee ONLY IF NO ONE ELSE uses the liquidity pool on the destination chain before their tx arrives there. If someone else beats the user to it, they could use some of the pool and the user's transaction fee will no longer be sufficient. Their transaction arrives on the destination chain and the contract checks what fee is payable. It is now, say, 8.5 USDT, so their transaction fails, their funds are returned on the source chain, but they lose their 8 USDT fee. They could have avoided this by paying a higher fee to ensure success (e.g. 9 USDT).
The question now is how to handle gas fees? This is what we are discussing now. My own feeling is to do it this way :
(1) Between most chains, the gas fee is small, so we could swallow it and pay it from the fixed fee that the user already will be paying (e.g. 5 USDT).
(2) When the destination chain is Ethereum, or perhaps BNB chain, we need a mechanism to charge a higher fee when the gas price is higher.
(3) We should charge the destination chain gas fee in the same currency as the liquidity fee, e.g. USDT, but for the sake of having a simple and easily understood fee structure, which will be a big marketing plus for us, we could have CHARGE BANDS which change depending on the gas price.
(4) Using Ethereum as an example of the destination chain, the frontend would call a function on Ethereum that calculates the gas price and which returns one of LOW, NORMAL, HIGH, VERY HIGH. This would require the user to pay an extra fee of 0, 10, 20, 50 USDT (values could be changed through on-chain governance). Again this is only a suggestion to the user, who could select a different value (e.g. the front end says to pay a NORMAL fee, but the user pays a HIGH fee to ensure success). The transaction proceeds and when it arrives on the destination chain (Ethereum in this case), the gas fee function is again called and the fee paid is checked against the actual fee and if not enough was paid, then the transaction reverts. The revert would happen if the user was unlucky and there was a gas price spike.The MPC actually pays the gas fee in the native coin on the destination chain (e.g. in ETH). The user pays the gas fee on the source chain for their transaction (e.g. in FTM, BNB etc.) separately from the USDT fee. How to top up the gas in the MPC in a decentralized way? We don't want to have to rely on a 'team' to do this. I suggest that we create a function on each chain that ANYONE can call to add gas to this wallet address. Normally this would be done via the monthly Governance vote though, making sure that there was always enough gas to perform transfers for the next month. In an emergency though, if gas ran out, then some kind soul could top it up and be compensated later via governance.
Please give us your input here on these topics. It's your chance to influence how the router works
-
If we could implement a fixed fee and they get CTM or Theia tokens if they overpay a transaction and have it airdrop on BNB chain. I think BNB is most used after ETH chain and probably everyone knows it. I don’t know if we can build something like this that’s calculate how much a user paid and return him the remain dollars in CTM or Theia on BNB chain. User can decide to keep the CTM or Theia or sell them on the market. We sure need liquidity on BNB chain for CTM or Theia.
-
@Apxymous I think that this is too hard to do at the smart contract level. It involves further cross-chain transactions and oracles to calculate the CTM or THEIA/USDT rate. These would all be attack vectors. I get what you mean though, just don't know how to do it safely
-
Yes, it’s pretty complicated. Perhaps we need to cover the fees from our own pockets and favour our users. When the user sign the transaction they will only pay the fees what is deduct from the source chain. The question is. Could we still be profitable if we do this? Having advertisement showing on our platform is an idea to have an extra income stream? If possible offer decentralise ads?
-
Thanks Selqui for the good ideas and I agree with most of them. From my own experience bridging tokens, I value speed and ease of use over differences is tens of dollars in USD equivalent value. Paying only once at the source chain is a major and important feature and cannot be compromised. The idea of paying for users for low cost chains is sound. I assume governance will need to come together if these chains start getting expensive down the road.
@Selqui said in Fee Structure for C3Router and C3Caller:
Using Ethereum as an example of the destination chain, the frontend would call a function on Ethereum that calculates the gas price and which returns one of LOW, NORMAL, HIGH, VERY HIGH. This would require the user to pay an extra fee of 0, 10, 20, 50 USDT
I like this idea and can we change this scale of success probability to 3-pt as in "LOW, RECOMMENDED, HIGH" - with RECOMMENDED being the default option. 3-pt scale is much easier for users to navigate.
@Apxymous said in Fee Structure for C3Router and C3Caller:
If we could implement a fixed fee and they get CTM or Theia tokens if they overpay a transaction and have it airdrop on BNB chain
I disagree with this. There are times I am VERY HAPPY to overpay if my bridging has a high certainty of completion. If a user chose to overpay, CTM should pocket the excess fees.
@Selqui said in Fee Structure for C3Router and C3Caller:
How to top up the gas in the MPC in a decentralized way? We don't want to have to rely on a 'team' to do this. I suggest that we create a function on each chain that ANYONE can call to add gas to this wallet address.
I like this idea very much. Is it possible that part of the excess fees collected be used to incentivize top-ups? For example, to top up FTM to the MPC, I could deposit FTM in exchange for USDC tokens the MPC had collected as excess fees at a 10% discount. I wonder if this is too complex to implement.
Sorry for the slow reply - been busy. Great work Selqui!
