cBridge delivers either existing destination tokens from liquidity pools or mapped tokens backed by originals locked in a vault; the route’s token contracts and configuration decide which model applies. For a cBridge route, that distinction tells you whether delivery depends on pool liquidity or on a representation you can redeem.
cBridge Routes Follow Token Contracts
The source and destination token contracts determine which bridging model a route uses. In Celer’s terminology, xLiquidity joins supported deployments of a token through pools on participating chains; xAsset maps an original token to a pegged representation on another chain. The fungible token model documentation describes the contract flows behind both. A token ticker alone cannot distinguish them, because two contracts can display the same symbol while having different issuers, redemption paths, or uses.
The model is configured for the supported route. You generally choose a source chain, destination chain, and token, rather than switching that route between pool delivery and minting at will. If two routes promise the same asset name, compare the destination contract addresses before treating their outputs as interchangeable.
Pool Routes Draw From Destination Liquidity
A pool route sends tokens already held in the destination pool to the recipient. Your deposit increases the source-side pool balance; authorized cross-chain coordination then releases tokens from the destination-side pool. No destination token is minted for that transfer. Liquidity providers and previous transfers supply the inventory, so the pool balances on both chains change as transfers move in either direction.
For cBridge liquidity pools, the available destination balance matters as much as whether the token is listed. A large transfer may exceed what the destination pool can release. The amount received also reflects the quoted bridge rate and fees: some pairs use a StableSwap-based rate that responds to pool imbalance, while others use a fixed 1:1 rate before fees. Compare the live quote with your intended amount; a route can remain available while its delivery amount changes.
Mapped Routes Draw on Locked Backing
A mapped route mints a pegged token after the original token enters a vault on its source chain. The vault holds the originals, cross-chain authorization confirms the deposit, and the destination token contract mints the corresponding representation. On the return trip, that contract burns the representation and the vault releases the originals. The mapped token therefore has a redemption path through the bridge’s vault rather than a destination pool that must hold enough tokens for every incoming transfer.
Supported mapped-chain transfers can burn the representation on one mapped chain and mint it on another without sending the original token back through its source chain. A cBridge mapped token still depends on valid vault backing, authorized minting and burning, and the bridge’s redemption process. The 1:1 minting rule describes units created against locked units; it does not by itself establish market price or issuer recognition.
Which Destination Token Fits Your Use?
The right route is the one whose actual destination contract satisfies your intended use. Before confirming, compare these four things:
- Token identity: Match the destination contract address to the asset you expect, not just its ticker or logo.
- Pool capacity: On xLiquidity, compare the amount you will receive with available liquidity and the current bridge rate.
- Backing and exit: On xAsset, identify the original token, the vault that holds it, and how you would redeem from the destination chain.
- Application acceptance: Confirm that the wallet, exchange, or protocol where you plan to use the token accepts that exact destination contract.
Neither model automatically makes its output issuer-native or removes bridge risk. Existing pooled tokens may still be bridge-issued deployments, and a mapped token’s peg relies on the vault and cross-chain authorization. A route’s contract configuration decides what arrives; liquidity, backing, and application support decide whether that arrival meets your purpose.
Common Transfer Questions
How do I bridge the token?
Select the source chain, destination chain, and token; inspect the destination contract, amount received, fees, and any slippage setting. Approve the source token if required, then submit the transfer in your wallet and follow its status in transfer history.
How long does it take?
Most transfers take roughly 5–20 minutes according to Celer’s transfer FAQ. Source-chain confirmation, cross-chain authorization, destination execution, and rate limits can extend that time, especially for larger transfers.
Why is the transfer pending?
First identify the pending stage. “Submitting” may mean the source transaction has not confirmed; “Waiting for SGN confirmation” or “Waiting for fund release” means it has progressed further. If the route fails for insufficient destination liquidity or slippage, the transfer history should show the available refund path.
Top comments (0)