Tldr:

• We propose a concept of future-proof interoperability: developers easily customize multi-chain security, adapting to specialized needs and emerging technologies, without changing application logic.
• The key to understanding the framework is to decouple the layers of the interoperability stack: validation (security), transport (e.g., routing), and message semantics (the structure used to send packets from one network to another).
• Applications set up cross-chain capabilities using a fixed set of message semantics. The underlying validation and transport logic can evolve, allowing the application developer to choose and update their security approach as needed.
• Adopting new / customized security approaches is easy: many-to-many transport and routing facilitates fast connection of new validation sources to Axelar network; programmability at the network layer supports custom validation rules. Applications built on top can benefit from these improvements without additional changes.

The Internet was developed to achieve a robust communication network that can “withstand” disasters as big as nuclear attacks. Scientists and engineers debated various communication methods for decades, before landing on the TCP/IP framework. So, the need for interconnectivity in the web's first versions was addressed before anyone started using the TCP/IP stack for commercial purposes.

In the blockchain era, things are developing in reverse. Demand for cross-chain communication already exists. Its usage is growing, while technology is being built in parallel. This, unfortunately, resulted in dozens of centralized patch solutions being built over the last few years, and billions of dollars lost.

The only way to grow Web3 is if we learn how to build robust, decentralized, and scalable interoperability protocols that can last for decades to come.

How should developers build their interchain dApps, given the demand and evolving technology?

Besides security and robustness challenges, the architecture of interchain dApps needs to be revisited from the ground up. For instance, many token transfer applications suffer from strong path-dependency. An asset traveling along the path A → B is often different from the same asset if it travels along the path A → C → B. This is because applications need to rely on a specific gateway to authorize mint/burn/lock/unlock operations. A message traveling along one path often has a different authorization gateway than a message traveling along a different path. In blockchains, the source of a message is equivalent to establishing its root of trust. So it’s critical to pick the right “gateway” as the security of applications depends on them. (In contrast, TCP/IP does not offer any security by default; hence messages can arrive from any “gateway,” and it’s up to the application-level protocols sitting on top [like HTTPS] to establish secure communication channels, using cryptographic methods.)

To see how we can solve these problems and simplify interchain deployments, let’s first decouple layers of interoperability and define the notion of future-proof interoperability. Following that, we’ll show how the Axelar network is adaptable, allowing applications to configure security in ways that improve robustness of individual connections, while leveraging consistent message semantics and many-to-many routing properties. Then, we’ll discuss how to instantiate interchain tokens & dApp deployments following the principles of future-proof interoperability.

The 3 layers of blockchain interoperability

To understand how interoperability should evolve, it's useful to distinguish message semantics, validation, and transport.

• Message semantics simply refers to the structure of messages or packets (API) that applications can use to send messages from one network to another. They're simple and often include fields like source chain, source address, destination chain, destination address, and payload. Applications send and receive messages following the semantics.
• Validation refers to the trust layer. It may be instantiated using a direct light-client based connection, external validation, or any other technology. Application security holds, so long as the validation layer holds.
• Transport: the transport layer is responsible for determining the route from a source to the destination and following it. It’s defined by the routing properties (pairwise, many-to-many) and relaying mechanics (permissioned vs permissionless). It may rely on an on-chain routing table or an off-chain registry.

Clearly decoupling the interoperability layers allows us to define a notion of future-proof interoperability. In it, developers can build their dApps based on specific message semantics, while the underlying validation and transport layers can be adapted and improved over time. As technologies and needs evolve, no changes to the application logic need to be made to leverage the lower-level improvements.

More specifically:

• An application should be instantiated following a fixed set of message semantics. The message semantics for cross-chain communication should change as rarely as possible.
• Underlying interoperability protocols can upgrade to improve validation (e.g., external validation is replaced with light-client validation) or transport (e.g., a better routing path is found) and the application can automatically and immediately benefit from the changes.

Multi-path deployments

Compared to most interoperability “protocols” that offer pairwise connectivity, the Axelar network offers a many-to-many transport layer. That is, any connection to the Axelar network is automatically interoperable with all other interconnected blockchains. So at the cost of one integration, a protocol developer can access N connections.

We envisage multiple connectivity paths between the Axelar network and other networks relying on different validation methods. Application developers may choose paths according to their requirements and evolving technology, without changes to application logic.

Axelar, being a programmable blockchain, can easily support different connectivity methods. (Today, it already supports IBC and EVM via RPC-based consensus across validators and light-client deployments on EVM chains.) In the event new validation methods emerge or are desired, different paths can be instantiated by deploying additional Axelar Gateways on destination chains: dApps building with Axelar are not tied down to a single validator set or token for security.

These paths can be composed in various ways. For example, if external validation, light-client, and ZK-based validation are available, an application can choose to accept messages if and only if 2 / 3 paths (gateways) authorize the requests. Or, it may accept a message for low-value transfers from any of the paths, but higher-value transfers are accepted if and only if multiple paths authorize the messages.

Paths of connectivity essentially establish new validation rules. And any new validation path can immediately benefit the developers with potentially better security properties, and leverage the underlying transport layer to route messages to all other interconnected chains. Programmability in the Axelar blockchain enables routing and integration that delivers superior flexibility and (potentially) redundancy to applications choosing to customize validation paths, at a level that other interoperability networks cannot duplicate.

Next, we describe how to instantiate applications with future-proof interoperability for an interchain token and general interchain dApp deployments.

The interchain tokens

We describe multi-path instantiations as an example of asset transfers. For asset transfers, the problem of path-dependence has caused a lot of liquidity fragmentation and painful user experience. That is, a user transferring asset X along the path A → B often ends up with a different asset than if they were to take a path A → C → B, transferring the same asset. This applies to IBC and most other pairwise protocols. Interoperability hubs like Axelar solve this problem by having a canonical representation of an asset on every chain.

To take a step further, we show how to design an asset-transfer application with the following properties:

• Path-agnostic. All transfers along the paths trusted by the application and across all chains, result in the same asset X on the destination chain.
• Network-independent. Application developers wishing to further customize their security may declare multiple trust roots. For instance, the application may state "I trust Axelar Gateway I, II and III, but wish to authorize messages only if they're approved by 2 / 3 Gateways." The application may also replace Gateway addresses if new, better mechanisms are in place for validation at the network layer.

A simple design that meets both of the above constraints can be instantiated as follows:

• Interchain token contracts, ITC, are deployed across, say, all EVM chains, and have the same address, addr. (You can see how to do this using Axelar's constant address deployer service.)
• ITC links to an Auth contract. The Auth contract specifies gateways the token contracts trust and access policies around them (1 / 1 approval, 2 / 3 approvals, etc).

A message is trusted if and only if:

1. It arrives from a gateway (or a series of gateways) that are trusted by Auth contract, and
2. The sender address is the same as the receiver contract. (That is, by default, the token linker trusts "its own code," but additional trusted addresses may be included in the Auth contract.)

For non-EVM chains, additional (chain, address) tuples may be appended to condition (1) that do not share the same address with the destination contract. As new connections become available, the Auth contracts can be replaced or updated to authorize those connections.

Path-Agnostic dApp Deployments

Like interchain tokens, a general application can be deployed to benefit from multi-path validation and routing logic.

• An application is given multiple Gateways backed by different validation logic.
• An Auth contract can be instantiated to authorize validating gateways and approval policy. (Requests of form X require a single approval; requests of form Y require at least two approvers, etc.)
• As new paths are discovered, the application can authorize new connections or remove broken connections.

Note that Auth contracts need to support updates in this model. A secure way to instantiate these may include a combination of:

• Leveraging dApp token holders to add/remove new paths of connectivity via governance.
• Using an external offline committee.
• Adding time-based delays to the upgrade paths to prevent worst-case attacks.

Put together, applications can rely on fixed message semantics, while continuing to innovate at the application level. New paths of connectivity between the Axelar network and other networks can be instantiated based on different validation logic. All transactions are automatically routable across new and existing blockchain connections.

Finally, developers can compose security at the application level to rely on multi-path approvals based on different security models. Combined with decentralized upgrades to add/remove paths, this design leads to a long-term forward-compatible instantiation that can scale to interconnect the whole of Web3.