Celer cBridge v1.0 is officially launched on the mainnet today! Users can immediately use cBridge to perform high-speed and low-cost cross-chain and cross-layer transfers on Ethereum, Arbitrum and Binance Smart Chain, as well as Polygon.
cBridge will support more layer2 and layer1 blockchain cross-chain transfers in the short term. In addition, anyone will be able to join the cBridge network by running a cBridge node to provide cross-chain and cross-layer liquidity, while generating income by charging fees.
cBridge is an important milestone, it marks Celer will be in the multi-chain multi-layer blockchain expansion ecology in the future, Provide the key core infrastructure for re-aggregating decentralized liquidity, thereby greatly improving interactivity and composability.

After the emergence of any new computer system, with the continuous application in practice, which System characteristics are more important, and which system characteristics are not so important will be checked out quickly. Once the system has reached the upper limit of performance under certain current constraints, in order to further iterate and improve the system, the system designer always has to relax the constraints and make a deal with the "devil": sacrifice less important features to improve the more important aspects of the system. Features to adapt to the development of usage requirements. This is the "tradeoff" principle in computer system design. Typically, this trading game is implemented by adding an additional abstraction or "layer" on top of an existing system.
System designers will always first try to understand which properties are truly incompatible and tradable. Understanding different properties has led to various "impossible n angles" and "theorems" in the history of computer science. In the context of blockchain, everyone has probably heard of the impossible triangle of "decentralization, scalability, and security".
But it should be pointed out that these well-known xxx triangles usually do not describe all possible choices, and we can jump out of the established Frameworks go find new tradeoffs and features in exchange for the main features we want. For example, two popular paths to blockchain scalability are: 1. Selling some degree of decentralization to the “devil” within the boundaries of the “blockchain scalability trilemma”; 2. Creatively jumping out Impossible triangle, by "selling" interoperability and composability in exchange for new scalability. The first path is actually the design principles of side chains and DPoS blockchains, and the second is the basic idea of layer-2 extension technology (including state channels and rollup chains).
No matter which technical route, with their development, we can easily see, The future must belong to a multi-chain and multi-layer architecture. Under such a multi-chain multi-layer architecture, the liquidity and composability of the blockchain, which was originally a relatively complete single system, will be isolated and isolated into multiple independent layer2 and layer1 chains.
However, "selling" interoperability and composability is like selling part of the soul of the blockchain. Liquidity fragmentation will greatly reduce the integrity of the overall application ecosystem. For example, DeFi Lego, which could have been combined, will be severely damaged. Transfers between various chains can only be assisted by centralized exchanges, or require extremely high time and costs. The cost can be realized, and the cross-chain function call is impossible to talk about.
For many long-tail users and usage scenarios, the cost of such cross-chain and cross-layer interaction has become a huge block Chain usage barriers. This will inevitably lead to the loss of long-tail users, which, to some extent, greatly violates the true vision of decentralization.

