cBridge 2.0: A Universal Cross-Chain Platform Based on the Celer State Guardian Network
TechFlow Selected TechFlow Selected
cBridge 2.0: A Universal Cross-Chain Platform Based on the Celer State Guardian Network
Afterwards, we will enter the second phase: "SGN as a cBridge node gateway and service level agreement (SLA) arbiter."
Navigating Web3 tides with focused insights
Since the launch of cBridge 1.0, our total cross-chain transaction volume has been doubling weekly. In its first month, we processed only $10M in cross-chain transfers; in the following month, that figure surged to $170M, with daily volumes consistently exceeding $10M. Liquidity providers (LPs) operating cBridge nodes have earned an annualized return of 45% purely from transaction fees—no additional incentives required. This is exciting—but it’s just the beginning.
Today, we are excited to announce the upgrade plan for cBridge 2.0 and provide a brief overview of this innovative evolution.
The technical architecture of cBridge 2.0 will deliver the best-in-class cross-chain experience available today. It enables deeper liquidity, provides the most efficient and user-friendly liquidity management for both cBridge node operators and non-node liquidity providers (LPs), and offers generalized cross-chain messaging capabilities to support advanced applications such as cross-chain NFTs and cross-chain DEXs. All features of cBridge 2.0 are built upon an upgraded CELR-staking-powered State Guardian Network (SGN), further enhancing the SGN’s value capture.
Summary: What improvements does cBridge 2.0 bring?
For readers less interested in technical details, here is a concise summary of cBridge 2.0’s upgrades and advantages.
For users:
- Deeper liquidity: Supports larger single cross-chain transactions.
- Simpler user experience: Introduces one-click transfers.
- Support for native gas token transfers: For example, WETH on BSC can be directly bridged to native ETH on Arbitrum to pay gas fees there.
- Expanded chain and token support.
- Service-level assurance for bridge nodes: A new service quality insurance mechanism penalizes offline nodes and compensates affected users.
For liquidity providers (LPs) and cBridge nodes:
- Provide liquidity without running a node: In cBridge 1.0, providing liquidity required running a cBridge node. In 2.0, SGN itself acts as a shared cBridge node. LPs can delegate liquidity to this co-managed node operated by SGN, earning fees without running their own infrastructure.
- Optimal liquidity management: Unlike other solutions, cBridge 2.0 LPs don’t need to mint synthetic tokens, join volatile AMMs, or suffer high impermanent loss. Simply provide single-sided liquidity and freely manage distribution for arbitrage opportunities.
- High liquidity efficiency: Eliminates the need for double liquidity locking, maximizing capital efficiency and LP returns.
- Intelligent liquidity rebalancing: SGN centrally manages liquidity, generating optimal asymmetric AMM curves based on supply and demand to incentivize arbitrageurs and LPs to maintain balanced network liquidity.
- Optimized self-hosted node scheduling: For LPs who choose to run their own nodes, SGN ensures optimal user experience through unified scheduling.
For CELR stakers and validators in SGN:
- Value capture: As SGN stakers and validators provide essential services for cBridge 2.0, they directly earn value via cross-chain transaction fees and liquidity mining rewards.
- Protocol governance: System parameters like pricing curves and fee ratios are governed via a decentralized, CELR-staking-based protocol.
For developers:
- White-label frontend SDK: Enables multi-chain dApps to embed cBridge functionality natively, allowing users to bridge directly within their app.
- Generalized cross-chain message passing: Empowers developers to build complex applications beyond simple asset transfers, such as cross-chain NFTs and DEXs.
So, how do we achieve all these new capabilities in cBridge 2.0?
Answer: Celer’s State Guardian Network – SGN.
In cBridge 2.0, we expand SGN’s functionality to support two distinct bridging models, catering to diverse user and LP preferences. Below, we introduce the overall system architecture.
State Guardian Network Overview
The State Guardian Network (SGN) is the core component of Celer’s overall architecture. Within Celer’s system design, SGN is a specialized PoS chain that monitors L1 events related to Layer 2 states and faithfully relays Layer 2 information back to Layer 1 when needed.
In Celer state channels, SGN helps store channel states and responds to malicious settlements on L1. In Celer’s layer2.finance rollup, SGN scales into a decentralized block proposer network, relaying call data and state roots back to L1. Even if PoS consensus fails, any SGN node can submit fraud proofs to ensure security.
CELR holders can stake CELR in SGN either as validators or delegators, actively providing these critical services. In return, stakers earn staking rewards and service fees.
SGN as cBridge Node Gateway and Service-Level Agreement (SLA) Arbiter
Design Choices and Limitations of cBridge 1.0 Nodes
In cBridge 1.0, when a cBridge node joins the network, it registers various information—such as fee schedules and liquidity status—with a gateway service. The gateway continuously monitors the node’s status and performance. When a user request is made, it is routed to the gateway, which evaluates registered nodes based on liquidity availability, historical success rate, fees, etc., then recommends the most suitable bridge node. In 1.0, we adopted a centralized gateway to quickly gain operational insights into scheduling strategies.
However, the 1.0 gateway only provides users with “for reference” suggestions on which cBridge nodes to use.
Although cBridge 1.0 uses a non-custodial architecture—users never need to trust nodes with their funds—there remain usability issues related to “node availability.” For example, if a user sends the first half of a conditional transfer (HTLC), but the node goes offline before completing the second step, the user must wait for the HTLC to time out. The offline node faces no penalty, and the user receives no compensation for the delay.
We address both limitations in 2.0 using SGN.
Decentralized and Efficient cBridge Node Scheduling via SGN
In 2.0, we migrate all centralized gateway logic to the decentralized SGN as a distributed service. Instead of registering with a centralized gateway, cBridge nodes now register with SGN, declaring their fee preferences, liquidity availability, etc.
When a user makes a request, the system operates as follows:
- User queries SGN for estimated fees and liquidity availability.
- If acceptable, user initiates the first half of an HTLC transfer, specifying maximum fee tolerance.
- SGN monitors and receives the transaction, assigning one or more registered cBridge nodes based on scheduling rules. This assignment is recorded on the SGN chain and marked in the user’s HTLC.
- Assigned node accepts and completes the second half of the HTLC.
- SGN continues monitoring until completion, then clears the transaction state from the chain.
This enables scalable growth of cBridge nodes with fair, unbiased selection. But benefits go beyond scalability.
Bridge Node SLA Bond and Slashing Mechanism
Unlike the 1.0 gateway, SGN as the scheduling layer actively monitors the entire cross-chain transaction lifecycle. As a decentralized PoS chain, SGN can now enforce binding commitments—not just offer advisory suggestions—and penalize nodes that fail to fulfill assigned tasks.
When a cBridge node registers with SGN, it may deposit an “SLA bond”—a valuable token stack—tied to specific service-level promises (e.g., uptime, fee levels, liquidity reserves) into a pool contract. If SGN detects a violation—e.g., a node going offline mid-transfer—the bond can be slashed to compensate users for degraded experience and opportunity cost. (Note: user funds are never at risk; compensation covers only opportunity costs from frozen liquidity.)
During node selection, the size and availability of the SLA bond become key priority factors. Reliable nodes are incentivized to stake bonds to increase selection chances, while unreliable ones are pushed to the bottom or excluded entirely.
With SLA bonds backed by the decentralized “SGN gateway,” cBridge ensures high-quality service. This fosters a healthy, rapidly growing, decentralized network of node operators for LPs who prefer self-hosted liquidity.
Some may argue that because PoS consensus could fail, SLA bonds might be wrongfully slashed, making the model not fully “self-custodial.”
We emphasize that SLA bonds only require a small fraction of total liquidity to effectively ensure smooth UX and a self-healing ecosystem. This trade-off is well worth it. Most importantly, from the user’s perspective, the entire process remains fully non-custodial with zero fund risk.
Node Scheduling Rules
Scheduling rules are designed to optimize user experience. We developed an empirical “node quality score” combining multiple factors—SLA parameters (fees, response time) and historical performance (success rate, average latency). Nodes are prioritized based on this score during user requests. We aim to refine this formula over time via protocol governance and operational feedback.
Compared to Connext’s recently launched nxtp protocol—which shares a similar self-custody model—cBridge offers simpler user interaction, lower latency, reduced cost, no complex multi-node auctions, and guaranteed service levels to protect user interests.
SGN as Shared Liquidity Pool Manager
Provide Liquidity Without Running a cBridge Node
The above improvements primarily benefit self-hosted LPs who run their own nodes. However, we recognize many LPs and users want to provide liquidity without managing infrastructure, and are comfortable with the security level provided by SGN’s PoS consensus via CELR staking. Additionally, a shared liquidity pool model allows faster bootstrapping of network liquidity, accelerating better UX.
Therefore, in cBridge 2.0, we introduce a new mode: SGN collectively manages shared liquidity pool contracts across multiple chains. This treats the distributed PoS chain (SGN) and its managed liquidity pools as a single “node,” giving LPs the option to easily delegate liquidity to SGN, earn cross-chain fees, and avoid running any nodes.
What security guarantees does this model offer?
PoS-Level Security and Decentralized Governance
In this cBridge 2.0 model, shared liquidity pool contracts are managed via SGN’s PoS consensus. Moving funds requires a CELR-stake-weighted multisignature. The pool is only at risk if over ⅔ of the total stake collude maliciously. Importantly, as cBridge transaction volume and total value secured grow, the cost and difficulty of such attacks naturally increase. This fundamentally differs from TSS-based multisig solutions, where security doesn’t scale with network value since no token staking is involved.
SGN’s validator governance is open and decentralized: new validators can be elected and join the set through staking-based governance, without special coordination.
Simple LP Experience and High Liquidity Efficiency
How do LPs manage liquidity under this model? Existing solutions like Hop Protocol and Thorchain require LPs to deposit token liquidity alongside a protocol-controlled settlement token into on-chain AMM pools. These models have drawbacks:
- Thorchain forces LPs to use highly volatile RUNE as a settlement token, leading to significant impermanent loss.
- Even when minting synthetic tokens from native assets, LPs face complex operational overhead when adding, removing, or rebalancing liquidity across chains.
- Hop Protocol requires “bonders” to front liquidity, resulting in low efficiency—each transfer locks twice the necessary liquidity.
cBridge 2.0 solves the “liquidity attribution problem” with a novel design, delivering simplicity and high efficiency. To understand our system, first consider what “liquidity attribution” means. In any multi-chain bridge, when a user sends funds from source to target chain, LPs (or pooled liquidity) pay out on the target chain while receiving funds on the source chain. Suppose an LP provides liquidity on chain A. When a user sends funds from chain B to A, the LP’s liquidity is effectively “reallocated”: their balance decreases on A and increases on B. The liquidity attribution problem asks: “How does the system track each LP’s liquidity across chains?” and “How can liquidity be efficiently managed to maximize fee yield?”
AMM-based solutions implicitly track LP liquidity by allocating settlement and native tokens within pools. Bridge structures (e.g., TSS validators or L2–L1 messaging protocols) only manage the minting/burning of settlement tokens. Users always pay AMM swap fees to convert settlement tokens to native tokens on the target chain—sometimes even on the source chain. When imbalances occur, arbitrageurs move liquidity from surplus to deficit chains. They’re incentivized to send funds from liquidity-scarce chains (S) to abundant ones (A) to rebalance.
Meanwhile, LPs have stronger incentives to rebalance—they avoid bridge fees when harvesting arbitrage profits. However, the rebalancing process is complex. For instance, to move liquidity from S to A, an LP must:
- Remove liquidity from S’s AMM pool.
- Transfer settlement tokens from S to A.
- Sell settlement tokens at a premium in A’s AMM pool for native tokens.
- Move native tokens back to S.
- Buy settlement tokens on S.
- Add liquidity back to S’s AMM pool.
These steps incur significant operational, transaction, and time costs.
In cBridge 2.0, we believe the bridge structure (SGN) can be highly optimized compared to on-chain smart contract operations, drastically reducing costs. Thus, each LP’s liquidity is explicitly tracked. Adding liquidity is simple: send native tokens in one transaction to the pool contract; SGN records each LP’s balance on-chain. Essentially, SGN maintains a (chain_id, LP_address, token_type, balance) table in its chain state.
When processing cross-chain requests, SGN uses the entire pool’s liquidity to calculate slippage and pricing (detailed next), then treats LPs as “virtual cBridge nodes,” routing transfers according to their liquidity distribution. Conceptually, for each transfer, each LP’s balance on the target chain proportionally decreases, while increasing on the source chain. In practice, we use random sampling and approximation algorithms to minimize state changes and costs while ensuring statistical fairness among LPs—details in our technical docs.
This architecture also supports arbitrage-driven rebalancing and gives LPs maximum flexibility. Each LP clearly sees their real-time liquidity distribution, enabling informed decisions when adding or withdrawing from any chain. This reduces rebalancing from 6 to 3 steps—with no AMM swap costs:
- LP removes native token liquidity directly on A. Due to system slippage, they immediately lock in arbitrage profit.
- LP moves native tokens from A to S.
- LP adds native tokens to the pool on S.
LPs can still withdraw all liquidity from a single or selected chains. In cBridge 2.0, this triggers an internal cross-chain transfer treating the LP as a user, moving liquidity to the desired chain before withdrawal. Note: the LP bears system slippage during this transfer, but this cost is lower than swapping settlement tokens in AMM-based solutions.
More importantly, cBridge 2.0 uses native token liquidity directly, eliminating high impermanent loss. Compared to Hop Protocol, cBridge requires no extra bonder liquidity lockups, achieving maximum liquidity efficiency and optimal fee returns.
Cross-Chain Bridging Pricing to Incentivize Balanced Liquidity
In cross-chain systems, native token liquidity exists across multiple chains. As demand shifts, intrinsic pricing between the same token on different chains dynamically changes—based on transfer costs via native bridges and local supply-demand imbalances.
Any bridge solution must capture these price dynamics through well-designed bonding curves. This creates strong incentives for LPs to rebalance liquidity across chains, maintaining a well-provisioned, balanced network for all user requests.
Staying true to our “smart architecture” principle, we implement a Curve-inspired bonding curve pricing mechanism within SGN. When a user transfers tokens between chains, SGN calculates output based on available liquidity on source and target chains. Beyond pricing, a fixed fee is deducted per transaction and paid to LPs.
Specifically, for any chain pair i and j, let xi and Xj denote balances of a given token on chain i and j. When computing slippage for token transfers between i and j, the following invariant must always hold:
- A is a constant per chain pair. For a given pair, A is identical for all tokens.
- D is variable. Initial D can be solved via cubic equation given initial liquidity on both chains, then iteratively updated as liquidity changes.
- Wi and Wj are relative weights controlling asymmetry in transfer slippage. Weight configuration is per chain pair and satisfies Wi + Wj = 2.
We use these weight parameters to reflect inherent chain asymmetries. For example, depositing into rollups like Arbitrum and Optimism is much cheaper and faster than withdrawing (which takes up to 7 days). We adjust weights in the bonding curve to capture such differences.
In the red asymmetric curve (vs. blue symmetric reference), greater slippage is created when transferring from chain i to j during imbalance. If Wi = 1 and Wj = 1, it simplifies to Curve Finance’s original curve.
Generalized Cross-Chain Message Passing
cBridge 2.0 builds a smart cross-chain framework on SGN. Beyond asset transfers, it enables a generalized cross-chain message passing system: SGN monitors events on source chains and posts consensus-verified attestations on target chains, completing the cross-chain information flow.
We will gradually open this underlying capability to developers as an SDK for building use cases—not just bridges, but also cross-chain NFTs, DeFi aggregators, and more.
Network Value Capture
Unlike many governance tokens where holders don’t perform essential protocol functions, CELR holders and the State Guardian Network are clearly indispensable to cBridge’s operation.
Thus, users and LPs in cBridge 2.0 pay fees to SGN for its services. These fees are proportionally distributed to CELR stakers in SGN. Specifically:
- In the SGN-as-gateway-and-SLA-arbiter model, a portion of cross-chain fees and slashed bonds goes to SGN for node scheduling and SLA enforcement.
- In the SGN-as-shared-liquidity-manager model, part of cross-chain fees pays SGN for handling all cross-chain liquidity movements.
Additionally, various system parameters require governance-based updates to ensure stability. CELR serves as the governance token for this new component of the Celer ecosystem.
Closing Thoughts on Design Trade-offs in cBridge’s Multi-Chain Bridge Architecture
Finally, our view on key trade-offs in cross-chain bridge design. We believe the biggest trade-off centers on control over system liquidity.
Some argue self-custodial bridge solutions are the “purest” and “safest.” While we respect this principle, we emphasize not everyone can run a full cBridge node. That said, we are confident in this model’s potential—which is why we designed the “SGN as cBridge node gateway and SLA arbiter” self-hosted approach.
At the same time, we believe our design accommodates diverse user and LP preferences, presenting all options fairly so users and LPs can choose based on their own risk-return profiles. That’s why cBridge 2.0 also includes the “SGN as shared liquidity pool manager” model—to accelerate liquidity bootstrapping and broader adoption.
After all, whether black or white, as long as it catches mice, it’s a good cat.
Launch Plan
Blockchain interoperability is uncharted territory—recent hacks underscore this. We uphold the highest security standards and are committed to preserving our clean security record.
Therefore, cBridge 2.0 will launch in phases.
We plan to launch the “SGN as shared liquidity pool manager” model as the first phase testnet in October, undergoing at least two comprehensive smart contract audits.
Following testnet and audit results, we will initiate a $1 million bug bounty program and gradually roll out the cBridge 2.0 mainnet.
Subsequently, we will enter the second phase: “SGN as cBridge node gateway and SLA arbiter” mode.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
