Fungible Token Bridging

Fungible Token Bridging Overview

When the intention is for a token to be bridged to a destination chain where the token has not yet been deployed — The architecture is as follows:

  • Two contracts are deployed (by the Celer team) on both the source chain and the destination chain: TokenVault and PeggedToken;

  • TokenVault: to deposit or withdraw the original tokens

  • PeggedToken: to mint or burn the pegged tokens

  • Relayers will be deployed on both the source and destination chains to fetch the SGN’s multisig attestations and call the TokenVault and PeggedToken contracts.

  • Celer’s State Guardian Network (SGN) serves as a message router for cross-chain transfers. It is a Proof-of-Stake (PoS) blockchain built on Tendermint. Validator nodes must stake $CELR to join the consensus process of the SGN

Scenario 1: A Rollup ERC20 Token Transfers From the rollup to the primary chain or Any Other Target Chain (ERC20 on Rollup -> ERC20 on primary/target chain)

When a user transfers the Rollup ERC20 Token from the rollup to the primary chain or other target chain, the token bridging will be supported by a Lock-and-Mint model so the asset flow will be:

  1. The user’s original tokens will be locked in the TokenVault contract on the rollup.

  2. After receiving the deposit event, the SGN will generate a multisig attestation to mint a matching number of pegged tokens on the primary or target chain.

  3. The relayer fetches the SGN’s multisig.

  4. The relayer calls the PeggedToken contract with the multisig.

  5. A matching number of tokens will be minted in a 1:1 pegged ratio by the PeggedToken contract and sent to the user’s account on the primary or target chain.

When a user transfers a Rollup ERC20 Token back to the Rollup, the token bridging will be supported in a Burn-and-Release model so the asset flow will be:

  1. The user calls PeggedToken to burn the pegged tokens on the primary chain or target chain.

  2. After receiving the burn event, SGN will generate a multisig attestation that grants the withdrawal of a matching number of original tokens from the TokenVault contract on the rollup.

  3. The relayer fetches the SGN’s multisig.

  4. The relayer calls the TokenVault contract with the multisig.

  5. A matching number of original tokens will be released in a 1:1 pegged ratio by the TokenVault contract and sent back to the user on the Rollup.

An example of such a case would be bridging the Rollup ERC20 token from the Rollup to Ethereum.

Scenario 2: primary chain native token transfers to the rollup as ERC20 (Native token on primary chain -> ERC20 on rollup)

Like Scenario 1, when the primary chain native token has not yet been deployed on the Rollup and a user transfers tokens from the primary chain to the Rollup, a Lock-and-Mint model will support the token bridging. When the user transfers tokens back from the Rollup to the primary chain, a Burn-and-Release model will support the token bridging.

An example of such a case would be bridging the ETH native token from Ethereum to the Rollup.

Scenario 3: primary chain ERC20 token transfer to the rollup as native token (ERC20 on primary chain -> Native on rollup)

For rollup that leverages the primary chain ERC20 token as a native token (gas) on rollup, NativeTokenWrapper contract should additionally be deployed on the rollup. The architecture is:

  • Two contracts are deployed on the rollup: NativeTokenWrapper (deployed by partner) and PeggedToken (deployed by the Celer team)

    • NativeTokenWrapper: to mint or burn the rollup-native gas token

    • PeggedToken: to call the NativeTokenWrapper contract for a mint or burn event

  • The TokenVault contract is deployed (by Celer) on the primary chain:

    • TokenVault: to deposit or withdraw the original ERC20 token

  • Celer’s State Guardian Network (SGN) is a message router for cross-chain transfers. It is a Proof-of-Stake (PoS) blockchain built on Tendermint. Validator nodes must stake $CELR to join the consensus process of the SGN.

  • Relayers will be deployed on both the source and destination chains to fetch the SGN’s multisig attestations and call the TokenVault and PeggedToken contracts.

When an ERC20 token on the primary chain is transferred to the rollup (to be used as a native gas token), the token bridging is supported by a Lock-and-Mint model and the asset flow is as follows:

  1. The original ERC20 token is locked in the TokenVault contract on the primary chain.

  2. After receiving the deposit event, the SGN will generate a multisig attestation that grants a mint event on the rollup.

  3. The relayer fetches the SGN’s multisig.

  4. The relayer calls the PeggedToken contract on the rollup for a mint event, the PeggedToken contract calls the mint function of the NativeTokenWrapper contract to mint a matching number of native gas tokens in a 1:1 ratio.

  5. The native gas tokens are sent to the user’s account on the rollup.

When a user transfers the gas token from the rollup back to the primary chain as ERC20, the token bridging is supported by a Burn-and-Release model, and the asset flow will be:

  1. The user calls the PeggedToken contract for a burn event on the rollup, the PeggedToken contract calls the burn function (payable) of the NativeTokenWrapper contract to burn the native gas tokens on the rollup.

  2. After receiving the burn event, the SGN will generate a multisig attestation that grants the withdrawal of a matching number of original ERC20 tokens from the TokenVault contract on the primary chain.

  3. The relayer fetches the SGN’s multisig.

  4. The relayer calls the TokenVault contract with the multisig.

  5. A matching number of original ERC20 tokens will be released in a 1:1 pegged ratio by the TokenVault contract and sent back to the user on the primary chain.

An example of such a case is if the rollup native gas token is originally an ERC20 token on the primary chain and wishes to be transferred to the rollup as the gas token. In most cases, the NativeTokenWrapper the partner deploys contract and a minter role is granted to cBridge.

Bridging Fee Structure

Bridge Fee = Base Fee + Protocol Fee, where the Protocol Fee ranges from 0.1% to 0.5% of the transaction amount and is negotiable on a case-by-case basis.

The Base Fee is paid in the form of the token being transferred and covers the destination chain gas cost for sending the token to the user. The Protocol Fee is paid to State Guardian Network (SGN) validators and stakers in return for their services.

PreviousCross-chain Interoperability using CelerNextNon-fungible Token Bridging

Last updated