Inside Axelar: How 75 Validators Enable Cross-Chain Smart Contract Calls

Axelar’s cross-chain infrastructure enables developers to build applications that wouldn’t be possible with simpler token bridges. Here’s what I learned by actually using it.

Most people think cross-chain bridges just move tokens from one blockchain to another. Lock tokens on one blockchain, mint wrapped versions on another blockchain, and that’s it – simple token transfer between chains. That’s how I understood bridges too; until I started digging into Axelar’s architecture and realized it’s not a bridge at all.

Axelar isn’t moving tokens from Chain A to Chain B – it’s letting developers call any smart contract function from any blockchain. You can trigger a function on Ethereum from Arbitrum, execute a governance vote on Polygon that affects Avalanche, or even build applications that span multiple chains in ways that shouldn’t be possible.

The magic in how this works is through 75 validators running a Byzantine Fault Tolerant consensus. A majority ⅔ of the validators have to agree before anything happens cross-chain and they use threshold signatures where each validator holds part of a key.

I wanted to see this in action, so I bridged some tokens and tracked what actually happened using Axelar’s block explorer. The transaction touched multiple blockchains, showed me exactly which block the validators reached consensus, and revealed way more detail than I’d seen with other bridges.

What I found was more complex and more interesting than I expected. Here’s how it actually works.

// TL;DR – Key Takeaways

• 75 validators use delegated Proof-of-Stake and Byzantine consensus to verify cross-chain messages – requiring ⅔ agreement before any transaction executes.
• Three connection architectures: Cosmos chains via native IBC, EVM chains via Gateway smart contracts, and specialized Gateway Programs (eg. Solana).
• General Message Passing (GMP) allows developers to call any smart contract function from any connected chain – not just transfer tokens.
• Security through economics: Validators stake AXL tokens and can be slashed for misbehavior, unlike reputation-based systems with no capital at risk.
• Transparency trade-off: Slower than centralized bridges, but Axelarscan shows transaction tracking that most bridges don’t provide.

My transaction cost $0.65 total and involved a “ContractCallWithToken” – Axelar’s GMP method that executes smart contract functions on destination chains, not just simple token transfers.

// What Is Axelar?

Axelar describes itself as “a decentralized interoperability network”, but truthfully, that undersells what it actually does. Most bridges just move tokens between chains. Axelar provides infrastructure that lets developers build cross-chain applications.

The difference matters. When I bridged USDC using Squid Router (a DEX aggregator), I wasn’t just moving tokens to my wallet on BSC. I was calling Squid’s smart contract on BSC with specific swap instructions. The tokens arrived already processed through Squid’s routing logic – all in a single cross-chain transaction.

This capability, known as General Message Passing, is what separates Axelar from simpler bridge protocols. Developers can trigger any function on any contract on any of Axelar’s 55+ connected chains.

The protocol is built on the Cosmos SDK – the same blockchain development framework used by Cosmos, Osmosis, and other Cosmos ecosystem chains. This gives Axelar native connectivity to Cosmos chains via IBC (Inter-Blockchain Communication), while custom Gateway contracts extend its reach to EVM (Ethereum Virtual Machine) chains and specialized Gateway Programs connect to non-EVM environments, like Solana.

Under the hood, 75 validators run the Axelar network, verifying cross-chain messages through Byzantine Fault Tolerant consensus. They stake AXL tokens (Axelar’s native token) and can be slashed for misbehavior – creating economic security rather than relying purely on reputation.

// The Architecture: 3 Ways to Connect Chains

Axelar connects to different blockchain architectures through three distinct methods:

1. Cosmos Chains: Native IBC

Cosmos chains connect to Axelar natively through IBC (Inter-Blockchain Communication); the same protocol that powers the broader Cosmos ecosystem. Because Axelar is built on Cosmos SDK, any Cosmos chain can communicate with Axelar without requiring additional gateway infrastructure.

IBC is a low-level communication protocol for blockchains. It’s built into the Cosmos SDK and has no central operator and doesn’t require validators or tokens. Axelar uses IBC as the foundation, then adds its validator network and Gateway architecture on top to reach non-Cosmos chains.

2. EVM Chains: Gateway Smart Contracts

