Chakra audit details

• Total Prize Pool: $60,000 in USDT
  • HM awards: $43,200 in USDT
  • QA awards: $1,800 in USDT
  • Judge awards: $4,500 in USDT
  • Validator awards: $2,500 USDT
  • Scout awards: $500 in USDT
  • Mitigation Review: 7,500 USDT (This will be a solo mitigation review)
• Read our guidelines for more details
• Starts August 29, 2024 20:00 UTC
• Ends September 12, 2024 20:00 UTC

Automated Findings / Publicly Known Issues

The 4naly3er report for solidity/handler can be found here.
The 4naly3er report for solidity/settlement can be found here.

Note for C4 wardens: Anything included in this Automated Findings / Publicly Known Issues section is considered a publicly known issue and is ineligible for awards.

It’s possible for Core Governance and the elections to schedule the same operation in timelocks, and therefore block each other.

Overview

Chakra Network is the first modular settlement layer designed to unlock Bitcoin's liquidity across diverse blockchain ecosystems.

Chakra offers a high-performance and parallelized modular settlement solution for efficient liquidity flow across Execution Layers and BTC Mainnet.

Chakra Network provides a shared settlement layer that enhances Bitcoin's integration into the broader blockchain landscape, enabling other execution layers such as L2's to focus on execution without the complexities of building settlement infrastructure.

This innovative approach unlocks interconnected liquidity and economic security, fostering a dynamic and vibrant ecosystem.

Execution layers benefit from Chakra's robust liquidity network effects, ensuring secure and scalable transaction processing.

Chakra Network empowers Bitcoin ecosystem participants to drive growth and innovation within a safe, scalable, and interoperable framework.

In addition, it enables DeFi projects to settle native BTC to target chains without friction, which extends the composability and utilities of their tokenized assets.

Links

• Previous audits: None
• Documentation: https://s3labs.notion.site/Contract-Design-Document-f4aa296f71fb40b1818c0890c40be55c?pvs=4
• Website: https://chakrachain.io/home
• X/Twitter: https://x.com/ChakraChain
• Discord: https://discord.gg/chakrachain

Scoping Q & A

General questions

ERC20 token behaviors in scope

External integrations (e.g., Uniswap) behavior in scope

EIP compliance checklist

N/A

Additional context

Main invariants

• In Settlement Handler Contract
  • Only the owner can add or remove handlers from the whitelist for a given chain.
  • The contract's mode (MintBurn, LockUnlock, LockMint, or BurnUnlock) is set during initialization and determines how tokens are handled during cross-chain transactions.
  • Cross-chain ERC20 settlements can only be initiated with a valid amount (greater than 0), a valid recipient address, a valid handler address, and a valid token address.
  • The nonce for each sender is incremented with each cross-chain transaction to ensure uniqueness of transaction IDs.
  • Cross-chain transaction IDs are uniquely generated based on the source and destination chain information, sender, handler addresses, and nonce.
  • Only the settlement contract can call the receive_cross_chain_msg and receive_cross_chain_callback functions.
  • The handler receiving a cross-chain message must be on the whitelist for the source chain.
  • The contract only accepts valid payload types (in this case, only ERC20 payloads).
  • The contract's behavior (minting, burning, locking, or unlocking tokens) is consistent with its initialized mode for both outgoing and incoming cross-chain transactions.
  • Cross-chain transaction statuses are properly tracked and updated (Pending, Settled, or Failed).
  • The contract ensures sufficient token balance before performing transfers, burns, or unlocks.
  • The contract uses safe transfer methods to move tokens, checking balances before transfers.
  • Only the specified token contract (set during initialization) can be used for transfers, mints, and burns within this handler.
  • The contract maintains a consistent state between locking/burning tokens on the source chain and minting/unlocking on the destination chain, depending on the settlement mode.
  • The contract uses a codec to consistently encode and decode ERC20 transfer payloads across chains.
• In Settlement Contract
  1. The contract can only be initialized once due to the use of the initializer modifier.
  2. Cross-chain transactions are uniquely identified by their txid, which is derived from a combination of chain names, addresses, and nonce.
  3. The nonce for each from_address is incremented for every new cross-chain message sent, ensuring uniqueness of transactions.
  4. Cross-chain messages can only be sent through the send_cross_chain_msg function, which creates a new entry in the create_cross_txs mapping.
  5. Received cross-chain messages are verified using signatures before being processed.
  6. A cross-chain message can only be received once. The status of a received transaction in receive_cross_txs must be CrossChainMsgStatus.Unknow before it can be processed.
  7. The status of a received cross-chain message can only transition from Unknow to either Success or Failed.
  8. Cross-chain callbacks can only be processed for transactions that have a Pending status in the create_cross_txs mapping.
  9. The status of a created cross-chain transaction can only transition from Pending to either the received status or Failed.
  10. Signature verification is required for both receiving cross-chain messages and cross-chain callbacks.
  11. Only valid settlement handlers can process received cross-chain messages and callbacks.
  12. The contract maintains separate mappings for created (create_cross_txs) and received (receive_cross_txs) cross-chain transactions.
  13. Events are emitted for all major cross-chain operations: message sending, message receiving, and callback processing.
  14. The contract relies on an external signature verifier (signature_verifier) for validating signatures.
  15. The contract inherits from BaseSettlement, implying it adheres to any invariants defined in that base contract.

Attack ideas (where to focus for bugs)

None

All trusted roles in the protocol

Describe any novel or unique curve logic or mathematical models implemented in the contracts

N/A

Running tests

This project uses starknet-foundry as the cairo development and testing framework.

The starknet-foundry version and scarb version used in this project are:

snforge 0.20.0
scarb 2.6.5
cairo: 2.6.4

To install them, use:

curl -L https://raw.githubusercontent.com/foundry-rs/starknet-foundry/master/scripts/install.sh | sh
snfoundryup -v 0.20.0
curl --proto '=https' --tlsv1.2 -sSf https://docs.swmansion.com/scarb/install.sh | sh -s -- -v 2.6.5

To clone the project and run tests, use:

git clone --recurse https://github.com/code-423n4/2024-08-chakra.git
cd 2024-08-chakra/solidity/handler
npm install
npx hardhat test
cd ../settlement
yarn
npx hardhat test
cd ../../cairo/handler
snforge test

Note: some tests will fail in solidity/settlement. They're irrelevant.

To run code coverage

npx hardhat coverage

Scope

See scope.txt

Files in scope

• Cairo:

• Solidity:

Everything else is out of scope.

Miscellaneous

Employees of Chakra and employees' family members are ineligible to participate in this audit.

Code4rena's rules cannot be overridden by the contents of this README. In case of doubt, please check with C4 staff.