2023-08-04 Audit Report - Axelar - axelarnet

Security Audit Report

Axelar: axelarnet

Authors: Ranadeep Biswas, Mirel Dalcekovic

Table of Contents Audit Overview ............................................................................................................ 1 The Project 1 Scope of this audit 1 Conducted work 1 Timeline 1 Conclusions 2 Further Increasing Confidence 2 Audit Dashboard ......................................................................................................... 3 Target Summary 3 Engagement Summary 3 Severity Summary 3 System overview ......................................................................................................... 4 Cross chain message flows of importance for this audit are: 5 Threat inspection ........................................................................................................ 7 Halting the axelar network chain 8 Possible exploit of funds 9 Distributed Denial of Service attacks 10 Findings ..................................................................................................................... 12 IF-AXELAR-01: Various Minor Code Improvements 13 IF-AXELAR-02: Event is not emitted for executed RouteMessage 15 IF-AXELAR-03: Simplify Relayers setup using FeeGrant 16 IF-AXELAR-04: Additional queries over nexus module for better UX 19 IF-AXELAR-05: Once the funds are deposited on the deposit address they can not be refunded 20 IF-AXELAR-06: IBC wrapping implementation improvement 22 IF-AXELAR-07: Current rate limits design could be improved 23 IF-AXELAR-08: Hardcoded denom issue on the devnets 25 © 2023 Informal Systems Axelar: axelarnet

Audit Overview The Project Axelar Network is a decentralized interoperability network that enables the transfer of value and data across different blockchain ecosystems. It achieves this by providing a secure and decentralized platform that allows developers to build and deploy applications that can interact with multiple blockchain networks without requiring significant changes to the underlying protocols. In essence, Axelar aims to remove the barriers that prevent different blockchain networks from communicating and interacting with each other, thus creating a more interconnected and efficient blockchain ecosystem. Axelar Network offers two types of cross-chain services: native token transfers and general message passing for Ethereum Virtual Machine (EVM) chains, with or without tokens attached. Recently, Axelar Network added a new feature enabling communication with Cosmos chains using its Global Messaging Protocol (GMP), which went live on the mainnet on April 11th. With these new features, Axelar Network now provides the ability to communicate with both EVM and Cosmos chains, making it an even more versatile and useful platform for developers building decentralized applications across multiple blockchain ecosystems.

Scope of this audit The audit took place from March 23, 2023 through April 18, 2023 by Informal Systems by the following personnel: • Ranadeep Biswas • Mirel Dalcekovic During the audit, we focused on analyzing the x/axelarnet module, which is a small component of the Axelar Network's complex system. The remainder of the system was largely considered a "black box" during the audit. Our analysis centered on the Axelar team's stated priorities, namely their use of the Inter-Blockchain Communication (IBC) protocol and the General Message Passing (GMP) functionality for communication with Cosmos chains. The GMP protocol is a decentralized messaging protocol that underlies the Axelar Network's cross- chain communication and asset transfer capabilities, enabling the transfer of native tokens between different blockchain networks with different consensus mechanisms. It's important to note that the Axelar Network contains off-chain components that play a critical role in cross-chain transfers, as they are responsible for triggering these transactions.

Conducted work The audit team started its work on March 24th. The development team's representative gave us an initial overview of the codebase, followed by one more detailed walkthrough of specific parts in the following week. The audit team engaged in reviewing the code of the axelarnet module as well as performing some e2e testing on axelar's public testnet.

Timeline • week 1: Onboarding to the project, walkthrough of GMP feature, system understanding and axelarnet module first iteration of code inspection with focus on IBC usage, translation of denominations. • week 2: Walkthroughs of Native token transfer features, the audit team inspecting the GMP feature, Native token transfers and rate limits. Development team updated the commit hash audited to the v0.33.0 version why the code was once again overviewed over the diffs created. • week 3: The audit team setting up of local axelar chain node and connecting it to the testnet, adaptations on the testnet by axelar team (placing rate limits, fees to be ther than zero ) familiarize with API, running e2e

tests - GMP focus on the fee logic, code inspection of evm translation logic and fee logic. Formulation of the work performed.

Conclusions In general, we found the codebase to be of high quality. The documentation on the Axelar site is well-written and covers the live features comprehensively. The code is well-structured and easy to follow, and the test suite includes both unit and integration tests. However, we faced some difficulties in understanding the underlying assumptions and design of the system. It took us some time to figure out how the modules communicate with each other and how cross-chain transfer flows are initiated. It would be helpful to provide call stack diagrams, state transitions, and details on the read/writes to the appropriate module's stores to facilitate understanding for future developers. As a confirmation of high quality code, we did not find any critical or high severity issues in the codebase. Most of the issues we encountered were related to aesthetics and suggestions for improving the current design. Overall, we are impressed with the quality of the codebase.

