Expanding the Axelar Ecosystem: Ideas for Infrastructure Projects

As the Axelar network expands and the Axelar Virtual Machine (AVM) goes live (subject to governance approvals), building and managing connections to the network is becoming easier and easier.

Furthermore, programmability at the network layer allows us to code at both the control and data paths of interoperability across Web3. In this post, we summarize some infrastructure ideas for teams interested in engaging in back-end protocol and network development.

The initial roll-out of the AVM (powered by CosmWasm and Axelar’s cross-chain consensus logic) will include:

  • A set of template contracts that one can instantiate to build a new connection
  • A universal “router” contract that will forward messages across the connections at the VM and the consensus layers

Connection approval to the router is subject to network governance and proper due diligence on the technical aspects of each connection (such as security model, safety guards, code audits and maintenance) should be performed. EVM and a few custom chain connections are being worked on by Commonprefix, Eiger, Axelar and other ecosystem teams. But there are many more directions where we see demand from partners. Here are a few of them.

Automating connections into Ethereum L2 stacks

Each L2 ecosystem, such as Optimism, Arbitrum, ZKsync and Polygon multi-chain SDKs, is independently going multichain. We can automate integration of interoperability into those SDKs or offer extensions. Can we support one-click deployments of a new L2 rollup with integrated interoperability at launch? A simple approach would be to create deployment pipelines for those stacks that could leverage light clients (for instance) to automate the connection. For example, a ZKSync chain’s light client is deployed to the Axelar network to establish a connection upon instantiation. Only an external relayer is needed subsequently to relay packets.

Independent relayers between EVM and the Axelar network

As we expect the number of EVM chains and L2s to continue to grow, the need for reliable relayers continues to increase. The Axelar network already supports permissionless relay — anyone can post messages across chains — and a marketplace can be easily built on top of it. For example, a relayer can deploy a set of their own gas-service smart contracts to offer to application developers. Since only one relayer is strictly necessary (and a few for redundancy), the efforts on this forum should be coordinated across the ecosystem for practical business reasons. The initial relayers can focus on the EVM template contracts that will be deployed shortly after the launch of the AVM.

Connections to new types of chains

A number of efforts are in progress to connect to chains with alternative consensus or smart-contract logic (such as non-EVM). These often require more work, but the benefit of instantiating alternative-consensus chains to the Axelar network is that they get immediate access to all N interconnected chains. Security and operational management costs will also go down.

Cross-chain account abstraction

As ERC-4337 continues to expand, we should leverage it to power chain-agnostic experiences. One can envisage a service provider that sits above the relay layer and offers gas-abstraction services for end users, automatically converting tokens to execute cross-chain transactions as needed.

Interchain governance-as-a-service

The recently released Interchain Governance Orchestrator is a great example of tooling that helps developers simplify their contract management across multiple chains. Imagine submitting a single parameter change or contract upgrade on your governance chain and instantly having it execute across all other chains where the application is deployed. This is the power of interchain governance.

Some applications might benefit from interchain governance via the community of the Axelar network itself. For instance, suppose a developer doesn’t want to have a multisig manage their upgrades, but still needs an upgrade path to fix potential bugs. They can hook the Interchain Governance Orchestrator into their application to accomplish this. To execute an upgrade, they can post a governance request on the Axelar network to AXL token holders. If the token holders approve, the upgrade will execute on the developer’s application across all chains. This can benefit applications that do not have tokens on their own to manage governance, while greatly reducing security risks and overhead: a developer doesn’t have to build multisigs into their upgrade paths. Building this as a service around the network would be a highly valuable addition for multichain communities.

Custom logic hosted on the Axelar network

One of the key benefits of Axelar network’s hub-and-spoke architecture is that there is a shortest five-second transfer path to any other network: a transaction occurring on the Axelar network is instantly settled and can be relayed to other networks. A developer can host some part of their application logic on the Axelar network. Naming services are good examples of this. A unified registry mapping addresses to names could live in a common place and propagate to other chains efficiently.

Shared interchain oracles

A critical challenge in the Web3 space involves accessing off-chain data. Oracle networks have been the primary solution, but each blockchain is limited to its own network of oracle providers. This is a problem for smaller protocols, which do not have many oracles available to receive off-chain data.

Axelar network’s General Message Passing protocol can send arbitrary messages across blockchains, making it possible for chains with smaller oracle networks to receive and validate oracle-based data from chains with larger oracle pools, such as Ethereum and BNB. Some applications have already built custom cross-chain oracle integrations using GMP – like Junkyard, an NFT game built on Polygon that calls a random beacon on Chainlink. Application developers would benefit from an oracle service that provides data on all Axelar-connected chains, out of the box.

Interchain token-bound account

Using token-bound accounts (TBAs) based on the ERC-6551 standard is a popular new method for managing assets directly from an NFT. In other words, the NFT acts as a “backpack" to hold the assets. By connecting ERC-6551 TBAs to Axelar network, protocols that leverage TBAs would receive out-of-the-box interoperability. This could be a tremendous opportunity for gaming, where in-game assets can easily be transferred to another blockchain through an interoperable TBA.

Transaction optimizer

Gas fees are a headache-inducing aspect of a blockchain transaction. Axelar’s growing network of blockchains could be leveraged to create a tool that analyzes the gas costs, interactions and requirements of a transaction and executes it on the most resource-efficient chain. This would provide users peace of mind, knowing they are getting the lowest-possible rates for their transactions.

Interchain anti-miner-extractable-value (MEV) bot

In a (hopefully not-too-distant) future world where tens of thousands of blockchains exist with hundreds of thousands of transactions going between them every second, it will be critical to ensure the precise ordering of transactions between various interconnected networks. An anti-MEV bot could serve as a critical intermediary, orchestrating the optimal execution and sequencing of a transaction to minimize concerns such as front-running and arbitrage. Such a protocol could integrate with Axelar network, leveraging its interchain communication framework to facilitate secure and efficient interoperability.

Interchain locker

A service that uses Axelar network as an intermediary to enable secure and reversible interchain token transfers would add an extra layer of security for transfers between different blockchains. This could be critical for handling security incidents where hackers try to swap stolen funds into stablecoins.

Asset transfers across chains could be wrapped in smart contracts that enable time-locked, revocable transfers with additional Axelar-enabled checks. For high-value transfers, the contract could be designed to only release funds if there are no issues within a fixed time window. This would add oversight and the ability to cancel or revoke suspicious cross-chain transfers.

What will you build?

These are just some of the infrastructure ideas we see the community requesting. If you want to get started on any of them, here’s what to do next:

See the official Axelar documentation and access the latest devnet with CosmWasm (if you need smart contracts).
When you have an idea:

We’re looking forward to seeing what you’ll build.


Hello Sergey,

I’m Ayvee, from Governaxe.

We are building a modular governance layer, leveraging Axelar’s security and interoperability. We would love to hear your thoughts on the idea.

Each DAO requires varying conditions and logic, therefore we aim to create a modular governance layer that enables cross-chain voting and execution. We plan to have modular sets of smart contracts where DAOs put together their own governance layer tailored to whatever needs they may have.

1 Like