For EVM-compatible chains (Ethereum, Arbitrum, Polygon, BSC, etc.), Axelar deploys Gateway smart contracts. These contracts:

• Verify validator signatures using threshold cryptography.
• Lock tokens on the source chain or mint wrapped tokens on the destination chain.
• Execute incoming cross-chain messages from Axelar validators.
• Handle General Message Passing calls to other contracts.

When I initiated my bridge from Solana to BSC, the Axelar Gateway contract on BSC received the validators’ signed message and executed the token transfer to Squid’s contract. The Gateway doesn’t hold tokens permanently – it locks them on the source chain and mints wrapped versions (like axlUSDC) on the destination chain.

3. Non-EVM Chains: Specialized Gateway Programs

Axelar is expanding beyond EVM chains through custom implementations for different environments. Solana, for example, required a specialized Gateway Program that interfaces with Axelar’s validator network while operating within Solana’s runtime.

This multi-architecture approach positions Axelar as infrastructure that can eventually reach any blockchain – though each new chain requires custom development and adds complexity. The recent integration with Solana shows Axelar’s commitment to expanding beyond the EVM ecosystem, but it also means the protocol must maintain and secure multiple codebases across different execution environments.

// The Validator Network: 75 Nodes Running Cross-Chain Consensus

Axelar’s security model centers on its validator network; 75 validators running delegated Proof-of-Stake consensus. Here’s how it works:

Competitive Validator Entry

The validator set operates as a permissionless system. The top 75 validators by staked AXL participate in consensus. To join, a new validator must stake more AXL tokens than the current 75th validator. This creates a merit-based system where the validator set can change over time based on stake accumulation.

Validators earn rewards proportional to their stake. Critically, validators earn additional rewards for running nodes on more connected chains. If you’re a validator running nodes on Ethereum, Arbitrum, BSC, and Solana, you earn more than a validator only supporting Ethereum. This incentivizes validators to maximize chain coverage, which benefits the overall network by ensuring cross-chain messages can be verified across more blockchain environments.

Byzantine Fault Tolerant Consensus

Axelar uses Byzantine Fault Tolerant consensus with a ⅔ threshold. This means at least ⅔ of the 75 validators (50+ validators) must agree on any cross-chain message before it executes. This is slower than centralized bridges, but provides stronger security guarantees. Meaning you’d need to compromise 34+ independent validators simultaneously to fake a cross-chain message.

Compare this to Wormhole’s 19 Guardians (Proof-of-Authority with no staking) or LayerZero’s Oracle + Relayer model (two independent parties that must collude). Axelar’s approach trades speed for decentralization. My 28-minute transaction reflects the time needed for 50+ validators to reach consensus, verify signatures, and coordinate execution.

Threshold Signatures

Instead of each validator signing messages individually, Axelar uses threshold signatures. Each validator holds a share of a multi-party key. To authorize a cross-chain message, ⅔ of validators must contribute their key shares to generate a valid signature. This prevents any single validator from having enough information to authorize fraudulent transactions.

The keys rotate periodically for security and to accommodate new validators joining the network. This rotation mechanism ensures that even if a validator’s key share is compromised, the window of vulnerability is limited.

Economic Security Through Slashing

Validators can be slashed (have their stake taken away) for misbehavior including double-signing, extended downtime, or signing invalid state transitions. While I couldn’t find specific slashing percentages in Axelar’s documentation, the existence of slashing creates economic security as validators have capital at risk, not just reputation.

This differs from reputation-based systems where validators have no financial stake to lose. With Axelar, attacking the network means potentially losing the AXL tokens you’ve staked which creates a financial disincentive for malicious behavior.

// General Message Passing: Beyond Token Transfers

The most important thing to understand about Axelar is that it’s not just a token bridge. General Message Passing (GMP) allows developers to call any smart contract function from any connected chain.

Here’s a simplified example of what GMP looks like in code:

solidity

// On Chain A (Ethereum): Send cross-chain message
function sendMessage(
     string calldata destinationChain,
     string calldata destinationAddress,
     string calldata message_
) external payable {
     bytes memory payload = abi.encode(message_);

// Prepay gas for execution on destination chain
gasService.payNativeGasForContractCall{value: msg.value}(
     address(this),
     destinationChain,
     destinationAddress,
     payload,
     msg.sender
);

// Tell Axelar Gateway to deliver this message
gateway().callContract(destinationChain, destinationAddress, payload);

}

