Fee Structure for C3Router and C3Caller
-
I fully support the idea of charging fees in stable coins (added to the required gas) for both C3Router and C3Caller.
-
I like the setup. My knowledge about the subject us limited so not a lot to add.
I have two questions:
There is a savings incentive to use ctm if I read correct. What happens if the mentioned 10 ctm is more than 10 usdc?Is 10 usdc or an equivalent a bit expensive for transfers between relative cheap chains? For example Tron to BSc or ftm to optimism? Would we be competitive with other providers? Being cheap, easy and fast are important factors to gain decent market share imo
-
@Ulliee Good points. For the first one about paying with CTM, we should make the amount settable using on chain governance, so the figure of 10 here was just indicative. The reasons for having this option are 3 I think : Firstly it's our token, so why not encourage all users to get to use it and buy it on DEXes, so rewarding liquidity providers? secondly the use of CTM increases the token velocity and volume, so helps traders and attracts CEXes to list it, finally using CTM would stabilise its price, since if CTM got too expensive, users would simply use USDC, but if it became cheap, there would be buy pressure, since users would prefer to pay with CTM.
I agree about the price differences on each chain. Maybe we should have different set fees for each destination chain? Regarding the amount, once again this can be set by voting. A lot depends on the average USD value being sent when choosing the price point. Do we want to encourage lots of small transfers, or fewer large transfers? This needs a lot of thought. I can't see a way of having variable fees without sacrificing decentralization though.
-
Hey guys, here are some thoughts and feedback from devs, feel free to add your thoughts together! We need to consider many conditions and the current stage, since we need to make a less human involved and stable product. Meanwhile, please consider the Router and Caller as two separate projects, since they have different mechanisms.
C3Router:
- Collection of transaction tokens: The quantity/percentage collected may vary, and manual adjustments by individuals or contracts are needed to mitigate price fluctuations. Failing to do so could lead to price risks. Alternatively, an automated fee update feature can be implemented, but this comes with higher costs for price retrieval (via an Oracle or other interface). Additionally, many tokens do not support oracles.
- Fixed amount of specific CTM tokens (anchored to USDT or USDC): The amount of CTM tokens required is determined by the token's value and is then used to calculate the transaction price. This approach carries the risk of losses due to price fluctuations.
- Overall, there is a high risk, and it is susceptible to user arbitrage.
- It relies on DEX, meaning new contracts must be written for different DEXs, leading to multiple contracts.
C3Caller:
Fee Structure:
Project owners must deposit CTM tokens into a C3Caller fee pool. The default choice is to prioritize or default to charging fees from this pool for cross-chain transactions.
Charging can be applied to the sender, receiver, or project owner.- It requires support for features such as webpage integration, deposit and withdrawal mechanisms, and insufficient fee warnings.
Blend Mode: Asset + Message
Monitoring Liquidity Usage:- Message call fees are charged with a message-based structure if CTM liquidity is not utilized.
- If CTM liquidity is utilized, asset fees are charged with a token-based structure(potentially exempting message call fees).
Current Design:
- Charging is based on the token and message fee models.
- Token-based charging involves collecting fees solely in the form of tokens.
- Message-based charging involves collecting fees solely for the message portion.
-
On C3Router: Instead of fees of 10 CTM I would offer a discount of let's 20% for paying with CTM (corresponding e.g. to 8 USDC). A similar approach could be used for C3Caller.
-
I'd like to share my perspective on Continuum's fee structure for bridging assets. The current consideration is a flat rate, which has its advantages for users dealing with substantial sums. However, it may pose some limitations for those involved in smaller transactions, effectively excluding them from the benefits Continuum aims to offer.
It's essential to acknowledge that different bridges have diverse approaches to charging users for their services. Here's a breakdown of a few examples:
cBridge: Their fee structure ranges from 0% to 2% of the bridged amount, and this percentage varies depending on the type of asset being bridged.
Wormhole Portal: Currently, their fees are negligible.
Stargate: Users are subject to a fixed fee of 6 basis points (bps).
Axelar Satellite: This bridge charges users for relayer gas fees, which can vary significantly based on the source and destination chains. This approach doesn't rely on a percentage of the bridged amount.
Considering these different models, if Continuum were to adopt a flat-rate fee structure across the board, it might not be as competitive as other bridging solutions, particularly for transactions involving smaller sums, which actually constitute a significant portion of the total number of transactions.
In my opinion, a more flexible and balanced approach would be to implement a dynamic fee calculation, up to a predefined maximum fee threshold. For instance, fees for transactions below a certain threshold (e.g., $10 or a predetermined flat fee) could be based on a percentage of the bridged amount, not exceeding 2%, similar to the cBridge model, but capped at a maximum of $10 (or the chosen flat fee).
By adopting this approach, Continuum can cater to the needs of both small and large transfers across its network, ensuring a fair and competitive fee structure.
Regarding the matter of the General Message Passing (GMP), it could potentially be set as a flat fee. Furthermore, introducing the option to use Continuum's native token (CTM) to pay for fees while offering users a discount is a practical idea. However, it's crucial to consider that most users may prefer not to hold tokens for an extended period and would likely opt to purchase them on an as-needed basis.
As a reference, Router Protocol's Voyager provides a relevant example of a bridge that allows users to pay fees with the protocol's token. They also offer the flexibility of payment in other tokens, but it might be a strategic decision to limit payment options to primary tokens like stablecoins (e.g., USDC and USDT) and major cryptocurrencies like ETH or WETH to streamline the user experience.
In summary, by adopting a dynamic fee calculation approach and offering convenient payment options, Continuum can better serve a wide range of users and improve its competitiveness in the bridging space.
-
For C3Router (but not C3Caller) I favour a split fee model where other protocols can deploy a contract derived from C3Router that pays ContinuumDAO a small fixed fee for each asset transfer and then they can charge a variable fee dependent on volume, tokens type, availability of oracles, DEX pools etc. We vote to allow these non-upgradeable contracts to use our MPC network after we have inspected them. We remain decentralized, but the protocols using C3Router will need some staff to manage their fee model to onboard tokens, respond to price changes etc. but they would need customer service anyway, so they are limited in how decentralized they can be.
-
Some great comments I think there is room for both sides and we shouldn’t limit what we offer !! Would it be possible to have CTM Decentral a pure DAO no human intervention all done by vote for the easier projects !! but maybe for the more complex areas we have CTM central we’re we try get a bigger share of the market for some of the more challenging situations with some limited human intervention but users are aware of this by the title of the CTM they choose maybe we could get decentral up and running first with the knowledge of a future plan to increase fees with the CTM central version as time goes on and we over come our challenges we could transition more of our market share from CTM Central to CTM Decentral
-
@John-CTM I was thinking along these lines too John, except I think we could create a completely separate project with different branding and website that uses the ContinuumDAO router. It would be centralized, in that it would need a support team to adjust fees, onboard new tokens and provide customer support. This new project would pay ContinuumDAO a small fixed fee per usage of C3Router. Other projects would be welcome to also use the router with their own models, communities and variable fee structures.
If you think about it, anyone could easily create a bridge using C3Caller to mint tokens on a target chain having locked up tokens on the source chain, rather than using C3Router. This would only pay ContinuumDAO a fixed fee, since they only pay by message length and not by the value being transferred. This is another argument for charging a fixed fee per transfer, since any protocol can side-step a high variable fee model by using C3Caller.
-
I appreciate both @Insomniac and @Selqui thoughts on this, from both competitive fees and long term decentralization perspective. I do favor a design that makes possible (and in the most simple way) complete autonomy of the network, and hence (still trying to wrap the tech info in the thread in my head) keeping a fix fee makes non-upgradeable contract possible.
In a long run, and I believe most here would agree, that CTM is going to be autonomous; CTM is going to be a core cross-chain infrastructure for crypto. So that all the new chains are able to connect with existing financial ecosystem readily and easily. And $10 is a very small fee in doing cross-chain transactions - almost nothing compared to what it will cost for doing any form of ETH settlements.
-
-
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!
