Fee Structure for C3Router and C3Caller
-
We need to think of a good way to charge for our services. Whatever we do should be properly decentralized, so we do not have to rely on individuals to collect fees, swap between many different tokens, charge smart contracts with fee rewards etc. Ultimately we want collected fees to appear automatically in a fee distribution smart contract as CTM.
I have collected the thoughts from the Telegram chat and add my own here. Please contribute to the discussion in this thread.
C3Router
To avoid having to collect fees in hundreds of different volatile tokens and convert them to CTM, we could charge a flat rate of (say) 10 USDC (more for transfers to Ethereum) for every transfer. This would be on top of gas on the source chain, but would pay for the gas on the destination chain. We partner with a DEX on every source chain to provide gas coin/CTM liquidity. The user has the following options to pay for the transfer (examples when Ethereum isn't the destination chain) : 10 USDC, the equivalent amount of gas as 10 USDC, or 10 CTM. This final option of paying in CTM should allow users to make a small saving.
Within C3Router, there are functions that interface with the AMM of the partner DEX (interface to Uniswap functions) to calculate how much gas is equivalent to 10 USDC, converts 10 USDC to CTM, converts gas coin to CTM and a function that sends the CTM to a Treasury contract for fee distribution.
C3Caller
The fee mechanism would be the same as for C3Router, but this time we charge a fixed amount of USDC or CTM per byte of data transferred. Something like 0.01 USDC/byte , or 0.01 CTM/byte seems reasonable to me, unless the destination chain is Ethereum. This mechanism would apply for both payment on the source chain, or the destination chain.
I like the simple marketing message - cross-chain transfers cost 10 USDC, or 0.01 USDC per byte. Really easy to explain to anyone.
-
-
@Apxymous we could also allow other projects to deploy their own version of C3Router and give these contracts permission to use the network (through formal voting). That way we could do fee sharing and avoid the hassle of customer service. Additionally, they would have to audit their own smart contracts and we would not be responsible for smart contract bugs or exploits.
-
-
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