Further Increasing Confidence The audit was limited to manual code review and manual analysis. We acknowledge that the Axelar development team follows excellent development practices, and they have performed comprehensive end-to-end testing of new features on their testnet before going live. To enhance confidence in the protocol design and implementation, as a next step, we recommend creating a detailed protocol-level specification that lists all the protocol's properties and assumptions behind them. This would aid in understanding the intended behavior of the Axelar network and identifying potential protocol-level issues.

Disclaimer This report is subject to the terms and conditions (including without limitation, description of services, confidentiality, disclaimer and limitation of liability, etc.) set forth in the associated Services Agreement. This report provided in connection with the Services set forth in the Services Agreement shall be used by the Company only to the extent permitted under the terms and conditions set forth in the Agreement. This audit report is provided on an “as is” basis, with no guarantee of the completeness, accuracy, timeliness or of the results obtained by use of the information provided. Informal has relied upon information and data provided by the client, and is not responsible for any errors or omissions in such information and data or results obtained from the use of that information or conclusions in this report. Informal makes no warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of this report. This report should not be considered or utilized as a complete assessment of the overall utility, security or bugfree status of the code. This audit report contains confidential information and is only intended for use by the client. Reuse or republication of the audit report other than as authorized by the client is prohibited. This report is not, nor should it be considered, an “endorsement”, “approval” or “disapproval” of any particular project or team. This report is not, nor should it be considered, an indication of the economics or value of any “product” or “asset” created by any team or project that contracts with Informal to perform a security assessment. This report does not provide any warranty or guarantee regarding the absolute bug-free nature of the technology analyzed, nor does it provide any indication of the client’s business, business model or legal compliance. This report should not be used in any way to make decisions around investment or involvement with any particular project. This report in no way provides investment advice, nor should it be leveraged as investment advice of any sort. Blockchain technology and cryptographic assets in general and by definition present a high level of ongoing risk. Client is responsible for its own due diligence and continuing security in this regard.

Audit Dashboard Target Summary • Type: Specification and Implementation • Platform: Golang • Artifacts: • axelarnet module at commit hash 4755f9cb4d • axelarnet module at release tag v0.33.0 • evm-cosmos examples at commit has 6d53a78b95, not under auditing but to provide context: • diff PR created for axelarnet changes during the audit, for easier overview

Engagement Summary • Dates: 23.03.2023 to 18.04.2023 • Method: Manual code review & protocol analysis • Employees Engaged: 2

Severity Summary Finding Severity #

Critical 0

High 0

Medium 0

Low 4

Informational 4

Total 8

System overview The Axelar network serves as a hub, linking different ecosystems together. Since it is a blockchain, it can do much more than bridges connecting blockchains, as all connected chains can communicate with each other seamlessly. The network also enables the generation of a one-time deposit address that can receive cross-chain funds from any wallet, giving users a centralized experience during exchanges with other open protocols and networks. To achieve high safety and liveness, Axelar has introduced protocols such as the Cross Chain Gateway Protocol (CGP) and the Cross Chain Transfer Protocol (CTP). Additionally, the network has an app-level protocol stack that sits on top of routing protocols, like CCG and other routing technologies, that allows application developers to connect their dApps on any chain and perform cross-chain requests. The Axelar network offers several advantages, including the ability for blockchain platform builders to easily plug in their blockchains to all other blockchain ecosystems with only a threshold account needing to be set up on the chain to connect to the network. For dApp builders, hosting their dApps anywhere, locking, unlocking, transferring assets, and communicating with applications on any other chain via CTP API is possible. Users can interact with all applications across the ecosystem directly from their wallets. Axelar allows sending cross-chain token transfers and messages between any Cosmos or EVM chains, providing a uniform cross-chain experience for developers. Gateway contracts: (Not under the scope of the audit.) To execute cross-chain transactions, Gateway contracts are deployed on all EVM-connected chains. The Gateway contract is controlled by a key that is held jointly by all Axelar validators. To achieve this, a multi-party cryptography scheme is used, where the key is divided into many pieces, known as key shares. The number of shares is equal to the amount of staked AXL tokens held by the validator. For an action to be executed, the threshold must be reached. Before transactions are authorized by the Gateway, they must first be confirmed by a validator vote. Once authorized, Axelar burns tokens or approves GMP transactions. Validators: To participate in consensus, validators must verify all cross-chain activity processed by the Axelar network. This involves running nodes for Axelar-supported chains and observing external chains for activity. The process involves a Delegated Proof of Stake (DPoS) mechanism where validators hold states of other connected chains and create an "incoming bridge." While signing details and threshold schemes are important for this mechanism, they are complex and were not analyzed in detail as they were outside the scope of the audit. Relaying services: Can be performed by anyone, no form of trust is required - existing relayer service can be used or apps can build and use their own relayers. Gas receiver Application developers using Axelar for General Message Passing have two options:

