Celer cBridge v1.0 is now live on mainnet! Users are now able to use cBridge to instantly transfer tokens across Ethereum, Arbitrum, Polygon and Binance Smart Chain, with many more side chain and layer-2 chain integrations planned for in the near future. Anyone can run a cBridge node to join the cBridge Network and provide cross-chain and cross-layer liquidity while generating yields through transaction fees. This marks an important milestone for Celer to create a key interoperability infrastructure to unite all the fragmented liquidity back together in the future of a multi-layer-2 and multi-chain blockchain ecosystem.
Why is cBridge a necessary infrastructure for a scalable blockchain future?
Blockchain scaling is a trading game with the devil
As the usage pattern evolves for any newly introduced computer system, more important features and traits will always deprioritize the development of less important or relevant ones. Once all performance boundaries have been reached with the current set of constraints, to further iterate and improve the system, system designers always have to loosen the constraints and make a tradeoff with the devil: sacrificing less important features/traits in order to improve the more important ones that are suitable for the growing use cases at hand. This is the principle of tradeoff for computer system design. Oftentimes, this tradeoff game is played out by adding additional abstraction, or “layers”, on top of existing systems.
System designers will always try first to understand what properties are truly incompatible with each other and can be used in a tradeoff. The process of understanding different tradeoffs leads to various “x-lemmas” and “theorems” in the history of computer science. In the context of blockchain, everyone has probably heard about the tradeoff between “decentralization, scalability and security,” which is also known in the space as the “blockchain scalability trilemma.”
It is important to point out that these well-known tradeoffs often do not describe the full range of tradeoffs and it is possible to find “trades” outside of these well-known constraints. For example, two popular paths for playing the blockchain scalability game are: 1)Within the boundary of “blockchain scalability trilemma”, sell some level of decentralization; Or 2) Creatively jump out of the trilemma and sell some level of interoperability and composability. While the first is the design principle for sidechains and DPoS layer-1 chains, the second leads down the road of multiple layer-2 scaling techniques and projects (Celer’s state channel and rollups included), with state channels focusing more on real-time interactiveness and achieving the lowest cost point and the rollup chains focusing more on development compatibility.
Regardless of which path leads to Rome first, it is clear that the future belongs to a multi-chain and multi-layer architecture where, as a whole ecosystem, the entirety of liquidity will be segregated and siloed into multiple separate layer2 and layer1 chains.
However, the forced trade of interoperability and composability is painful. Moving funds and states between these chains today either requires centralized assistance or has extremely high time-or-cost friction. In fact, for many use cases and users, the transaction value cannot justify cost and time involved. This will unfortunately lead to user gentrification where the long-tail of users will suffer the most and in a way, a loss of the true decentralized vision.
cBridge: win in the end game of blockchain scalability tradeoff
Fortunately, we can always try to buy back some of the lost composability and interoperability. Celer cBridge, as a new layer of abstraction on top of this multi-chain/multilayer future, allows users to bridge liquidity (and soon state) with much lower cost and time friction in a completely trust-free fashion. In this way, we can regain most of the lost composability and interoperability during the multi-chain expansion.
So what are we selling out to the devil? cBridge, as a natural add-on to Celer’s State Channel architecture, is trading the locked liquidity of the operating nodes in order to allow instant liquidity and state bridging. Our cBridge nodes need to provide liquidity locked up on each bridged chain so it can receive liquidity from a user on the source chain and instantly “push” liquidity to the user on the destination chain in a trust-free way.
Although “locking up liquidity” sounds scary, it is actually a super smart trade. Effectively, cBridge is leveraging the economy of scale to reduce the adverse effect of liquidity lockup. The economics of pricing cross-chain and cross-layer bridging is very nuanced and warrants a separate post, but the key here is to always maintain a win-win situation for both users and cBridge node operators. Two simplified examples:
First, for small-sized bridging requests existing rollups in the order of $100s, if users do not use cBridge and use native bridge solutions instead, the transaction costs can mount to $50-$200, or 40%-50% on a percentage basis. For cBridge nodes, as long as the fee percentage is lower than the aforementioned amount, say 5% users will choose cBridge without any hesitation. cBridge nodes are also making good profits. Let’s say one cBridge node bridges 10,000 transactions of $100, the fee it gets is $50,000. When it rebalances the liquidity, the economy of scale generates a 2,500% gross margin on the gas fee cost. Granted, there are additional costs of liquidity lockup during the node operation and rebalance. However, even if we use a very exaggerated number of $10,000 to account for that cost, we seem to get a netting profit with 400% margin.
Second, for large-sized transactions, cBridge’s main use is to accelerate the liquidity bridging speed. The pricing is marked based on the risk adjusted return for the destination chain for the accelerated time. Let’s say the lower-bound of the destination chain is 40% and the bridge nodes take 50% of that profit share. For a $1,000,000 transaction, cBridge can easily net $4,000 gross margin.
Note that the above two examples both assume the worst-case scenario where the bridging request is only single-sided and once liquidity is exhausted, bridge nodes need to rebalance the liquidity with a long locking up time. However, the reality is going to be much better with back-and-forth liquidity bridging requests. This will significantly boost the effect of the economy of scale to yet another level.
Finally, we just want to stress once again, cBridge is entirely non-custodial and trust-free. That means users do not need to trust any cBridge node to make the crossing safe and smooth.
So here we are, trading with the devil and winning in the end game! You can always find more technical information in our previous posts about Celer State Channel and cBrid
What is included in the mainnet launch?
Concretely, this mainnet launch comes with both the user facing interface as well as the cBridge node software.
From the user’s perspective, cBridge can be used to instantly transfer token cross-chain and cross-layer between any two of these networks: Ethereum, Arbitrum, Polygon and Binance Smart Chain. Users can access a user interface here. As a newly launched product, we always welcome UI/UX feedback from our community.
For those who want to try running a cBridge node and join us in planning the course of uniting liquidity while earning some nice yield, cBridge nodes software is a fully open source platform with some simple instructions on how to run, which you can find here.
Celer’s community of developers are always available on Discord and are always extremely helpful whenever they can be. However, like any newly launched system, we urge you to start slowly on deploying liquidity on cBridge nodes to give the system some run-in time in the wild.
What is coming in the future?
The cBridge v1.0 release is just a start and more features will come in future releases:
- Support more chains. cBridge is initially launched to demonstrate both the cross-chain and cross-layer functionality. We will meet users’ demands to expand to other chains as well.
- Dynamic pricing strategy SDK. One key component for cBridge is to define how to price the fee for the bridging requests based on the current competition level, size of transaction, available liquidity on the destination chain. A good pricing strategy can help to optimize yield and generate sustainable liquidity both ways. We don’t expect every cBridge operator to have the exact same fee strategy and therefore, we will open up a plugin-based SDK for any cBridge nodes to easily insert their own strategy with decision factors available to play with.
- State and smart contract call bridging. Token transfer and liquidity bridging are just the first steps. cBridge will move towards state bridging for cross-chain and cross-layer asynchronous function calls in the future.
Questions and Support?
You can always find us at our Discord for technical support. We are also available in all of the below channels!
