Since the launch of cBridge 1.0, the total amount of our cross-chain funds has continued to grow exponentially every week. In the first month of launch, we only processed $10M of cross-chain transfers. In the following month, cBridge The total amount of cross-chain funds has risen to $170M, and the daily cross-chain funds have also steadily exceeded the $10M mark. Liquidity providers of cBridge nodes can obtain 45% annualized income only from cross-chain handling fees without any additional incentives. It's exciting, but it's just the beginning.
Today we are pleased to announce the cBridge 2.0 upgrade plan, and give a brief introduction to this innovative upgrade.
The technical architecture of cBridge 2.0 will bring the best cross-chain trading experience in the market, which will be based on providing users with better liquidity depth, and providing the most efficient for cBridge nodes and liquidity providers (LP) who do not want to run nodes And easy-to-use liquidity management methods, and provide developers with generalized cross-chain messaging functions to support cross-chain NFT, cross-chain DEX and other applications. The realization of all functions of cBridge 2.0 is based on the upgrade of the CELR pledge-driven State Guardian Network (hereinafter referred to as SGN), which further enhances the value capture of the SGN network.
secondary title
The content of this article is brief: what kind of optimization does cBridge 2.0 achieve?
For users:
For users:
- Better liquidity depth: supports larger single cross-chain transactions.
- Easier use process: Provide one-click transfer function.
- Support transfers to native gas tokens: For example, WETH on BSC can be directly transferred across chains to native ETH on Arbitrum to pay the gas token on Arbitrum.
- Expansion and support for multiple chains and tokens.
- Bridge node service quality assurance mechanism: For users who choose to use bridge nodes, a new service quality insurance mechanism is introduced, and we will punish offline nodes and compensate users.
For liquidity providers (LP) and cBridge nodes:
- It is not necessary to run a node to provide liquidity:In cBridge 1.0, the only way to provide liquidity is to run a cBridge node. In 2.0, we added a new mode in which the SGN itself will exist as a cBridge node. Liquidity providers can delegate liquidity to the co-management node run by SGN, and do not need to run additional cBridge nodes themselves while obtaining cross-chain handling fees.
-Optimal Liquidity Management Experience:Compared with other cross-chain solutions, the LP of cBridge 2.0 does not need to mint synthetic tokens, does not need to forcibly join a highly volatile AMM liquidity pool, and does not need to suffer high impermanent losses. You only need to simply provide single-currency liquidity, and you can flexibly control your own liquidity distribution for arbitrage.
- Extremely high liquidity efficiency:Compared with other cross-chain solutions, cBridge 2.0 does not require additional double liquidity locking, thereby improving the unit value and efficiency of liquidity, and maximizing LP revenue.
- Reasonable liquidity rebalance design:cBridge 2.0 unifies and co-manages liquidity through SGN, supports and generates optimal asymmetric AMM curves according to supply and demand, thereby incentivizing arbitrageurs and LPs to maintain sufficient and symmetrical liquidity of the overall network.
- Optimal self-management mode cBridge node scheduling:For those liquidity providers who choose to self-operate and manage cBridge nodes, SGN will conduct a unified optimization of user experience scheduling.
Value Capture:
- Value Capture:Protocol Governance:
- Protocol Governance:Various system parameters, such as price curves, fee ratios, etc., are governed through a distributed protocol based on CELR pledge.
For developers:
- White label of the front-end SDK:Allow all kinds of multi-chain dApps to integrate the functions of cBridge locally, allowing users to directly cross-chain within their dApps.
- Provide cross-chain messaging function to support NFT cross-chain and other applications:It allows developers to develop more complex applications than simple asset cross-chains, such as cross-chain NFT and cross-chain DEX, etc.
So, how did we implement all these new functions and features in cBridge 2.0?
Answer: Celer's State Guardian Network - SGN.
secondary title
State Guardian Network Review
exist
existIn the Celer state channel, SGN helps to store channel state and respond to malicious settlement on L1 when needed. in Celerlayer2.finance rollup chain, SGN expands into a decentralized block producing network, passing call data and state roots back to L1. In the Rollup mode of operation, even if the entire PoS consensus fails, any SGN node can still put fraud-proof on the chain to ensure system security.
secondary title
SGN acts as cBridge node gateway and service level agreement (SLA) arbitrator
Node Design Choices and Limitations of cBridge 1.0
In cBridge 1.0, when a cBridge node joins the network, it registers various information with a gateway service, such as fee schedule and liquidity status. The gateway will continuously monitor the status and performance of the cBridge nodes. When a user request is made, it is directed to the gateway. The gateway evaluates registered nodes based on liquidity availability, historical bridging success rate, fees, etc. It then suggests the most suitable bridge node for the request. In 1.0, we chose to use a centralized gateway to quickly learn the operational experience of various scheduling strategies.
What the 1.0 gateway offers users is actually a "FYI" recommendation to use certain cBridge nodes. Although cBridge 1.0 is built with a non-custodial architecture where users never need to trust a node for the safety of their funds, it does have user experience issues related to "node availability". For example, if a user sends a conditional transfer (the first part of an HTLC) to a node, but the node goes offline before the two-step HTLC transfer completes, the user will have to wait for the conditional transfer to time out, and the cBridge node will not be offline And subject to any punishment, the user will not get any compensation for the waiting time.
We addressed both of these limitations in 2.0 with SGN.
Decentralized and efficient cBridge node scheduling through SGN
In 2.0, we first migrated all the centralized gateway logic as distributed services to the distributed SGN. cBridge nodes will register with SGN based on their fee preferences, liquidity availability, etc., rather than with centralized gateway services.
When a user makes a request, the normal system flow is as follows:
- Users query the current status of SGN for estimated transaction fees and liquidity availability.
- If the estimated fee is acceptable, the user sends the first half of the HTLC transfer, specifying a maximum fee tolerance.
- SGN monitors and receives transactions. It assigns one or more cBridge registered nodes for transactions according to node scheduling rules. This transaction allocation is written on the SGN chain and is also marked in the user's HTLC transfer.
- The assigned node accepts the assignment and responds by completing the remaining conditional transfers.
- SGN continues to monitor and track the transaction, once the transaction is successfully completed, the state related to this transaction will be cleared from the SGN chain.
Based on this, a more scalable cBridge node growth will be achieved to support consensus and unbiased node selection process. But the benefits of migrating cBridge nodes to SGN are more than that.
Bridge node SLA deposit and penalty mechanism
Different from the 1.0 gateway, under the framework of SGN as the scheduling layer (gateway), SGN monitors the whole process of cross-chain transactions. As a decentralized PoS chain, SGN can now provide more than just "suggestions for reference only", it can also impose penalties on cBridge nodes that cannot complete the allocated cross-chain transfers "as promised".
When a cBridge node registers with the SGN, it can place an "SLA bond" (i.e., a bunch of valuable Token). If SGN determines that the node violates the SLA, for example, the node goes offline when the transfer is not completed, SGN can confiscate its deposit as compensation for the decline in user experience and the opportunity cost of liquidity. (Note that there is never the possibility of user fund loss here, and the above compensation is only for the opportunity cost loss caused by "funds stuck".)
During node selection, the available value of the SLA deposit is a key factor for priority consideration in the node scheduling allocation process. Honest and reliable cBridge nodes have a strong willingness to stake a bond to increase their chances of being selected in the bridging process. On the other hand, less reliable nodes will be kicked out of the system or made the lowest priority option.
Through the SLA margin function supported by the distributed "SGN Gateway", cBridge nodes can perform high-quality SLA operations. This aims to provide a healthy, rapidly growing and decentralized network of cBridge node operators for liquidity providers who wish to maintain “self-hosted liquidity”.
Some might argue that setting up an SLA deposit cannot be called 100% self-custody due to the possibility of PoS consensus failures, where the SLA deposit could be wrongly slashed.
We would like to emphasize that the SLA margin only needs to be a small percentage of the total liquidity to efficiently ensure a smooth user experience and a self-healing cBridge node operator ecosystem. This is a very worthwhile trade-off. The most important thing is that the entire cross-chain process is always "non-custodial" from the user's point of view, and there is no risk of capital.
Node Scheduling Rules
The principle of node scheduling rule design is to optimize user experience. We built an empirical formula for a "Node Quality Score" that combines multiple factors such as parameters in a node's SLA (fee, response time) and historical performance (eg success rate, average response time). When selecting nodes for user requests, we prioritize nodes based on this score. We want this formula to be iterated and optimized over time through protocol governance, through empirical operational experience.
secondary title
SGN as shared liquidity pool manager
Provide liquidity without running a cBridge node
The improvements described above are more designed for self-hosted LPs that can run cBridge nodes themselves. However, we recognize that there are a large number of LPs and users who want to provide liquidity but do not want to run cBridge nodes themselves, while they are also satisfied with the level of security provided by the PoS consensus of SGN and CELR staking. In addition, through the shared liquidity pool model, the liquidity of the entire network can be easily activated, thereby promoting better user experience faster.
Therefore, in cBridge 2.0, we have introduced a brand new mode of operation: SGN as a whole manages the shared liquidity pool contracts on multiple chains. This actually treats SGN, which itself is a distributed PoS chain, and its managed liquidity pool as a single "node", and provides an option for LP to easily delegate liquidity to SGN, Obtain cross-chain fee income without running any nodes.
So, what security guarantees does this model provide?
PoS-level security and decentralized governance
In this mode of cBridge 2.0, the shared liquidity pool contract is managed through SGN's PoS consensus. Transferring funds in the pool contract requires a CELR stake-weighted multisig. The pool is only at risk if more than ⅔ of the total stake is malicious. What we want to emphasize is that with the increase in the number of cBridge cross-chain transactions and the growth of the total value captured by the cBridge network, any node attempting malicious behavior will naturally increase the difficulty and cost. This is fundamentally different from other solutions using TSS multi-signature in terms of security, because TSS itself does not bind any token pledge, so its security cannot grow with the growth of network value.
The validator governance model in SGN is open and decentralized: SGN allows new validators to be elected and join the set of validators through the Staking governance process without any special coordination process.
Simple Liquidity Provider (LP) Experience and High Liquidity Efficiency
So how do LPs manage their liquidity in this model? Existing solutions, such as Hop Protocol and Thorchain, require LPs to put token liquidity into an on-chain AMM pool along with another protocol-controlled settlement token. But this model has some disadvantages:
- For example, Thorchain requires LP to use Rune, a highly unstable settlement token, which will inevitably cause LP to suffer significant impermanent losses.
- Even when minting synthetic tokens from native liquidity tokens, LPs still face complex operational overhead when adding, removing, and rebalancing liquidity across multiple chains.
- For example, when Hop Protocol needs "bonder" to provide liquidity, its liquidity efficiency is low, because the actual demand for liquidity for any cross-chain transfer is twice its necessary liquidity.
cBridge 2.0 solves the "liquidity attribution problem" through a new design, providing a simple LP experience and high liquidity efficiency. To better understand our system design, we will first explain what "liquidity attribution" means. In any multi-chain bridging system, when a user sends funds from a source chain to a target chain, the LP (or aggregation pool) essentially pays funds to users on the target chain while receiving funds from users on the source chain. Now, suppose there is an LP providing liquidity to the system on chain A. When users send funds from chain B to chain A, the liquidity of LPs is essentially "redistributed": their liquidity on chain A decreases, and their liquidity on chain B increases. The liquidity attribution problem is defined as "how the system lets each LP know where all their liquidity is" and "how to effectively manage liquidity to optimize transaction fee yield".
AMM pool-based solutions implicitly track LP liquidity by allocating settlement tokens and native tokens in the AMM pool. Bridging structures such as TSS validators or L2 to L1 messaging protocols only manage the minting and burning of cross-chain settlement tokens. Users will always need to pay fees for AMM swaps from settlement tokens to native tokens on the target chain; sometimes even on the source chain. When liquidity imbalances occur in the network, it makes sense to move liquidity from chains with plentiful liquidity to chains with scarce liquidity to arbitrage slippage. Arbitrageurs will have an incentive to rebalance liquidity by sending funds from liquidity-scarce chains to liquidity-rich chains.
At the same time, LPs have a stronger incentive to balance liquidity, because they do not need to pay additional bridge fees to reap arbitrage income. However, the rebalancing process for LPs is very complicated. For example, if we denote the liquidity-scarce chain as S and the liquidity-abundant chain as A, LPs will need to take the following steps:
- Remove liquidity from S's AMM pool.
- Move settlement tokens from S to A.
- Sell the settlement token to the AMM pool on A at a premium to exchange it back to the native token.
- Move native tokens back to S.
- Purchase settlement tokens on S.
- Add liquidity back to S's AMM pool.
The above steps not only incur some operational expense, but also incur significant transaction and time costs.
In cBridge 2.0, we believe that the bridge structure (SGN in our case) can be highly optimized, radically reducing costs compared to on-chain smart contract operations. Therefore, in cBridge 2.0, the liquidity of each LP in the system is explicitly tracked. Adding liquidity is super easy: just add native tokens to the liquidity pool contract with a single transaction, and SGN will record the liquidity amount for each LP in SGN's chain state. Essentially, SGN maintains a (chain_id, LP_address, token_type, balance) table in its chain state.
When processing cross-chain transfer requests, SGN will use the liquidity of the entire pool to calculate slippage and pricing (detailed in the next section), and then SGN will treat LPs as "virtual cBridge nodes" and allocate them according to the liquidity of LPs transfer request. A simplified conceptual understanding is that for each transfer request, the LP liquidity balance of each target chain will decrease proportionally to its available liquidity, while their liquidity balance on the source chain will increase. Of course, in actual engineering implementation, we use methods such as random sampling and approximation algorithms to minimize state changes and costs while maintaining statistical fairness among LPs. This part is reflected in more detail in our technical documentation.
Such a structure is also suitable for liquidity balance based on arbitrageurs, and this design also provides maximum flexibility for LPs in managing their liquidity. Each LP can clearly see how their liquidity is distributed at any given time. This allows them to fully understand what is going on when they choose to remove or add liquidity to any chain. This simplifies the liquidity rebalancing process from 6 steps to 3 steps with no AMM swap costs:
- LP directly removes the liquidity of native tokens in A. Due to the slippage in the system, in this first step, LP has already locked in the slippage arbitrage income.
- LP moves the native token from A to S.
- Add native tokens to S's pool.
LPs can still remove all liquidity from a single chain or any combination of specific chains. In cBridge 2.0, the way this is done is by triggering internal cross-chain transfers and treating LPs as users, transferring their liquidity to the desired chain, and then removing liquidity. , please note that in this case, LP will bear the system slippage of the cross-chain transfer. However, this is no different than exchanging settlement tokens directly for AMM-based on-chain solutions, and is actually less expensive.
More importantly, in cBridge 2.0, LP directly uses native token liquidity, so it will not suffer high impermanent losses. Especially compared to Hop Protocol, cBridge does not require any additional bonder liquidity locking requirements, so as to achieve the highest liquidity efficiency and obtain the best liquidity rate return.
Cross-chain bridge pricing to incentivize balanced liquidity
In a cross-chain bridging system, the liquidity of the same native token exists on multiple chains. As the demand for the same native token on different chains changes, the inherent pricing between the same token on different chains will also change dynamically. This is based on the potential cost of using native bridges to transfer between different chains and the balance of supply and demand for liquidity on these different chains.
It is important for any bridging solution to be able to capture this inherent price variation by designing an appropriate bonding curve. This creates significant incentives for LPs to leverage "economies of scale" to rebalance liquidity across multiple chains to maintain a network with sufficient and balanced liquidity to handle all user requests.
Continuing to uphold our design principle of "smart architecture", we have established a bonding curve pricing mechanism inspired by the Curve stablecoin AMM within SGN. When a user transfers tokens from one chain to another, SGN will calculate the tokens received based on the available liquidity on the source and target chains. In addition to the pricing itself, a fixed fee is deducted from the transaction as a fee to the LP.
Specifically, for any pair of chains i and j, let the balances on chain i and chain j respectively be a given token. Then when we calculate the slippage of token transfers between chains, the following invariants should always hold for i and chain j:
- A is a constant for each chain pair. For the same chain pair, all tokens of A are the same.
-D is a variable. initial D. D can be obtained by solving the cubic equation for Given the initial liquidity on the two chains, after that, D. It should be updated iteratively according to the liquidity status.
- and are the relative weights of the two chains, used to control the slippage asymmetry of the transfer. Note that the configuration of weights is per chain pair and should be satisfied.
The reason we use these weight parameters in the bonding curve is to capture the inherent asymmetry of certain chains. For example, it is much simpler and cheaper to transfer into rollups such as Arbitrum and Optimism than to transfer out with a 7-day delay. Therefore, we can control the weights in the bonding curve to reflect this inherent difference produced by each chain.
In the red asymmetric curve above with the blue symmetry reference line, we can see that the curve creates more slippage for the transfer from chain i to chain j when the imbalance occurs. If , then simplify to the curve used by Curve Finance.
Universal Cross-Chain Messaging
cBridge 2.0 creates a smart cross-chain structure based on SGN. What this structure can do is not only cross-chain asset transfer, but also a general cross-chain messaging framework, in which SGN monitors any events on the source chain and publishes consensus notarization of these events on the target chain, completing Information cross-chain process.
secondary title
Network Value Capture
Unlike many governance tokens (where protocol token holders do not assume day-to-day functions of the protocol), it is clear that CELR holders and a network of state guardians are essential to the good operation of cBridge.
Therefore, users and LPs in cBridge 2.0 need to pay fees to SGN in exchange for its services. These fees are distributed proportionally to CELR stakers in SGN. Specifically:
- In the model where SGN acts as a bridging gateway and SLA arbitrator, a part of the cross-chain transaction fees and forfeited security deposit will be transferred to SGN for its scheduling node and SLA arbitration work.
- In the model where SGN acts as a shared liquidity manager, part of the cross-chain transaction fee is paid to SGN to help handle all cross-chain liquidity transfers.
secondary title
Concluding remarks on cBridge multi-chain bridge design trade-offs
This final section is about our thoughts on the technical trade-offs in the design of cross-chain bridges. We believe that the biggest trade-off in the design of cross-chain bridges depends on the ownership of the control rights of system liquidity.
Some might say that a self-regulatory bridging solution is the "purest" and "safest" bridging design. While we acknowledge the principles of this argument, we would like to emphasize that not everyone can actually run a cBridge full node. Of course, we are confident in the potential of this model, which is why we designed the "SGN as cBridge node gateway and service level agreement (SLA) arbitrator" self-hosted model.
At the same time, we believe that our design philosophy is to meet the preferences of various users and LPs, and present all available options in a non-biased manner, so that both users and LPs can choose according to their own preferences. This is why cBridge 2.0 also comes with a model of "SGN as a shared liquidity pool manager", which also hopes to guide liquidity faster to achieve wider adoption of cBridge.
secondary title
start plan
Blockchain interoperability is new territory, as evidenced by previous hacks in this area. We've always held system security to the highest standards and strive to keep our cybersecurity boot record unbroken.
Therefore, cBridge 2.0 will be rolled out in phases.
We plan to launch the "SGN as a shared liquidity pool manager" model in October as the first phase of the cBridge 2.0 test network, and conduct at least two security audits on the system and smart contracts.
After the testnet and audit, we will launch a $1 million bug bounty program and gradually roll out the cBridge 2.0 mainnet.
After that, we will enter the "SGN as cBridge node gateway and service level agreement (SLA) arbitrator" mode as the second stage.
