Security & Bug Bounty

Audits

Axelar network code is audited regularly, and the audit reports are published in the audits repository. All Axelar network code and contracts are open source, so anyone can review them and look for vulnerabilities.

Bug bounty

There are two ways to responsibly disclose security vulnerabilities:

Submit a report to the Immunefi bug bounty program.
Send an email to axelar-security@commonprefix.com describing the vulnerability.

Even if your security vulnerability is not eligible for a bounty from the bug bounty program (option 1), the Axelar team might decide to award a bounty for a vulnerability submitted by email (option 2).

Vulnerability criteria

Most vulnerabilities that are found automatically using widely-available tools (e.g. improper domain configuration) are out of scope for the bug bounty program (option 1). Axelar may decide to award a bounty of up to USD $100 for a vulnerability of this kind submitted by email (option 2).

Such a vulnerability usually does not need a detailed report: the initial submission should be a short note describing the issue. If a more detailed report is needed, Axelar will reply with a request.

How the network is secured

This page is adapted from a post originally published to axelar.network/blog.

Security is a multidimensional problem with binary outcomes. Defining the security of a system is an incredibly complex task, but with rigorous models, designs and engineering practices, it's possible to build systems that can stand against attacks. When it comes to securing cross-chain communication, there are two core properties.

Safety: how many nodes in the system does an adversary need to compromise to double-spend or maliciously execute a transaction (that may lead to an invalid asset transfer, for instance)?
Liveness: how many nodes in the system does the adversary need to compromise to halt the system?

The goal is to achieve the above properties with maximal robustness of the network. This is achieved by Axelar, by implementing multiple different layers of security features.

Proof-of-stake consensus

In Byzantine systems, if you break liveness, the system halts its operation, but an adversary would need to do much more to break safety. For instance, a blockchain may halt under a denial-of-service attack on its validators, limiting their ability to send messages and reach consensus. But to break the safety of the blockchain, the adversary might need to find vulnerabilities in validator nodes and extract their secret keys. Robustness of such systems is thus achieved via diversification of software deployments. One validator might deploy on an Ubuntu machine, another on Debian, some in cloud environments, and some on-premise.

This kind of decentralization is critical to satisfy strong safety and liveness properties needed to handle cross-chain functions. This is why Axelar is built using battle-tested proof-of-stake consensus, supporting a diverse and dynamic validator set. Anyone can join, anyone can participate, anyone can contribute to the security of the network.

Quadratic voting

Concentration of power is a problem that many proof-of-stake networks today face. Validators that do a good job operating their nodes tend to receive more delegations from the community and have higher stake in the system. Standard proof-of-stake systems use delegated weight to count how many votes a validator should have in the system. The unfortunate side effect of this is concentration of voting power: if a single validator has a lot of stake, they have a lot of influence in the system.

Even with a system that is technologically capable of decentralization, it’s necessary to determine a mechanism to increase decentralization over time, and counteract concentration of power. By implementing quadratic voting, Axelar is breaking new ground in proof-of-stake security. Quadratic voting has been widely discussed among blockchain leaders, but to date no major blockchain has implemented it.

Quadratic voting is a way to continue decentralizing the system while making it harder for validators to accumulate voting power. The number of votes each validator may cast is equivalent to the square root of their stake. A threshold of validators, weighted by the square root of the stakes, then must collectively coauthorize every cross-chain request. As validators accumulate stake, it becomes more difficult for them to accumulate voting power.

Note that while quadratic voting is implemented for validation and processing of cross-chain transactions, the underlying consensus follows the standard PoS staking model (1 token, 1 vote) for block production and rewards.

Key rotations

Validators of the Axelar network maintain keys that allow them to coauthorize cross-chain requests, a process similar to how validators coauthorize every block on the blockchain. Validators are strongly encouraged to implement best practices for isolating these keys, and are required to rotate them periodically. These key rotations secure the network against a persistent attacker, who might try to accumulate malicious keys by compromising validators sequentially.