Protocol overview

Celer Bridge, cBridge, is a multi-chain interoperability system that provides cross-chain token bridging with deep liquidity for users between all chains. It's basically a system that lets you move tokens between different blockchains, like a bridge connecting them.

And here's the juicy part: right now, they've got a whopping $2 million up for grabs as a bug bounty on Immunefi. Can you imagine finding a crit and reporting it? Easy money, right? ;)

The following article is a cheat sheet for whitehats/devs or even experienced users who want to understand how cBridge works, user flows, and some scenarios. Plus, a short compilation of questions formulated from the point of view of whitehat (me)

“This article does not promote any malicious activities, including hacking or exploiting vulnerabilities in the cBridge system.”

Basics

• Decentralized and non-custodial asset bridge.

• Deep liquidity: supports large transfer sizes.

• Single-click operations.

• Makes use of Celer State Guardian Network (SGN) services and functionality.

• Message bridging (NOT IN SCOPE).

• Supports two fungible token bridging models:

  • Canonical mapping bridge for tokens that only have been deployed to one chain. (NOT IN SCOPE)

  • Pool-based bridge for tokens that have been deployed on different chains.

• Supports 150+ tokens across 40+ blockchains and layer-2 rollups.

• Supports node slashing

10_000ft view

• CELR holders can stake (CELR stakers) their tokens into the SGN by becoming a validator and providing services for Celer Products or through delegation.

• Users and LPs of the Bridge pay fees to the SGN in exchange for its services, like on every PoS blockchain.

• CELR stakers receive staking and fee rewards from cBridge and other Celer products.

• LPs can add liquidity to the cBridge liquidity pool on any chain.

• Bridge Users send tokens to a destination chain, using cBridge nodes’ liquidity and pooled LPs liquidity; this costs a fee (cBridge fee).

• Bonded Validators validate and sign the cross-chain transaction.

• Malicious or faulty validators can be slashed out of their staking token.

• 50% of the fees from cross-chain transfers are forwarded to cBridge LPs whose liquidity is used in the transfers, and the other 50% goes to SGN stakers (CELR stakers).

In a nutshell, cBridge enables users to transfer tokens between supported chains in a decentralized and trustless manner, leveraging the liquidity provided by LPs on each chain. Transactions with the bridge contract typically require signatures from a threshold of validators, known as weighted signatures.

Deep dive

Scope of the bounty

At the time of writing this article, the bug bounty set on Immunefi for cBridge has the following contracts in scope, as well as all the inherited ones:

• Staking.sol

• SGN.sol

• StakingReward

• FarmingRewards

• Govern.sol

• Viewer.sol

• Bridge.sol

• Pool.sol

Architecture & diagrams

Terminology

SGN → The Celer State Guardian Network, a specialized PoS chain providing services for Celer Products. In this case, for the Bridge.

Delegator → A CELR token holder that delegates its holdings to an SGN validator.

Validator → A CELR token holder that must run a full SGN node in charge of validating and signing cross-chain transactions.

Staker → A delegator or a validator staking CELR on Staking.sol in exchange for network + staking rewards.

LPs → Users that provide liquidity to the pool-based bridge on a specific chain (Ethereum, polygon, bsc, etc.).

nativeLiquidity → The chain native token provided to the bridge pool by an LP, e.g., ETH on Ethereum.

relay → The function of the bridge that initiates the second half of a cross-chain transaction in the destination chain.

bond → Bunch of tokens with value (user-delegated + validator owned) that the validator locks in Staking.sol to be part of the network and be able to perform diverse tasks.

bondedTokens → Total amount of tokens of bonded validators.

signer→ Actor that signs valid cross-chain transactions and other protocol interactions. It can be either a validator or an address previously registered as a signer by that validator.

MinRequiredTokens → Minimum amount of tokens needed for a validator to be bounded.

selfDelegation → Amount of tokens that a validator delegates to himself.

xLiquidity tokens → Tokens that have been deployed on different chains used in the Pool-based bridge.

Weighted multi-signatures → This means that each signer has a different amount of power; this power is accounted by the amount of tokens the signer’s validator has bonded.

Key points and focus areas for whitehats

Imo, there are two areas to focus on:

• The multi-sig verification in the cBridge system plays a critical role in guarding important functions of the protocol. If there were to be a bug or vulnerability in this part of the code, the impact could be catastrophic.

• Staking.sol Covers most of the validator functionality; this makes it quite a complex state machine; validators can be delegated, self-delegated, bonded, unbonding, etc.

Questions

Bridge:

• Is the interaction with arbitrary weird ERC20 tokens considered? → NOT SUPPORTED

• Is there a token whitelist for xLiquidity tokens? → There is an amount cap for each epoch and token, only for some tokens.

• Are transactions replayable? → Each transaction has a unique id that gets whitelisted after it succeeds

Staking:

• How do CELR holders delegate? → Holders can delegate to a validator in Staking.sol.

• Is it possible to de-register a node while a transaction is happening?→ nodes can only be unbonded if they have been slashed or have less than minimum tokens.

• How do un-delegations work, and why are they only taken into account when a validator is bonded → each user can un-delegate if the resulting tokens of a validator go below the threshold and the validator is unbonded

SGN:

• Can a user slash a node’s bond without reason? → NO, validators on the SGN network have to sign the transaction.

• Can cross-chain messaging trick msg.sender → OUTSIDE SCOPE, SGN tedermint network (the CELER Network) is not in the bug bounty scope.

• How does cross-chain msg.sender work? Is there any aliasing done to the addresses? → Cross-chain transactions are signed by multiple validators, multi sigs

• What does HTLC mean? → time-locked hashed txs, every cross-chain tx has a deadline.

• How is the priority SLA queue implemented? Can a less reliable node be the first option? → Node selection rule, governance can change it → not in scope

• What is protobuffer → MESSAGE PASSING ENCODING PROTOCOL

• How much is the SLA bond amount compared to liquidity? → They don’t take it into account

• Is the relayer centralized? → OUT OF SCOPE

• Devs assume that the security model is the most secure, is this true? → Decentralized multi-sig validators.

• How does the optimistic rollup work? → who can veto a tx? → SGN chain

Rewards:

• Difference between StakingRewards and FarmingRewards → StakingRewards paid in CELR from Staking or validating, FarmingRewards extra CELR when providing liquidity to some pools with incentives.

• How are StakingRewards paid? → in CELR, when a staker/validator calls claimReward in StakingRewards.sol

• How much are bridging fees paid to validators? 50% of bridge fees

• How are liquidity fees paid to bridge LPs? Withdraw from Pool.sol

• Does a validator earn more than a delegator? → yes, validators take a cut of the delegators’ fees that have delegated to them

More questions:

• What kind of proxy is used?

• Can the signature validity checks be tricked on the destination chain?

Cross-chain environment

Other bridging & messaging protocols

Disclaimer: It's important to note that the purpose of this cheat sheet is not to spread or promote any malicious activities, including hacking or exploiting vulnerabilities in the cBridge system. The information provided is intended solely for educational and informational purposes to help whitehats, devs, and experienced users better understand how cBridge works, user flows, terminology, and scenarios. Engaging in any unauthorized activities, such as attempting to hack or exploit the cBridge system or any other blockchain projects, is illegal and unethical. Any such activities are strongly discouraged and can have legal consequences. Users should always comply with applicable laws and regulations, and report any identified vulnerabilities or security concerns to the cBridge team through appropriate channels such as Immunefi. The cBridge team and platform are committed to maintaining the security and integrity of the system, and users are encouraged to use their knowledge and skills responsibly and ethically.

Good luck and happy hacking, whitehat ;)