// On Chain B (Polygon): Receive and execute
function _execute(
     bytes32 commandId,
     string calldata sourceChain,
     string calldata sourceAddress,
     bytes calldata payload_
) internal override {
     string memory message = abi.decode(payload_, (string));

// Message received – execute application logic

}

The developer doesn’t manage validators, threshold signatures, or cross-chain verification. Axelar’s infrastructure handles it. The developer just needs to:

1. Encode their message (can be any data – tokens, function calls, complex instructions).
2. Prepay gas for destination chain execution.
3. Call the Gateway contract.

Axelar validators then verify, sign, and deliver the message to the destination chain, where it’s automatically executed.

Real-World Example: Squid Router

My transaction used this exact architecture. Squid Router is a DEX aggregator built on Axelar’s GMP. When I bridged from Solana to BSC:

1. On Solana: Squid’s contract called Axelar Gateway with my USDC.
2. Axelar Network: 75 validators reached consensus and signed the message.
3. On BSC: Axelar Relayer executed Squid’s contract with my tokens plus swap instructions.

The result: my USDC didn’t just arrive in my BSC wallet – it arrived already routed through Squid’s DEX aggregation logic, finding the best swap rates across multiple BSC DEXs. All in a single cross-chain transaction.

This is what GMP enables: cross-chain applications that execute complex logic, not just token transfers.

// Security: Audits and Attack Vectors

Axelar’s approach to security includes multiple independent audits before deploying new functionality. All audit reports are publicly available on GitHub.

For example, a recent audit by Ackee Blockchain Security of Axelar’s Solana Gateway Program identified several critical vulnerabilities before mainnet launch. One finding (C1: “Remote deployment with a specified minter can be fully bypassed with fraudulent approval”) revealed that insufficient validation in the Interchain Token Service could allow attackers to bypass minter approval requirements.

The vulnerability worked like this:

1. Alice deploys “TokenA” (worthless) on Solana.
2. Alice creates an approval for remote deployment of TokenA.
3. Due to insufficient validation, Alice uses TokenA’s approval to deploy someone else’s “TokenB” on Ethereum.
4. Alice becomes the minter of TokenB on Ethereum (even though it’s not her token).
5. Alice mints millions of TokenB on Ethereum.
6. Alice bridges TokenB back to Solana and sells it for profit.

The approval mechanism didn’t verify WHICH token was being deployed on the destination chain, only that some approval existed. This could have allowed attackers to approve their worthless token, then deployed any valuable token they wanted with themselves as the minter.

The vulnerability was patched before mainnet deployment. But it highlights the complexity of cross-chain security: Axelar must secure not just its validator network, but also Gateway contracts on each EVM chain, specialized Gateway Programs for non-EVM chains like Solana, and the interactions between all these components.

Every new chain type adds attack surface. The Solana integration required an entirely new codebase (Solana programs vs EVM smart contracts) with different security considerations and potential vulnerabilities. This is the price of multi-architecture support. More flexibility for developers, but more complexity for security.

// My Transaction: What Actually Happened

Let me walk through what Axelarscan revealed about my 28-minute bridge:

Step 1: Sent (Arbitrum)

My transaction started on Arbitrum – not Solana as I expected. Squid Router had analyzed liquidity across multiple chains and determined the best route was Solana → Arbitrum → BSC. Not directlu from Solana → BSC. This routing happened invisibly. From my perspective, I clicked “Bridge from Solana to BSC” and waited.

The transaction called Axelar’s Gateway contract on Arbitrum, transferring 29.63 axlUSDC (Axelar’s wrapped USDC) to the Gateway.

Block: 405,783,015 (Arbitrum)
Transaction Hash: 0xb7c8d79c…218cea272
From: My wallet (0x93C7…24E7)
To: Axelar Gateway

Step 2: Gas Paid

In the same transaction, I prepaid gas for execution on the destination chain (BSC). This is a critical part of Axelar’s architecture – the sender pays upfront for the computational cost of executing their message on the destination chain.

