Axelar Network - niloy's results

Approach

I took a systematic approach to analyzing the provided smart contracts:

• Read through all contract code to understand the overall architecture and functionality.
• Check for proper use of modifiers like onlyOwner, onlyProxy, etc to limit access.
• Analyze key functions and data structures for security issues.
• Evaluate use of libraries, interfaces and inheritance patterns.
• Assess upgradability mechanisms and reentrancy guards.
• Look for DOS risks with mappings, arrays or unbounded loops.
• Verify math and overflow safety with usage of SafeMath and proper uint data types.
• Review events and error handling.
• Consider likely failure modes and malicious actors.

Architecture

The contracts implement an architecture for cross-chain token transfers and interchain communication. Key components:

• TokenManager handles token locking/minting/burning
• InterchainTokenService facilitates messaging for cross-chain transfers
• StandardizedToken provides common token functionality
• Various utility contracts like Timelock, Multisig, etc

This is a well-designed architecture that encapsulates functionality into appropriate contracts. The use of interfaces allows flexible integration of components.

Code Quality

Overall the codebase follows best practices and is of good quality:

• Well commented for understanding
• Proper use of modifiers for access control
• Interfaces used appropriately
• Enums provide readability
• Events used extensively
• Custom errors provide context

Some opportunities for improvement:

• Reduce code duplication in places
• Additional validation on inputs/outputs of functions
• More unit tests would be helpful

Security Analysis

From a security perspective, the key risks identified include:

• Centralization around owner accounts
• Potential reentrancy issues
• Logic bugs in core functions
• Malicious proposals in governance

Centralization Risks

The contracts have some centralization risks stemming from reliance on owner addresses and privileged roles like operators:

• The InterchainTokenService contract is initialized with an operator who has privileged control. This could be decentralized by using a DAO-controlled operator role.
• The Operatable contract allows the operator to be changed by the current operator. A Timelock could be added for changing critical privilege roles.
• The TokenManager and StandardizedToken contracts also rely on a distributor role. Again a Timelock should be considered for changing this privileged role.
• The FinalProxy and InitProxy contracts allow the owner full control. A Timelock should be used for upgrading proxies or transferring ownership.

Reentrancy

Reentrancy is prevented in critical state-changing functions:

• InterchainTokenService._processSendToken uses an effect-interaction pattern to update state before calling external contracts.
• TokenManager._takeToken and _giveToken update balances before transferring tokens.
• StandardizedToken._mint and _burn update balances before calling the token manager.
• One area that could be strengthened is calling external contracts from InterchainTokenService._execute.

Input Validation

Proper input validation helps prevent abuse of multi-call functions:

• Multicall contract checks for matching input and output array lengths.
• InterchainTokenService does array length checks in _execute.

Additional validation on destination addresses and token amounts would further improve security.

@## Access Controls

The use of modifiers provides access control restrictions:

• Operatable and Distributable restrict access to privileged roles.
• OnlyProxy prevents direct calls to proxy implementations.
• Upgradable restricts upgrading to owner.
• Timelock enforces time-based restrictions.

Consider using a whitelist rather than onlyRemoteService in InterchainTokenService for more flexibility.

Logic Risks

To fully assess logic risks, thorough testing of core functions like:

• InterchainTokenService._execute
• TokenManager._takeToken and _giveToken
• StandardizedToken interchainTransfer

Thank you for having the look into my analysis of Axelar Network codebase.

Time spent:

17 hours