Axelar

Axelar is cross-chain application infrastructure built around gateways, validator-mediated message approval and General Message Passing. It is not a finished bridge screen: an integrating application defines the destination contract, payload, token behaviour and user experience for each supported route.

General Message Passing makes the destination action explicit

A source application calls its local Axelar Gateway with a destination chain, contract address and payload. The receiving contract implements the Axelar Executable interface and decides what the approved payload does, so a gateway connection alone does not make every contract, asset or application reachable.

The callContractWithToken path attaches a token to a contract call. Actual asset support still depends on token-manager configuration, the selected chains and the destination contract, rather than following automatically from two chains being connected.

Validators approve while delivery and execution remain separate

Axelar’s proof-of-stake validators vote on observed source-chain events and threshold-authorise an accepted command for the destination gateway. The gateway records the approved payload hash, and execution tracking prevents the same approved command from running again.

Approval is not the final business outcome. Relaying, destination gas and destination-contract execution remain separate stages; an underfunded route, delivery delay or contract revert can leave a request incomplete even after the network has accepted its message.

Route costs and coverage are specific to the integration

A cross-chain request can incur source-chain, Axelar-network, relay and destination-execution costs. Axelar’s gas service can collect payment in the source chain’s native asset and estimate the later work, but the quote is route- and payload-specific rather than a permanent network-wide price.

A production route needs deployed gateways on both chains, the exact destination identifier and contract, enough destination execution resources and application support in that direction. Connected-chain coverage does not guarantee a reciprocal route, supported asset or compatible destination action.

A shared verifier model versus route-selected verification

Axelar fits teams that want a network-operated interoperability path across its connected ecosystems. The trust model includes its validator set and gateway authorisation process, as well as the security of both chains and the application’s own destination logic.

LayerZero is the close alternative when an OApp should select compatible verifier networks, message libraries and execution arrangements for each route. Axelar instead presents a shared validator and gateway path; the trade-off is a common verification model rather than application-selected route-level configuration.