Axelar: Multichain Infrastructure Built on a Security Foundation
1. Beyond Asset Movement
Early multichain infrastructure largely evolved around two metrics: the number of supported chains and the speed of asset transfers. But as multichain applications have expanded into production environments, it has become clear that asset movement alone is no longer sufficient.
Axelar has responded to this shift by expanding its technology stack across message passing, execution environments, token management, chain connectivity, and open standards. This article examines the role each component plays and how, together, they are expanding the scope of multichain infrastructure.
2. GMP (General Message Passing): The Foundation for Multichain Communication
For a multichain application to operate in a production environment, an action on one chain must be able to trigger a smart contract call or state change on another. Axelar's General Message Passing (GMP) is the core capability that makes this cross-chain message delivery and execution possible.
2.1 The Limits of Asset-Only Bridging
Traditional bridge designs typically locked an asset on one chain and minted a wrapped version of equivalent value on another. That model is effective for moving tokens, but it falls short of what modern multichain applications require.
Consider a deposit, swap, or collateral check that originates on one chain and needs to trigger smart contract execution on another. Moving tokens is not enough. The event payload, resulting state information, and any data required for downstream execution must be transmitted together.
2.2 How GMP Works
GMP provides a messaging layer that lets a smart contract on one chain call a smart contract on another. Developers can use it to connect an event on the source chain directly to a function call or state change on the destination chain.
In this process, Axelar's validators observe the message on the source chain and reach consensus on its validity. The Gateway on the destination chain then verifies that the incoming call has been authorized, and the destination contract executes its logic using the delivered payload.
3. MDS (Mobius Development Stack): A Technology Stack for Multichain Applications
If GMP provides the foundation for cross-chain messaging and execution, MDS is the integrated technology stack Axelar offers for building multichain applications on top of it.
MDS is organized around three components: AVM, ITS, and Interchain Amplifier. AVM extends interoperability into a programmable execution layer. ITS standardizes how tokens are issued and managed across chains. Interchain Amplifier opens up the process of connecting new chains and external systems.
Rather than connecting each chain individually and managing them in isolation, developers can use Axelar to design multichain services in a more unified way.
3.1 AVM (Axelar Virtual Machine): Programmable Interoperability
Most smart contract execution environments were designed to operate within the bounds of a single chain. Ethereum opened the door to DeFi and a wide range of on-chain services, but its execution scope is fundamentally confined to one network.
AVM is Axelar's execution environment built to move beyond that constraint, allowing cross-chain interaction itself to be expressed as smart contract logic. Built on CosmWasm, AVM turns interoperability into a programmable layer.
Developers can write smart contract logic that runs on the Axelar network and configure cross-chain connections and deployments in a more automated way. AVM also underpins capabilities like Interchain Amplifier and Interchain Token Service, supporting more scalable new-chain integrations and multichain token management.
In this sense, AVM takes cross-chain connectivity and message handling beyond fixed infrastructure features and turns them into a programmable surface that developers can design and extend themselves.
3.2 ITS (Interchain Token Service): A Standard for Multichain Token Issuance and Management
Under traditional bridge models, the same token often existed as different versions on different chains. Each chain ended up with its own wrapped representation, and the safety of minting and burning those wrappers was tied to a particular bridge's validation setup. A bridge incident could directly affect the liquidity and usability of every token that depended on it.
ITS unifies these fragmented token issuance and management practices under a single, consistent framework. Instead of creating a separate wrapped token on every chain, ITS allows a token deployed across multiple chains to preserve the same issuance rules, functionality, and fungibility.
To make this work, ITS uses a set of smart contract components, including Token Manager, Handler, and ITS Hub, to automate minting, burning, locking, transfer-limit configuration, and other aspects of supply management. Developers can launch entirely new tokens through ITS or extend an existing token to additional chains.
ITS is therefore not just a token transfer mechanism. It is a framework for standardizing token issuance and supply management across a multichain environment, and it applies wherever a project needs the same asset structure and behavior across multiple networks. Teams can keep their home chain's issuance authority intact while using ITS to design how their token expands across the broader ecosystem.
3.3 Interchain Amplifier: An Open Model for Chain Connectivity
In most interoperability networks, integrating a new chain has historically depended on the operating team's development priorities, available integration resources, and network-level approval processes. Which chain gets connected first often comes down to the operator's roadmap, and even chains with clear ecosystem demand can face delays.
Interchain Amplifier makes this process more open. Developers and ecosystem participants can configure smart contracts, relayers, and verification mechanisms to connect a new chain or external system to the Axelar network. The architecture is flexible enough to accommodate different tech stacks, including Solidity and Rust, as well as different consensus models. In effect, Amplifier shifts chain integration from a curated, sequential process led by the network operator into one that developers and ecosystem participants can drive forward directly.
Rollkit, the Celestia-based rollup framework, provides a useful example. Rollkit makes it easier to launch a Celestia-backed chain, but enabling that chain to interoperate with Ethereum or other external networks is a separate challenge. Through an integration with Celestia Labs, Axelar built a path for Rollkit-based chains to connect to the Axelar network, giving them interoperability with other chains connected through Axelar. Amplifier is not merely about adding more supported chains; it transforms chain integration itself into a more open and scalable process.
If MDS gives developers cross-chain execution, token management, and chain connectivity on top of Axelar, the next question is whether different interoperability protocols can be used together through a shared interface.
4. OpenBridge and ERC-7786: Open Standards for Connecting Interoperability Protocols
Opening up chain connectivity is only part of the picture. As long as each interoperability protocol runs on its own validation model and exposes its own interface, developers remain locked into the protocol they initially built on. Designing an application around a specific protocol can require changes to application logic whenever a team wants to add or replace another protocol.
Axelar and OpenZeppelin propose a way out through OpenBridge and ERC-7786. The goal is to let multiple interoperability protocols be used through a single standard interface, with the option to combine several validation paths where additional assurance is required.
4.1 The Limits of Single-Protocol Dependence
Each of the major interoperability solutions handles cross-chain messaging and asset movement through its own validation model and operational stack. Single-protocol dependence here does not mean reliance on a single validator set. It means an application is bound to the validation architecture and interface of one particular interoperability protocol.
Under this model, layering in a different validation model or migrating to a different protocol later is rarely simple. If something goes wrong inside that protocol's validation or operations, services built on top of it can also be exposed. Repeated bridge security incidents have highlighted the need to avoid relying on a single validation path.
4.2 OpenBridge: Combining Multiple Validation Models
OpenBridge is an open-source framework that lets the validation paths of multiple interoperability protocols be combined behind a single standard interface. A single cross-chain message can be sent through several ERC-7786-compatible bridges or interoperability protocols at once, with execution gated on receiving a configurable number of independent confirmations on the destination chain.
Axelar and OpenZeppelin describe this as an x-of-y-of-n configuration. For a high-value cross-chain loan, for example, a developer might require confirmations from at least two of three interoperability protocols before the message is executed. If one validation path fails, the others can continue to provide coverage, reducing overall risk.
OpenBridge is not simply another bridge solution. It treats existing interoperability protocols as composable validation layers that can be mixed and matched.
Dimension | Single-Protocol Dependence | OpenBridge Approach |
|---|---|---|
Validation | Relies on a single interoperability protocol | Combines multiple validation paths |
Failure impact | An issue in the protocol can affect every dependent service | Issues on one path can be mitigated through additional validation |
Policy configuration | Bound to the protocol's validation flow | Flexible x-of-y-of-n configuration |
Adoption pattern | Pick one solution and build on it | Combine multiple solutions through a shared interface |
4.3 ERC-7786: A Standard Interface for Interoperability Protocols
ERC-7786 is the cross-chain messaging standard that makes it possible for OpenBridge to coordinate multiple interoperability protocols. It defines a common interface through which different bridges and messaging protocols can exchange messages, and OpenBridge is built directly on top of it.
OpenZeppelin's involvement is worth noting. OpenZeppelin maintains some of the most widely used secure smart contract libraries and developer tooling in the Solidity ecosystem. ERC-7786 is therefore more than an extension of Axelar's own capabilities. It is an attempt to establish cross-chain messaging as a common interface across the broader Solidity development ecosystem.
The standard is explicitly designed to avoid locking applications into any one interoperability protocol. If a range of protocols can plug into the same interface, developers gain the flexibility to combine multiple validation models, replace protocols when needed, and design more adaptable multichain applications.
5. Extending Into Institutional Use: Infrastructure for Tokenized Assets
The Axelar stack outlined above points to a broader pattern: bringing messaging, execution, token management, chain connectivity, and validation together into a single infrastructure layer for multichain environments. That requirement is not unique to DeFi applications. It also appears in institutional settings, where tokenized assets need to be issued, operated across multiple networks, and integrated with distribution and settlement processes.
For institutions, the central question is rarely which chain to pick. It is which common infrastructure can support tokenized assets across the issuance, movement, and operations lifecycle when those assets live on several networks at once. JPMorgan Onyx and Deutsche Bank's DAMA 2 are early indications that this question is being explored in real institutional tokenization work.
5.1 JPMorgan Onyx: Interchain Movement of a Tokenized Fund
As part of Project Guardian, J.P. Morgan and Axelar ran a proof of concept for the interchain movement of a tokenized fund, with Oasis Pro and Provenance Blockchain Zones also participating. The exercise tested whether a tokenized portfolio could be structured and operated across multiple blockchain environments rather than being confined to a single network.
Axelar served as the interoperability infrastructure connecting asset movement and messaging across those networks. The PoC provides a concrete example of how the GMP-based messaging and multichain execution patterns described earlier can carry over into institutional tokenized-asset operations.
5.2 DAMA 2: Deutsche Bank's Asset Tokenization Platform
Deutsche Bank introduced the MVP and technical architecture for its institutional asset tokenization platform in the DAMA 2 litepaper. DAMA 2 is designed as a tokenization platform built on public blockchains, with regulatory alignment and privacy as foundational design principles.
DAMA 2 is currently in the phase of building out additional features and use cases on top of the MVP, with Axelar providing interoperability infrastructure that allows the platform to extend beyond a single network into a broader multichain environment. It is another sign that institutional asset tokenization is being designed as a single platform spanning issuance, operations, distribution, and cross-chain connectivity, rather than as isolated deployments on individual networks.
Taken together, these institutional conversations are converging on the same conclusion: tokenized assets need infrastructure that can handle issuance, movement, operations, and distribution consistently across multiple networks at once.
6. The New Basis of Competition
The Axelar stack reviewed here points to a clear shift: multichain infrastructure is moving beyond bridge architectures built around asset movement and toward broader execution environments with standardized connectivity.
GMP connects cross-chain messaging with execution. AVM extends interoperability logic into a programmable surface. ITS brings token issuance and management across chains under a single consistent framework. Interchain Amplifier reshapes chain integration into a more open process. OpenBridge and ERC-7786 chart a path toward using multiple interoperability protocols through a shared interface.
What these pieces have in common is that Axelar's security architecture is no longer functioning as a defensive layer alone. It has become the foundation on which multichain services can scale. The JPMorgan Onyx PoC and Deutsche Bank's DAMA 2 suggest that this shift is taking concrete shape beyond DeFi, in institutional environments as well.
As the issuance, settlement, and movement of tokenized assets pick up pace, the demands on multichain infrastructure will continue to grow, particularly around security, standardization, and interoperability. The basis of competition is shifting with them. Bridge throughput alone no longer defines the frontier. What will matter from here is whether an infrastructure layer can bring validation models, token standards, chain integration, and common interfaces together into a single technology stack and provide an environment where production services and liquidity can operate reliably.
Key Source
Axelar Docs - General Message Passing Overview
Axelar Docs - Interchain Token Service
Axelar Docs - Interchain Amplifier Introduction
Axelar Blog - Mobius Development Stack Launch
Axelar Blog - Axelar Virtual Machine: The Future of Interoperability
Axelar Blog - OpenBridge & ERC-7786 Announcement
Axelar Network - Mobius Development Stack
Axelar Network - ITS Overview
Axelar Network - ITS for Liquid Staking Tokens
Axelar Network - Institutional Interoperability Whitepaper
OpenZeppelin - Introducing OpenZeppelin Contracts v5.2
Blockworks - Axelar Interchain Amplifier & Rollkit
CoinDesk - JPMorgan Apollo Tokenize Funds PoC
Deutsche Bank - DAMA 2 Litepaper
Disclaimer
The contents of this report are for informational purposes only and do not constitute a recommendation or basis for legal, business, investment, or tax advice under any circumstances. References to specific assets or securities are for informational purposes only and do not represent an offer, solicitation, or recommendation to invest. The final responsibility for any investment decisions lies solely with the investor, and this report should not be used as a guideline for accounting or legal judgment.
As a matter of principle, the author does not trade related assets using material non-public information obtained during the research or drafting process. The author and Catalyze may have financial interests in the assets or tokens discussed herein and may serve as a strategic partner to certain networks.
The opinions and analyses expressed in this report reflect the author's personal views and do not necessarily represent the official position of Catalyze or its affiliates. All information is current as of the date of publication and is subject to change without prior notice.