Gas Prepaid: 0.00002 ETH
To: Axelar Gas Service
Purpose: Cover BSC execution costs

Step 3: Confirmed (Axelar Network)

This is where the Axelar validators came in. The 75 validators reached Byzantine consensus on my cross-chain message, verifying that:

• The Gateway contract on Arbitrum actually received my tokens.
• The message was valid and properly formatted.
• The destination (Squid contract on BSC) was correct.
• The gas prepayment was sufficient.

Block: 21,046,324 (Axelar blockchain)
Transaction Hash: AA7202A673…E9D27691AE
Result: Validators signed the message with threshold signatures

This step took the majority of the 28 minutes. Getting 50+ independent validators to verify, sign, and reach consensus on a cross-chain message is inherently slower than centralized bridges.

Step 4: Approved (Relayer Preparation)

After validator consensus, an Axelar Relayer prepared to execute the transaction on BSC. The Relayer verified the validator signatures and submitted the approved message to BSC’s Axelar Gateway.

Block: 70,035,877 (BSC)
From: Axelar Relayer
To: Axelar Gateway (BSC)
Gas: 0.00006 ETH

Step 5: Executed (BSC)

Finally, the Axelar Gateway on BSC executed the message by calling Squid’s contract with my tokens and swap instructions. The tokens arrived in my BSC wallet as USDC (not axlUSDC), having been processed through Squid’s routing logic.

Block: 70,036,387 (BSC)
Transaction Hash: 0x86d3e287…7f733e1628
From: Axelar Relayer
To: Squid (0x…Squid contract address)
Method: ContractCallWithToken (GMP)

Total Time: 28 minutes 21 seconds
Total Cost: $0.65 ($0.28 in Solana gas + $0.37 in bridge fees)

// What This Means for Users

When to Use Axelar

Choose Axelar when you need:

• Cross-chain smart contract calls (not just token transfers).
• Connections to Solana or Cosmos chains (not all offer this).
• Lower fees (if willing to wait longer).
• Transparency (detailed transaction tracking).

When to Use Alternatives:

Choose alternatives when you need:

• Speed (seconds vs minutes).
• Simplicity (don’t need complex routing).

Risks to Understand

Validator Centralization: While 75 validators sounds decentralized, the competitive staking model means the largest token holders control the validator set. This is common across PoS systems, but worth noting.

Multi-Chain Complexity: Axelar must maintain Gateway contracts/programs across 55+ chains. Each chain adds potential attack surface. The Solana audit finding shows how complex this gets.

Routing Opacity: Squid routed my transaction through Arbitrum without telling me. This optimizes for cost/speed, but reduces user control over routing.

How to Verify Transactions

Always check Axelarscan (https://axelarscan.io/) for detailed tracking. The five-step breakdown shows:

• Whether validators have confirmed (Step 3).
• If relayers are processing (Step 4).
• When execution happened on destination (Step 5).

If a transaction is stuck, Axelarscan shows which step failed. This is very helpful for debugging or contacting support.

// Final Thoughts

Axelar isn’t just a bridge. Axelar is cross-chain infrastructure that enables developers to build applications that span multiple blockchains. General Message Passing, multi-architecture connectivity (Cosmos, EVM, Solana), and transparent validator consensus separate it from simpler token bridges.

The trade-offs are clear: slower than centralized alternatives, more complex to audit, but with stronger decentralization guarantees and capabilities that simpler bridges can’t provide.

My 28-minute, $0.65 transaction moved tokens across three blockchains, executed a DEX aggregator contract, and involved 75 validators reaching Byzantine consensus – all through a simple “Swap” button. That abstraction is both impressive (hiding complexity from users) and slightly terrifying (users have no idea what’s happening under the hood).

For developers building cross-chain applications, Axelar provides infrastructure that makes complex cross-chain interactions possible. For users just trying to move tokens from Chain A to Chain B, you’re paying the price of that infrastructure complexity whether you need it or not.

Next up: I’m analyzing Chainlink’s Cross-Chain Interoperability Protocol (CCIP) to see how traditional oracle networks are approaching the cross-chain bridge space.

// Resources

• Axelar Network
• Axelar Documentation
• My transaction on Axelarscan
• Squid Router