They can build their own relayer services on the destination chain, which will cover the gas fees required for the final executable smart contract call;
They can pay gas fees with the Axelar Gas Receiver on the source chain. Gas receiver is a smart contract that accepts tokens as payment to cover costs of contract execution for general message passing tx. Axelar relayer services will confirm the gas payment on the source chain, then automatically execute the smart contract call on the destination chain when it gets approved. Modules The axelarnet module serves as the gateway to the Cosmos side, while the evm module is responsible for the EVM chains. The Nexus module acts as a central hub for packet transfers between the chains. Although there are other modules, such as multisig/vote, which offer useful features like signing and voting, they are not relevant to the scope of this audit.

Cross chain transfers Using the permissioned command in axelarnet, any IBC channel can be registered with an alias or chain name, which can then be used as a destination for token transfers and messages. Two types of cross-chain sends are supported:

native token transfers and
general message passing (with or without tokens attached). The scope of this audit is the cosmos side of axelar: • axelarnet module • and its use of the IBC. Our analysis will cover IBC rate limits, handling of failures in transfers, and denomination representations in axelarnet modules, including the translation of IBC denoms. We will also examine both types of cross-chain message flows through the axelarnet module.

Cross chain message flows of importance for this audit are: Processing of cross chain messages received from other cosmos/evm chains:

The execution flow for existing GMP messages Is triggered with RouteMessage function on the axelarent API. The flow is as described on the diagram.

Execution of cross chain messages is triggered from:

axelarnet module's end blocker - for native token transfers
with messages existing on axelarnet API: • native/IBC token transfers: • RouteIBCTransfers - sets up everything for axelarnet's • ExecutePendingTransfers • RetryIBCTransfer • GMPs: • RouteMessage - triggers the processing of the GMPs across the system Given the complexity of the Axelar network and the presence of off-chain components, certain parts of the system could not be thoroughly analyzed within the time constraints of this project. It's worth noting that some components, such as the relayer services, are black-boxed and were not audited in this study. However, the analysis carried out offers valuable insights into the functionality of the axelarnet module and its role in enabling cross-chain transactions in the network. To ensure a comprehensive and high-quality audit, we focused on understanding the essential components of the system. The brief overview of the system provided in this report represents our collective understanding.

Threat inspection The following section outlines the three-week audit performed on the axelarnet module's code. Due to the system's complexity, as described in our system overview and internal notes, it was challenging to analyze all possible impacts and cases that could lead to issues related to or arising from the axelarnet module. We spent most of our onboarding time understanding and abstracting the components that were not audited and gaining insights into the system's behavior that impacts or is dependent on the module being audited. The audit's scope was to analyze the functionality of the axelarnet module as a bridge on the Cosmos side of the Axelar network, whose primary role is to process and direct messages from the Axelar network to the destination chain. Since the module is dependent on many Axelar network components and communicates with them, our analysis was limited, and we considered most of these components as black boxes. The audit was primarily focused on the scope discussed during the kick-off meeting: • IBC usage • IBC denoms translation • General Message Passing • EVM message translation on the Cosmos side During the initial stage of the audit, the auditing team spent time identifying potential threats and analyzing the impact of the axelarnet module. Our primary objective was to validate the design's correctness and identify any issues in the codebase that could result in the realization of these threats. To achieve this, we held weekly sync meetings with the axelar team to discuss possible flaws in the system and gain insights into the current behavior of the system. Through these efforts, we were able to validate that the identified threats could not be realized. The following analysis contains our conclusions and the explanation of the axelarnet module's design on how those threats are mitigated. In addition to our threat inspection analysis, we have documented our results as findings and executed end-to-end test cases. We have shared our findings and testing results with axelar team representatives in the form of a list of minor issues and suggestions for design and implementation improvements. It should be noted that, while we do our best in the analysis below, a security audit can by no means guarantee the absence of threats: the real guarantees can be provided only via systematic quality assurance, including manual and automated testing, and, ultimately, via the usage of formal methods, such as model-based testing or formal verification. We have identified main categories of threats: • Halting of the axelar network chain. As main IBC transferring logic is placed in the end blocker of the axelarnet module, we took the effort to inspect whether and how the logic or possible panics from deeper in the call stack could lead to halting the chain. • Possible exploit of funds We analyzed manipulation with the deposit address, to see if there are certain design flaws that could lead to stealing the funds from this intermediatory account. Also, Fee logic was analyzed to confirm that the fee payment (if provided) is a prerequisite for placing the specific cross chain transfer in the waiting queue for execution. We questioned permissionless registration of chains and assets, with the possibility of placing the rate limit for a specific asset could be potentially dangerous, so we proved that those messages are executed only in case of the user holding the appropriate permission role. • dDoS attacks - We analyzed the possibilities of the malicious or faulty creation of Native token transfer or General Message Passing messages. Also, since there are state transitions defined for both types of the cross chain messages, we were considering possible faulty state transitions for IBC transfer and GMPs in nexus and axelarnet modules. We were analyzing the possibility of creating cross chain messages that will fail to execute, and

Excerpt (19999 of 47692 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation