Since the release of cBridge 1.0, it has seen a continuous doubling of volume week over week. Starting at $10M of total volume for the first month, it reached $170M in the second month with now over $10M of daily volume. At this point, we are seeing around a 45% APY just on fees for the liquidity provided. Exciting? Absolutely—and we are just getting started!
Enter cBridge 2.0: an innovation-packed major upgrade. cBridge 2.0 introduces the best-in-class cross-chain token bridging experience with deep liquidity for users, highly efficient and easy-to-use liquidity management for both cBridge node operators and Liquidity Providers who do not want to operate cBridge nodes, and new exciting developer-oriented features such as general message bridging for cases like cross-chain DEX and NFTs. All of the above is made possible by extending the existing functionality and services provided by the Celer State Guardian Network (SGN) powered by validators and stakers in the system with value capture.
TL;DR: How is cBridge 2.0 better?
For folks not interested in the shadowy super-coder technical stuff, here is a quick summary of improvements and additions brought by 2.0.
For users
- Deep liquidity: supports much larger transfer sizes.
- Simpler to use: offer an option to reduce two-step operations to a single click.
- Native gas token unwrapping: e.g. transfer WETH from BSC to unwrapped ETH on Arbitrum.
- Extend to even more tokens and chains
- Insured bridge node Service Level: did you initiate a transfer but the bridge node was not available? Slash cBridge node’s bond to cover your opportunity cost!
For LPs and cBridge node operators
- LPs don’t have to run a cBridge node: in cBridge 1.0, the only way to provide liquidity is to run a cBridge node. In 2.0, we added a second mode where the SGN itself acts as a “cBridge node.” For LPs satisfied with PoS-consensus-level security based on CELR token economics in the SGN, they can directly delegate liquidity to the network without operating a node themselves.
- Simple Liquidity Provider (LP) experience: No minting synthetic tokens, no volatile token pair AMM pool, no high impermanent loss, no complicated rebalancing. Simply add liquidity to the chain of your choice and start to earn fees!
- High liquidity efficiency: No double liquidity locking, fully utilize liquidity with the highest yield.
- Incentivized liquidity rebalance: lopsided liquidity movement? No worries! An AMM-style bonding curve and a flexible liquidity mining mechanism are in place to incentivize LPs and arbitrageurs to rebalance liquidity cross-chain.
- High Quality-of-Service node scheduling: For LPs operating self-custodial cBridge nodes, the SGN becomes the decentralized layer to allocate user transfer requests to different LPs through policies that incentivize high-quality service and competitive pricing.
Fo staker and validators participating in State Guardian Network
- Value capture: In return for their active services and roles in supporting cBridge 2.0, PoS stakers and validators in the SGN directly capture the value of cBridge via fees paid to the block producer facilitating user’s bridging request. This is very much like fee being paid for any PoS blockchain validators.
- Governance: Various system parameters including pricing curve, fee percentage, and more are governed through a decentralized governance process built in the active service SGN.
For developers:
- White-label frontend SDK: Allows multi-chain dApp to have a built-in cross-chain experience.
- Cross-chain messaging for NFT and more: Allows developers to build applications beyond simple cross-chain asset transfers, including cross-chain DEX and NFT cross-chain minting.
So, how do we achieve all of these cool improvements and innovations? What bridging design tradeoff space do we cover in the 2.0 architecture? At a high level, how exactly do all of these things work?
Answer: The State Guardian Network (SGN).
In cBridge 2.0, we extend the SGN to support two different bridging operation models that can cater to LPs and users with different preferences. In this blog, we provide an architectural overview with detailed technical specifications to follow.
Refresher on the State Guardian Network
The Celer State Guardian Network (SGN) has been an essential part of Celer Network’s architecture. In Celer’s layer-2 scaling architecture, the SGN is a specialized Proof-of-Stake (PoS) chain that serves the purposes of monitoring L1 transactions related to L2 state and faithfully passing layer-2 information back to layer-1 when needed.
In the Celer State Channel, the SGN helps store channel states and respond to malicious settlements on L1 when needed. In the Celer layer2.finance rollup chain, the SGN extends as a decentralized block producer network to pass call data and state roots back to the L1 blockchain and submit fraud-proof from any SGN node even when the entire PoS consensus fails.
CELR holders can stake their tokens into the SGN by becoming a validator or through delegation and actively provide the above-mentioned services. SGN participants receive staking rewards as well as fees in exchange for the services they help provide.
The SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator
Design Choices and Limitations of 1.0
In cBridge 1.0, when a cBridge node joins the network, it registers to a gateway service with various information such as fee schedule and liquidity status. This gateway will continuously monitor the status and performance of the cBridge node. When a user request is made, it is directed to the gateway. The gateway evaluates the registered nodes based on liquidity availability, historical bridging success rate, fee, and more. Then it suggests the most suitable bridge node for the request. In 1.0, we chose to use a centralized gateway to quickly learn operation experiences on various scheduling policies.
Basically, what the 1.0 gateway provides to the user is really an “FYI” suggestion to use certain cBridge nodes. Although cBridge 1.0 is built with non-custodial architecture and users NEVER need to put trust in nodes for their fund’s security, there is indeed a user experience issue related to node availability. As an example, if after a user sends a conditional transfer to a node but the node goes offline before the two-step HTLC transfer is complete, they will have to wait until the conditional transfer times out, without any penalty to or compensation from this offline cBridge node.
We solve both of these limitations in 2.0 via the SGN.
Decentralized bridge node scheduling via the SGN
In 2.0, we first decentralized all of the gateway logic by migrating it as a service on top of the SGN. Instead of registering with a centralized gateway service, cBridge nodes will register with the SGN with their fee preference, availability of liquidity, and more.
When a user request is made, this is the “happy” system flow:
- The user queries the current state of the SGN to get an estimated transaction fee and liquidity availability.
- If the estimation is acceptable, the user sends the first half of the HTLC transfer with max fee tolerance specified.
- The SGN monitors and picks up the transaction. It assigns one or more registered cBridge nodes to the transaction based on node selection rules. This transaction assignment is written on the SGN chain and also marked on the user’s HTLC transfer.
- The assigned node picks up the assignment and responds by completing the rest of the conditional transfer.
- The SGN continues to monitor and track the transaction and once the transaction is successfully completed, the state related to this transaction is purged from the SGN chain.
This allows for a much more scalable cBridge node onboarding process with a consensus-based and unbiased node selection process. But we didn’t stop there.
Bridge node SLA bond and slashing mechanism
As opposed to 1.0’s gateway, the SGN-as-a-gateway architecture monitors the whole process of the cross-chain transaction. As a decentralized PoS chain, the SGN can now offer more than just a “friendly suggestion.” It can also enforce penalties to registered cBridge nodes that cannot complete transactions assigned to them “as promised.”
When a cBridge node registers with the SGN, it can put down an “SLA bond” (i.e. a bunch of tokens with value) associated with some SLA promises (e.g. availability, fee level, and liquidity reserve) in a pool contract. If the SGN determines that this node violates the SLA, such as being offline with an assigned transfer, the SGN can slash the bond as compensation to the user for the degraded user experience and liquidity opportunity cost. (remember, no fund loss for users is possible, this is just for “fund getting stuck” cost.)
During node selection, the value available in the SLA bond is a key factor in how the node is prioritized in the transfer assignment process. Honest and reliable cBridge nodes are heavily incentivized to invest in a reasonable SLA bond to increase their chances of getting selected in the bridging process. On the other hand, less reliable nodes will be driven out of the system or will only be called upon as a last option. Finally, cBridge nodes can only be de-registered with the SGN once there are no pending cross-chain transactions.
With the SLA bond slashing capability powered by the decentralized “SGN gateway,” the node availability challenge, and more generally, the SLA assurance concerns, are solved. This is aimed to facilitate a healthy, fast-growing, and decentralized cBridge node operator network for liquidity providers who want to maintain their self-custodial liquidity.
Some may argue that the SLA bond is not a 100% self-custodial setting due to the possibility of having the SLA bond wrongly slashed because of the possibility of a PoS consensus failure.
While this is true, we want to highlight that the SLA bond only needs to be a very tiny portion of the total liquidity in order to become highly efficient in ensuring a smooth user experience and a self-healing cBridge node operator ecosystem. This is a very worthwhile tradeoff to make and most importantly, the entire transfer process stays 100% non-custodial.
Node selection rule
The principle of the node selection rule design is to optimize for user experience. We build an empirical Node Quality Score formula to incorporate multiple factors such as the parameters in a node’s SLA (fee, response time) as well as historical performance. (e.g. success rate, average response time) When selecting nodes for user requests, we prioritize the nodes according to this score. We expect this formula to iterate and optimize over time with empirical operation experiences through protocol governance.
The SGN as a Shared Liquidity Pool Manager
Provide liquidity without running a cBridge node
The above improvements are designed more for self-custodial LPs who are capable of running their own cBridge nodes. However, we recognize that there are a large number of LPs and users who want to provide liquidity without running a cBridge node themselves and are satisfied with the security level provided by the SGN’s PoS consensus with CELR staking. In addition, through a shared liquidity pool model, the entire network liquidity can be easily bootstrapped to facilitate a much better user experience much faster.
So in cBridge 2.0, we are introducing an entirely new model of operation where the SGN manages shared liquidity pool contracts on multiple chains. This effectively treats the SGN and its managed liquidity pool as a single “node” along with all the other non-custodial LP-managed nodes and gives an option to the LPs to delegate liquidity easily without the hassle of running a node.
So, without any ambiguity, what security level does this model offer?
PoS-level security and decentralized governance
In cBridge 2.0, shared liquidity pool contracts are managed through the SGN’s PoS consensus. CELR staking weighted multi-signatures are needed to move funds in the pool contracts and malicious or faulty nodes will be slashed out of their staking token. It is only when nodes with more than ⅔ of the total stake are malicious, that the fund pool will be at risk. We want to stress that as the number of cBridge transactions grows and the total value captured by the network grows, it will be a naturally increasing economic deterrent for any node to try to behave maliciously.
The validator governance model in the SGN is open and decentralized: the SGN allows new validators to be elected and join the validator set through the staking governance process without any special coordination processes.
Simple Liquidity Provider (LP) experience and high liquidity efficiency
So how do LPs manage their liquidity in this model? Existing solutions require LPs to put canonical token liquidity along with another protocol-controlled settlement token in on-chain AMM pools. But this model has a few drawbacks:
- Some models require LPs to use a highly volatile settlement token and therefore inherently expose LPs to a significant impermanent loss.
- Even in the case of minting synthetic tokens through canonical liquidity tokens, LPs still suffer from complicated operational overhead when adding, removing, and rebalancing liquidity across multiple chains.
- In the case where “bonder” liquidity is required, the liquidity efficiency is lower because the liquidity requirement for any transfer is double what’s necessary.
cBridge 2.0 provides a simple LP experience and high liquidity efficiency through a new design to solve the “liquidity attribution problem.” To 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 destination chain, LP(s) (or aggregated pools) essentially pay funds to the user on the destination chain while receiving funds from the user on the source chain. Now, let’s say there is an LP providing liquidity to the system on chain A. When a user sends funds from chain B to chain A, the LP’s liquidity essentially is “redistributed”: their liquidity on chain A is reduced and their liquidity on chain B is increased. The liquidity attribution problem is defined as “how does the system allow every LP to know where all of their liquidity is?” and hence how to effectively manage the liquidity to optimize for transaction fee yield.
An AMM pool-based solution tracks LPs liquidity implicitly via the distribution of settlement tokens and canonical tokens in the AMM pool. The bridging fabric (e.g. TSS validators or L2-to-L1 messaging protocols) only manages the minting and burning of the settlement tokens cross-chain. The user will always need to pay for an AMM swap from the settlement token to the canonical token on the destination chain; sometimes even on the source chain as well. When a lopsided liquidity movement happens in the network, it makes sense to move liquidity from the liquidity-abundant chain to the liquidity-scarce chain to arbitrage the slippage. Arbitragers will have an incentive to rebalance the liquidity by sending funds from the liquidity-scarce chain to the liquidity-abundant chain.
Active LPs have stronger incentives due to that they don’t need to pay additional bridging fees to harvest the arbitrage gain. However, the rebalancing process for LP is quite complicated. As an example, if we denote the liquidity-scarce chain as S and liquidity-abundant chain as A, an LP would need to take the following steps:
- Remove liquidity from the AMM pool in S.
- Move the settlement token from S to A.
- Sell the settlement token to the canonical token on A at a premium
- Move the canonical token back to S.
- Purchase the settlement token on S.
- Add liquidity back into the AMM pool on S.
The above steps not only cause operational overhead but can also incur significant transaction and time costs. (e.g. in the case of the bonder model)
In cBridge 2.0, we argue that the bridging fabric (in our case the SGN) is specialized and can be highly optimized to have fundamentally lower costs when compared to on-chain smart contract operations. Therefore, in the cBridge 2.0, every LP’s liquidity in the system is explicitly tracked. Adding liquidity is super simple: just one transaction to add the canonical token into the liquidity pool contract and the SGN will record each LP’s liquidity amount in the SGN’s chain state. In essence, the SGN maintains a table of (chain_id, LP_address, token_type, balance) in its chain states.
When processing cross-chain transfer requests, the SGN will use the entire pool’s liquidity to calculate the slippage and pricing. (more on this in the next section) The SGN then treats LPs as “virtual cBridge nodes” and allocates the transfer request against the LP’s liquidity. A simplified conceptual understanding is that, for every transfer request, every destination chain’s LP’s balance is reduced proportionally to their available liquidity while their liquidity balance is increased on the source chain. Of course, various methods including random sampling and approximation algorithms are used to minimize state changes and hence costs, all while maintaining statistical fairness among LPs. More details are in our technical documentation.
The same arbitrager-based rebalance incentives applies, but this design additionally gives LPs the utmost flexibility when managing their liquidity. Every LP can clearly see exactly how their liquidity is distributed at any given time. This allows them to be fully informed when choosing to remove or add liquidity to any chains. This significantly simplifies the liquidity rebalancing process from 6 steps to 3 steps with no AMM swap costs:
- The LP removes liquidity from A directly in canonical tokens. Due to system-wide pricing difference, with this first step, the LP locks in the arbitrage gain.
- The LP moves the canonical tokens from A to S.
- The LP adds the canonical tokens on pools in S.
It is still possible for LPs to remove all liquidity from a single chain or any combination of specific chains. In cBridge 2.0, the way to do this is to trigger an internal cross-chain transfer and treat the LP as a user and transfer their liquidity to the desired chains and then remove the liquidity. Note that in this case, the LP will shoulder the system slippage for the cross-chain transfer. However, this is no different than directly swapping settlement tokens for the on-chain AMM-based solutions and in fact, has a lower cost.
What’s more, as described in this model, LPs use canonical token liquidity directly and therefore do not suffer from high impermanent loss. Plus, it provides the highest level of liquidity efficiency without any additional bonder liquidity lockup requirement.
Cross-chain bridge pricing to incentive balanced liquidity
In a cross-chain bridging system, liquidity for the same canonical token exists on multiple chains. As the demand for the same canonical token shifts for different chains, the inherent pricing between the same token on different chains also dynamically changes. This is based on the underlying costs to use those native bridges to move across different chains and the supply-demand balance of liquidity on those different chains.
It is very important for any bridging solution to be able to capture this inherent pricing shift with a properly designed bonding curve. This creates important incentives for LPs to leverage the “economies of scale” and rebalance liquidity across multiple chains to maintain a network with sufficient and balanced liquidity to process all of the user requests.
Continuing with our design principle of having an “intelligent fabric,” we build a Curve-inspired bonding curve pricing mechanism inside the SGN. When a user transfers tokens from one chain to another, the SGN will calculate the received token based on the available liquidity on the source and destination chains. In addition to the slippage and pricing, a flat fee is deducted from the transaction as payment to LPs.
Specifically, for any pair of chains, i and j, let xiand xjbe the balance on-chain i and chain j for a given token, respectively. Then the following invariant should always hold true when we calculate the pricing and slippage of token transfers between chain i and chain j:
- A is a per-chain-pair constant. For the same chain pair, A is the same for all tokens.
- D is a variable. The initial D can be obtained by solving a cubic equation against D given the initial liquidity on the two chains. After that, D should be iteratively updated based on liquidity status.
- wi and wj are the relative weights for the two chains, which is used to control the pricing asymmetry for the transfers. Note that the configuration of weights is per-chain-pair and should satisfy wi+wj=2.
The reason we have these weight parameters in the bonding curve is to capture the inherent asymmetry of certain chains. For example, transferring into optimistic rollups, such as Arbitrum and Optimism, is much simpler and lower cost than the 7-day delay of transferring out. Therefore, we can control the weight in the bonding curve to reflect this inherent difference created by each and every chain.
In the above red asymmetric curve with the blue symmetric reference line, we can see the curve creates more slippage for transfers from chain i to chain j when the imbalance happens. If wi=1, wj=1, it reduces to the Curve invariant.
It is also possible to treat an entire network of similar canonical liquidity as a single multi-variable bonding surface. More analysis is needed on the effects of these two different potential designs in terms of slippage effectiveness and cost of operation.
General cross-chain messaging
cBridge 2.0 creates an intelligent cross-chain fabric based on the SGN. This fabric can do more than just cross-chain asset transfers. Under the asset bridging functionality is actually a general cross-chain messaging framework where the SGN monitors certain events on the source chain and posts a PoS consensus secured notarization on the destination chain.
We will be gradually opening up this underlying functionality to developers as an SDK to build use cases for not only on-chain bridging, but for other use cases like cross-chain NFT, cross-chain DeFi aggregation, and more.
Network Value Accurral
Unlike many tokens where protocol token holders do not take on active duty of the protocol’s daily function, it is obvious that CELR token stakers and validators are indispensable in the smooth operation of cBridge via the SGN’s new extension, as explained in both of the above models.
As such, users and LPs in cBridge 2.0 are required to pay fees to the SGN in return for its services. This is very much like fee being paid for any PoS blockchain validators. These fees are distributed to the CELR stakers in the SGN nodes who generate the block. Specifically:
- In the model where the SGN acts as a bridge gateway and as a SLA arbitrator, a part of the total transaction fee is actually fee paid to the SGN for its work of scheduling nodes and SLA arbitration.
- In the model where the SGN acts as a shared liquidity manager, a part of the total transaction fee is the fee due to SGN for its work in helping processing all of the cross-chain transfers.
There are also a number of system parameters and configurations that require governance-based updates and tuning to ensure the smooth and continuous operation of the system. CELR will also be acting as a governance token for this new component in Celer’s ecosystem.
Closing notes on multi-chain bridge design tradeoffs
Finally, we provide our perspective on the cross-chain bridging design tradeoff space. We believe that the biggest tradeoff in cross-chain bridging design is about the control of liquidity in the system.
Some may argue that a self-custodial-only bridging solution is the “purest” and “safest” bridging design. While we recognize the principle of this argument, we want to highlight that the reliable operation and operational security of cBridge set a fairly high bar for liquidity providers. We are, of course, confident about this model’s long-term potential and that is why we designed the self-custodial “SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator” model.
In the meantime, we believe in our design philosophy of covering the entire tradeoff space and presenting all of the available options in an unbiased manner so both users and LPs can select their best options. This is why cBridge 2.0 also comes with the model of “The SGN as a Shared Liquidity Pool Manager” with the hope to bootstrap liquidity faster to achieve wider adoption.
After all, no matter if it is a white cat or a black cat; as long as it can catch mice, it’s a good cat.
Launch Plan
Blockchain interoperability is new as evidenced by the previous hacking incidents in this space. We, as Celer community, treat security with the highest standard and strives to keep our long records of safe launches and operations for the network.
cBridge 2.0 will be launching in phases. In Oct 2021, we plan to launch the “SGN as a Shared Liquidity Pool Manager” mode as the Phase One testnet with at least two security audits on the system and smart contract.
After the testnet and audits, we will launch a $1M bug bounty program along with a gradual rollout mainnet.
After that, we will proceed to “SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator” mode as the Phase Two.