< br>
Fortunately in computer system design, our trading game is never a one-shot deal. We can redeem most of the composability and interoperability lost due to the multi-chain multi-layer architecture by selling other things. The emergence of Celer cBridge has made this kind of redemption possible: cBridge provides a new abstraction layer on top of multi-chain/multi-layer, allowing users to conduct high-speed transactions in a completely trustless manner with lower costs and time costs. The bridging liquidity and state function call bridging, thus redeeming most of the interactivity and composability that would have been sold.
So in return, what have we sold to the devil? cBridge is a natural extension of Celer's state channel architecture. The precondition for each cBridge node to help users bridge liquidity is to have Lock enough liquidity to accept liquidity from the user's chain, and immediately "push" liquidity to the target chain the user wants to go to without any centralized trust.
Although it sounds like locking up liquidity is not a good thing, this transaction In fact, we are making a lot of money. This is because cBridge nodes can take advantage of transfer fees and "economies of scale" to greatly reduce the adverse effects of liquidity locking.
The model and economics of cross-chain and cross-layer bridge pricing need a separate article to discuss. Here we give a few simple examples to illustrate whether it is a large or small transaction, This kind of economies of scale can always achieve a win-win situation for users and cBridge node operators Results.
First of all, for small amounts, such as cross-chain and cross-layer transactions at the level of one hundred dollars, if you do not use cBridge, use native For bridging, the transaction cost will reach $50-$200, accounting for about 40%-50% of the total transaction amount. As the operating node of cBridge, if a 5%-10% handling fee is charged, users will choose to use cBridge as a bridge without hesitation. But did the cBridge node lose money? not at all. Take the following bridge as an example (such as transferring from Arbitrum to Ethereum), if a node helps to bridge 10,000 off-bridge transactions of $100, although for each transaction, the price is much lower than that of users using native bridges, However, the total handling fee obtained by the node operator is $50,000 - $100,000. And when the bridging node rebalances the liquidity, he only needs to perform a native off-bridge operation to rebalance the liquidity, which costs $50-$200 in total, and finally makes a net profit of at least $49,800.
Secondly, for larger-scale transactions, the main function of cBridge is to greatly accelerate the speed of liquidity bridging (especially in Various types of rollups are in the process of getting off the bridge). Fees can be priced based on reasonable risk-adjusted returns, which are generally much higher than risk-free returns. For example, for a bridging transaction of $1,000,000, assuming that the current risk-free interest rate has reached an annualized rate of 10%, the cBridge node can at least obtain an income that matches the risk-free income, and also That's $2,000.
Finally, the above two simple examples simply assume that the bridging transmission is unilateral, and after the liquidity is exhausted, it needs to be completely Liquidity is rebalanced. In fact, the upper bridge and the lower bridge will always exist at the same time, so the mobility will be much more balanced in the actual application process than the two hypothetical examples above. Therefore, in practice, the revenue of cBridge nodes will be higher.
In this way, we allow users to seamlessly move assets and states on different chains through the cBridge architecture, thereby restoring most of the composability that was sacrificed for expansion , win in this deal with the devil!
Finally we want to emphasize that cBridge is completely non-custodial and trustless. This means that users do not need to trust any cBridge nodes during use. You can find more technical information in our previous post about Celer State Channel and cBridge.
The cBridge mainnet release includes two aspects, user-oriented interface and full-node software.
Users can immediately start using cBridge through cbridge.celer.network, in any two of Ethereum, Arbitrum, BSC and Polygon Instant asset cross-chain between chains. As a newly launched product, we always welcome user experience feedback from the community.
For those who want to try running a cBridge node and join the liquidity bridge network while getting some nice For those who benefit, the cBridge node software is a completely open source platform, and everyone can run it. You can move to our github to get related software and operation methods (https://github.com/celer-network/cBridge- node).
Celer's development community will always be on Discord answering community questions and providing support. However, as with any newly launched system, we would like you to gradually deploy liquidity on cBridge nodes to give the system some time to grind and be tested for security.
cBridge v1.0 is just the beginning, future versions will Provides more features:
- Open Networking of cBridge Nodes
span>. For those who want to try to run a cBridge node and join the cBridge network to provide cross-chain and cross-layer liquidity, while generating income by charging fees, once we have passed some time tests, the cBridge node network will soon be fully open to any third party join in!
- Support more chains. cBridge will gradually expand support to other layer1 and layer2 chains according to user needs.
- Dynamic Pricing Strategy SDK. A key component of cBridge is how to price the bridge based on current supply and demand, transaction size, and available liquidity on the target chain. A good pricing strategy can help optimize yield and generate sustainable liquidity. We don't want every cBridge operator to have the exact same fee policy, so we will open up a plugin-based SDK for each cBridge node to easily plug in their own policies and available decision factors.
- state and smart contract call bridging. Token transfers and liquidity bridging are just the first steps. In the future, cBridge will develop towards the state bridging of cross-chain and cross-layer asynchronous function calls.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia