Fee Structure for C3Router and C3Caller
-
-
If you look at Stargate as an example, they charge 6 bp as pointed out by @Insomniac, which is actually a very small fee. If we do use a split fee model, which I still think is a good idea, then the fixed fee part would have to very small. Stargate has a huge 24 hour volume, sometimes over $100 million and number of transactions in 24 hours, sometimes over 200,000. The average value of a transaction is about $500. These numbers will be exceeded in a bull run. Rather than the figures of 5 or 10 USD we have been speaking of for the fixed part of the fee, a more competitive number would be of the order of 0.1 USD, or even less (not including gas charge). If we can match the usage figures from Stargate, this could still bring in 20,000 USD per day revenue for CTMDAO.
-
@Selqui yes, we want to encourage usage and too high a fee would become a barrier to entry for protocols wanting to build using Continuum.
$10 for a cross-chain message is definitely not feasible considering protocols could trigger 100 or more during a busy day and on the back of a small revenue.
$0.1 would make sense if we're going at a flat rate to drive usage volumes utilizing the network rather than maximizing revenue. If we want something that widely used, the fee as to feel inconsequential.
-
@Selqui great the main infrastructure CTM Dao fully decentralised no concessions to this at all it should be bulletproof I think most are in favour of this
All concessions to decentralised could be made by the new project and any projects that plug in this gives us all full freedom to do everything else
Fee structure for CTM can easily be changed by emergency vote quite quick if needed once set if it isn’t working so can easily be tested and changed
-
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!
