What did cBridge do right to secure its position in the first tier of cross-chain bridges?
From the changes in cross-chain demand, we can see the gains and losses of cBridge 2.0.Author: Azuma
On November 18, the cross-chain payment network cBridge, launched by the Layer2 scaling project Celer Network, officially went live on the mainnet with version 2.0. cBridge official link: cbridge.celer.network .
In version 2.0, cBridge has made significant optimizations in areas such as liquidity provision mechanisms, node operation rules, and user experience, aiming to provide users with a better cross-chain asset experience. Among the many improvements, the most core change is the addition of a brand new liquidity "co-management" mechanism on top of the liquidity "self-management" foundation of version 1.0, making it the only cross-chain bridge on the market with a dual-line parallel asset management model of "self-management" + "co-management."
"Self-management" and "co-management" may sound somewhat difficult to understand at first, and users unfamiliar with the cBridge architecture may find it hard to discern the differences behind these two abstract terms. In the following article, we will gradually explain the similarities and differences between these two liquidity provision mechanisms and analyze the deeper reasons behind cBridge's improvement in response to changes in market demand.
cBridge 1.0, a successful start
Before discussing 2.0, let’s take a step back and look at the development history of cBridge.
cBridge was first proposed earlier this year (February 18), and version 1.0 officially launched on the mainnet in mid-year (July 23). At that time, security incidents in the cross-chain field were frequent, with several cross-chain concept projects such as Chainswap and THORChain falling victim to hackers, and Poly Network was directly hacked for $610 million, becoming the highest amount involved in a hacking incident in DeFi and even the entire cryptocurrency history.
Amidst the dark clouds, security became the primary criterion for users when selecting cross-chain bridge services, and the features of cBridge 1.0 precisely met this demand, as this new type of cross-chain bridge, based on Celer Network's existing state channel product, enhanced security at the foundational architecture level.
Regarding the design architecture of cBridge 1.0, Odaily Planet Daily had previously interviewed Celer Network co-founder and CEO Dong Mo in early August, for more details see "Interview with Celer: What Kind of Cross-Chain Bridge Do Users Really Need."
Specifically, cBridge 1.0 broke away from the traditional logic of centralized liquidity swaps through a unified liquidity pool (the "co-management" mentioned earlier) and adopted a brand new liquidity provision mechanism that allowed liquidity providers to manage funds themselves and respond to user liquidity swap needs by running nodes (the "self-management" mentioned earlier).
The core difference between these two models is that under the cBridge 1.0 scheme, the contract layer no longer needs to undertake the tasks of gathering liquidity on the source chain and releasing liquidity on the target chain, thus it does not need to directly hold any funds; all funds will be completely under the control of the nodes from start to finish. This significantly reduces the risk of fund loss due to contract attacks, achieving a higher level of security.
With the security advantages of the "self-management" model, coupled with extremely fast ecological coverage (covering almost all mainstream ecosystems such as Ethereum, BSC, Avalanche, Fantom, Polygon, Arbitrum…) and a good user experience (the thinner contract layer means transaction fees are closer to regular transfer fees; transfer times are extremely short, for example, transferring from Arbitrum originally took seven days, but through cBridge only takes a few minutes; the interface is simple and easy to use), cBridge 1.0 quickly opened up the market and stood out among numerous cross-chain bridges.
As of November 18, less than four months after the launch of version 1.0 on the mainnet, the total cross-chain transaction volume of cBridge 1.0 had already exceeded $1 billion.
With the surge in business volume, cBridge also earned a good market reputation. When the official cross-chain bridge BSC Bridge was taken offline due to development planning reasons, Binance officially recommended two alternative services to users, one of which was cBridge.
Why add "co-management" if "self-management" is so successful?
Undoubtedly, for cBridge, the "self-management" model of version 1.0 was a very successful start. So the question arises, since "self-management" is so successful, why did cBridge still add the "co-management" mechanism in version 2.0?
To answer this question, we need to look at the changes in market demand. Since September, with the collective explosion of public chains like Solana, Avalanche, and Fantom, the wealth effect of emerging ecosystems has begun to rise, and in pursuit of these new wealth opportunities, users' demand for cross-chain asset transfers has gradually increased, which has raised higher requirements for the liquidity depth of cross-chain bridges.
In this context, the criteria for users choosing cross-chain bridges have also changed somewhat; while emphasizing security, they also consider the depth of the bridge itself. Looking at the situation of cBridge 1.0, although the "self-management" liquidity management solution is secure enough, the threshold for operating nodes is quite high, and node managers need to do things including but not limited to:
Maintain a secure hot wallet environment for private keys;
Ensure operational reliability;
Manage RPCs for each connected chain;
Manage liquidity;
Adjust fee configuration files, etc.
Such a high operational threshold has inadvertently excluded many users who intend to provide liquidity for cBridge, thus limiting cBridge's liquidity expansion capability. In reality, while cBridge 1.0 performed excellently in terms of fees and speed for small and medium-sized cross-chain transactions, it incurred relatively larger losses when handling large transactions due to the overall limited liquidity of the nodes compared to some leading "co-management" solutions.
To further meet market demand, cBridge needs to explore other liquidity provision mechanisms to solve the liquidity expansion problem. This is also the reason why cBridge turned its attention to "co-management" in version 2.0.
How does cBridge 2.0 implement "co-management"?
Although it has been decided to implement "co-management," cBridge 2.0's architecture differs significantly from ordinary cross-chain bridge solutions in terms of specific implementation plans.
Specifically, in version 2.0, cBridge allows Celer's State Guardian Network (SGN) to manage shared liquidity pool contracts across multiple chains as a whole, effectively treating SGN as an open node. Users who wish to provide liquidity for cBridge but find it difficult to operate nodes can choose to delegate their funds directly to the SGN network to earn cross-chain transaction fee revenue. Of course, those who are capable of operating nodes themselves can continue to use the "self-management" model of version 1.0.
When launching cBridge 2.0, Celer emphasized its State Guardian Network (SGN). In Celer's overall system architecture, SGN is a special PoS chain used to monitor L1 events related to L2 states and faithfully relay L2 information back to L1 when needed. SGN's architecture is no different from that of other PoS public chains, and its security is jointly maintained by all validation nodes in the network (not the cross-chain bridging nodes mentioned earlier, but the nodes of the SGN chain itself), thus providing a significant security advantage compared to some cross-chain bridges that use multi-signature solutions.
Upon further examination of the design of the new mechanism, we find that cBridge 2.0 cleverly achieves a win-win situation among multiple parties in the ecosystem:
Liquidity providers, needless to say, benefit from a new mechanism that provides a simpler and more convenient entry channel, allowing more people to participate directly and share in cross-chain transaction fee revenues.
As the number of liquidity providers increases, the overall liquidity depth of cBridge will also improve, thereby enhancing the experience of using large funds for cross-chain transfers.
Additionally, CLER holders can also benefit from this—users who stake CELR to SGN can earn staking rewards and corresponding service fees by providing validation services.
Of course, with every advantage comes a disadvantage. Although the design choice of having SGN manage the liquidity pool has greatly improved system security, given the still severe security situation in the cross-chain field, many users may still have reservations about entrusting funds to a cross-chain liquidity pool.
To further alleviate potential concerns and provide liquidity providers with a more reassuring participation experience, Celer Network has made significant efforts in three other areas:
First, cBridge 2.0 and the upgraded SGN smart contracts are open-sourced;
Second, independent audits have been conducted by three leading security firms: CertiK, Peckshield, and SlowMist;
Third, a $2 million bug bounty program has been launched in collaboration with ImmuneFi for security researchers and white-hat hackers.
Even with so many security guarantees in place, Celer Network has not let its guard down. According to official plans, cBridge 2.0 will be gradually launched in three phases (currently in the second phase: liquidity depth guidance). In different phases, cBridge 2.0 will gradually lift restrictions on liquidity scale and add iterative features to monitor the protocol's operational status and ensure everything is foolproof.
On December 3, cBridge 2.0 launched its first functional iteration, which includes: completing the liquidity migration from cBridge 1.0 to 2.0; supporting native asset cross-chain transfers on the source chain, such as directly transferring native ETH from Ethereum to other chains; supporting Bridge as a Service functionality to meet cross-chain needs in the absence of native bridges; and expanding message modes to accommodate complex logic and large message cross-chain transfers.
On December 15, cBridge 2.0 initiated liquidity mining incentives, and its liquidity pool TVL has now reached $74 million, growing 164% in the past two days.
According to Odaily Planet Daily, cBridge continues to increase support for various native asset cross-chain needs. As of December 17, the total cross-chain funds of cBridge have reached $1.49 billion.
Securing its position in the first tier of cross-chain bridges, cBridge did these three things right
From the proposal of cBridge's research and development direction in February to the launch of version 1.0 in July, and then to the launch of version 2.0 in November, alongside the explosive trend of cross-chain technology, cBridge has gradually entered and secured its position in the first tier of the cross-chain bridge sector, benefiting the parent project Celer Network's development.
Looking back at the development history of cBridge and combining the project's different actions at various points in time, we attempt to summarize some of the successful elements that this project possesses, which may serve as a reference for other emerging projects.
First is market foresight; the project team must dare to predict the future development direction of the sector and even the industry. cBridge was first proposed in February this year when the demand in the cross-chain market was not as clear as it is now, and Celer Network, which primarily focuses on Layer2 scaling, launched a new technical research direction—cross-chain bridges, which has a strategic layout flavor.
Second is the ability to understand demand; the project team not only needs to accurately grasp user needs but also must be able to adjust product design in a timely manner according to changes in market demand. This point is also the main thread of this article, as the transition from version 1.0 to version 2.0 clearly demonstrates how cBridge views changes in cross-chain market demand.
Finally, it comes down to product delivery capability. The time between the release of cBridge version 1.0 and version 2.0 is only a few months, and Celer Network's ability to quickly deliver and iterate products in such a short time while ensuring usability and security indicates that the team has a high level of execution efficiency.
In an interview with us in August, Dong Mo mentioned, "An ideal cross-chain bridge should be secure, easy to use, and inexpensive." Several months have passed, and judging by product performance and user reputation, cBridge is getting closer to its ideal form.
