VNMRTZWhen bug-fixes go wrong: RAI debt auctions bug
“The way to be safe is never to be secure.” -Benjamin Franklin Its common to see projects hacked after an audit. After all, a security review doesn't guarantee a project is entirely free of bugs; it's more about enhancing security standards and uncovering as many potential issues as possible within a limited timeframe. But, things turn around when in the process of addressing a seemingly low-severity bug (some might even call it informational), the proposed bug-fixes introduce a hig...
VNMRTZEVM: Degen Bit Masking
'If you wish to make an apple pie from scratch, you must first invent the universe'. -Carl Sagan Note: This article dives directly into assembly code and explores advanced bit operations. If you're an experienced developer or researcher, you're in the right place. However, if you're not familiar with these topics, I recommend reading the article “Solidity and EVM: Bit Shifting and Masking in Assembly(YUL)“ by 0xweiss first before continuing with this one. This backgro...
EVM Researcher | Smart Contract Auditor & Software Engineer
VNMRTZWhen bug-fixes go wrong: RAI debt auctions bug
“The way to be safe is never to be secure.” -Benjamin Franklin Its common to see projects hacked after an audit. After all, a security review doesn't guarantee a project is entirely free of bugs; it's more about enhancing security standards and uncovering as many potential issues as possible within a limited timeframe. But, things turn around when in the process of addressing a seemingly low-severity bug (some might even call it informational), the proposed bug-fixes introduce a hig...
VNMRTZEVM: Degen Bit Masking
'If you wish to make an apple pie from scratch, you must first invent the universe'. -Carl Sagan Note: This article dives directly into assembly code and explores advanced bit operations. If you're an experienced developer or researcher, you're in the right place. However, if you're not familiar with these topics, I recommend reading the article “Solidity and EVM: Bit Shifting and Masking in Assembly(YUL)“ by 0xweiss first before continuing with this one. This backgro...
EVM Researcher | Smart Contract Auditor & Software Engineer
Subscribe to VNMRTZ
Subscribe to VNMRTZ
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
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? ;)
Find bugs and vulnerabilities on Celer and get paid up to $2,000,000.
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.”
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
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.
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
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.
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.
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
What kind of proxy is used?
Can the signature validity checks be tricked on the destination chain?
Swap any tokens instantly cross-chain with deepest liquidity, low fees, and guaranteed rates.
https://immunefi.com/bounty/axelarnetwork/
Find bugs and vulnerabilities on Wormhole and get paid up to $5,000,000.
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 ;)
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? ;)
Find bugs and vulnerabilities on Celer and get paid up to $2,000,000.
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.”
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
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.
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
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.
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.
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
What kind of proxy is used?
Can the signature validity checks be tricked on the destination chain?
Swap any tokens instantly cross-chain with deepest liquidity, low fees, and guaranteed rates.
https://immunefi.com/bounty/axelarnetwork/
Find bugs and vulnerabilities on Wormhole and get paid up to $5,000,000.
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 ;)
No activity yet