Cbridge
Cbridge transfers tokens across chains through liquidity pools and mapped assets
Cbridge moves tokens between supported blockchains through liquidity pools, mapped-token contracts or Circle’s USDC burn-and-mint protocol. Its xLiquidity model pays out from destination liquidity, while xAsset connects original tokens with mapped versions. The selected token and destination determine the applicable mechanism, the asset received and the conditions that allow settlement.
Moving a balance, returning a mapped token and supplying bridge liquidity are different jobs. Each changes a different record: a wallet balance, a token’s circulating representation or a liquidity position.
Bottom line: A bridge transfer’s destination token and settlement mechanism determine its liquidity requirements, security dependencies and available recovery path.
Token availability determines the transfer model
The token’s deployment and configured bridge connection determine the available transfer model. A shared ticker alone doesn’t establish compatibility between assets on different chains.
Existing tokens and xLiquidity
xLiquidity connects supported token deployments through pools. A transfer adds tokens to the source pool and draws the destination payment from another pool. The recipient receives the destination pool’s asset, so its identity matters when another application will use the balance.
Mapped tokens and xAsset
xAsset supports a configured relationship between an original token and its mapped representation. Vault and token contracts handle the corresponding locking, minting, burning and release operations. This path relies on that mapping rather than a destination pool holding an existing token deployment.
The separate CCTP integration
Supported USDC transfers through CCTP V2 use Circle’s bridge contracts and attestation service. It burns native USDC on the source chain and mints native USDC on the destination, using Circle attestations rather than SGN attestations. Its availability depends on the supported network configuration; sharing the bridge interface doesn’t make every transfer use the same infrastructure.
Why can a supported transfer be unavailable?
A supported transfer can become unavailable because liquidity, pool caps, transfer limits or enabled directions prevent the requested amount from moving. Listing a token establishes compatibility, not capacity for every transfer.
Destination liquidity limits xLiquidity payouts. Separately, a source pool cap can prevent additional incoming tokens, even when the destination has funds. Transfer estimation can also reject a disabled token or direction. Increasing slippage tolerance doesn’t remove these restrictions.
Amount limits and security delays have their own configuration. Destination contracts can delay transfers whose amounts exceed a configured threshold. Volume caps can also restrict settlement within a defined period. These restrictions remain relevant even when their settings change; read the current volume caps, delay thresholds and durations from the destination contracts.
Mapped assets and their return path
xAsset’s backing relationship explains both the outward transfer and redemption. The mapped token represents locked assets, while the applicable contracts control changes to that representation.
Original tokens and backing
A vault holds original tokens while a destination contract issues their mapped counterparts. The mapping uses a 1:1 token ratio. That describes the backing relationship; bridge fees still affect the amount received. It doesn’t establish a market price or make the mapped token interchangeable with every similarly named asset.
Redemption and transfers between mapped chains
Returning through the configured redemption path burns mapped tokens and authorizes release of original tokens from the vault. xAsset v2 also supports transfers between supported mapped chains through burning and minting, without first returning to the original chain. That capability applies to configured mappings, not arbitrary token contracts.
What changes between a quote and settlement?
The bridge rate, fees and available liquidity can change after a quote, so an estimate describes the requested transfer under particular conditions. A fresh estimate reduces the gap between those conditions and submission.
Most xLiquidity pairs use a StableSwap pricing curve that responds to pool balance. Some pairs instead use a fixed 1:1 bridge rate. The bridge rate and fees are separate parts of the received amount; a fixed rate doesn’t imply a free transfer.
For xLiquidity and xAsset, the bridge fee includes a base component covering destination delivery costs and a protocol component. Source-chain transaction gas is another expense, including approval gas where approval is necessary. Slippage tolerance governs acceptable variation for pool transfers; it doesn’t promise execution when liquidity or another requirement fails.
Wallet authorization and the commitment boundary
Consider a supported xLiquidity transfer whose destination payment must remain above the sender’s acceptable minimum. Destination liquidity is a continuing requirement, while the quote reflects changing pool conditions. Before submitting the transfer, the sender can revise the amount or stop.
- Confirm that the configured destination token matches the intended receiving asset.
- Obtain a fresh estimate for the selected amount and direction.
- Keep source-chain gas available for any required approval and transfer transactions.
- Review the spending allowance separately from the transfer authorization.
- Submit the transfer only if the minimum receipt allowed after fees and slippage remains above your acceptable minimum.
When settlement succeeds, compare the destination payment with the completed transfer record and the amount sent, accounting for the bridge rate and fees. An approval alone doesn’t establish that outcome: it grants spending permission, and a separate transaction requests the transfer.
If liquidity or slippage prevents settlement after submission, the recorded failure may enter the refund path. Recovery then requires the bridge’s refund authorization and an on-chain refund transaction. A pending transfer doesn’t create a general cancellation right, and a completed destination payment cannot be undone through that failure-refund path.
What does the State Guardian Network verify?
The State Guardian Network verifies relevant source-chain events and produces validator attestations that authorize corresponding bridge operations. Its role connects activity on chains that don’t share a single transaction record.
The State Guardian Network generates stake-weighted multisignature attestations for cross-chain messages. Destination contracts check the required authorization before executing the associated operation. This introduces a validator and contract dependency alongside the security of the connected blockchains.
The security architecture also supports delayed execution, allowing guardian checks before eligible operations complete. Its application depends on the configured transfer conditions. A delay therefore needs interpretation alongside the transfer status; elapsed time alone doesn’t establish failure or refund eligibility.
Liquidity provision and application integration
Pool positions and withdrawals
Liquidity providers supply the assets that pool transfers draw upon and earn a share of the associated transaction fees. Their position differs from a wallet balance awaiting transfer: bridging activity can redistribute supplied liquidity across chains. Significant pool imbalance can also cause impermanent loss, meaning the position can underperform simply holding the supplied assets.
Removing liquidity requires authorization through the State Guardian Network followed by the applicable on-chain withdrawal. A removal request and a completed withdrawal are distinct states. The withdrawal record matters when reconciling the remaining position with returned tokens.
Bridging inside another application
Applications can integrate the bridge through its SDK and transfer interfaces. Integration still requires the correct token configuration, transfer mechanism and status handling. Pool transfers, canonical mappings and CCTP transfers have different contract paths; an application must preserve those distinctions even when it presents one transfer form.
Transfer records and the next destination
A source transaction confirms what happened on the starting chain. The bridge record separately identifies confirmation, destination release, completion or a refund-related state. Keeping the transfer identifier and transaction hashes makes those records easier to reconcile without confusing a submitted request with delivered funds.
Before using the received asset, confirm that its destination chain and token contract match the receiving application’s requirements. Bridge completion establishes delivery; acceptance by a lending market, exchange or other application is a separate compatibility question.
Common questions, answered
Must I hold CELR to make a token transfer?
An ordinary bridge transfer doesn’t require CELR solely because the State Guardian Network uses it for staking. The transfer requires the selected asset and the source chain’s gas token for applicable transactions. Bridge fees can be deducted in the transferred asset. CELR staking is a separate activity from sending tokens through the bridge.
Can Cbridge move tokens between addresses on the same chain?
The bridge’s cross-chain estimation flow requires different source and destination chains. A same-chain wallet payment uses that blockchain’s ordinary transfer mechanism. Selecting identical chains in a bridge request doesn’t turn it into a local transfer and can produce an error.
Why might a completed transfer not appear in my wallet’s token list?
A wallet’s displayed token list may not show the destination asset even when the transfer has completed. The relevant balance belongs to the receiving address on the destination chain. Compare the destination transaction and token contract with the wallet’s selected network and displayed asset before treating a missing token entry as a failed transfer.
Are farming rewards available in every liquidity pool?
Additional farming rewards depend on whether the pool has an active farming session. They are separate from the transaction fees associated with liquidity use. A pool’s earlier reward campaign doesn’t establish continuing availability, and a displayed reward rate shouldn’t be treated as a permanent property of supplying liquidity.
Does every failed transfer require a refund transaction?
A failed status doesn’t always require a refund transaction. The bridge distinguishes a failed transfer needing no refund from a transfer that must enter the refund flow. Refund preparation and refund confirmation are also separate states, so the recorded status determines whether an on-chain recovery action is available.