Canonical Token Bridge

Search…
cBridge 2.0 supports two token bridging models: 
Pool-based bridge model for canonical tokens. This model is intended for canonical tokens that have already been generated on different chains (e.g., USDT, USDC, ETH). When a canonical token needs to be transferred between chain A and chain B, two liquidity pools need to be first created on chain A and chain B, respectively. The bridge rate is dynamically adjusted according to the balances of the two liquidity pools, using the StableSwap pricing curve. 
Canonical token bridge model (mint & burn). This model is intended for the use case where a token has already been generated on chain A (e.g., Ethereum) but not yet on chain B (e.g., BSC) and bridging is needed between chain A and chain B as business grows (e.g., the dApp is launched on chain B). When a user transfers from chain A to chain B, the original token will be locked on chain A and an equal amount of pegged token will be minted and sent to the user on chain B. Reversely, when a user transfers from chain B to chain A, the pegged token will be burned on chain B and an equal amount of token will be sent back to the user on chain A.
In the below sections, we describe the detailed flow and architecture for the canonical token bridge model.
Canonical Token Bridge Architecture
Suppose token T has been generated on chain A but not yet on chain B. If bridging is needed for token T between chain A and chain B, then two contracts need to be deployed: 
TokenVault contract. This contract is deployed on chain A. The user can deposit token T to this vault and receive pegged tokens on chain B, or withdraw token T from the vault if pegged tokens are burned on chain B.
PeggedToken contract which mints the pegged tokens to the user or burns the pegged tokens on chain B.
Transfer from chain A to chain B (Mint Flow)
The below figure illustrates the steps for bridging token T from chain A to chain B. 
1.User deposits X token T to the TokenVault contract on chain A. 
2.The Celer State Guardian Network (SGN) monitors the deposit event. Upon receiving the deposit event, the SGN generates a multisig that grants minting X pegged tokens on chain B. 
3.The relayer fetches the SGN’s multisig 
4.On chain B, the relayer calls the PeggedToken contract with the multisig. 
5.The PeggedToken contract mints X tokens to the user on chain B.
Transfer from chain B to chain A (Burn Flow)
The below figure illustrates the steps for the bridging the pegged tokens from chain B back to chain A.
1.User calls PeggedToken contract to burn X pegged tokens on chain B. 
2.The Celer SGN monitors the burn event. Upon receiving the burn event, the SGN generates a multisig that grants the withdrawal from the TokenVault contract on chain A. 
3.The relayer fetches the SGN’s multisig.
4.On chain A, the relayer calls the TokenVault contract with the multisig.
5.The TokenVault contract sends back X original tokens to the user.
FAQ
How is the fee determined under the mint & burn bridge model? 
Similar to the pool-based bridge model, the fee consists of two parts: the base fee and the percentage fee. The base fee is used to cover the relayer’s gas cost on destination chain. The percentage fee is proportional to the transfer amount and is paid to the Celer SGN stakers as economic incentives for guarding its security. The fee percentage is governed by the Celer SGN (usually, the fee percentage is 0%-0.04%).
The SGN as a Shared Liquidity Pool Manager
Next - Introduction
cBridge Security
Last modified 5mo ago
Copy link
Contents
Canonical Token Bridge Architecture
FAQ