Axelar Network audit details

• Total Prize Pool: $85,000 in USDC
  • HM awards: $71,500 in USDC
  • QA awards: $3,000 in USDC
  • Judge awards: $6,000 in USDC
  • Validator awards: $4,000 in USDC
  • Scout awards: $500 in USDC
• Join C4 Discord to register
• Submit findings using the C4 form
• Read our guidelines for more details
• Starts August 8, 2024 20:00 UTC
• Ends August 26, 2024 20:00 UTC

Automated Findings / Publicly Known Issues

The 4naly3er report 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.

• Please refer to previous audits, especially for AxelarAmplifierGateway, interchain-token-service, axelar-amplifier

Publicly Known Issues:

ITS hub balance tracking should be applied when minter isn't set (https://github.com/axelarnetwork/interchain-token-service/issues/270)

• ITS Hub balance tracking should only be applied when the minter isn't set in the deploy Interchain Token message type. If a minter is set, then the balance invariants can't be preserved since the minter address can mint on the remote chain. This is a fine trade off for custom tokens who want more control. The balance invariant is more so intended for the common use case of deploying a canonical ITS token or a trustless native interchain token to remote chains via the Factory, where the minter isn't set.
  Hence, additionally check if minter length is 0 in ITS hub to enable tracking.

Overview

What is Axelar?

Axelar delivers secure cross-chain communication for Web3, enabling you to build Interchain dApps that grow beyond a single chain. Secure means Axelar is built on proof-of-stake, the battle-tested approach used by Ethereum, Polygon, Cosmos, and more. Cross-chain communication means you can build a complete experience for your users that lets them interact with any asset, any application, on any chain with one click.

Interchain Token Service (ITS):

The Interchain Token Service allows users and developers to easily create their own token bridge, handling all underlying interchain communication. Users can either use the provided InterchainToken or implement their own. There are multiple configuration options for bridges, and users must trust the deployer of any bridge they use, similar to how they must trust the operator of a token.

Interchain Amplifier:

The Interchain Amplifier enables developers to permissionlessly set up connections to the Axelar network. Developers gain access to Axelar's interconnected network of chains and can "amplify" their resources by paying the cost equivalent to developing only one connection. They can establish connections between new ecosystems or existing chains to add new network properties, such as improved security or better delivery and availability.

• More details on Amplifier: https://docs.axelar.dev/dev/amplifier/introduction

Axelar Amplifier Gateway:

Axelar Amplifier Gateway is a smart contract that lives on the external chain connecting to the Axelar Network. It facilitates the sending and receiving of cross-chain messages to other chains via the Axelar Network. AxelarAmplifierGateway is the EVM reference implementation of the external gateway.

ITS Token Hub for Amplifier

• Tech Spec: ITS Token hub design for Amplifier
• Design Notes: Design Notes (Aug 2024)

Links

• Previous audits: https://github.com/axelarnetwork/audits?tab=readme-ov-file
• Documentation: https://docs.axelar.dev/
• Website: https://www.axelar.network/
• X/Twitter: https://twitter.com/axelarnetwork
• Discord: https://discord.com/invite/aRZ3Ra6f7D
• Youtube: https://www.youtube.com/@axelar-network

---

Scope

Files in scope

• For the EVM Amplifier Gateway contracts:

• For the Cosmwasm/Rust ITS Hub contracts:

• For the interchain-token-service contracts:

Files out of scope

Any files not under the scope tables are OUT OF SCOPE

Scoping Q & A

General questions

ERC20 token behaviors in scope

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

EIP compliance checklist

Only Interchain Token adheres to EIP-20.

Additional context

Main invariants

• Security: Identify and mitigate vulnerabilities to prevent exploits and attacks.
• Reliability: Ensure the contract behaves consistently under various conditions.
• Efficiency: Verify that the contract performs optimally without unnecessary gas consumption.
• Correctness: Ensure the smart contract logic correctly implements the intended functionality without errors.

Attack ideas (where to focus for bugs)

Security Concerns - Access Control, Signature Verification, Reply Protection, Data integrity

• Does the access control mechanism correctly restrict access to sensitive functions?
• Are role-based access controls (onlyRole) correctly implemented for managing flow limiters and operator roles?
• Does the storage function correctly reference the intended storage slots and ensure security?
• Can the signature verification function correctly verify the required signatures?
• Does the function handling signature proofs properly reject invalid or malicious proofs?
• Can the message validation function correctly update the message status to prevent replay attacks?
• Does the message approval function properly check if a message has already been approved to avoid double approvals?
• Are token details, such as addresses and flow limits, securely managed and protected from tampering?
• Does the contract ensure that minting and burning of tokens are properly authorized and logged?
• Any misbehavior by the token which identified through its token ID, does not impact other tokens registered by ITS?

Functional Concerns - Message Approval and Execution, Signer Rotation, Event Emission

• Can the message approval functions correctly handle and store message approvals?
• Does the message validation function accurately validate messages and update their status?
• Does the signer rotation function correctly handle signer rotation, enforce the minimum rotation delay, and prevent rotation to duplicate signers?
• Can the signer rotation function address potential edge cases and ensure proper updates to the signer set?
• Does the contract emit all necessary events correctly and include appropriate data?
• Can event emissions avoid inadvertently exposing sensitive information?

Upgradability Concerns - Upgrade Mechanism, Storage Compatibility

• Does the upgrade mechanism correctly delegate calls to the implementation contract?
• Can the initialization and upgrade functions handle scenarios without introducing vulnerabilities?
• Does the storage layout remain compatible with future upgrades to prevent data corruption or loss?
• Can the storage structures be correctly defined and used?

Potential Edge Cases - Error Handling, Gas Efficiency

• Does the contract have proper error handling and revert statements for invalid inputs, unauthorized access, and other potential failure scenarios?
• Can the contract be optimized for gas efficiency, particularly in loops and storage access patterns?

All trusted roles in the protocol

N/A

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

N/A

Running tests

• Clone the repo:

git clone --recurse https://github.com/code-423n4/2024-08-axelar-network.git

• For Interchain Token Services (make sure you´re at the interchain-token-service folder :

npm ci
npm run build
npm run test

To run gas benchmarks:

REPORT_GAS=true npm run test

To run code coverage:

npm run coverage

More detailed info here.

• For EVM Amplifier Gateway (make sure you´re at the axelar-gmp-sdk-solidity folder :

npm ci
npm run build
npm run test

To run gas benchmarks:

REPORT_GAS=true npm run test

To run code coverage:

npm run coverage

More detailed info here.

• For Cosmwasm/Rust ITS Hub contracts (make sure you´re at the axelar-amplifier folder :

rustup update
cargo build
cargo test

• More info about EVM contract deployments here.

• Test Coverage for Interchain Token Service contracts:

• Test coverage for EVM Amplifier Gateway contracts:

Miscellaneous

Employees of AXELAR 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.