Status: Live on Mainnet

We’re thrilled to announce the launch of ITS Hub, a significant leap forward in blockchain interoperability. ITS Hub builds on the foundation of the Interchain Token Service (ITS) by introducing a central hub for routing token operations, improved security, scalability, and interoperability across a diverse range of chains, including EVM and non-smart contract ecosystems.

ITS Hub Contract

• ✨ CosmWasm-based contract on the Axelar network

• 🔐 Central routing hub for token transfers

• 🌉 Supports both Amplifier and consensus chains

• 🔄 Replaces peer-to-peer token transfer structure

Token Support

• ITS Tokens: Supported (with limitations)

  • Based on General Message Passing (GMP)

  • Minted, burned, and managed connected EVM chains

• Gateway Tokens: Not supported (future release)

What is ITS Hub?

ITS Hub is a CosmWasm-based contract on the Axelar network that serves as a central routing hub for all token transfers across Amplifier , consensus chains, and non-EVM chains like Sui and Stellar. This model replaces the peer-to-peer token transfer structure of the original ITS, enabling centralized balance tracking, rate limits, and streamlined security measures. By routing through ITS Hub, developers can bridge tokens while benefiting from enhanced interoperability across various blockchain ecosystems.

Key Features and Benefits

• Unified Token Routing

  All ITS-enabled chains route token transactions through the ITS Hub, enabling simplified bridging for diverse blockchain architectures, including EVM chains and non-smart contract chains like XRPL.

• Enhanced Security

  ITS Hub applies centralized balance tracking to prevent over-escrow and enforce invariants, while rate limits mitigate risks from compromised chains or contracts.

• Scalability and Interoperability

  ITS Hub supports ITS tokens, enabling seamless bridging across Amplifier chains, consensus chains, and non-smart contract ecosystems.

• Future Compatibility

  ITS Hub is designed to accommodate evolving features such as integrating GMP Express, Axelar, and Cosmos chains and permissionless EVM onboarding support.

• Support for ITS Tokens

  ITS tokens, based on Axelar’s General Message Passing (GMP), are minted, burned, and managed directly on connected EVM chains. Gateway tokens, however, are not supported in this iteration of ITS Hub.

How ITS Hub Works

ITS Hub introduces a dual GMP call mechanism for routing token transactions:

1. Source Chain to ITS Hub: The ITS Edge Contract sends a GMP call to the ITS Hub, wrapping the original payload.

2. ITS Hub to Destination Chain: The ITS Hub processes the payload, applies security measures, and forwards it to the ITS Edge Contract on the destination chain.

This design ensures robust state tracking and scalability across diverse chain architectures.

Rollout and Compatibility

ITS Hub supports Ethereum, Flow, and Sui for its initial release, with ongoing efforts to integrate Stellar, Ripple, Solana, and others. Amplifier chains currently support token transfers to Ethereum and other Amplifier chains, with broader functionality planned for future iterations.

⚠️⚠️⚠️

• Custom ITS tokens are not supported in the current version.

• Transfers from Amplifier chains are currently limited to Ethereum and other Amplifier chains.

• Gateway Tokens integration is planned for future releases.

Upcoming Chain Support

• Stellar

• Ripple ("XRPL")

• Solana

• XRPL EVM sidechain

• Hyperledger

Migration

The ITS Hub architecture is designed for seamless integration with existing systems while preparing for future enhancements. Current ITS users can continue using the peer-to-peer system, with migration paths being developed for routing through ITS Hub in future updates.

What’s Next?

As Axelar continues to expand its ecosystem, ITS Hub will play a pivotal role in cross-chain interactions. Upcoming features include:

• Broader blockchain support for Amplifier and non-smart contract chains.

• Integration with GMP Express for faster message passing.

• Migration tools for existing P2P ITS connections to adopt ITS Hub.

Resources and Documentation

• ITS Hub Documentation

• Interchain Token Service

• General Message Passing (GMP) Overview

• Axelar Amplifier

If you have any questions or need assistance, please open an issue in our support repository. We're here to help!

As the year began, there was a focus on bridging Web3 gaming and staking solutions, laying out roadmaps for the months ahead. By December (this year), significant mainnet milestones were celebrated, groundbreaking stack components were introduced, integration with leading ecosystems was achieved, and a thriving developer community was witnessed. Let’s look back at a transformative year.

TLDR

• In 2024, Axelar advanced multichain interoperability, connecting over 69 chains.

• Launched the Mobius Development Stack, enhancing blockchain connectivity.

• Integrated with the Immutable ecosystem and enabled Liquid Staked ETH transfers to BNB Chain.

• Introduced Interchain Token Service (ITS) and the Interchain Amplifier.

• Launched the Axelar developer blog.

• Enhanced developer tools and community engagement through workshops and educational content.

• Surpassed 2 million cross-chain transactions.

• Integrated Flow and Hedera with the Interchain Amplifier.

• Sponsored events like ETHGlobal Bangkok and hosted Amplify Bangkok, showcasing innovative projects.

In January, integration with Immutable was achieved, enabling Liquid Staked ETH (wstETH) transfers to the BNB Chain while unveiling a roadmap featuring the Axelar Virtual Machine, Interchain Amplifier, and Interchain Tokens. Axelar was also announced as a partner to integrate with the Monad blockhain. February saw the launch of the Interchain Token Service on the mainnet, allowing the creation and registration of multichain tokens. By March, Axelar introduced the Interchain Amplifier concept, using CosmWasm and other innovations to build a chain-agnostic, decentralized cross-chain infrastructure.

Major Developments

• Launched Interchain Token Service (ITS) on mainnet (February).

• Established a partnership with Immutable for multichain GameFi.

• Established a partnership with Monad.

• Integrated with Lido DAO, bringing wstETH to BNB Chain.

• Released 2024 roadmap outlining ambitious platform expansion.

Technical Updates

• Released comprehensive guides for Interchain Token Service.

• Enhanced AxelarJS capabilities for gas services and debugging.

• Expanded developer documentation and tutorials.

• Integration with Moralis was introduced to enhance development tools.

Community Engagement

• Participated in ETH Denver Hacker House.

• Conducted multiple developer workshops.

• Launched new developer-focused educational content.

• Launched the Developer Blog

Q2 (April - June)

The second quarter marked significant progress in Axelar's technical infrastructure and developer tools. During Q2, Axelar accelerated its efforts toward seamless, permissionless interoperability. In April, the Interchain Amplifier was released on Devnet, featuring chain-agnostic message routing and CosmWasm integrations. In May, the Amplifier integrated with Rollkit, supporting sovereign blockchains and leading to a more developer-focused content strategy.

By June, tutorials on building multichain stablecoins were published, the Axelar Gas Service documentation was updated, and Foundry Axelar gmp example developer tools were improved with local testing support, fostering adoption and a strong technical ecosystem.

Major Developments

• Deployed Interchain Amplifier on devnet.

• Enhanced Remix (LearnETH) integration with multichain development tutorials.

• Expanded support for Polygon Amoy and Linea Sepolia on testnet.

• Reached significant cross-chain transaction milestones.

Technical Achievements

• Released new tutorials for cross-chain development.

• Enhanced IBC chain connectivity.

• Improved documentation for interchain messaging.

• Launched Farcaster Frame integration with Axelar GMP.

Community Growth

• Hosted multiple developer workshops.

• Expanded tutorial series for advanced token management.

• Enhanced support for multichain RWA development.

Q3 (July – September)

Q3 saw the development of core technologies and the expansion of cross-chain capabilities. Starting in July with the Interchain Amplifier’s testnet debut, developers could deploy multichain stablecoins and enhance token functionality with ITS.

In August, the Axelar network underwent its mainnet upgrade and announced a collaboration with OpenZeppelin to standardize key interoperability standards. By September, the Amplifier's infrastructure was live on the mainnet, and the Foundry Axelar GMP example repository included ITS examples. This positioned Axelar to offer unmatched flexibility and simplified cross-chain deployments as new integrations were introduced.

Major Developments

• Successfully upgraded mainnet to v1.0.2 (August 28).

• Launched OpenZeppelin integration.

• Advanced Interchain Amplifier to testnet.

• Released Multichain RWA lending tutorials.

Technical Progress

• The Foundry Axelar GMP example repository integrated Interchain Token Service.

• Implemented mainnet deployment for Amplifier.

• Enhanced network stability and performance.

• Introduced BatchRequest message type for granular transaction handling on the Network.

• Improved chain connectivity with new IBC-related queries.

Developer Resources

• Released new documentation for Amplifier verifier onboarding.

• Produced advanced ITS token integration tutorials.

• Expanded cross-chain development guides.

• Improved troubleshooting documentation based on developer queries and partner support.

Q4 (October – December)

In the final quarter of 2024, Axelar demonstrated its growth as a top interoperability platform. During Q4, Axelar broadened its reach with the October launch of the Mobius Development Stack (MDS). This allowed developers to combine on-chain and off-chain logic across various ecosystems, including the newly integrated Flow blockchain, under the Interchain Amplifier.

In November, events like Amplify Bangkok and ETHGlobal Bangkok highlighted Axelar’s community-driven innovation, with developers creating projects such as omnichain tokens and sovereign deployment tools.

Major Developments

• Launched Axelar's Mobius Development Stack (MDS).

• Integrated Flow blockchain with Interchain Amplifier.

• Surpassed 2 million cross-chain transactions.

• Connected to over 69 blockchain networks.

Events

• Hosted Amplify Bangkok alongside Devcon.

• Sponsored ETHGlobal Bangkok Hackathon.

• Showcased innovative projects, including Mooodeng, ETHVercel, and Swift Easy

  • Mooodeng: Mooodeng is an omnichain token solution integrating multiple cross-chain protocols, enabling seamless token transfers and interactions across blockchain ecosystems.

  • ETHVercel: ETHVercel enables the deployment of sovereign applications with ZK-powered location validation. It earns Proof of Deployment tokens (ERC-5192) while maintaining granular access control in a collaborative ecosystem.

  • Swift Easy: Swift Easy is a dual-ledger-based SWIFT extension for enterprise-grade cross-border payments.

  • Smooth Store: SmoothStore is a decentralized storage platform with seamless onboarding using EIP-7702 biometric authentication, enabling secure file storage via FaceID or fingerprint.

  • BS-ITC: BS-ITC enables cross-chain token transfers, facilitating a smoother user experience for decentralized ecosystems.

• Conducted more developer workshops

Technical Achievements

• Enhanced Interchain Token Service Capabilities.

• Expanded support for multiple blockchain ecosystems like the Flow blockchain and Hedera

Looking Forward to 2025

As a transformative 2024 concludes, Axelar stands more potent than ever in its mission to build the Internet of Blockchains. The foundation laid this year through the Mobius Development Stack, Interchain Amplifier, and strategic partnerships positions Axelar for continued growth and innovation in 2025.

Key areas of focus for the coming year include:

• Further expansion of blockchain network integrations. Integrating prominent non-evm chains such as Sui, Stellar, Solana, and XRP.

• Enhanced developer tools and resources.

• Continued advancement of cross-chain technologies.

• Deeper integration with emerging blockchain ecosystems

The achievements of 2024 demonstrate technological advancement and a commitment to building a more accessible and interoperable Web3 ecosystem. As 2025 begins, Axelar continues to lead in blockchain interoperability, enabling developers to create the next generation of cross-chain applications.

For more information about Axelar and to stay updated on future developments, visit Axelar Network or join our growing community on Discord and X (Twitter).

About Axelar: Axelar is the Web3 interoperability platform, delivering the shortest path to scale: an open stack to connect all blockchains. Adopters include Uniswap, Microsoft, and dozens of natively multichain startups, building applications to reach all blockchain users at once – 10X as many active users as the leading Web3 application environment.

This month, we're excited to share major progress and milestones in enhancing cross-chain interoperability with Axelar's Mobius Development Stack (MDS), unlocking a new omnichain design space for developers. We also highlight the Amplify Bangkok event, the ETHGlobal Bangkok Hackathon, and updates to our developer tools and documentation.

🆙 Axelar Network's 2024 Milestones - Progress Update

Axelar's Mobius Development Stack (MDS) has officially launched, and it's just the beginning of a new era in cross-chain interoperability. With MDS, developers can seamlessly connect to over 60 blockchain ecosystems—including Solana, Sui, and XRP Ledger—while maintaining secure and open properties end-to-end.

Deploying a token that natively exists across multiple chains, preserving unique features like governance rights or yield mechanisms everywhere it's used, or effortlessly integrating augmented security by bonding restaked ETH and BTC through partnerships with EigenLayer and Babylon. With Axelar MDS, these possibilities are now a reality, opening up a world of new opportunities for decentralized applications.

Key components like the Interchain Token Service (ITS) and Axelar Virtual Machine (AVM) are now live on mainnet, enabling no-code token creation and programmable interchain logic. Plus, our collaboration with OpenZeppelin is set to establish standardized, vendor-agnostic cross-chain communication interfaces, empowering developers to build multichain dApps from day one. Learn more.

🎉 Amplify Bangkok @ Devcon 2024

Amplify Bangkok brought together blockchain leaders, experts, and builders to explore cutting-edge advancements in interoperability, decentralized technologies, and cross-chain innovation. Hosted alongside Devcon, this event featured live debates, insightful talks from top industry speakers, and exciting networking opportunities. Keynote speakers included Andy from The Rollup, Camila Russo from The Defiant, Ed Felten from Arbitrum, and Georgios Vlachos from Axelar Protocol.

Missed it? Don’t worry —watch the video here.

🔬 ETHGlobal Bangkok Hackathon

We are excited to be a part of the ETHGlobal Bangkok Hackathon (November 15–17, 2024) by offering a bounty to developers from around the world who gathered in Thailand to explore solutions in interoperability, privacy, and decentralized systems. This event featured over 1,000 attendees, 68 protocols, and 61 workshops, with $750,000 in prizes across various categories, including Axelar's $4,000 bounty.

Here are some of the standout projects from the event:

• Mooodeng: Mooodeng is an omnichain token solution integrating multiple cross-chain protocols, enabling seamless token transfers and interactions across blockchain ecosystems.

• ETHVercel: ETHVercel enables the deployment of sovereign applications with ZK-powered location validation, earning Proof of Deployment tokens (ERC-5192) while maintaining granular access control in a collaborative ecosystem.

• Swift Easy: Swift Easy is a dual-ledger-based SWIFT extension designed for enterprise-grade cross-border payments.

• Smooth Store: SmoothStore is a decentralized storage platform with seamless onboarding using EIP-7702 biometric authentication, enabling secure file storage via FaceID or fingerprint.

• BS-ITC: BS-ITC enables cross-chain token transfers, facilitating a smoother user experience for decentralized ecosystems.

This hackathon was a fantastic opportunity for developers to experiment, collaborate, and showcase their ideas. We look forward to seeing more innovative projects in future hackathons—stay tuned for even more events in 2025!

For more about Axelar and how we are helping to build the "Internet of Blockchains," check out Axelar Network“

📚 New Tutorials, Docs, and More

We've just published several technical articles and documentation updates.

Axelar GMP / Amplifier

• Amplifier ampd 1.2: A daemon that is run by verifiers who form the decentralized group that vote on the truthfulness of cross-chain transactions.

• Multichain RWA Lending with Axelar GMP: how to build a multichain real-world asset lending platform using Axelar GMP.

• Manual Relaying Cosmos 2-way Calls: Learn how to manually relay Cosmos GMP 2-way calls

🎤 Catch up on any events you missed

Did you miss our recent talks? Here are some highlights:

• Multichain Gas Estimation & Optimisation with Axelar

• Axelar's Mobius Development Stack: Milestones + Progress

• Tracking and Troubleshooting with Axelarjs SDK and Axelarscan

📌 Stay Connected

We have a lot more planned for the upcoming months, so you won’t want to miss out.

• 🐦 Follow us on X (Twitter) to stay updated on upcoming developer content and live events.

• 💬 Join our Discord community for real-time discussions and support.

• 📰 Subscribe to the Axelar Developer blog to stay up to date on the latest Axelar news.

Thank you for being a part of the Axelar community. We can't wait to see what you'll build next!

About Axelar: Axelar is the Web3 interoperability platform, delivering the shortest path to scale: an open stack to connect all blockchains. Adopters include Uniswap, Microsoft, and dozens of natively multichain startups, building applications to reach all blockchain users at once – 10X as many active users as the leading Web3 application environment.

This month, we're excited to share major milestones in enhancing cross-chain interoperability. We've launched Axelar's Mobius Development Stack (MDS), unlocking a new omnichain design space for developers. Additionally, the Flow blockchain is now integrated with our Interchain Amplifier, expanding seamless connectivity across networks. We've also released updates to our developer tools and documentation.

🆙 Axelar's Mobius Development Stack

Axelar has introduced MDS, a suite of open tools and protocols that open up an entirely new omnichain design space. Now, applications can seamlessly connect to users and logic anywhere on the internet while maintaining verified and open properties end-to-end.

Imagine this: a user sends a message on Telegram that rebalances a vault on Sui, which then interacts with DeFi protocols on Arbitrum and even a private blockchain of a financial institution. With Axelar MDS, such integration isn't just possible—it's effortless. This level of interoperability opens up a world of new possibilities for decentralized applications.

If you're looking to build the next generation of omnichain dApps, Axelar MDS might just be the toolkit you need! Learn more.

🔬 Flow Blockchain Integration with Interchain Amplifier

We're excited to announce that Axelar has integrated the Flow blockchain with the Interchain Amplifier, expanding the horizons for developers building on Flow.

This integration enables seamless cross-chain communication and asset transfers via Amplifier between Flow and other connected networks. Now, you can leverage Axelar's secure cross-chain messaging protocols to enhance your Flow-based applications, making them interoperable with a broader ecosystem.

Curious? Get started here.

📚 New Tutorials, Docs, and More

We've just published several technical articles and documentation updates.

Axelar GMP

• Multichain RWA Lending with Axelar GMP: how to build a multichain real-world asset lending platform using Axelar GMP.

• Manual Relaying Cosmos 2-way Calls: Learn how to manually relay Cosmos GMP 2-way calls

ITS

• Cross-Chain Memecoins With Axelar: Learn how to deploy and use your cross-chain memecoin both via the no-code portal and the programmatic solutions.

• Token Manager Types: Learn how Token Manager contracts facilitate the connection between your interchain token and the Interchain Token Service (ITS).

🎤 Catch up on any events you missed

Did you miss our recent talks? Here are some highlights:

• Tracking and Troubleshooting with Axelarjs SDK and Axelarscan

• Axelar's Mobius Development Stack: Milestones + Progress

• A Hitchhiker’s Guide to Multichain dApps

📌 Stay Connected

We have a lot more planned for the upcoming months, so you won’t want to miss out.

• 🐦 Follow us on X (Twitter) to stay updated on upcoming developer content and live events.

• 💬 Join our Discord community for real-time discussions and support.

• 📰 Subscribe to the Axelar Developer blog to stay up to date on the latest Axelar news.

Thank you for being a part of the Axelar community. We can't wait to see what you'll build next!

What is ampd?

ampd is part of the Interchain Amplifier. It is a daemon that is run by verifiers who form the decentralized group that vote on the truthfulness of cross-chain transactions. ampd looks on-chain for polls and signing requests, and then checks independent sources for the truthfulness of transactions and votes on-chain.

What’s new?

Version 1.2 adds features and improves the debuggability of transactions:

• adds the ability to send tokens from a verifier using the underlying tofnd cryptographic library and keys

  • ampd send-tokens <TO_ADDRESS> <AMOUNT> <DENOM>

  • eg. ampd send-tokens axelar16dxsfhyegy40e4eqfxee5jw5gyy2xxtcw4t2na 1000000 uaxl

• verifiers can set a proxy address to receive rewards for contributions. Instead of going directly to the verifier, rewards will be paid to the address supplied. This depends on a future release of Rewards 1.1 on amplifier.

  • ampd set-rewards-proxy <PROXY_ADDRESS>

• more information about failures are presented to users

• the ability to configure the log level with RUST_LOG environmental variable

What’s next?

The team is continuing to work on the plugin architecture and the addition of support for new chain tech stacks.

To tackle these challenges, Axelar, the leading Web3 interoperability platform, has a feature called Axelar's General Message Passing (GMP), which offers an effective and scalable solution. It enables secure and efficient communication between blockchains beyond simple asset transfers.

To understand how Axelar's GMP can impact real-world scenarios, let's consider an example of how blockchain technology is already changing lives.

A farmer named Amani lives in a small village with acres of fertile land but can't get a loan from local banks because he lacks a traditional credit score. Now, think of Sarah, a tech entrepreneur in New York working on blockchain solutions. Their worlds seem far apart, but blockchain technology could connect them. Consider Goldfinch, a real-world example in the DeFi space. It allows borrowers from emerging markets to secure loans using real-world assets as collateral, funded by global investors who trust in blockchain's transparency. This system opens doors for people previously excluded from the financial system.

Now, imagine scaling this idea across multiple blockchains, each optimized for different strengths like speed, security, or low fees. A multichain platform could tap into the best of each world, creating a truly global lending ecosystem that operates 24/7, without borders, and with minimal friction.

In this guide, we'll explore how to build a multichain real-world asset lending platform using Axelar GMP. If you want to see the complete code, you can find it on GitHub here.

What is a Real-world Asset (RWA)?

A Real-World Asset (RWA) is a digital representation of a tangible or intangible asset that exists outside the blockchain ecosystem. These digital tokens symbolize ownership or rights to various types of assets, such as:

1. Real estate.

2. Commodities (e.g., gold, oil).

3. Fine art.

4. Intellectual property.

5. Financial instruments (e.g., stocks, bonds).

The process of creating these digital representations is called tokenization. This involves converting real-world assets into blockchain-based tokens. The following are the advantages of tokenization:

1. Increased liquidity: Assets previously difficult to divide or trade can now be easily bought and sold in smaller fractions.

2. Broader accessibility: Investors can access a wider range of assets with lower capital requirements.

3. Improved transparency: Blockchain technology provides a clear, immutable record of ownership and transactions.

4. Enhanced efficiency: Tokenization can streamline various processes by reducing administrative overhead and costs.

Prerequisites

• A good understanding of Solidity.

• A MetaMask wallet with FTM and Celo funds for testing. If you don’t have these funds, you can get FTM from the Fantom faucet and Celo from the Celo faucets.

• aUSDC faucet.

• Familiarity with the remix.ethereum.org portal.

Before we get started, let's outline what we'll be doing and why each component is important for our multichain RWA lending platform:

1. MockRWAToken: This contract will simulate a tokenized real-world asset. For our demonstration, we'll create a simplified version that allows us to mint and transfer tokens.

2. RWAOracle: This contract will act as a price feed for our RWA tokens. For our purposes, we'll create a simple oracle that allows us to set and update asset values manually.

3. LendingPool: This is the core contract of our platform. It will handle the creation of loans, manage collateral, and facilitate cross-chain interactions using Axelar GMP.

By creating these contracts, we can simulate a simple RWA lending platform that works across different blockchains. This setup will let users, like our example farmer Amani, use their tokenized real-world assets as collateral, even if the lender is on another blockchain network.

Next, we'll start by creating the MockRWAToken. This will serve as the foundation for our platform, representing the tokenized real-world assets that can be used as collateral.

Create a Mock RWA Token

To begin your implementation, you’ll start by creating a MockRWAToken contract. This will serve as a representation of tokenized real-world assets.

• Navigate to remix.ethereum.org.

• Create a new folder named "contracts".

• Inside this folder, create a new file called MockRWAToken.sol.

Add the following code snippet to the file:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MockRWAToken is ERC721, Ownable {
    uint256 private _nextTokenId;

    constructor(
        address initialOwner
    ) ERC721("Mock RWA", "MRWA") Ownable(initialOwner) {}

    function safeMint(address to) public onlyOwner {
        uint256 tokenId = _nextTokenId++;
        _safeMint(to, tokenId);
    }
}

In the code snippet above, you:

• Created an ERC721 token contract named "Mock RWA" with the symbol "MRWA"

• Implemented a safeMint function that allows the contract owner to create new tokens

• Used OpenZeppelin's ERC721 and Ownable contracts for standard functionality and access control

In the next step, you will create the RWAOracle contract, which will provide price information for your tokenized assets. This oracle will help determine the value of the assets used as collateral in your lending platform.

Create a Mock RWA Oracle

In your contracts folder, create a new file named RWAOracle.sol add the following code snippet:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";

// RWA Oracle
contract RWAOracle is Ownable {
    constructor(address initialOwner) Ownable(initialOwner) {}

    mapping(uint256 => uint256) private rwaValues;

    event RWAValueUpdated(uint256 indexed tokenId, uint256 value);

    function updateRWAValue(
        uint256 _tokenId,
        uint256 _value
    ) external onlyOwner {
        rwaValues[_tokenId] = _value;
        emit RWAValueUpdated(_tokenId, _value);
    }

    function getRWAValue(uint256 _tokenId) external view returns (uint256) {
        return rwaValues[_tokenId];
    }
}

This contract provides two key functions:

• updateRWAValue: Allows the contract owner to set or update the value of an RWA token.

• getRWAValue: Retrieves the current value of a specific RWA token

In a production environment, this oracle would connect with real-world data sources to provide accurate, up-to-date asset valuations. For our demonstration, this simplified version is enough to show the main features of our lending platform.

Next, you'll create the LendingPool contract, which will connect the MockRWAToken and RWAOracle to enable cross-chain lending operations.

Create the Lending Pool Contract

Now that you have your MockRWAToken and RWAOracle ready, you can move on to creating the LendingPool contract. In your contracts folder, create a new file named LendingPool.sol.

Import Necessary Contracts

Add the following code snippet to import the necessary contracts.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

// Import required OpenZeppelin contracts
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol";

// Import Axelar contracts for cross-chain functionality
import "@axelar-network/axelar-gmp-sdk-solidity/contracts/executable/AxelarExecutable.sol";
import "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol";

// Import our custom RWAOracle contract
import "./RWAOracle.sol";

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    // Contract code here

}

Add State Variables, Structs, and Events

//...

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

        // Main contract interfaces
        IERC20Metadata public lendingToken;
        ERC721 public rwaToken;
        RWAOracle public rwaOracle;
        IAxelarGasService public immutable gasService;

        // Constants for loan parameters
        uint256 public constant LIQUIDATION_THRESHOLD = 150;
        uint256 public constant INTEREST_RATE = 5;

        // Cross-chain source information
        string public sourceAddress;
        string public sourceChain;

        // Loan struct to store loan information
        struct Loan {
            uint256 amount;
            uint256 collateralId;
            uint256 startTime;
            uint256 duration;
            address borrower;
            bool isActive;
        }

        // Mapping to store loans by ID
        mapping(uint256 => Loan) public loans;
        uint256 public nextLoanId;

        // Events for various loan actions
        event LoanCreated(uint256 loanId, address borrower, uint256 amount, uint256 collateralId);
        event LoanRepaid(uint256 loanId);
        event LoanLiquidated(uint256 loanId, address liquidator);
        event CrossChainLoanRepaid(uint256 loanId);
        event CollateralReleased(uint256 loanId, uint256 collateralId, address borrower);
}

In the code above, you:

• Defined key contract components: tokens, oracle, loan parameters

• Created Loan struct to store loan information

• Created events for contract actions like LoanCreated, LoanRepaid, LoanLiquidated, CrossChainLoanRepaid, CollateralReleased

Ignore the red lines showing on your remix right now; you will fix it in a bit.

Implement the Constructor

//...
contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...

    constructor(
        address _initialOwner,
        address _gateway,
        address _gasService,
        address _lendingToken,
        address _rwaToken,
        address _rwaOracle
    ) AxelarExecutable(_gateway) Ownable(_initialOwner) {
        // Initialize contract components
        gasService = IAxelarGasService(_gasService);
        lendingToken = IERC20Metadata(_lendingToken);
        rwaToken = ERC721(_rwaToken);
        rwaOracle = RWAOracle(_rwaOracle);
    }

}

In the code above, you implemented the constructor, set up the contract with the necessary addresses, and initialized the inherited contracts.

Next, you will proceed to implement the main functions, starting with a function to initiate a multichain loan.

Create a Multichain Loan Function

This function allows users to initiate a loan on a different blockchain using their RWA token as collateral. To do this, add the following code to your LendingPool contract:

//...
contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...

    function initiateCrossChainLoan(
        string memory destinationChain,
        string memory destinationAddress,
        uint256 _amount,
        uint256 _collateralId,
        uint256 _duration
    ) external payable {
        // Ensure gas payment is provided
        require(msg.value > 0, "Gas payment is required");

        // Check if the sender owns the RWA token
        require(
            rwaToken.ownerOf(_collateralId) == msg.sender,
            "Not the owner of the RWA"
        );

        // Verify collateral value is sufficient
        uint256 collateralValue = rwaOracle.getRWAValue(_collateralId);
        require(
            (collateralValue * 100) / _amount >= LIQUIDATION_THRESHOLD,
            "Insufficient collateral"
        );

        // Prepare payload for cross-chain message
        bytes memory payload = abi.encode(
            msg.sender,
            _amount,
            _collateralId,
            _duration
        );

        // Pay for gas on the source/destination chain
        gasService.payNativeGasForContractCallWithToken{value: msg.value}(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            lendingToken.symbol(),
            _amount,
            msg.sender
        );

        // Transfer collateral to this contract
        rwaToken.transferFrom(msg.sender, address(this), _collateralId);

        // Transfer lending tokens to this contract
        lendingToken.transferFrom(msg.sender, address(this), _amount);

        // Approve gateway to spend lending tokens
        lendingToken.approve(address(gateway), _amount);

        // Initiate cross-chain call with token transfer
        gateway().callContractWithToken(
            destinationChain,
            destinationAddress,
            payload,
            lendingToken.symbol(),
            _amount
        );
    }
}

In the code snippet above, you:

• Implemented verification of gas payment for cross-chain operation

• Check ownership of the RWA token and ensure collateral value meets the liquidation threshold

• Prepared the payload for cross-chain messages and paid for gas on the source/destination chain

• Transferred RWA token (collateral) to the contract using the transferFrom

• Transferred lending tokens to the contract with the transferFrom method and approved the gateway to spending lending tokens by calling the approve method

• Finally, Initiated the cross-chain call using callContractWithToken

Create Repay Cross-Chain Loan Function

When a cross-chain loan is initiated and collateral is received, users need to repay the loan when they are ready. To achieve this, you will implement the loan repayment function.

In the contract, create a function named repayCrossChainLoan that accepts _loanId, destinationChain, and destinationAddress to repay the loan.

To do this, add the following code snippet below:

//...

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...
    function repayCrossChainLoan(
        uint256 _loanId,
        string memory destinationChain,
        string memory destinationAddress
    ) external payable nonReentrant {
        // Ensure gas payment is provided
        require(msg.value > 0, "Gas payment is required");

        // Retrieve loan details
        Loan storage loan = loans[_loanId];

        // Verify loan status and borrower
        require(loan.isActive, "Loan is not active");
        require(loan.borrower == msg.sender, "Not the borrower");

        // Calculate total repayment amount
        uint256 interest = calculateInterest(
            loan.amount,
            loan.startTime,
            loan.duration
        );
        uint256 totalRepayment = loan.amount + interest;

        // Transfer repayment amount from borrower
        require(
            lendingToken.transferFrom(
                msg.sender,
                address(this),
                totalRepayment
            ),
            "Transfer failed"
        );

        // Mark loan as inactive
        loan.isActive = false;

        // Prepare payload for cross-chain message
        bytes memory payload = abi.encode(
            _loanId,
            loan.collateralId,
            loan.borrower
        );

        // Pay for gas on the destination chain
        gasService.payNativeGasForContractCallWithToken{value: msg.value}(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            lendingToken.symbol(),
            loan.amount,
            msg.sender
        );

        // Initiate cross-chain call to release collateral
        gateway().callContract(sourceChain, sourceAddress, payload);

        // Emit event for cross-chain loan repayment
        emit CrossChainLoanRepaid(_loanId);
    }
}

In the code snippet above, you:

• Implemented a check for gas payment to cover cross-chain operation costs

• Retrieved and verified the loan details, ensuring the loan is active, and the caller is the borrower

• Calculated the total repayment amount, including interest, using the calculateInterest function

• Transferred the repayment amount from the borrower to the contract using transferFrom

• Marked the loan as inactive after successful repayment

• Prepared a payload for the cross-chain message, including loan ID, collateral ID, and borrower address

• Utilized the gasService to pay for gas on the source/destination chain, ensuring smooth cross-chain operation

• Initiated a cross-chain call using gateway.callContract to trigger collateral release on the source chain

• Emitted a CrossChainLoanRepaid event to log the successful repayment

In the step above, you called the calculateInterest function, but it hasn't been implemented yet. Let’s do that in the following step.

Implement Interest Calculation Function

This function calculates the interest for a loan based on the loan amount, start time, and duration.

//...

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...

    function repayCrossChainLoan(){
    //...
    }

    function calculateInterest(
        uint256 _amount,
        uint256 _startTime,
        uint256 _duration
    ) public view returns (uint256) {
        uint256 timeElapsed = block.timestamp - _startTime;

        // Cap the time elapsed to the loan duration
        if (timeElapsed > _duration) {
            timeElapsed = _duration;
        }

        // Calculate interest: (amount * rate * time) / (365 days * 100 * 10^decimals)
        // For a 5% annual rate
        uint256 interest = (_amount * 5 * timeElapsed) / (365 days * 100);

        // Adjust for token decimals (assuming 6 decimals for USDC)
        return interest / 1e6;
    }
}

In the code snippet above, you:

• Calculated the time elapsed since the loan started using block.timestamp

• Implemented a cap on the elapsed time to ensure it doesn't exceed the loan duration

• Computed the interest using a formula that accounts for a 5% annual rate: (amount * rate * time) / (365 days * 100)

• Adjusted the calculated interest for token decimals, assuming 6 decimal places for USDC

• Returned the final interest amount

Next, you will implement the _executeWithToken to handle transferring the loan amount to the borrower.

Create the _executeWithToken Function

In this step, you'll implement the _executeWithToken function that manages cross-chain token transfers and loan creation on the destination chain. This function is essential for completing the cross-chain loan process.

//...

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...
    function _executeWithToken(
        bytes32 commandId, 
        string calldata _sourceChain,
        string calldata _sourceAddress,
        bytes calldata payload,
        string calldata tokenSymbol,
        uint256
    ) internal override {
        // Verify that the received token matches the lending token
        require(
            keccak256(bytes(tokenSymbol)) ==
                keccak256(bytes(lendingToken.symbol())),
            "Invalid token"
        );

        // Store the source chain and address
        sourceAddress = _sourceAddress;
        sourceChain = _sourceChain;

        // Decode the payload to extract loan details
        (
            address borrower,
            uint256 _amount,
            uint256 _collateralId,
            uint256 _duration
        ) = abi.decode(payload, (address, uint256, uint256, uint256));

        // Create a new loan internally
        uint256 loanId = _createLoanInternal(
            borrower,
            _amount,
            _collateralId,
            _duration
        );

        // Transfer the loan amount to the borrower
        require(lendingToken.transfer(borrower, _amount), "Transfer failed");

        // Emit an event for the created loan
        emit LoanCreated(loanId, borrower, _amount, _collateralId);
    }
}

In the code snippet above, you:

• Verified that the received token symbol matches the lending token symbol using keccak256 hash comparison

• Stored the source chain and address for future reference

• Decoded the payload to extract loan details, including borrower address, loan amount, collateral ID, and loan duration

• Created a new loan internally by calling the _createLoanInternal function with the extracted details

• Transferred the loan amount to the borrower using the transfer method of the lending token

• Emitted a LoanCreated event with the new loan's details

In the implementation above, you called the _createLoanInternal function, but it hasn't been implemented yet. Let’s do that in the following step.

Implement _createLoanInternal Function

The _createLoanInternal function is a helper function used to create a new loan with the internal type that returns the loan ID.

//...

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...
    function _createLoanInternal(
        address borrower,
        uint256 _amount,
        uint256 _collateralId,
        uint256 _duration
        ) internal returns (uint256) {
            // Generate a new unique loan ID
            uint256 loanId = nextLoanId++;

            // Create a new Loan struct and store it in the loans mapping
            loans[loanId] = Loan({
                amount: _amount,          // The amount of the loan
                collateralId: _collateralId,  // ID of the collateral RWA token
                startTime: block.timestamp,   // Current time as the loan start time
                duration: _duration,      // Duration of the loan
                borrower: borrower,       // Address of the borrower
                isActive: true            // Mark the loan as active
            });

            // Return the newly created loan ID
            return loanId;
    }
}

In the code snippet above, you:

• Generated a new loan ID by incrementing the nextLoanId counter

• Created a new Loan Struct with the provided parameters and additional details:

  • Set the loan amount, collateral ID, and duration as provided

  • Recorded the current timestamp as the loan's start time

  • Set the borrower's address

  • Marked the loan as active

• Stored the new loan in the loans mapping using the generated loan ID

• Returned the new loan ID

You're almost done! It's great to see you've made it this far in the tutorial.

Implement _execute Function for Incoming Cross-chain Message

This _execute function is automatically called by the Axelar relayers. It decodes the incoming payload and releases the collateral to the borrower on the source chain. Add the following code snippet to your contract.

//...

contract LendingPool is AxelarExecutable, ReentrancyGuard, Ownable {

    //...
    function _execute(
        bytes32,
        string calldata,
        string calldata,
        bytes calldata payload
    ) internal override {
        (uint256 loanId, uint256 collateralId, address borrower) = abi.decode(
            payload,
            (uint256, uint256, address)
        );

        // Release the collateral
        rwaToken.transferFrom(address(this), borrower, collateralId);

        emit CollateralReleased(loanId, collateralId, borrower);
    }
}

In the next step, you will test the contract using Fantom and Celo in this tutorial. However, feel free to use any network you prefer.

Testing the Lending Pool Contract

You will test all the contracts you have built during this tutorial. To proceed, deploy and mint mock RWA tokens to the specified address.

Deploy Mock RWA Token

You will deploy the mock RWA Token on the Fantom network. Click on the MockRWAToken.sol file and go to the deploy section, as shown below.

Next, click Transact and specify your address.

After deployment, you should be able to see the transaction chain similar to this. in the next step you will mint tokens to your preferred address.

Mint RWA tokens

Scroll down to the deploy section on Remix, as shown below, to use the safeMint method. Mint the token to the specified address and click on transact.

Check out the transaction here. Your transaction should look similar. To confirm, you can use the balanceOf method to verify, as shown below, where you can see the specified address has a balance of 1.

Next, you will deploy the RWAOracle contract, which simulates the Oracle price feed flow.

Deploy RWAOracle Contract

To deploy the RWAOracle contract, navigate to the RWAOracle.sol file on the Fantom network and deploy the contract as shown below.

After deploying, you should have a transaction on-chain similar to this on the Fantom network.

Set RWA Token Value

Next, set the RWA token value of the token you minted in the previous step. as shown below. The _tokenId is 0 (this is the first token minted), _value should be set to 20000000 which is 20×10^6.

After updating the RWA token value, you should have a transaction on-chain similar to this.

Deploy the Lending Pool Contract on the Fantom Testnet

Deploying the LendingPool contract is similar to how you deployed the other contracts earlier in this tutorial. Go to the lending pool contract file, click on the deploy section, and enter the following details as arguments for the contract. Then, click transact to deploy the contract on the Fantom testnet.

_initialOwner: 0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C // Replace with your address
_gateway: 0x97837985Ec0494E7b9C71f5D3f9250188477ae14
_gasService: 0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6
_lendingToken: 0x75Cc4fDf1ee3E781C1A3Ee9151D5c6Ce34Cf5C61
_rwaToken: 0x1C84e5556301202e6f6d4826Be5e13265E48ee17
_rwaOracle: 0x57d6A23A9cD2A719A8da3e47b402c0E88AB6036E

The _initialOwner is the address of the account that minted the token. You can find the _gateway and _gasService addresses in the Axelar documentation here. This lendingToken is the aUSDC asset that the user will lend. For the Fantom network, scroll down on this page to the Assets section and copy the aUSDC contract address on Fantom.

You can find the transaction link here.

Deploy the Lending Pool Contract on the Celo Testnet

Since this tutorial focuses on multichain lending, you will work with contracts on both the Fantom Testnet and the Celo Testnet. You will also deploy the contract on Celo before testing the cross-chain lending feature. Follow the same steps you used to deploy on the Fantom Testnet.

_initialOwner: 0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C // Replace with your address
_gateway: 0xe432150cce91c13a887f7D836923d5597adD8E31
_gasService: 0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6
_lendingToken: 0x254d06f33bDc5b8ee05b2ea472107E300226659A
_rwaToken: 0x1C84e5556301202e6f6d4826Be5e13265E48ee17
_rwaOracle: 0x57d6A23A9cD2A719A8da3e47b402c0E88AB6036E

The _initialOwner is the address of the account that minted the token. You can find the _gateway and _gasService addresses in the Axelar documentation here. This lendingToken is the aUSDC asset that the user will lend. For the Celo test network, scroll down on this page to the Assets section and copy the aUSDC contract address on Celo.

You can find the transaction link here.

The next step is to initiate the cross-chain loan. Before doing that, you need to approve the lending pool contract address on the MockRWAToken contract on the Fantom testnet to allow the transfer of the asset from the user.

Approve the Lending Pool Contract Address on MockRWAToken on the Fantom Testnet

Navigate to the MockRWAToken Deployment as shown below and click on approve, then specify the contract address.

Please switch your network back to the Fantom testnet from Celo and then click the “transact” button.

After approval is successful, you should have the transaction onchain similar to this.

Approve Lending Pool Contract to Spend the Asset to Be Borrowed

In the lending pool contract, there is an implementation inside the initiateCrosschainLoan function. You must approve the LendingPool contract address on the lending token contract (the asset you want to lend out).

The asset you are using is aUSDC. If you don't have it, please request it on our Discord channel here by going to the faucet channel and asking for it for free.

//...

// Transfer lending tokens to this contract
lendingToken.transferFrom(msg.sender, address(this), _amount);

Go to the Axelar documentation here, scroll down to the asset section, and click on the aUSDC contract address on Fantom.

Go to the "Contract" tab, click on "Write Contract," and then connect your wallet by clicking on "Connect to Web3," as shown below.

Enter the lending pool contract address and the amount to be approved; for example, 0xE9D662dd2E4A479C2559bec1685b1BA4C4Ee24E1 and 50000000, which equals 50 × 10^6 since it is in aUSDC.

Link to the approval transaction here.

One last thing before you call the initiateCrosschain function, you need to fund the destination contract so it can loan the user the required asset.

Here's how it works: If the user triggers the initiate cross-chain loan function from the source chain (Fantom) and reaches the destination chain (Celo), the _executeWithToken function in the contract will be triggered automatically. This is where you implement sending the asset the user wants to lend and fund the contract with the asset in the following step.

Fund the Destination Contract with the Asset to be Borrowed

To fund the contract on the destination chain (Celo), you can either request the asset on Axelar Discord to be sent directly to the contract address or transfer it from your account. Let's transfer it from an account as shown below.

Next, proceed to initiate the cross-chain loan. Here is the transaction link.

Call initiateCrossChainLoan on the Lending Pool Contract on Fantom Network

To initiate the cross-chain loan request, navigate to the lending pool deployment on Remix as shown below and enter the following details.

destinationChain: celo
destinationAddress: 0x36365FbCB839E309226d4f488310CcA3feDB91f4
_amount: 5000000 // 5 aUSDC
_collateralId: 0
_duration: 3600

Next, click “transact”.

Next, add gas value.

Transaction hash on the Fantom testnet is available here. You can also view it on Axelarscan here.

Congratulations! You have successfully initiated a cross-chain loan from the Fantom testnet to Celo. How does that feel? Great, right?

Next, you need to repay the loan, which is the typical process of lending.

Call repayCrossChainLoan on Lending Pool Contract on Celo Tesnet

One of the most interesting things about cross-chain activities or processes with Axelar GMP is that you can implement any custom functionality, like initiating a loan from one chain, repaying the loan from that same chain, or repaying the loan on the destination chain where the asset was used, and vice versa.

You must approve the LendingPool contract address to be able to transfer the amount the user wants to repay from the user's account to the address.

Go to the Axelar documentation here, scroll down to the asset section, and click on the aUSDC contract address on Celo.

Go to the "Contract" tab, click on "Write Contract," and then connect your wallet by clicking on "Connect to Web3," as shown below.

Link to the approval transaction.

To repay the loan, navigate to the lending pool deployment contract section on Celo Remix and add the following details.

_loadId: 0
destinationChain: Fantom
destinationAddress: 0xE9D662dd2E4A479C2559bec1685b1BA4C4Ee24E1

Next, add gas value.

Please switch your network back to the Fantom testnet from Celo and then click the “transact” button.

Transaction hash on the Celo testnet is available here. You can also view it on Axelarscan here.

Woohoo! You have successfully repaid the loan and completed the entire process. If you check the transaction details page, you will notice the collateral has been released, as shown below.

Conclusion

In conclusion, integrating Axelar's General Message Passing (GMP) into a multichain Real-World Asset (RWA) lending platform offers a transformative approach to decentralized finance. The practical implementation of tokenized real-world assets, as demonstrated through the creation of smart contracts like MockRWAToken, RWAOracle, and LendingPool, showcases the potential for a more inclusive financial ecosystem.

This system empowers individuals, such as our hypothetical farmer Amani, to leverage their assets for financial growth, regardless of geographical or traditional banking limitations.

References

• Axelar General Message Passing (GMP)

• Real-World Asset (RWA)

• Testnet Asset

Memecoins have always been a part of the industry, but have recently been thrust into the spotlight these past few months with what people are calling memecoin-mania. Like any token on the market, the amount these memecoins can grow is limited to the number of holders it can reach. If the token is deployed on a single chain its available demand is limited to the community of that blockchain. With the emergence of Axelar’s Interchain Token Service (ITS), memecoin creators now can create a natively cross-chain memecoin easier and quicker than has ever been done before.

ITS is a permissionless cross-chain token bridging service that allows users to deploy new cross-chain tokens and integrate live tokens to enable cross-chain functionality. It has a smart-contract deployed on nearly two dozen EVM chains that users can interact with to integrate and bridge their token. For a quicker integration, there is also a no-code solution (testnet portal) that users can integrate with as well. The rest of this blog will show you how to deploy and use your cross-chain memecoin both via the no-code portal and the programmatic solutions.

Memecoin With ITS Portal

The most simple way to get your cross-chain memecoin deployed on multiple chains with built-in cross-chain functionality is through the portal. The portal is a free permissionless UI that interacts with the ITS contract. It gives you the option to deploy a fresh new token or integrate an existing token. Let’s go with the new token option. You can now fill out the token registration form.

This requires the token’s name, symbol, decimal points, and total supply. While these parameters are relatively self-explanatory the mintable toggle is less so. The mintable toggle will allow you to set a “minter” address that can mint the token, since this is a memecoin it is best-practice that this token does not have any address that can mint additional tokens beyond the initial supply that is being minted on deployment. The salt is a unique value, which along with the deployer’s address (ITS itself in this case) will be used to generate the interchainTokenId. This ID is the unique value for your interchain token as far as ITS is concerned on-chain. There can technically be other tokens with the same name and symbol but the ID will need to be unique.

Once the token parameters have been filled in you can select which chains you want to deploy on (in addition to the chain you have your wallet currently connected to).

You have the option to deploy to any of these chains (and many others as well) simultaneously. For now, you can just deploy on Immutable to keep gas costs at a minimum.

Once the token is deployed, you will find yourself on the token detail page where you will see all the relevant info for the token as well as the chains the token is deployed to. On this page, you can also deploy your token to other chains that you did not initially deploy on.

The token detail page shown above also provides a simple UI where you can interact with your token. For each chain your token is on with liquidity, you can send a cross-chain transfer between chains. In our case, the token only has liquidity on BNB. If the token was deployed with the mintable option toggle on, then you could also mint tokens.

The token that has been deployed from the portal is an Interchain Token. It contains all the standard functionality of an Open Zeppelin ERC20 with the addition of the interchainTransfer() functionality. Another added benefit is that the token is immediately verified on all the block explorers it is deployed to, which adds to the legitimacy of the memecoin in the eyes of the community.

Minting

In this example, since the token is not mintable the 1 Billion tokens that were minted upon creation are all that will ever be created. However, the token that is deployed still does have a mint() function. The reason for this is that when tokens are bridged between chains they are burned on the source chain and minted on the destination chain. If the token has no official minter then the only contract that can mint the token is the ITS contract itself. This does not pose any security threat for your memecoin to mint an infinite new supply of new tokens as the mint() function only exists to bridge the existing supply of tokens between chains, rather than to create fresh new tokens.

Adding Value

Now that your token is deployed successfully, you can create a liquidity pool for it on a Decentralized Exchange (DEX) so that it can receive some actual value. This can be done on any number of exchanges, we will use Pancake Swap.

DEXs allow users to swap tokens. They leverage pools of assets to generate a value for each token. For however many pools are in a given token the DEX uses a formula to calculate what each asset in the pool can be traded for.

For the memecoin all you have to do to give your token a starting value is to create a pool for your token alongside another token that already has an inherit value. Once you have funded that pool with the two tokens your memecoin will be given a value relative to the amount of liquidity supplied to the pool for the two tokens.

The memecoin so far is deployed on BNB and Immutable. Let’s create a liquidity pool on Pancake Swap’s BNB instance for the CCM memecoin with Binance’s native BNB token.

To do this go to the Add Liquidity page on Pancake Swap and ensure that your wallet is pointed to BNB’s testnet. You can then create a new pool for tBNB and your ITS token’s address by importing your ITS token on the Pancake Swap UI

Next, you can deposit funds into the new pool. You can deposit however many of the memecoins and BNB you want to the pool, depending on what you want the price of the memecoin to be. For this demo, we will deposit 75% of all minted memecoins to the pool along with 0.5 BNB. The DEX UI will show you the value of your memecoin relative to BNB before creating the token pair.

You can then submit the transaction to create your pair!

Once the transaction executes you will be able to swap your token on PancakeSwap for other tokens so that it has a real value.

Notice the CCM asset does not have an image being picked up by the DEX. This is beyond the scope of this tutorial but to do so you could add your token metadata to TrustWallet, which many DEX’s pull from to render token metadata.

Cross-Chain Token

Great! At this point, you have deployed an ITS-compatible token, which exists on both BNB and Immutable. The real magic though is the ability to send these tokens seamlessly between the two chains (and more chains as the CCM token is onboarded to new chains).

Stepping back into the ITS Portal you will see the token has been minted on the BNB home chain but there is a supply of 0 on the Immutable chain. The portal offers a simple one-click transaction experience where users can simply input the amount of tokens they want to transfer. Simply click the transfer button, which will allow you to transfer to any chain your token is deployed to. This will trigger a cross-chain transaction that can be viewed on the Axelarscan block explorer. When the transfer completes, the tokens will be burned on BNB and automatically minted on the Immutable chain. You’ve just migrated your tokens seamlessly!

Now that the token is on Immutable you can create a pool on a DEX there so that the token has a value on that chain as well. This adds more overall liquidity to your token as it will now be exposed to the communities on more than just the BNB chain, thus providing more opportunity for memecoin to increase in value.

Adding Value on Immutable

Similar steps can be taken to give the token value on Immutable as you did on BNB.

For Immutable you will need to use the Quickswap DEX to create a pool for the CMM token’s instance there.

This will follow a very similar flow to the path you used on PancakeSwap.

• Go to the pools page

• Import your memecoin by pasting in the address

• Select your fee tier

• Select your token’s price range

• Deposit your memecoin as long as an additional collateral (you can simply do IMX for Immutable) into the pool.

When you press the preview button, your pool should look as follows

Great! At this point, you should now have a fully functioning pool on the Immutable blockchain. Your memecoin is now operational and accruing value on both BNB and Immutable.

Why this matters

Now that your users can interact with your tokens on multiple blockchains the amount of users you can reach and liquidity that can be injected into your memecoin significantly increases with each new blockchain you deploy your token to. This can be as strategic as being an early memecoin adopter of a hot new layer two or reaching the large user base of more established blockchain ecosystems.

With your token operating on dexes across multiple blockchains the opportunity for lucrative arbitrage opportunities becomes available for your community. Your community can do the heavy lifting and earn substantial rewards in the process to ensure the price of your memecoin is consistent across chains. More creative teams can try to gamify this process to make their memecoin fun and unique compared to other non-cross-chain memecoins on the market.

Memecoin Programmatically

When going through the ITS Portal the token that will be created is an Interchain Token. For teams that want to have some more customization to the functionality of their token, they will need to integrate with the ITS contract programmatically. To do this you will need to call the deployTokenManager() function exposed by the ITS contract.

Before integrating with ITS the ERC20 memecoin must be deployed programmatically. This can be done via a foundry-based local repository or through a simple ERC20 deployment on Remix. Once the token is deployed and has an address you can integrate it with the ITS contract by calling the aforementioned deployTokenManager() function.

To call this function you need to pass in several parameters.

1. Salt: A unique identifier for your tokens deployment

   • This will be used to generate the interchainTokenId.

2. DestinationChain: The chain you are integrating your token on

   • If you’re not making a cross-chain call this can be an empty string.

3. TokenManagerType:

   • The type of token manager to be deployed. There are several types of managers, the recommended one for most integrations is the mint/burn token manager. More on Token Managers can be found here.

4. Params:

   • This is an encoding of your token’s operator and tokenAddress.

5. GasValue:

   • This is the amount of gas to pay for your cross-chain deployment. As with DestinationChain if you are deploying your token manager on the same chain (i.e. not a cross-chain call), this can be set to 0.

Once this function is called you will be returned your interchainTokenId

InterchainTokenId

The interchainTokenId is the unique identifier for your ITS token across all the different chains it is integrated with. It is how ITS will know which token across all chains your token corresponds to when burning it on one chain and minting on another.

This ID is created by hashing the address of the sender of the Token Manager deployer with the salt used in the Token Manager deployment. For this reason, it is critical to use the same deployer address across all ITS integrations so that the interchainTokenId is consistent across all chains for your token.

Interchain Transfer

Once your token is integrated and you have an interchainTokenId across several chains you can call the interchainTransfer() function to send cross-chain transactions for your token. This function is defined on the ITS contract but can also be added to your token if you prefer to send cross-chain transfers from the token itself.

It takes several parameters including;

1. TokenId: This is the interchainTokenId you received when you deployed the token manager.

2. DestinationChain: Name of the chain you are sending the token to.

3. DestinationAddress: Receiving address on the destination chain.

4. Amount: Amount of the tokens you are sending.

5. Metadata: (optional) Executable data to be sent alongside your token. Most likely not needed for more basic memecoin initiatives.

6. GasValue: Amount of gas you are sending to pay for the transaction. It should match the msg.value you're sending with the token transfer.

Once this function is called you should be able to see the cross-chain transaction be sent on Axelarscan.

For a more detailed example of how to integrate and send a custom cross-chain transfer, you can visit this example.

What’s Next?

Now that your memecoin is successfully deployed and bridgeable between different blockchains you can whitelist your token to Squid Router. Squid provides an easy-to-use cross-chain swapping experience for your token, it also plugs into many popular wallets such as Meta Mask. By whitelisting on Squid your users will have a one-click bridging experience.

In this blog, you went over how to deploy a cross-chain token both with the ITS Portal and programmatically by interacting with the ITS contract directly. You interacted with DEXes on multiple blockchains to assign a value to the token which on mainnet could prevent exciting arbitrage opportunities for users.

What may have once been an ordinary memecoin on one blockchain is now a unique cross-chai compatible memecoin with the ability to access any user in web3.

For more exciting technical tutorials pushing the limits of what can be done cross-chain check out the Axelar Developer Blog and the Axelar Examples repository. For more ITS tutorials check out the developer guides on the Axelar docs.

About Axelar: Axelar is the Web3 interoperability platform, delivering the shortest path to scale: an open stack to connect all blockchains. Adopters include Uniswap, Microsoft, and dozens of natively multichain startups, building applications to reach all blockchain users at once – 10X as many active users as the leading Web3 application environment.

This month, we're excited to share major milestones in our journey to enhance cross-chain interoperability, including the Interchain Amplifier on mainnet with integrations forthcoming and significant updates to our developer tools.

🆙 Axelar Network: Beyond What You Thought Possible

📅 Save the Date: October 3, 2024

We're preparing for a significant announcement that will redefine what's possible with blockchain interoperability. Mark your calendars for October 3, 2024, and stay tuned for an exciting reveal! Learn more.

🔬 Interchain Amplifier Deployed on Mainnet

We are super pumped to announce that the Interchain Amplifier service has been successfully deployed and instantiated on the mainnet. This deployment lays the foundation for enhanced cross-chain interoperability within the Axelar network.

What the Interchain Amplifier Offers

• Seamless Connection of Diverse Blockchain Consensus Engines

• Integration with Traditional Off-Chain Systems

• Minimal Developer Overhead

Key Components Include

• On-Chain Message Router

• Gateways

• CosmWasm Methods for Bidirectional Messaging

Current Status

• Deployment Completed: The Amplifier infrastructure is live on the mainnet.

• Integrations Pending: Active integrations with various chains are being developed and rigorously tested on the testnet to ensure stability and reliability before their mainnet deployment.

What This Means for You

Gain unprecedented flexibility in building cross-chain applications with reduced complexity. As integrations are finalized and proven on testnet, they will be seamlessly proposed and rolled out on mainnet, expanding your opportunities to leverage diverse blockchain ecosystems.

Curious? Get started with Amplifier here.

🛠️ Foundry Axelar GMP Example Now Supports Interchain Token Service (ITS) Integration

We're excited to announce that our Foundry Axelar General Message Passing (GMP) Example repository now supports the Interchain Token Service (ITS), making it easier than ever to build cross-chain applications.

What is the Interchain Token Service (ITS)?

Axelar's Interchain Token Service (ITS) is a solution that allows developers to create and manage tokens that operate seamlessly across multiple blockchain networks. With ITS, you can deploy tokens that are natively cross-chain, eliminating the complexities of manually bridging and wrapping tokens.

What's New in the Repository?

• Interchain Token Example: Learn how to deploy a brand-new interchain token using ITS.

• Canonical Token Deployment Example: Discover how to deploy a canonical token that serves as a single source of truth across chains.

• Interchain Custom Token Example: Explore how to create custom tokens with interchain functionality.

Why This Matters to You

• Simplify Multichain Token Development: Create tokens that work across different blockchain networks without juggling multiple codebases.

• Streamline Cross-Chain Interactions: Utilize Axelar's General Message Passing to interact effortlessly with contracts on other chains.

• Accelerate Your Development Process: Leverage ready-made examples and scripts to speed up building your cross-chain applications.

Check out the updated repository here: Foundry Axelar GMP Example.

📚 New Tutorials, Docs, and More

We've just published several relevant technical articles and documentation updates.

Amplifier

• Amplifier Roadmap: The Interchain Amplifier will be gradually rolled out in six phases, unlocking features like CosmWasm smart contract support, chain onboarding, relayer functionality, and ITS token transfers on the Axelar network.

• Verifier Security Expectations: Learn about the security expectations for verifiers in the Axelar network, including running full nodes, maintaining uptime, rotating keys, pulling rewards, supporting trustworthy chains, and participating in security drills and escalations.

• Add rewards for Amplifier chain integrators: Learn how to add funds to the rewards pool of an Amplifier-integrated chain.

ITS

• Token Manager Types: Learn how Token Manager contracts facilitate the connection between your interchain token and the Interchain Token Service (ITS).

🎤 Catch up on any events you missed

Did you miss our recent talks? Here are some highlights:

• A Hitchhiker’s Guide to Multichain dApps

• Build a Multichain RWA Lending Platform

• Building a Multichain Tax Contract with ITS

📌 Stay Connected

We have a lot more planned for the upcoming months, so you won’t want to miss out.

• 🐦 Follow us on X (Twitter) to stay updated on upcoming developer content and live events.

• 💬 Join our Discord community for real-time discussions and support.

• 📰 Subscribe to the Axelar Devblog to stay up to date on the latest Axelar news.

Thank you for being a part of the Axelar community. We can't wait to see what you'll build next!

To address this, developers have long relied on OpenZeppelin Governor, a widely trusted framework for on-chain governance. However, when paired with cross-chain functionality, the complexity increases. This is where Axelar's Interchain Governance Orchestrator steps in – a framework for governance actions across multiple chains.

To quickly get started and test the implementation directly, you can find the full code on GitHub here.

In this tutorial, you will learn how to:

• Build and deploy the following EVM smart contracts GovernanceToken, InterchainProposalSender, ThresholdContract, CrossChainGovernor.

• Send a governance proposal from a source chain to update a Threshold contract on a destination.

• Write test cases to test all the contract's functionality.

Prerequisites

• A basic understanding of Solidity and JavaScript.

• Familiarity with the OpenZeppelin Governor contract.

What is the OpenZeppelin Governor Contract?

The OpenZeppelin Governor contract is an on-chain governance system for decentralized protocols compatible with Compound's GovernorAlpha and GovernorBravo. It allows governance through token-based voting, where users delegate tokens to gain voting power. Proposals represent executable code changes; only users with sufficient voting power can submit them. Each protocol customizes voting periods and quorum thresholds.

The system includes optional features like proposal delays and timelocks, providing flexibility in governance processes. Unlike Compound's Governor, the OpenZeppelin Governor can function with or without a timelock.

Interchain Governance Orchestrator

Interchain Governance Orchestrator is a system that simplifies cross-chain governance for Web3 applications. It consists of two primary contracts:

1. InterchainProposalSender (on source chain): Encodes and sends proposals to other chains.

2. InterchainProposalExecutor (on destination chain): Receives and executes proposals on target contracts.

This system allows developers to manage governance across multiple chains more efficiently, reducing complexity and risk.

Getting started with Axelar General Message Passing

Axelar General Message Passing (GMP) empowers developers to call any function on interconnected chains seamlessly.

With GMP, developers gain the ability to:

1. Call a contract on chain A and interact with a contract on chain B.

2. All-in-one gas payment for cross-chain calls

3. Execute cross-chain transactions by calling a contract on chain A and sending tokens to chain B.

Project setup and installation

Create and initialize a project

Open up your terminal and navigate to any directory of your choice. Run the following commands to create and initiate a project:

mkdir interchain-governance-with-openzeppelin-governor-example
cd interchain-governance-with-openzeppelin-governor-example

npm init -y

Install Hardhat and the AxelarJS SDK

Install Hardhat, OpenZeppelin, hardhat toolbox, and the axelar-gmp-sdk-solidity with the following commands:

npm install --save-dev hardhat@2.14.0 @openzeppelin/contracts@4.9.0 @axelar-network/axelar-gmp-sdk-solidity@5.10.0 @nomicfoundation/hardhat-toolbox@2.0.2

Initialize a Hardhat project

npx hardhat init

Choose "Create a JavaScript project" when prompted.

888    888                      888 888               888
888    888                      888 888               888
888    888                      888 888               888
8888888888  8888b.  888d888 .d88888 88888b.   8888b.  888888
888    888     "88b 888P"  d88" 888 888 "88b     "88b 888
888    888 .d888888 888    888  888 888  888 .d888888 888
888    888 888  888 888    Y88b 888 888  888 888  888 Y88b.
888    888 "Y888888 888     "Y88888 888  888 "Y888888  "Y888

👷 Welcome to Hardhat v2.14.0 👷‍
✔ What do you want to do? · Create a JavaScript project
✔ Hardhat project root: · /interchain-governance-with-openzeppelin-governor-example
✔ Do you want to add a .gitignore? (Y/n) · y
✨ Project created ✨
See the README.md file for some example tasks you can run

Give Hardhat a star on Github if you're enjoying it! ⭐️✨
<https://github.com/NomicFoundation/hardhat>

Build the smart contracts

In this section, you will build the InterchainCalls library to help define structures for cross-chain calls and contracts GovernanceToken, InterchainProposalSender, ThresholdContract, and CrossChainGovernor for multichain governance.

Build the InterchainCalls library

Create a file InterchainCalls.sol in the contracts directory and add the following code snippet to create a library to be reused while implementing the interchain proposal contract and cross-chain governance contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// @title InterchainCalls Library
/// @notice This library defines structures for cross-chain calls using Axelar Network
library InterchainCalls {

    /// @dev Represents a complete interchain call
    struct InterchainCall {
        string destinationChain; // The name of the destination chain
        string destinationContract; // The address of the contract on the destination chain
        uint256 gas; // The amount of gas to be paid for the call
        Call[] calls; // An array of calls to be executed on the destination chain
    }

    /// @dev Represents a single call to be executed on the destination chain
    struct Call {
        address target; // The address of the contract to call on the destination chain
        uint256 value; // The amount of native tokens to send with the call
        bytes callData; // The encoded function call data
    }
}

In the code snippet above, you:

• Created an InterchainCalls library with two structs: InterchainCall and Call.

• InterchainCall defines the overall cross-chain message structure, including destination and multiple calls.

• Call represents individual function calls on the target chain.

In the next section, you will build the InterchainProposalSender, where you will be utilizing the InterchainCalls library.

Build the Interchain Proposal Sender contract

Create the InterchainProposalSender contract, a component of your cross-chain governance system. This contract will send proposals from one blockchain to another using the Axelar General Message Passing feature.

The main objectives of this contract are:

1. To interface with Axelar's Gateway and Gas Service for cross-chain communication.

2. To provide a method for sending proposals to other chains, including the necessary gas payments.

3. To encode the proposal data in a format that can be understood and executed on the destination chain.

Now, let's create the InterchainProposalSender.sol file in the contracts directory and add the following code snippet to implement the sendProposal function.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {IAxelarGateway} from "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGateway.sol";
import {IAxelarGasService} from "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol";
import "./InterchainCalls.sol";

/// @title InterchainProposalSender
/// @notice This contract sends cross-chain proposals using the Axelar network
contract InterchainProposalSender {
    IAxelarGateway public immutable gateway;
    IAxelarGasService public immutable gasService;

    error InvalidAddress();
    error InvalidFee();

    /// @notice Initializes the contract with Axelar Gateway and Gas Service addresses
    /// @param _gateway Address of the Axelar Gateway
    /// @param _gasService Address of the Axelar Gas Service
    constructor(address _gateway, address _gasService) {
        if (_gateway == address(0) || _gasService == address(0))
            revert InvalidAddress();
        gateway = IAxelarGateway(_gateway);
        gasService = IAxelarGasService(_gasService);
    }

    /// @notice Sends a proposal to another chain
    /// @param destinationChain The name of the destination chain
    /// @param destinationContract The address of the contract on the destination chain
    /// @param calls An array of calls to be executed on the destination chain
    function sendProposal(
        string memory destinationChain,
        string memory destinationContract,
        InterchainCalls.Call[] calldata calls
    ) external payable {
        require(msg.value > 0, "Gas payment is required");
        bytes memory payload = abi.encode(abi.encodePacked(msg.sender), calls);

        gasService.payNativeGasForContractCall{value: msg.value}(
            address(this),
            destinationChain,
            destinationContract,
            payload,
            msg.sender
        );
        gateway().callContract(destinationChain, destinationContract, payload);
    }
}

In the code snippet above, you:

• Imported the necessary Axelar interfaces:

  • IAxelarGateway for cross-chain messaging

  • IAxelarGasService for handling gas payments

  • Our custom InterchainCalls library for structuring call data

• Defined the InterchainProposalSender contract to send proposals across different blockchain networks via the Axelar network

• Initialized the contract with immutable references to the Axelar Gateway and Gas Service in the constructor, ensuring they are valid addresses:

  • Checked for invalid addresses and reverted with InvalidAddress() if necessary

• Implemented the sendProposal function, which:

  • Requires a non-zero msg.value to ensure gas fees are provided (require(msg.value > 0, "Gas payment is required");)

  • Encodes the sender's address and the array of calls into a payload using abi.encode

  • Pays the gas fees for the cross-chain transaction using the Axelar Gas Service

  • Sends the proposal to the specified contract on the destination chain via the Axelar Gateway

Build the Governance Token contract

Voting on a proposal requires voting power, and to allow a user to have this voting power, you need to create the GovernanceToken contract. This token will:

1. Provide voting power to token holders.

2. Implement the ERC20 standard with additional voting and permit capabilities.

3. Allow the owner to mint new tokens.

This contract combines features from OpenZeppelin's ERC20, ERC20Permit, ERC20Votes, and Ownable contracts to create a governance token suitable for your cross-chain governance system.

Let's implement this contract by creating a new file in our contracts directory and adding the following code snippet.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

/// @title GovernanceToken
/// @notice ERC20 token with voting and permit capabilities for governance
contract GovernanceToken is ERC20, ERC20Permit, ERC20Votes, Ownable {
    uint256 public constant MAX_SUPPLY = 1000000 * 10 ** 18; // 1 million tokens

    /// @notice Initializes the token and mints the entire supply to the initial owner
    /// @param initialOwner Address of the initial token owner
    constructor(
        address initialOwner
    )
        ERC20("GovernanceToken", "MGT")
        ERC20Permit("GovernanceToken")
        Ownable(initialOwner)
    {
        _mint(initialOwner, MAX_SUPPLY);
    }

    /// @notice Mints new tokens (only callable by owner)
    /// @param to Address to receive the minted tokens
    /// @param amount Amount of tokens to mint
    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }

    // The following functions are overrides required by Solidity
    function _update(
        address from,
        address to,
        uint256 amount
    ) internal override(ERC20, ERC20Votes) {
        super._update(from, to, amount);
    }

    function nonces(
        address owner
    ) public view override(ERC20Permit, Nonces) returns (uint256) {
        return super.nonces(owner);
    }
}

In the code snippet above, you:

• Set a maximum supply of 1 million tokens

• Implemented a constructor that mints the entire supply to the initial owner

• Added a mint function that allows the owner to create new tokens

• Overrode the _update function to ensure proper functionality with ERC20Votes

• Overrode the nonces function to resolve conflicts between ERC20Permit and Nonces

Build the Threshold Contract contract

Now, you'll create the ThresholdContract, which will be the target of your cross-chain governance proposals. This contract will:

1. Store a threshold value that can be updated through governance.

2. Provide a function to update the threshold.

3. Emit an event when the threshold is changed.

This simple contract will serve as an example of how cross-chain governance can be used to manage parameters on different blockchains.

Let's implement this contract in our contracts directory. Create a file ThresholdContract.sol inside the contracts directory, then add the following code snippet.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// @title ThresholdContract
/// @notice A simple contract to manage and update a threshold value
contract ThresholdContract {
    uint256 public threshold;

    event ThresholdUpdated(uint256 newThreshold);

    /// @notice Updates the threshold to a new value
    /// @param newThreshold The new threshold value to set
    function updateThreshold(uint256 newThreshold) external {
        threshold = newThreshold;
        emit ThresholdUpdated(newThreshold);
    }
}

Build the CrossChain Governor contract

The CrossChainGovernor contract is the most important part of this tutorial. It combines standard on-chain governance with cross-chain capabilities. This contract will allow token holders to propose and vote on actions that can be executed across different blockchain networks.

Contract declaration and imports

Before adding the code, you want to set up the basic structure of your CrossChainGovernor contract. This includes importing necessary OpenZeppelin and Axelar contracts, as well as your custom InterchainCalls and InterchainProposalSender contracts. You'll also declare your contract and its inheritance.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// Import necessary OpenZeppelin and Axelar contracts
import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";
import "@axelar-network/axelar-gmp-sdk-solidity/contracts/executable/AxelarExecutable.sol";
import "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol";
import "./InterchainCalls.sol";
import "./InterchainProposalSender.sol";

/**
 * @title CrossChainGovernor
 * @dev A governance contract that enables cross-chain proposal creation and execution using Axelar Network.
 * @notice This contract allows for creating and executing threshold update proposals across different blockchain networks.
 */
contract CrossChainGovernor is
    Governor,
    GovernorCountingSimple,
    GovernorVotes,
    AxelarExecutable
{
    // Contract body will be added in subsequent steps
}

State variables and events

Add the state variables and events for your contract. This includes variables for the Axelar gas service, proposal sender, threshold address, and mappings for whitelisted callers and senders. You'll also define the CrossChainProposal struct and relevant events.

//...

contract CrossChainGovernor is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, AxelarExecutable {
    //...

    // Axelar gas service for cross-chain transactions
    IAxelarGasService public immutable gasService;

    // Contract for sending interchain proposals
    InterchainProposalSender public immutable proposalSender;

    // Mappings to store whitelisted senders and callers for cross-chain governance
    mapping(string => mapping(string => bool)) public whitelistedSenders;
    mapping(string => mapping(bytes => bool)) public whitelistedCallers;

    // Structure to store threshold proposal details
    struct ThresholdProposal {
        string destinationChain;
        string destinationContract;
        address thresholdContract;
        uint256 newThreshold;
    }

    // Mapping to store threshold proposals
    mapping(uint256 => ThresholdProposal) public thresholdProposals;

    /**
     * @dev Emitted when a threshold proposal is created.
     * @param proposalId The ID of the created proposal.
     * @param destinationChain The target blockchain for the proposal.
     * @param destinationContract The address of the contract on the destination chain.
     * @param thresholdContract The address of the threshold contract.
     * @param newThreshold The proposed new threshold value.
     */
    event ThresholdProposalCreated(
        uint256 proposalId,
        string destinationChain,
        string destinationContract,
        address thresholdContract,
        uint256 newThreshold
    );

    /**
     * @dev Emitted when a whitelisted caller is set.
     * @param sourceChain The source blockchain of the caller.
     * @param sourceCaller The address of the caller.
     * @param whitelisted The whitelist status of the caller.
     */
    event WhitelistedCallerSet(
        string sourceChain,
        bytes sourceCaller,
        bool whitelisted
    );

    /**
     * @dev Emitted when a cross-chain proposal is executed.
     * @param proposalHash The unique hash of the executed proposal.
     */
    event CrossChainProposalExecuted(bytes32 indexed proposalHash);

    /**
     * @dev Emitted when a threshold proposal is executed.
     * @param proposalId The ID of the executed proposal.
     */
    event ThresholdProposalExecuted(uint256 indexed proposalId);

    /**
     * @dev Emitted when a whitelisted sender is set.
     * @param sourceChain The source blockchain of the sender.
     * @param sourceSender The address of the sender.
     * @param whitelisted The whitelist status of the sender.
     */
    event WhitelistedSenderSet(
        string sourceChain,
        string sourceSender,
        bool whitelisted
    );

    // Constructor here
}

Add a constructor

Add the constructor for your CrossChainGovernor contract. This will initialize the contract with the necessary parameters, including the governance token, Axelar gateway, gas service, proposal sender, and threshold address.

//...

contract CrossChainGovernor is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, AxelarExecutable {
    //...

    /**
     * @dev Constructor to initialize the CrossChainGovernor contract.
     * @param _name The name of the governor.
     * @param _token The voting token address.
     * @param _gateway The Axelar gateway address.
     * @param _gasService The Axelar gas service address.
     * @param _proposalSender The address of the InterchainProposalSender contract.
     */
    constructor(
        string memory _name,
        IVotes _token,
        address _gateway,
        address _gasService,
        address _proposalSender
    ) Governor(_name) GovernorVotes(_token) AxelarExecutable(_gateway) {
        gasService = IAxelarGasService(_gasService);
        proposalSender = InterchainProposalSender(_proposalSender);
    }

 }

Add whitelisting and proposal threshold update

In this step, you will add whitelisting and proposal threshold functions. These functions will be used on the source chain to whitelist and propose updating thresholds on the destination chain.

//...

contract CrossChainGovernor is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, AxelarExecutable {
    //...

    /**
     * @dev Sets a whitelisted proposal sender.
     * @param sourceChain The source blockchain of the sender.
     * @param sourceSender The address of the sender to be whitelisted.
     * @param whitelisted The whitelist status to be set.
     */
    function setWhitelistedProposalSender(
        string calldata sourceChain,
        string calldata sourceSender,
        bool whitelisted
    ) external onlyGovernance {
        whitelistedSenders[sourceChain][sourceSender] = whitelisted;
        emit WhitelistedSenderSet(sourceChain, sourceSender, whitelisted);
    }

    /**
     * @dev Sets a whitelisted proposal caller.
     * @param sourceChain The source blockchain of the caller.
     * @param sourceCaller The address of the caller to be whitelisted.
     * @param whitelisted The whitelist status to be set.
     */
    function setWhitelistedProposalCaller(
        string calldata sourceChain,
        bytes memory sourceCaller,
        bool whitelisted
    ) external onlyGovernance {
        whitelistedCallers[sourceChain][sourceCaller] = whitelisted;
        emit WhitelistedCallerSet(sourceChain, sourceCaller, whitelisted);
    }

    /**
     * @dev Proposes a threshold update.
     * @param destinationChain The target blockchain for the proposal.
     * @param destinationContract The address of the contract on the destination chain.
     * @param thresholdContract The address of the threshold contract.
     * @param newThreshold The proposed new threshold value.
     * @return proposalId The ID of the created proposal.
     */
    function proposeThresholdUpdate(
        string memory destinationChain,
        string memory destinationContract,
        address thresholdContract,
        uint256 newThreshold
    ) public returns (uint256 proposalId) {
        // Create proposal parameters
        address[] memory targets = new address[](1);
        uint256[] memory values = new uint256[](1);
        bytes[] memory calldatas = new bytes[](1);

        targets[0] = thresholdContract;
        values[0] = 0;
        calldatas[0] = abi.encodeWithSignature(
            "updateThreshold(uint256)",
            newThreshold
        );

        // Create the proposal
        proposalId = propose(
            targets,
            values,
            calldatas,
            "Proposal to update the threshold contract"
        );

        // Store the threshold proposal details
        thresholdProposals[proposalId] = ThresholdProposal({
            destinationChain: destinationChain,
            destinationContract: destinationContract,
            thresholdContract: thresholdContract,
            newThreshold: newThreshold
        });

        // Emit event for threshold proposal creation
        emit ThresholdProposalCreated(
            proposalId,
            destinationChain,
            destinationContract,
            thresholdContract,
            newThreshold
        );

        return proposalId;
    }
 }

Add execute threshold proposal function

Next, add a function to execute threshold proposals using the proposal ID and other helper functions like _getProposalTargets, _getProposalValues, and _getProposalCalldatas.

//...

contract CrossChainGovernor is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, AxelarExecutable {
    //...

      /**
     * @dev Executes a threshold proposal.
     * @param proposalId The ID of the proposal to be executed.
     */
    function executeThresholdProposal(uint256 proposalId) public payable {
        require(
            state(proposalId) == ProposalState.Succeeded,
            "Proposal must be succeeded"
        );
        ThresholdProposal memory proposal = thresholdProposals[proposalId];
        InterchainCalls.Call[] memory calls = new InterchainCalls.Call[](1);
        calls[0] = InterchainCalls.Call({
            target: proposal.thresholdContract,
            value: 0,
            callData: abi.encodeWithSignature(
                "updateThreshold(uint256)",
                proposal.newThreshold
            )
        });

        // Send the proposal to the destination chain
        proposalSender.sendProposal{value: msg.value}(
            proposal.destinationChain,
            proposal.destinationContract,
            calls
        );

        // Execute the proposal on the current chain
        super.execute(
            _getProposalTargets(proposalId),
            _getProposalValues(),
            _getProposalCalldatas(proposalId),
            keccak256(bytes("Proposal to update the threshold contract"))
        );

        // Emit event for threshold proposal execution
        emit ThresholdProposalExecuted(proposalId);
    }

    /**
     * @dev Internal function to get proposal targets.
     * @param proposalId The ID of the proposal.
     * @return An array of target addresses for the proposal.
     */
    function _getProposalTargets(
        uint256 proposalId
    ) internal view returns (address[] memory) {
        address[] memory targets = new address[](1);
        targets[0] = thresholdProposals[proposalId].thresholdContract;
        return targets;
    }

    /**
     * @dev Internal function to get proposal values.
     * @return An array of values for the proposal (always 0 in this case).
     */
    function _getProposalValues() internal pure returns (uint256[] memory) {
        uint256[] memory values = new uint256[](1);
        values[0] = 0;
        return values;
    }

    /**
     * @dev Internal function to get proposal calldatas.
     * @param proposalId The ID of the proposal.
     * @return An array of calldata for the proposal.
     */
    function _getProposalCalldatas(
        uint256 proposalId
    ) internal view returns (bytes[] memory) {
        bytes[] memory calldatas = new bytes[](1);
        calldatas[0] = abi.encodeWithSignature(
            "updateThreshold(uint256)",
            thresholdProposals[proposalId].newThreshold
        );
        return calldatas;
    }

}

Add _execute function

To execute a cross-chain call received from another chain, you need to implement the _execute function that receives and processes cross-chain calls on the destination chain.

//...

contract CrossChainGovernor is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, AxelarExecutable {

    //...

    /// @notice Executes a cross-chain call received from another chain
    /// @param sourceChain The name of the source chain
    /// @param sourceAddress The address of the sender on the source chain
    /// @param payload The encoded payload containing the calls to be executed
    function _execute(
        bytes32 commandId,
        string calldata sourceChain,
        string calldata sourceAddress,
        bytes calldata payload
    ) internal override {
        if (!whitelistedSenders[sourceChain][sourceAddress]) {
            revert NotWhitelistedSourceAddress();
        }

        (bytes memory sourceCaller, InterchainCalls.Call[] memory calls) = abi
            .decode(payload, (bytes, InterchainCalls.Call[]));

        if (!whitelistedCallers[sourceChain][sourceCaller]) {
            revert NotWhitelistedCaller();
        }

        _executeProposal(calls);

        emit CrossChainProposalExecuted(sourceChain, sourceAddress, payload);
    }

    /// @notice Executes the calls in a cross-chain proposal
    /// @param calls An array of calls to be executed
    function _executeProposal(InterchainCalls.Call[] memory calls) internal {
        uint256 length = calls.length;

        for (uint256 i = 0; i < length; i++) {
            InterchainCalls.Call memory call = calls[i];
            (bool success, bytes memory result) = call.target.call{
                value: call.value
            }(call.callData);

            if (!success) {
                _onTargetExecutionFailed(call, result);
            }
        }
    }

    /// @notice Handles the failure of a call execution
    /// @param call The call that failed
    /// @param result The result of the failed call
    function _onTargetExecutionFailed(
        InterchainCalls.Call memory call,
        bytes memory result
    ) internal pure {
        if (result.length > 0) {
            assembly {
                revert(add(32, result), mload(result))
            }
        } else {
            revert ProposalExecuteFailed();
        }
    }
 }

OpenZeppelin Governor Functions

Finally, add the required overrides for OpenZeppelin Governor functions. These include votingDelay, votingPeriod, and quorum.

//...

contract CrossChainGovernor is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, AxelarExecutable {

    //...

     /**
     * @dev Returns the voting delay.
     * @return The number of blocks between proposal creation and voting start.
     */
    function votingDelay() public pure override returns (uint256) {
        return 1;
    }

    /**
     * @dev Returns the voting period.
     * @return The number of blocks for the voting period.
     */
    function votingPeriod() public pure override returns (uint256) {
        return 50400;
    }

    /**
     * @dev Returns the quorum required for a proposal to pass.
     * @return The minimum number of votes required for a quorum.
     */
    function quorum(uint256) public pure override returns (uint256) {
        return 1e18;
    }
}

Test the contracts

You have successfully implemented all the contracts required to establish cross-chain governance with the OpenZeppelin governor. Now, you need to write a unit test to ensure that all the functions implemented in your contracts work correctly.

You will create test cases for each prominent system feature, verifying deployment, governance settings, whitelisting, proposal lifecycle, voting, and execution. Follow along as we walk through each test case.

Create MockAxelarGateway and MockAxelarGasService files

Before proceeding to test the CrossChainGovernor contract, you need to create mock contracts for AxelarGateway and AxelarGasService. These mock contracts simulate the behavior of the real Axelar contracts and will allow you to run the tests effectively.

You should place these mock contracts in a folder called mock inside the contracts directory.

Create MockAxelarGateway.sol

Navigate to the contracts/mock directory and create a file named MockAxelarGateway.sol. Add the following code to mock the basic functionality of Axelar's gateway.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// @title MockAxelarGateway
/// @dev This is a mock contract for testing purposes that simulates the behavior of AxelarGateway.
contract MockAxelarGateway {
    /// @notice Simulates the cross-chain contract call
    /// @param destinationChain The chain the contract call is destined for
    /// @param destinationContract The contract address on the destination chain
    /// @param payload The data payload sent to the destination contract
        function callContract(
        string memory,
        string memory,
        bytes memory
    ) external pure {}
}

Create MockAxelarGasService.sol

Similarly, create another file in the same folder named MockAxelarGasService.sol and add the following code to simulate the Axelar gas service.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// @title MockAxelarGasService
/// @dev This is a mock contract for testing purposes that simulates the behavior of AxelarGasService.
contract MockAxelarGasService {
    /// @notice Simulates the payment of gas fees for cross-chain calls
    function payNativeGasForContractCall(
        address,
        string memory,
        string memory,
        bytes memory,
        address
    ) external payable {}
}

Your folder structure should now look like this:

/contracts
   └── /mock
         ├── MockAxelarGateway.sol
         └── MockAxelarGasService.sol

Create the CrossChainGovernor.test.js file

Inside the test folder, create a file named CrossChainGovernor.test.js. This file will contain all your unit tests for the CrossChainGovernor contract.

Import dependencies

Start by importing the necessary modules and tools. In your CrossChainGovernor.test.js file, add the following code:

const { ethers } = require("hardhat");
const { expect } = require("chai");
const { anyValue } = require("@nomicfoundation/hardhat-chai-matchers/withArgs");

The code snippet above will import ethers from Hardhat, expect from Chai for assertions, and anyValue for an event matching with arbitrary values.

Setting up the contract instances with beforeEach

Before you dive into individual test cases, deploy the contracts to set up the environment. The beforeEach hook ensures that you have fresh instances of your contracts before every test case.

//...

describe("CrossChainGovernor", function () {
  let governanceToken,
    crossChainGovernor,
    mockAxelarGateway,
    mockAxelarGasService,
    interchainProposalSender,
    thresholdContract;
  let owner, addr1, addr2;

  beforeEach(async function () {
    [owner, addr1, addr2] = await ethers.getSigners();

    const GovernanceToken = await ethers.getContractFactory("GovernanceToken");
    governanceToken = await GovernanceToken.deploy(owner.address);

    const MockAxelarGateway = await ethers.getContractFactory("MockAxelarGateway");
    mockAxelarGateway = await MockAxelarGateway.deploy();

    const MockAxelarGasService = await ethers.getContractFactory("MockAxelarGasService");
    mockAxelarGasService = await MockAxelarGasService.deploy();

    const InterchainProposalSender = await ethers.getContractFactory("InterchainProposalSender");
    interchainProposalSender = await InterchainProposalSender.deploy(mockAxelarGateway.address, mockAxelarGasService.address);

    const ThresholdContract = await ethers.getContractFactory("ThresholdContract");
    thresholdContract = await ThresholdContract.deploy();

    const CrossChainGovernor = await ethers.getContractFactory("CrossChainGovernor");
    crossChainGovernor = await CrossChainGovernor.deploy(
      "CrossChainGovernor",
      governanceToken.address,
      mockAxelarGateway.address,
      mockAxelarGasService.address,
      interchainProposalSender.address
    );

    await governanceToken.delegate(owner.address);
    await governanceToken.transfer(addr1.address, ethers.utils.parseEther("100"));
    await governanceToken.connect(addr1).delegate(addr1.address);
    await governanceToken.mint(owner.address, ethers.utils.parseEther("1000000"));

    await ethers.provider.send("evm_mine", []);
  });
});

This beforeEach function deploys new instances of the contracts, sets up the necessary addresses, and mints tokens for testing.

Run the deployment tests

Let's start by testing if the contracts are deployed correctly and with the correct parameters.

//...

describe("CrossChainGovernor", function () {

//...

    describe("Deployment", function () {
          it("Should set the right token", async function () {
            expect(await crossChainGovernor.token()).to.equal(governanceToken.address);
          });

          it("Should set the right gas service", async function () {
            expect(await crossChainGovernor.gasService()).to.equal(mockAxelarGasService.address);
          });

          it("Should set the right proposal sender", async function () {
            expect(await crossChainGovernor.proposalSender()).to.equal(interchainProposalSender.address);
          });
        });
});

To test the deployment, run the following command:

npx hardhat test

  CrossChainGovernor
    Deployment
      ✔ Should set the right token
      ✔ Should set the right gas service
      ✔ Should set the right proposal sender

  3 passing (2s)

Testing governance settings

Test the governance settings, including voting delay, voting period, and quorum.

//...

describe("CrossChainGovernor", function () {

//...

        describe("Governance settings", function () {
          it("Should have the correct voting delay", async function () {
            expect(await crossChainGovernor.votingDelay()).to.equal(1);
          });

          it("Should have the correct voting period", async function () {
            expect(await crossChainGovernor.votingPeriod()).to.equal(50400);
          });

          it("Should have the correct quorum", async function () {
            expect(await crossChainGovernor.quorum(0)).to.equal(ethers.utils.parseEther("1"));
          });
        });
});

Run this test with the following command:

npx hardhat test

  CrossChainGovernor
    Deployment
      ✔ Should set the right token
      ✔ Should set the right gas service
      ✔ Should set the right proposal sender
    Governance settings
      ✔ Should have the correct voting delay
      ✔ Should have the correct voting period
      ✔ Should have the correct quorum

  6 passing (2s)

Test whitelisting functionality

Test whether you can whitelist a proposal sender.

//...

describe("CrossChainGovernor", function () {

//...

        describe("Whitelisting", function () {
          it("Should allow whitelisting a proposal sender", async function () {
            const destinationChain = "destinationChain";
            const destinationContract = thresholdContract.address;
            const newThreshold = 1000;

            const proposeTx = await crossChainGovernor.proposeThresholdUpdate(
              destinationChain,
              destinationContract,
              thresholdContract.address,
              newThreshold
            );

            const proposeReceipt = await proposeTx.wait();

            await expect(proposeTx)
              .to.emit(crossChainGovernor, "ThresholdProposalCreated")
              .withArgs(anyValue, destinationChain, destinationContract, thresholdContract.address, newThreshold);
          });
        });
});

To test the whitelisting functionality, run the following command:

npx hardhat test

CrossChainGovernor
    Deployment
      ✔ Should set the right token
      ✔ Should set the right gas service
      ✔ Should set the right proposal sender
    Governance settings
      ✔ Should have the correct voting delay
      ✔ Should have the correct voting period
      ✔ Should have the correct quorum
    Whitelisting
      ✔ Should allow whitelisting a proposal sender

  7 passing (2s)

Testing Threshold proposals

You can now test the creation and voting on threshold proposals.

//...

describe("CrossChainGovernor", function () {

//...

    describe("Threshold Proposal", function () {
      it("Should allow creating a threshold proposal", async function () {
        const destinationChain = "destinationChain";
        const destinationContract = thresholdContract.address;
        const newThreshold = 1000;

        await expect(
          crossChainGovernor.proposeThresholdUpdate(
            destinationChain,
            destinationContract,
            thresholdContract.address,
            newThreshold
          )
        )
          .to.emit(crossChainGovernor, "ThresholdProposalCreated")
          .withArgs(anyValue, destinationChain, destinationContract, anyValue, newThreshold);
      });

      it("Should allow voting on a threshold proposal", async function () {
        const destinationChain = "destinationChain";
        const destinationContract = thresholdContract.address;
        const newThreshold = 1000;

        const proposeTx = await crossChainGovernor.proposeThresholdUpdate(
          destinationChain,
          destinationContract,
          thresholdContract.address,
          newThreshold
        );
        const proposeReceipt = await proposeTx.wait();

        const proposalId = proposeReceipt.events.find(e => e.event === "ThresholdProposalCreated").args.proposalId;

        await ethers.provider.send("evm_mine", []);

        await expect(crossChainGovernor.castVote(proposalId, 1)).to.emit(crossChainGovernor, "VoteCast");
      });
    });

});

Test the Threshold proposals by running the command below:

npx hardhat test

CrossChainGovernor
    Deployment
      ✔ Should set the right token
      ✔ Should set the right gas service
      ✔ Should set the right proposal sender
    Governance settings
      ✔ Should have the correct voting delay
      ✔ Should have the correct voting period
      ✔ Should have the correct quorum
    Whitelisting
      ✔ Should allow whitelisting a proposal sender
    Threshold Proposal
      ✔ Should allow creating a threshold proposal
      ✔ Should allow voting on a threshold proposal (13069ms)

  9 passing (16s)

Testing proposal lifecycle

Test the full lifecycle of a proposal, including its state transitions.

//...

describe("CrossChainGovernor", function () {

//...

        describe("Proposal lifecycle", function () {
          let proposalId;

          beforeEach(async function () {
            const destinationChain = "destinationChain";
            const destinationContract = thresholdContract.address;
            const newThreshold = 1000;

            const proposeTx = await crossChainGovernor.proposeThresholdUpdate(
              destinationChain,
              destinationContract,
              thresholdContract.address,
              newThreshold
            );

            const proposeReceipt = await proposeTx.wait();
            proposalId = proposeReceipt.events.find(e => e.event === "ThresholdProposalCreated").args.proposalId;

            await ethers.provider.send("evm_mine", []);
          });

          it("Should start in the Pending state", async function () {
            const proposalState = await crossChainGovernor.state(proposalId);
            expect(proposalState).to.equal(0); // Pending
          });

          it("Should move to Active state after votingDelay", async function () {
            await ethers.provider.send("evm_mine", []);
            const proposalState = await crossChainGovernor.state(proposalId);
            expect(proposalState).to.equal(1); // Active
          });

          it("Should allow voting when Active", async function () {
            await expect(crossChainGovernor.castVote(proposalId, 1)).to.emit(crossChainGovernor, "VoteCast");
          });
        });
    });

Run:

npx hardhat test

Testing proposal execution

Lastly, ensure that proposals are only executed when successful.

//...

describe("CrossChainGovernor", function () {

//...

        describe("Proposal Execution", function () {
          it("Should allow execution of a succeeded proposal", async function () {
            const proposalId = anyValue;
            const gasFee = ethers.utils.parseEther("0.1");
            await expect(
              crossChainGovernor.executeThresholdProposal(proposalId, {
                value: gasFee,
              })
            ).to.emit(crossChainGovernor, "ThresholdProposalExecuted");
          });

          it("Should not allow execution of an already executed proposal", async function () {
            const proposalId = anyValue;
            const gasFee = ethers.utils.parseEther("0.1");
            await crossChainGovernor.executeThresholdProposal(proposalId, {
              value: gasFee,
            });

            await expect(
              crossChainGovernor.executeThresholdProposal(proposalId, {
                value: gasFee,
              })
            ).to.be.revertedWith("Proposal must be succeeded");
          });
        });

});

Run the proposal execution test using the following command:

npx hardhat test

CrossChainGovernor
    Deployment
      ✔ Should set the right token
      ✔ Should set the right gas service
      ✔ Should set the right proposal sender
    Governance settings
      ✔ Should have the correct voting delay
      ✔ Should have the correct voting period
      ✔ Should have the correct quorum
    Whitelisting
      ✔ Should allow whitelisting a proposal sender
    Threshold Proposal
      ✔ Should allow creating a threshold proposal
      ✔ Should allow voting on a threshold proposal (13203ms)
    Proposal lifecycle
      ✔ Should start in the Pending state
      ✔ Should move to Active state after votingDelay
      ✔ Should allow voting when Active
    Proposal Execution
      ✔ Should not allow execution of a proposal that hasn't succeeded (42ms)
      ✔ Should allow execution of a succeeded proposal (13341ms)
      ✔ Should not allow execution of an already executed proposal (13399ms)

  15 passing (44s)

Proposal creation and voting

This section covers how to test the creation of proposals by token and non-token holders, ensure proper voting behavior, and prevent double voting.

Test for non-token holders creating proposals

In this test, we check if non-token holders can create proposals. However, the proposal should fail due to a lack of quorum.

//...
describe("CrossChainGovernor", function () {

//...

        describe("Proposal Creation and Voting", function () {

                it("Should allow non-token holders to create proposals, but the proposal should fail", async function () {
                  const [, nonHolder] = await ethers.getSigners();

                  // Create a proposal
                  const tx = await crossChainGovernor
                    .connect(nonHolder)
                    .proposeThresholdUpdate(
                      "destinationChain",
                      crossChainGovernor.address,
                      thresholdContract.address,
                      1000
                    );

                  const receipt = await tx.wait();
                  const event = receipt.events.find(
                    (e) => e.event === "ThresholdProposalCreated"
                  );
                  expect(event).to.not.be.undefined;

                  const proposalId = event.args.proposalId;

                  // Advance the block to move past the voting delay
                  const votingDelay = await crossChainGovernor.votingDelay();
                  for (let i = 0; i <= votingDelay.toNumber(); i++) {
                    await ethers.provider.send("evm_mine", []); // Mine blocks
                  }

                  // Let the proposal become active and fail due to insufficient quorum
                  const votingPeriod = await crossChainGovernor.votingPeriod();
                  for (let i = 0; i <= votingPeriod.toNumber(); i++) {
                    await ethers.provider.send("evm_mine", []); // Advance to the end of the voting period
                  }

                  // Check if the proposal state is defeated (3) due to lack of quorum
                  const newProposalState = await crossChainGovernor.state(proposalId);
                  expect(newProposalState).to.equal(3); // State 3 is Defeated
                });
    });

});

Test voting before voting delay has passed

This test ensures that voting cannot occur before the voting delay set by the governance process.

//...

it("Should not allow voting before the voting delay has passed", async function () {
  // First, create a proposal to get a valid proposalId
  const tx = await crossChainGovernor.proposeThresholdUpdate(
    "destinationChain",
    crossChainGovernor.address,
    thresholdContract.address,
    1000
  );

  // Wait for the transaction to be mined and get the event logs
  const receipt = await tx.wait();
  const event = receipt.events.find(
    (e) => e.event === "ThresholdProposalCreated"
  );

  // Ensure the event exists and extract the proposalId
  if (!event) {
    throw new Error("ThresholdProposalCreated event not found");
  }
  const proposalId = event.args.proposalId;

  // Now try to cast a vote before the voting delay has passed
  await expect(
    crossChainGovernor.castVote(proposalId, 1)
  ).to.be.revertedWith("Governor: vote not currently active");
});

//...

Test voting after voting period has ended

This test ensures no voting can happen after the designated voting period ends.

//...

it("Should not allow voting after the voting period has ended", async function () {
  // First, create a proposal to get a valid proposalId
  const tx = await crossChainGovernor.proposeThresholdUpdate(
    "destinationChain",
    crossChainGovernor.address,
    thresholdContract.address,
    1000
  );

  const receipt = await tx.wait();
  const event = receipt.events.find(
    (e) => e.event === "ThresholdProposalCreated"
  );

  if (!event) {
    throw new Error("ThresholdProposalCreated event not found");
  }
  const proposalId = event.args.proposalId;

  // Wait for the voting period to pass
  const votingPeriod = await crossChainGovernor.votingPeriod();
  for (let i = 0; i <= votingPeriod.toNumber(); i++) {
    await ethers.provider.send("evm_mine", []);
  }

  // Now try to vote after the voting period has ended
  await expect(
    crossChainGovernor.castVote(proposalId, 1)
  ).to.be.revertedWith("Governor: vote not currently active");
});

Test double voting prevention

This test ensures that voters cannot cast more than one vote on the same proposal.

//...

it("Should not allow double voting", async function () {
  // First, create a proposal to get a valid proposalId
  const tx = await crossChainGovernor.proposeThresholdUpdate(
    "destinationChain",
    crossChainGovernor.address,
    thresholdContract.address,
    1000
  );

  const receipt = await tx.wait();
  const event = receipt.events.find(
    (e) => e.event === "ThresholdProposalCreated"
  );

  if (!event) {
    throw new Error("ThresholdProposalCreated event not found");
  }
  const proposalId = event.args.proposalId;

  // Move forward to the voting period
  const votingDelay = await crossChainGovernor.votingDelay();
  for (let i = 0; i <= votingDelay.toNumber(); i++) {
    await ethers.provider.send("evm_mine", []);
  }

  // Cast the first vote
  await crossChainGovernor.castVote(proposalId, 1);

  // Now attempt to cast a second vote, which should fail
  await expect(
    crossChainGovernor.castVote(proposalId, 1)
  ).to.be.revertedWith("GovernorVotingSimple: vote already cast");
})

Running all the tests

After adding the above tests, you can run all tests in the CrossChainGovernor.test.js file by executing the following command:

npx hardhat test

CrossChainGovernor
    Deployment
      ✔ Should set the right token
      ✔ Should set the right gas service
      ✔ Should set the right proposal sender
    Governance settings
      ✔ Should have the correct voting delay
      ✔ Should have the correct voting period
      ✔ Should have the correct quorum
    Whitelisting
      ✔ Should allow whitelisting a proposal sender
    Threshold Proposal
      ✔ Should allow creating a threshold proposal
      ✔ Should allow voting on a threshold proposal (113ms)
    Proposal lifecycle
      ✔ Should start in the Pending state
      ✔ Should move to Active state after votingDelay
      ✔ Should allow voting when Active
    Proposal Creation and Voting
      ✔ Should allow non-token holders to create proposals, but the proposal should fail (13098ms)
      ✔ Should not allow voting before the voting delay has passed (46ms)
      ✔ Should not allow voting after the voting period has ended (166ms)
      ✔ Should not allow double voting (39ms)
    Proposal Execution
      ✔ Should not allow execution of a proposal that hasn't succeeded
      ✔ Should allow execution of a succeeded proposal (139ms)
      ✔ Should not allow execution of an already executed proposal (189ms)

  19 passing (1m)

Congratulations 🥳 all the tests passed.

Next Steps

This example builds directly on Axelar's Interchain Governance Orchestrator, making it straightforward to integrate with the OpenZeppelin Governor for cross-chain governance. With these tools, you can easily manage governance across multiple blockchains.

To move forward, try deploying your contracts on testnets supported by Axelar. This will help you test the system in a real-world environment. You can also explore more advanced features like cross-chain token transfers and contract calls through Axelar's General Message Passing.

Conclusion

In this tutorial, you learned how to build and test the CrossChainGovernor contract using OpenZepplin and Axelar General Message Passing. From testing deployments, governance settings, and whitelisting to proposal lifecycles and execution, you've covered all the essential aspects.

References

• OpenZeppelin Governance Docs

• Bridging Uniswap & Filecoin: A Cross-Chain Governance Case Study

• Axelar General Message Passing (GMP)

• Hardhat Documentation

• Hardhat Chai Matchers

What is the Interchain Token Service (ITS)?

Axelar's Interchain Token Service allows developers to create and manage tokens that operate seamlessly across multiple blockchain networks. With ITS, you can deploy tokens that are natively cross-chain, eliminating the complexities of bridging and wrapping tokens manually.

ITS leverages sophisticated mechanisms to ensure tokens maintain their integrity and security across chains, offering a robust solution for developers looking to extend their tokens' reach beyond a single blockchain. It scales tokens to many chains, supporting existing and newly minted tokens, preserving native-like fungibility and functionality on connected EVM chains, and automating deployment and maintenance so teams can easily manage supply.

What's New in the Repository?

We've added several new examples to help you get started with ITS:

• New Interchain Token Example: Learn how to deploy a brand-new interchain token using ITS.

• Canonical Token Deployment Example: Discover how to deploy a canonical token that serves as a single source of truth across chains.

• Interchain Custom Token Example: Explore how to create and interact with custom tokens with interchain functionality.

You can check out the updated repository here: Foundry Axelar GMP Example

How Does This Benefit You?

By integrating ITS into the Foundry Axelar GMP example, we've made it simpler for you to:

• Develop Multichain Tokens: Easily create tokens that work across different blockchain networks without dealing with multiple codebases.

• Simplify Cross-Chain Interactions: Use Axelar's General Message Passing (GMP) to interact with contracts on other chains effortlessly.

• Accelerate Development: Utilize ready-made examples and scripts to speed up your development process.

Getting Started

1. Clone the Repository:

   Begin by cloning the Foundry Axelar GMP Example repository.

    git clone https://github.com/axelarnetwork/foundry-axelar-gmp-example
   

2. Navigate into the Project Directory:

    cd foundry-axelar-gmp-example
   

3. Install Dependencies:

   Run the following command to install all dependencies and build the project:

    make all
   

   This command will:

   • Install the necessary dependencies.

   • Create a .env file from .env.example.

   • Build and update the project.

4. Start Local Chains:

   To test Axelar GMP locally, start local blockchain networks:

    make local-chain-start
   

   Leave this running in a separate terminal.

5. Deploy Contracts:

   Deploy the contracts to the local chains:

    make local-chain-deploy
   

6. Execute Contracts:

   Now you can test General Message Passing (GMP) and other features:

    make local-chain-execute
   

Features

We've included a set of Makefile Commands to streamline your workflow:

• make all: Install dependencies, build, and update the project.

• make setup-env: Create a .env file from .env.example.

• make install: Install all dependencies.

• make build: Compile the smart contracts.

• make update: Pull the latest updates for the project.

• make deploy: Deploy a specific contract to a specified network.

• make execute: Execute a function of a deployed contract on a specified network.

• make format: Format the codebase using Foundry's formatter.

• make test: Run tests with increased verbosity.

• make clean: Remove generated artifacts.

• make rpc: Display RPC URLs for various networks.

• make help: Display the help menu.

• make local-chain-start: Start local blockchain networks using Anvil.

• make local-chain-deploy: Deploy contracts to local chains.

• make local-chain-execute: Execute commands to test GMP with ITS.

  Interchain Token Service (ITS) commands for local chains:

  • make deploy-interchain-token: Deploy an interchain token on local chains.

  • make deploy-mint-burn-token-manager-and-transfer: Set up token managers and perform a transfer on local chains.

  • make deploy-canonical-token: Deploy a canonical token on local chains.

  • make help: Display the help menu with available commands and descriptions.

Interchain Token Service (ITS) commands for testnet:

• make deploy-canonical-token-testnet: Deploy and register a canonical token on testnet.

• make transfer-canonical-token-testnet: Perform interchain transfer of a canonical token on testnet.

• make deploy-interchain-token-testnet: Deploy an interchain token on testnet.

• make transfer-interchain-token-testnet: Perform interchain transfer of an interchain token on testnet.

• make deploy-custom-token-testnet: Deploy a custom token on testnet.

• make transfer-custom-token-testnet: Perform interchain transfer of a custom token on testnet.

Check out the updated repository here: Foundry Axelar GMP Example.

What's Next?

We encourage you to explore the new ITS features and build cross-chain applications. The updated examples are designed to help you grasp the concepts quickly and integrate them into your projects.

Prefer Hardhat? Check out our Axelar Examples repository for more resources.

If you have any questions or need assistance, please open an issue in our support repository. We're here to help!

🆙 Axelar Network upgrade: v1.0.2

On August 28, 2024, we successfully upgraded our mainnet to v1.0.2, paving the way for exciting new features:

• Mainnet deployment for Amplifier

• Enhanced stability and performance

• New IBC-related queries for better chain connectivity

• "BatchRequest" message type for granular transaction handling

• Quick (de)activation of core-amplifier connections

This release enabled mainnet deployment for Amplifier and included updates to axelard, vald (1.0.2), and tofnd (1.0.1).

What this means for you: Faster, more reliable cross-chain operations and greater flexibility in managing your interchain applications.

Ready to upgrade? Check out our detailed instructions and changelog.

🔬 Interchain Amplifier: now on testnet, coming soon to mainnet

The Interchain Amplifier has hit testnet, with mainnet deployment just around the corner. This feature offers:

• Seamless connection of diverse blockchain consensus engines

• Integration with traditional off-chain systems

• Minimal developer overhead

Key components include:

• On-chain message router

• Gateways

• CosmWasm methods for bidirectional messaging

What this means for you: Unprecedented flexibility in building cross-chain applications with reduced complexity.

Curious? Get started with Amplifier.

🤝OpenZeppelin Integration

We're excited to announce that Axelar and OpenZeppelin are joining forces to solve Ethereum's interoperability challenges, especially with the rise of Layer 2 solutions. For you as a developer, this collaboration means:

• Standardized Solidity code for cross-chain messaging

• Integration with OpenZeppelin's Contract Wizard

• Simplified tools for building interchain contracts using Axelar

Excited to learn more? Read the full announcement.

📚 New tutorials, docs, and more

We've just published several relevant technical articles and documentation updates.

Amplifier

• Amplifier Roadmap: Learn about what you'll be able to do with Amplifier now and in the future, as the Interop Labs team rolls out more features.

• Message Relaying with Amplifier: Learn how to relay cross-chain messages using Axelar's Amplifier, from message verification to execution on the destination chain, with code examples provided for Avalanche and Ethereum Sepolia.

• Verifier Security Expectations: Learn about the security expectations for verifiers in the Axelar network, including running full nodes, maintaining uptime, rotating keys, pulling rewards, supporting trustworthy chains, and participating in security drills and escalations.

• Add rewards for Amplifier chain integrators: Learn how to add funds to the rewards pool of an Amplifier-integrated chain.

• Common Amplifier Error Messages (Chain Integrators).

• Common Amplifier Error Messages (Verifiers / Relayers).

ITS

• Create Multichain Tokens with Interchain Token Service: Learn how to create a Multichain Token that is fungible and customizable across all blockchains.

• Bridge your Existing ERC20 token to all chains with ITS using the Ethereum: Learn how to programmatically create a Canonical Interchain Token from scratch using Interchain Token Service and the Ethereum Boilerplate.

• How to Mint an ERC-20 Token on Base with the Interchain Token Service in 5 Steps: This step-by-step guide will teach you how to mint a multichain ERC-20 token on the Base network using Axelar’s Interchain Token Service (ITS) and use the Moralis Token API to retrieve token balances easily.

Docs Updates

• Cross-Chain Messaging: EVM to Cosmos: Learn to enable cross-chain communication between EVM and Cosmos using Axelar's GMP. This tutorial covers deploying contracts on Avalanche and Osmosis, sending and receiving messages between them, and verifying transactions, allowing you to build interoperable dApps across both ecosystems.

• Specify the refund address for a contract call: Learn how to specify a refund address for unused gas in Axelar's GMP.

• Transactions: Tracking and Retrying Failed States: Learn how to track and recover failed blockchain transactions using Axelarscan and the AxelarJS SDK.

• CommandID: Learn about the CommandID, a unique identifier crucial for secure cross-chain communication, its role in message verification, and examples in Solidity and Go to prevent replay attacks and ensure message integrity.

🎤 Catch up on any events you missed

Did you miss our recent talks? Here are some highlights:

• Build a Multichain RWA Lending Platform

• Building a Multichain Tax Contract with ITS

• Moralis Presents: Building Multichain Stablecoins

We have a lot more planned for the upcoming months, so you don’t want to miss out. To stay up Follow us on X and join Discord to stay abreast of upcoming developer content and live events.

We have a lot more planned for the upcoming months, so you don’t want to miss out. To stay up to date on the latest Axelar news, make sure you are subscribed to the Axelar Devblog.

Interchain Amplifier is Going Live on Testnet

Testing phase to begin Friday.

We're excited to share that the Interchain Amplifier is going live on Testnet today and will begin a test phase!

This marks a significant milestone in enhancing blockchain interoperability. Axelar’s Amplifier capabilities seamlessly connect a broad range of blockchain consensus engines and traditional off-chain systems with minimal developer overhead.

The core components of the Interchain Amplifier on the Axelar network include:

• An on-chain message router

• Gateways

• CosmWasm methods for both receiving and sending messages

Please note that the testnet is in the testing phase, and we will be onboarding new chains there in the coming weeks, so stay tuned.

Get started here to check it out.

Developer Content Highlights

We've just published several relevant technical articles and documentation updates.

ITS

• Building Multichain Stablecoins Part One: Deploy multichain stablecoins with Axelar's Interchain Token Service: custom ERC20 integrations, cross-chain transactions, and upgradable contracts.

• Building Multichain Stablecoins Part Two: Deploy your stablecoin on a second chain, send a transaction between two chains with your token, and upgrade your token.

• How to Mint an ERC-20 Token on Base with the Interchain Token Service in 5 Steps: This step-by-step guide will teach you how to mint a multichain ERC-20 token on the Base network using Axelar’s Interchain Token Service (ITS) and use the Moralis Token API to retrieve token balances easily.

Amplifier

• Governance Proposals for Integrating New EVM-based Chains: Learn how to onboard a new chain with the Axelar Amplifier through governance proposals.

• Add rewards for Amplifier chain integrators: Learn how to add funds to the rewards pool of an Amplifier-integrated chain.

Everything Else

• How to fix command not found: axelard / tofnd: If you have followed the Axelar setup instructions for becoming a verifier but keep running into a command not found error when trying to run axelard or tofnd, try navigating to the folder your binary is in and referring directly to that binary instead of setting up an alias.

Developer Event Highlights

The Axelar team has been traveling the world to empower developers. Here are a few highlights from our talks:

• Moralis Presents: Building Multichain Stablecoins

• OnHack Summer Buildathon, July 2024

• How to Build an Advanced ITS Token

Building a Multichain Tax Contract with ITS

Join us for a live workshop where we'll build a Multichain Tax Contract using the Interchain Token Service (ITS). Using the powerful Interchain Token Service (ITS), you'll learn how to create, deploy, and manage a custom token that operates across multiple networks. Watch as we implement smart contract logic that mints, burns, and applies fees to tokens as they travel between chains.

Set a reminder here.

Follow us on X and join Discord to stay abreast of upcoming developer content and live events.

We have a lot more planned for the upcoming months, so you don’t want to miss out. To stay up to date on the latest Axelar news, make sure you are subscribed to the Axelar Devblog.

In section one, you built an upgradable custom ERC20 stablecoin, that accrues value for token holders and burns a percentage of each token transfer to address token inflation. You also began building a factory contract that integrated with Axelar's Interchain Token Service. The factory deployed your custom ERC20 as an upgradable token using create3. In this section, you will build out the functionality to deploy your token from your home chain onto a remote chain via your factory contract. You will also build out the functionality to upgrade your token to a simple V2 version. Finally, you will be able to test the token by actually sending a cross-chain transaction!

Deploy On Remote Chain

Let's build out a separate function called deployRemoteSemiNativeToken() to handle this deployment. This function will be used to deploy an instance of the SemiNativeToken discussed earlier. Recall, Semi Native tokens will not have the transaction fee redistribution and burning functionality that Native tokens have, these will be simpler tokens merely to provide some pseudo presence for your stablecoin on a chain you may not want to operate your official token on yet.

Since there is no burnRate and txFeeRate needed here, all you need to pass into this function is the name of the destination chain you want to deploy your token on.

function deployRemoteSemiNativeToken(string calldata _destChain) external payable {}

To start you will want to compute the interchainTokenId that ITS will use to register the token. To compute your token's interchainTokenId you need to hash the string interchain-token-id with the address that is deploying the token with a unique salt. This can be done as follows

bytes32 computedTokenId = keccak256(abi.encode(keccak256('its-interchain-token-id'), address(this), S_SALT_ITS_TOKEN));

Next, you will need to construct and send your GMP message to the destination chain.

Your GMP message needs to be of type bytes so let's encode the different components of your GMP message in a bytes type object. The three unique messages you will be encoding here a first your computedTokenId, second the Semi Native Token's creationCode, and last the Semi Native Token's selector. This can be done as follows

bytes memory gmpPayload = abi.encode(computedTokenId, type(SemiNativeToken).creationCode, SemiNativeToken.initialize.selector);

Now that you have your encoded message you can interact with the Axelar GasService and Gateway to send your GMP message. If this is new to you, feel free to watch this tutorial for the basics of sending a GMP message.

To pay for the transaction with the Axelar Gas Service you must call the payNativeGasForContractCall() function. This function requires the address making the payment, the destination chain, the destination address, the gmp message, and the refund address (in the event of an overly high gas payment) as its parameters.

This can be written out as follows:

   s_gasService.payNativeGasForContractCall{ value: msg.value }(
            address(this),
            _destChain,
            address(s_deployer).toString(),
            gmpPayload,
            msg.sender
        );

Note the s_deployer variable that is referenced as the destination address. This is pointing to a storage variable called s_deployer that has yet to be defined.

It can be defined up top with the rest of your storage variable and passed in as the fifth parameter to your initialize function so that your initialize function now looks like this.

   function initialize(
        IInterchainTokenService _its,
        IAxelarGasService _gasService,
        IAxelarGateway _gateway,
        AccessControl _accessControl,
        Deployer _deployer
    ) external initializer {
        s_its = _its;
        s_gasService = _gasService;
        s_gateway = _gateway;
        s_accessControl = _accessControl;
        s_deployer = _deployer;

        S_SALT_ITS_TOKEN = 0x0000000000000000000000000000000000000000000000000000000000003039; //12345
    }

Now that your s_deployer function is available you can send your GMP message to the destination chain you need to call the callContract() function on the Axelar Gateway contract. It requires similar parameters to the previous function, namely the destination chain, destination address, and GMP message.

s_gateway.callContract(_destChain, address(s_deployer).toString(), gmpPayload);

Your deployRemoteSemiNativeToken() should now be complete. Note the conditional that was added at the beginning of the function that references a new mapping you need to add in storage called s_semiNativeTokens, this will be where you register all your remote SemiNativeTokens that you want your factory contract to be aware of. In this if statement, you are making sure that the SemiNativeToken has not yet been deployed on the remote chain you're attempting to deploy to.

    function deployRemoteSemiNativeToken(string calldata _destChain) external payable {
        if (s_semiNativeTokens[_destChain] != address(0) && s_nativeToken != address(0)) revert TokenAlreadyDeployed();

        bytes32 computedTokenId = keccak256(abi.encode(keccak256('its-interchain-token-id'), address(this), S_SALT_ITS_TOKEN));

        bytes memory gmpPayload = abi.encode(computedTokenId, type(SemiNativeToken).creationCode, SemiNativeToken.initialize.selector);

        s_gasService.payNativeGasForContractCall{ value: msg.value }(
            address(this),
            _destChain,
            address(s_deployer).toString(),
            gmpPayload,
            msg.sender
        );

        s_gateway.callContract(_destChain, address(s_deployer).toString(), gmpPayload);
    }

Now that the transaction has been sent from the contract on the source chain. It needs to be received on the destination chain.

Deployer Contract

Your factory contract is now complete! However, you need to have a factory on all the destination chains that your factory will interact with. To make the factory more modular you can break up the following logic that still needs to be built out into a separate contract that you can call Deployer.

This will also be an upgradable contract with a similar initialize() function to the factory.

contract Deployer {
   IInterchainTokenService public s_its;
   AccessControl public s_accessControl;
   IAxelarGateway public s_gateway;

   bytes32 public S_SALT_ITS_TOKEN;

   /// @custom:oz-upgrades-unsafe-allow constructor
   constructor() {
       _disableInitializers();
   }
  function initialize(IInterchainTokenService _its, AccessControl _accessControl, IAxelarGateway _gateway) external initializer {
        s_its = _its;
        s_accessControl = _accessControl;
        s_gateway = _gateway;

        S_SALT_ITS_TOKEN = 0x0000000000000000000000000000000000000000000000000000000000003039; //12345
    }
}

Notice the S_SALT_ITS_TOKEN is the exact same value as the S_SALT_ITS_TOKEN in the in the TokenFactory contract. This is to ensure that the ITS token that will be wired up here on the destination chain will map to the same interchainTokenId.

Execute

Recall where you left off in the TokenFactory contract. You were able to send a cross-chain message from the source chain via the deployRemoteSemiNativeToken() function. Now, to handle that message on the destination chain you can use the execute() function.

This function takes several parameters including the _commandId, _sourceChain, _sourceAddress, and _payload. The payload is the GMP message you sent from the source chain

function execute(bytes32 _commandId, string calldata _sourceChain, string calldata _sourceAddress, bytes calldata _payload) external {}

The first line that must be written here is a call via the AxelarGateway to validateContractCall(). This function will ensure that the payload being passed in is a message that has been validated and confirmed by the Axelar validator set rather than an invalid message from a potentially malicious caller. This can be called as follows

if (!s_gateway.validateContractCall(_commandId, _sourceChain, _sourceAddress, keccak256(_payload))) revert NotApprovedByGateway();

Now that you know the payload is valid you can decode it to get the actual GMP message you passed in from the source chain. Recall, in the TokenFactory contract on the src chain encoded a computed tokenId value, the creation code of the SemiNativeToken contract, and the selector for the SemiNativeToken contract. These values can be decoded using the abi.decode() function

(bytes32 computedTokenId, bytes memory semiNativeTokenBytecode, bytes4 semiNativeSelector) = abi.decode(
    _payload,
    (bytes32, bytes, bytes4)
);

With your data now available on the destination chain you can deploy the SemiNativeToken just like you deployed the origin NativeToken on the source chain.

Since the SemiNativeToken will also be an upgradable token you must deploy the implementation first followed by the proxy that will point to the implementation. Note the salt value being passed into _create3() here is the same value in the deployHomeNative() function, meaning that the implementation address of these tokens will be the same address.

address newTokenImpl = _create3(semiNativeTokenBytecode, 0x00000000000000000000000000000000000000000000000000000000000004D2);
if (newTokenImpl == address(0)) revert DeploymentFailed();

Next, you can call the getEncodedCreationCodeSemiNative() code, this will be very similar to the getEncodedCreationCodeNative() you wrote in the TokenFactory contract.

    function _getEncodedCreationCodeSemiNative(
        address _proxyAdmin,
        address _implAddr,
        bytes32 _itsTokenId,
        bytes4 semiNativeSelector
    ) internal view returns (bytes memory proxyCreationCode) {
        //init func args
        bytes memory initData = abi.encodeWithSelector(semiNativeSelector, s_its, _itsTokenId);

        //concat bytecode + init func args
        proxyCreationCode = abi.encodePacked(type(TransparentUpgradeableProxy).creationCode, abi.encode(_implAddr, _proxyAdmin, initData));
    }

Now back in your execute() function you can call the _getEncodedCreationCodeSemiNative(). The output of this will be your proxy contract's creation code

   bytes memory creationCodeProxy = _getEncodedCreationCodeSemiNative(
            address(this),
            newTokenImpl,
            computedTokenId,
            semiNativeSelector
        );

You can now deploy your proxy contract and store its address.

address newTokenProxy = _create3(creationCodeProxy, 0x000000000000000000000000000000000000000000000000000000000000007B);
if (newTokenProxy == address(0)) revert DeploymentFailed();
s_tokenProxy = ITransparentUpgradeableProxy(newTokenProxy);

The final thing you need to do is connect your newly deployed token to ITS. You can do this exactly as you did before, by calling the deployTokenManager().

  s_its.deployTokenManager(
            S_SALT_ITS_TOKEN,
            '',
            ITokenManagerType.TokenManagerType.MINT_BURN,
            abi.encode(msg.sender.toBytes(), newTokenProxy),
            0
        );

Note, that the parameters passed in are exactly the same as in the TokenFactory contract, the only difference is the TokenManagerType. Rather than passing in a lock/unlock token manager, you can pass a mint/burn, the reason being that this execution is taking place on a remote chain rather than the source chain where you want to lock up bridged tokens.

Your completed execute() function should be as follows

    function execute(bytes32 _commandId, string calldata _sourceChain, string calldata _sourceAddress, bytes calldata _payload) external {
        if (!s_gateway.validateContractCall(_commandId, _sourceChain, _sourceAddress, keccak256(_payload))) revert NotApprovedByGateway();

        (bytes32 computedTokenId, bytes memory semiNativeTokenBytecode, bytes4 semiNativeSelector) = abi.decode(
            _payload,
            (bytes32, bytes, bytes4)
        );

        address newTokenImpl = _create3(semiNativeTokenBytecode, 0x00000000000000000000000000000000000000000000000000000000000004D2);
        if (newTokenImpl == address(0)) revert DeploymentFailed();

        bytes memory creationCodeProxy = _getEncodedCreationCodeSemiNative(
            address(this),
            newTokenImpl,
            computedTokenId,
            semiNativeSelector
        );

        address newTokenProxy = _create3(creationCodeProxy, 0x000000000000000000000000000000000000000000000000000000000000007B);
        if (newTokenProxy == address(0)) revert DeploymentFailed();

        s_tokenProxy = ITransparentUpgradeableProxy(newTokenProxy);

        // Deploy ITS
        s_its.deployTokenManager(
            S_SALT_ITS_TOKEN,
            '',
            ITokenManagerType.TokenManagerType.MINT_BURN,
            abi.encode(msg.sender.toBytes(), newTokenProxy),
            0
        );
    }

Optional Callback

Axelar allows for two-way callback functions to have an immediate transaction back from the destination chain to the source chain. In this case you can send the address of your newly deployed SemiNativeToken proxy back to your source chain's TokenFactory contract.

This can be done very easily in your execute() function in the Deployer contract. Right underneath where you called deployTokenManager() you can call the callContract() function.

s_gateway.callContract(_sourceChain, _sourceAddress, abi.encode(newTokenProxy));

This call will make a cross-chain transaction back to the source chain to the source address that sends the original transaction. You can encode the address of the newTokenProxy as the GMP message to be sent back to the TokenFactory contract.

Now back on the TokenFactory contract you will need to implement and execute() method just like you did on the Deployer contract to handle the incoming GMP message.

In this execute function you will of course need to implement the validateContractCall() function again and then you can decode the GMP message and store in the TokenFactory contract.

  function execute(bytes32 _commandId, string calldata _sourceChain, string calldata _sourceAddress, bytes calldata _payload) external {
        if (!s_gateway.validateContractCall(_commandId, _sourceChain, _sourceAddress, keccak256(_payload))) revert NotApprovedByGateway();
        s_semiNativeTokens[_sourceChain] = abi.decode(_payload, (address));
    }

Upgrade SemiNativeToken

The final bit of functionality for this demo is the ability to upgrade your token directly from the Deployer contract. In the event that you choose to upgrade your SemiNativeToken.

To upgrade your token's proxy you will need to trigger the upgradeAndCall() function from your Proxy Admin contract. In your Deployer function create a new function called upgradeSemiNativeToken()

function upgradeSemiNativeToken(address _proxyAdmin) external onlyAdmin {}

First, you need to deploy a new implementation contract for your proxy to point to. For the purpose of this demo you can simply deploy a new SemiNativeTokenV2 contract with the exact same code and add a new function to it called isV2() that returns a bool .

   address newTokenImpl = _create3(
            type(SemiNativeTokenV2).creationCode,
            0x0000000000000000000000000000000000000000000000000000000000003439
        );
        if (newTokenImpl == address(0)) revert DeploymentFailed();

Now with your upgradeAndCall() function deployed, you can upgrade the token proxy to the newTokenImpl that you just deployed.

ProxyAdmin(_proxyAdmin).upgradeAndCall(s_tokenProxy, newTokenImpl, '');

At this point, your proxy should successfully be pointing to a new implementation address!

Deploy

It is critical for the _create3() addresses written out in the Factory and Deployer contracts to work correctly that these contracts are also the same address otherwise the contracts they deploy will be different from one another. To deploy these contracts you can use Axelar's create3Deployer script from Axelar's gmp-sdk package.

You can deploy the contract via Hardhat Tasks. Let's start with Moonbase.

Moonbase

Define your task like this

task('deployMoonbase', 'deploy deployer on remote chain (Moonbase for testing').setAction(async (taskArgs, hre) => {}

Now in the task you can deploy the contract for Moonbase.

First, you need to call the getWallet() function, which is written up in the utils folder. This will get your live wallet for the Moonbase chain. Make sure to include your private key in the .env file for the wallet to work correctly.

const wallet = getWallet(chains[1].rpc, hre);

Now you can deploy your upgradable AccessControl and Deployer contract on Moonbase. To do this simply call the create3DeployContract() from the Create3Deployer script.

    const implAccessControl = await create3DeployContract(create3DeployerAddress, wallet, AccessControl, 1720, []);
    const implDeployer = await create3DeployContract(create3DeployerAddress, wallet, Deployer, 1721, []);

    const proxyAccess = await create3DeployContract(create3DeployerAddress, wallet, Proxy, 1722, [
        implAccessControl.address,
        wallet.address,
        '0x',
    ]);
    const proxyDeployer = await create3DeployContract(create3DeployerAddress, wallet, Proxy, 1723, [
        implDeployer.address,
        wallet.address,
        '0x',
    ]);

    console.log(`proxyAccess ${proxyAccess.address}`);
    console.log(`proxyDeployer ${proxyDeployer.address}`);

Once deployed you can initialize your two newly deployed contracts.

const AccessControlFactory = await ethers.getContractFactory('AccessControl');
const DeployerFactory = await ethers.getContractFactory('Deployer');

const proxyAccessControlInstance = await AccessControlFactory.attach(proxyAccess.address);
const proxyDeployerInstance = await DeployerFactory.attach(proxyDeployer.address);

await proxyAccessControlInstance.initialize(wallet.address);
await proxyDeployerInstance.initialize(chains[1].its, proxyAccess.address, chains[1].gateway);

To trigger this hardhat script in your CLI type

hh deployMoonbase --network moonbase

Celo

The same task can be set for the Celo deployment. The one difference is that this time you will need to pass in the address of the deployer that you TokenFactory will be interacting with.

This can be done with the addParam call.

task('deployHomeCelo', 'deploy factory on home chain, (celo for testing)')
    .addParam('deployer', 'Deployer on dest chain')
    .setAction(async (taskArgs, hre) => {
        const wallet = getWallet(chains[0].rpc, hre);

        const implAccessControl = await create3DeployContract(create3DeployerAddress, wallet, AccessControl, 1720, []);
        const implFactory = await create3DeployContract(create3DeployerAddress, wallet, Factory, 1721, []);

        const proxyAccess = await create3DeployContract(create3DeployerAddress, wallet, Proxy, 1722, [
            implAccessControl.address,
            wallet.address,
            '0x',
        ]);

        const proxyFactory = await create3DeployContract(create3DeployerAddress, wallet, Proxy, 1723, [
            implFactory.address,
            wallet.address,
            '0x',
        ]);

        console.log(`celo contract address: ${proxyFactory.address}`);

        const AccessControlFactory = await ethers.getContractFactory('AccessControl');
        const TokenFactoryFactory = await ethers.getContractFactory('TokenFactory');

        const proxyAccessControlInstance = await AccessControlFactory.attach(proxyAccess.address);
        const proxyFactoryInstance = await TokenFactoryFactory.attach(proxyFactory.address);

        await proxyAccessControlInstance.initialize(wallet.address);

        await proxyFactoryInstance.initialize(
            chains[0].its,
            chains[0].gasService,
            chains[0].gateway,
            proxyAccess.address,
            taskArgs.deployer,
        );
    });

Great! At this point once you run hh deployHomeCelo --deployer "<YOUR_DEPLOYER_ADDRESS>" --network celo you should get your home chain's TokenFactory address in the cli.

Test

Let's now test this contract using the hardhat cli

To wire up your contract to your cli you type in

hh console --network <YOUR_HOME_CHAIN>

const Contract = await ethers.getContractFactory("TokenFactory")
const contract = await Contract.attach("<YOUR_CONTRACT_ADDRESS>")

Now with your contract connected to the cli, let's use your newly deployed TokenFactory on the home chain to deploy a NativeToken on your home chain. You can do this by calling the deployHomeNative() function.

await contract.deployHomeNative()

this should return a transaction receipt in your CLI and store the deployed instance of your contract in the s_tokenProxy storage variable. Query the variable to make sure you have the address stored correctly.

await contract.s_tokenProxy()
--> <"YOUR_TOKEN_ADDRESS"> //should be returned

Now with your token deployed on the home chain you can call the deployRemoteSemiNativeToken() on the remote chain.

await contract.deployRemoteSemiNativeToken("moonbeam", {value: "1000000000000000000"})

This should return a transaction hash that you can view on the Axelarscan Block Explorer. While this cross-chain transaction is executing you can interact with your token on the home chain to mint some new tokens to your contract.

You can wire it up similarly to how you wired up the TokenFactory contract.

const Contract = await ethers.getContractFactory("NativeToken")
const contract = await Contract.attach("<YOUR_TOKEN_ADDRESS")

Now with your token wired up you can mint tokens to your account that you will transfer to the destination chain.

await contract.mint("YOUR_RECEIVING_ADDRESS", 1000000000000000000)

You may need to specify a gasLimit when running the previous transaction.

At this point you should have a balance of your new token in your wallet equal to what you just minted. You can now transfer this token between accounts to make sure that the burn and txFee deductions are working correctly.

Cross Chain Transfer

With your token now deployed on multiple chains and a balance minted on the home chain you can now transfer your token from the home chain to the remote chain.

If you set a lock/unlock transaction token manager on the home chain then you will need to approve the Interchain Token Service (ITS) contract to handle the tokens on your behalf. This is because ITS will call the transferFrom() function when sending the cross chain transaction.

await contract.approve("0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C", 1000000000000000000)

You can now interact with ITS programmatically to trigger the cross-chain transfer or you can go through the explorer.

To send the transfer from the home chain to the remote chain you will need to call the interchainTransfer() function on the ITS contract.

The following params are required

1. payableAmount: The gas amount to be paid for the cross-chain tx

2. tokenId: The interchain token id of your token. You can find your tokenId in the logs of NativeTokenDeployed() event

3. destinationChain: The chain where your Deployer contract was deployed to

4. destinationAddress: The address you want to receive the tokens on the destination chain

5. amount: Amount of tokens to be sent

6. metadata: Data to be sent with your token. You can leave this as 0x for this example

7. gasValue: The gas amount to be paid for the cross-chain tx (in wei this time)

This should trigger another cross-chain transaction that you can track on Axelarscan.

Once this transaction has executed you should now see your balance increment on the destination chain!

Upgrade

To upgrade the token you can call the upgradeSemiNativeToken() function your deployer

await contract.upgradeSemiNativeToken("<YOUR_PROXY_ADMIN_ADDRESS>")

Once this is executed. You can query the isV2() token function at the same deployed token proxy address at the destination chain, which should now be returning true

const Contract = await ethers.getContractFactory("SemiNativeTokenV2")
const contract = await Contract.attach("<YOUR_PROXY_ADDRESS>")

await contract.isV2()
-> true

Conclusion

Congratulations if you made it until the end of this tutorial! You have now deployed an upgradable custom stablecoin with transaction fee redistribution to token holders. You have used create3 to deploy all your contracts at static addresses across different chains.

If you were unable to code along you take a look at the completed code here.

Interchain Token Service is a new initiative with the ability to provide simple cross-chain integration for your ERC20 token, we are excited to see what you will build with ITS.

If you have a new token you wish to deploy or an existing token you are looking to integrate with ITS you are more than welcome to reach out to Interop Labs team to see how we can help.

This blog assumes you have an understanding of how to use Hardhat, a basic understanding of upgradable contracts, and how ERC20s operate.

Note: The token being built here contains many of the properties that can be used for a stablecoin such as transaction fee redistribution to token holders and transaction burning to contain inflation. The token will not contain all the components of a complete stablecoin. Rather the blog will focus more on the integration of the cross-chain components and testing of the token.

What is Interchain Token Service?

The Interchain Token Service (ITS) allows for the integration of tokens across many different blockchains. It can support the deployment of fresh new Interchain Tokens across multiple chains and it can also connect pre-existing custom ERC20s. ITS also comes with an easy-to-use frontend, which offers a no-code solution for deploying your token across any connected chain that you choose.

Objective

In this blog, you will be focusing on custom ERC20 token integrations to ITS. Custom tokens can have more advanced functionality than the InterchainTokens that ITS deploys out of the box in its no-code solution. The token that you will be building will be an upgradable token that will be deployed using Axelar's create3 service. The token will also have transaction fee redistribution to token holders and a burning mechanism, that burns a small percentage of each transaction to simulate inflation control.

In addition to the token itself, you will be using a TokenFactory contract that you will build out to deploy your token across different chains. There will be two types of tokens that will be built out, NativeToken and SemiNativeToken. The NativeToken will be the main token with the previously discussed features. The SemiNativeToken on the other hand will be a simpler ERC20 that will also be deployed through the factory. The reason for the two different tokens is to simulate a common issue, which teams in the stablecoin space face. Oftentimes, teams may be restricted to only officially operate on a certain group of chains, perhaps due to regulations or other restrictions. For the chains, that a team is regulated to operate on they can use the NativeToken but for those chains where they are not regulated, the simpler SemiNativeToken can be deployed by anyone via the TokenFactory. The SemiNativeToken will eventually be replaced by a NativeToken once the team is eligible to fully operate on that chain.

Architecture

This project will be built using Hardhat (but it can of course be built out with Foundry as well). The five contracts you'll be interacting with are the TokenFactory, TokenDeployer, NativeToken, SemiNativeToken, and AccessControl.

Let's build!

Start by cloning the starter code.

NativeToken

You can begin by writing up the NativeToken contract.

Start by giving the token a name and importing the required OpenZeppelin helper contracts.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import '@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol';
import '@openzeppelin/contracts-upgradeable/token/ERC20/extensions/ERC20BurnableUpgradeable.sol';
import '@openzeppelin/contracts-upgradeable/token/ERC20/extensions/ERC20PausableUpgradeable.sol';
import '@openzeppelin/contracts-upgradeable/token/ERC20/extensions/ERC20PermitUpgradeable.sol';
import '@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol';

contract NativeToken is  Initializable, ERC20Upgradeable, ERC20BurnableUpgradeable, ERC20PausableUpgradeable, ERC20PermitUpgradeable {}

Next, go ahead and create the initializer for the token.

 /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize() public initializer {
        __ERC20_init('USD Token', 'USD');
        __ERC20Burnable_init();
        __ERC20Pausable_init();
        __ERC20Permit_init('USD Token');
    }

Once the initializer has been implemented you can implement two publicly available mint() and burn() functions.

 function mint(address _to, uint256 _amount) public whenNotPaused isBlacklisted(_to) {
     _mint(_to, _amount);
 }

 function burn(address _from, uint256 _amount) public whenNotPaused {
     _burn(_from, _amount);
 }

Note the whenNotPaused modifier on both the mint() and burn() functions which will be activated in case of an emergency.

You also need to override the _update() function. This function is written out in the ERC20Upgradeable contract that you're inheriting from. The _update() function is used when transferring a value amount of tokens from one address to another. You will need to eventually implement the custom burning and transaction fee logic in this function.

For now, implement it as follows:

    function _update(address from, address to, uint256 value)
        internal
        override(ERC20Upgradeable, ERC20PausableUpgradeable) whenNotPaused
    {
        ERC20Upgradeable._update(from, to, value);
    }

Great! At this point, you should have a working ERC20 token that can be upgradable!

Let's build this out a bit further. As mentioned before we want the token to have a burnRate for every transaction that is sent and a fee which will be paid out to token holders.

Set the burnRate and txFeeRate in storage as two public uint256 variables. You can set a value for them in your initialize() function

Your contract should now look like this.

    uint256 public s_burnRate;
    uint256 public s_txFeeRate;


    /*************\
     INITIALIZATION
    /*************/

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize(
        uint256 _burnRate,
        uint256 _txFeeRate
    ) public initializer {
        __ERC20_init('USD Token', 'USD');
        __ERC20Burnable_init();
        __ERC20Pausable_init();
        __ERC20Permit_init('USD Token USD');

        s_burnRate = _burnRate;
        s_txFeeRate = _txFeeRate;
    }

Now, back in your _update() function you can include some logic that will occur on every token transfer.

First, you set the burnAmount by multiplying the value of the transfer by the s_burnRate you set and then divide that by 1e18 (assuming your token has 18 decimal points). The same can be done for the transaction fee.

Now that you have the burnAmount and the fee you can subtract those two values from the actual amount being sent.

This can be written out as follows

     uint256 burnAmount = (_value * s_burnRate) / 1e18;
     uint256 fee = (_value * s_txFeeRate) / 1e18;

     uint256 amountToSend = _value - fee - burnAmount;

Once you have the amountToSend you can burn the burnAmount and update a new storage variable called s_rewardPool with the fee.

Worth noting, is you only want to deduct these fees when a token is being transferred from one address to another as opposed to when a new token is being minted. The way to do this is to check if the _from address is address(0). If it is, then return the function before calling the aforementioned functionality. The completed _update() function should be as follows.

    function _update(
        address _from,
        address _to,
        uint256 _value
    ) internal override(ERC20Upgradeable, ERC20PausableUpgradeable) whenNotPaused {
        if (_from == address(0)) {
            // Minting case, do not apply burn and fee
            ERC20Upgradeable._update(_from, _to, _value);
            return;
        }
        uint256 burnAmount = (_value * s_burnRate) / 1e18;
        uint256 fee = (_value * s_txFeeRate) / 1e18;

        uint256 amountToSend = _value - fee - burnAmount;

        if (burnAmount > 0) _burn(_from, burnAmount);

        if (amountToSend + burnAmount + fee != _value) revert InvalidSendAmount();
        s_rewardPool += fee;
        ERC20Upgradeable._update(_from, _to, amountToSend);
        emit RewardAdded(fee);
    }

Now that there is a reward pool accruing for token holders, you can include a simple claimRewards() function that allows token holders to claim a proportional reward for the number of tokens that they hold.

To calculate the reward you can check the balance of tokens that they have multiplied by the reward pool divided by the total supply of the token. Let's extract this into its own helper function called _calculateReward()

    function _calculateReward(address _account) internal view returns (uint256) {
        if (totalSupply() == 0) return 0;
        return (s_rewardPool * balanceOf(_account)) / totalSupply();
    }

Now the claimRewards() function can call this function and mint an appropriate reward based on the output of the calculateReward() function. The claimRewards() function can be written as follows

   function claimRewards() external whenNotPaused {
        uint256 reward = _calculateReward(msg.sender);
        s_rewardPool -= reward;
        _mint(msg.sender, reward);
        emit RewardClaimed(msg.sender, reward);
    }

The final bit of functionality this token needs is the ability to alter these rates going forward. Let's add those functions as follows

  function setBurnRate(uint256 newBurnRate) external whenNotPaused  {
        s_burnRate = newBurnRate;
  }

  function setTxFee(uint256 newRewardRate) external whenNotPaused  {
        s_txFeeRate = newRewardRate;
  }

Great! At this point, most of the token logic is now complete. The only issue you might want to restrict is who can call critical functions such as setBurnRate and setTxFee().

AccessControl

To address this you will add a new contract called AccessControl. The AccessControl will inherit from OpenZeppelin's AccessControlUpgradeable contract.

The AccessControl contract will allow for several roles including admin role, minter role, and blacklisted role. You will need a mapping to track the different addresses that have been assigned to specific roles. The completed AccessControl will look something like this.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import '@openzeppelin/contracts-upgradeable/access/AccessControlUpgradeable.sol';

contract AccessControl is AccessControlUpgradeable {
    bytes32 public constant MINTER_ROLE = keccak256('MINTER_ROLE');
    bytes32 public constant PAUSER_ROLE = keccak256('PAUSER_ROLE');
    bytes32 public constant BLACKLIST_ADMIN_ROLE = keccak256('BLACKLIST_ADMIN_ROLE');

    // eligible minters
    mapping(address => bool) private _minterAddresses;

    // blacklisted (receiver) addresses
    mapping(address => bool) private _blacklistedAddresses;

    function initialize(address _defaultAdmin) public initializer {
        __AccessControl_init();
        _grantRole(DEFAULT_ADMIN_ROLE, _defaultAdmin);
        _grantRole(MINTER_ROLE, _defaultAdmin);
        _grantRole(BLACKLIST_ADMIN_ROLE, _defaultAdmin);
    }

    function addAdminRole(address _address) external onlyRole(DEFAULT_ADMIN_ROLE) {
        grantRole(DEFAULT_ADMIN_ROLE, _address);
    }

    function removeAdminRole(address _address) external onlyRole(DEFAULT_ADMIN_ROLE) {
        revokeRole(DEFAULT_ADMIN_ROLE, _address);
    }

    function addNewMinter(address _address) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _minterAddresses[_address] = true;
    }

    function removeMinter(address _address) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _minterAddresses[_address] = false;
    }

    function addToBlacklist(address _address) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _blacklistedAddresses[_address] = true;
    }

    function removeFromBlacklist(address _address) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _blacklistedAddresses[_address] = false;
    }

    function isAdmin(address _address) external view returns (bool) {
        return hasRole(DEFAULT_ADMIN_ROLE, _address);
    }

    function isWhitelistedMinter(address _address) external view returns (bool) {
        return _minterAddresses[_address];
    }

    function isBlacklistedReceiver(address _address) external view returns (bool) {
        return _blacklistedAddresses[_address];
    }
}

Note: For blacklisting, we included a simplified mapping to collect any potential blacklisted addresses from receiving your token. In production, it would be recommended to use a service such as ChainAnalysis, which has an easy-to-use Oracle that you can integrate with your contract that tracks sanctioned addresses that regulators would prohibit your token from being sent to.

Now with your AccessControl set you can return to your NativeToken contract to integrate with the AccessControl contract.

First, you need to import the AccessControl contract to your token.

import './AccessControl.sol';

Next, in the initialize function of your Token contract, make sure to pass in the address of your AccessControl contract and then store in a storage variable.

Your initialize function should now look like this.

  function initialize(
        AccessControl _accessControl,
        uint256 _burnRate,
        uint256 _txFeeRate
    ) public initializer {
        __ERC20_init('USD Token', 'USD');
        __ERC20Burnable_init();
        __ERC20Pausable_init();
        __ERC20Permit_init('USD Token');

        s_accessControl = _accessControl;

        s_burnRate = _burnRate;
        s_txFeeRate = _txFeeRate;
    }

Now you can add a modifier to use the AccessControl contract to restrict certain functionality to specific addresses granted a given role.

For example, isAdmin can restrict the msg.sender to be a specific whitelisted admin.

 modifier isAdmin() {
        if (s_accessControl.isAdmin(msg.sender)) revert OnlyAdmin();
        _;
    }

You can use the isAdmin modifier for your setBurnRate() and setTxFeeRate() modifiers.

Great! At this point, you should have all the functionality you need for your NativeToken! Now you need to deploy your token. For this, you can use a Factory contract to deploy the token on your home chain as well as other remote chains.

Token Factory

In this section, you will build the TokenFactory which will deploy the NativeToken you have just written on the home chain and also send a General Message Passing (GMP message) to a remote blockchain where you can deploy your token as well!

The factory will deploy a TransparentProxy for your token so that your token is upgradable. It will also use create3 so that your token is at the same address across all chains that you choose to deploy on.

Much like the NativeToken contract, this contract will also be upgradable. So let's start with the initialize function.

The initialize function will take in several params including the address of the InterchainTokenService, the addresses of Axelar's Gateway and GasService contracts (which you will need for sending GMP messages), and the address of your AccessControl contract.

You will also need the appropriate storage variables to store these parameters in. Your TokenFactory contract should look like this now.

import '@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol';
import '@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGateway.sol';
import '@axelar-network/interchain-token-service/contracts/interfaces/IInterchainTokenService.sol';
import '@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol';  
contract TokenFactory {   
    IInterchainTokenService public s_its;
    AccessControl public s_accessControl;
    IAxelarGasService public s_gasService;
    IAxelarGateway public s_gateway;    

    /*************\
     INITIALIZATION
    /*************/
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize(
        IInterchainTokenService _its,
        IAxelarGasService _gasService,
        IAxelarGateway _gateway,
        AccessControl _accessControl,
    ) external initializer {
        s_its = _its;
        s_gasService = _gasService;
        s_gateway = _gateway;
        s_accessControl = _accessControl;
    }
}

With your initializer being built you can now move on to actually deploying the token.

Let's write a specific function for deploying the token on your home chain called deployHomeNative()

Since your NativeToken requires a burnRate and txFeeRate you must make sure to pass that into your deployHomeNative() function to set those rates for the token. The function should look like this

function deployHomeNative(uint256 _burnRate, uint256 _txFeeRate) external onlyAdmin returns (address newTokenProxy) {}

Note the onlyAdmin modifier can be defined exactly as you did previously in the Token contract so that only your team can deploy the original token on the home chain.

Before writing up the rest of this function you will need to import the Create3.sol contract from the axelar-gmp-sdk dependency. This will give you access to the _create3() function that you will use to deploy the contract. Import the dependency as follows

import '@axelar-network/axelar-gmp-sdk-solidity/contracts/deploy/Create3.sol';

Now with the dependency imported, you can have your contract inherit from the Create3 contract.

When deploying with create3() you will need to pas in a bytes32 salt, which will be used to determine the address of your contract. For simplicity you can defined to salts in the beginning of the deployHomeNative() function. The first salt can be for the deployment of your proxy and the second for the deployment of your implementation.

bytes32 SALT_PROXY = 0x000000000000000000000000000000000000000000000000000000000000007B; //123
bytes32 SALT_IMPL = 0x00000000000000000000000000000000000000000000000000000000000004D2; //1234

These hexes correspond to the numbers 123 for the proxy and 1234 for the implementation.

Next, you can deploy the implementation of the NativeToken contract. (Recall since the contract is going to be an upgradable contract you need to deploy both a proxy and implementation).

To deploy the implementation simply call the _create3() internal function, which is defined in the Create3 contract that you inherited from before.

// Deploy implementation
address newTokenImpl = _create3(type(NativeToken).creationCode, SALT_IMPL);
if (newTokenImpl == address(0)) revert DeploymentFailed();

The _create3() takes the deployment bytecode of the NativeToken contract and the salt that you already defined. You can then run a sanity check to make sure that the deployment was in fact successful and did not return a 0 address.

Now with your implementation contract deployed, you can move on to the proxy. Deploying the proxy will be a bit different than deploying the implementation, as you will technically be deploying a TransparentUpgradeableProxy that is pointing to your implementation. To do this you can define a helper function called _getEncodedCreationCodeNative().

This function will take in your ProxyAdmin, your implementation address, your _burnRate, and your _txFeeRate.

Your function signature should look like this

    function _getEncodedCreationCodeNative(
        address _proxyAdmin,
        address _implAddr,
        uint256 _burnRate,
        uint256 _txFeeRate
    ) internal view returns (bytes memory proxyCreationCode) {}

Now in this function, you can set your initData for the Token itself. Recall these are the three params that you required in your initialize function for the NativeToken contract (accessControl, burnRate, and txFeeRate). You can encode these three params into a single bytes variable that will be used when initializing your proxy

bytes memory initData = abi.encodeWithSelector(NativeToken.initialize.selector, s_accessControl, s_its, _burnRate, _txFeeRate);

Now (still in your _getEncodedCreationCodeNative() function). You can encode the initData you just defined along with the _proxyAdmin and the _implAddr that the TransparentProxy will require when it's being deployed. You can then encode that with the creation code of the TransparentProxy itself. This all translates into the following line of code

proxyCreationCode = abi.encodePacked(type(TransparentUpgradeableProxy).creationCode, abi.encode(_implAddr, _proxyAdmin, initData));

So your completed _getEncodedCreationCodeNative() function now looks like this:

    function _getEncodedCreationCodeNative(
        address _proxyAdmin,
        address _implAddr,
        uint256 _burnRate,
        uint256 _txFeeRate
    ) internal view returns (bytes memory proxyCreationCode) {
        bytes memory initData = abi.encodeWithSelector(NativeToken.initialize.selector, s_accessControl, s_its, _burnRate, _txFeeRate);

        proxyCreationCode = abi.encodePacked(type(TransparentUpgradeableProxy).creationCode, abi.encode(_implAddr, _proxyAdmin, initData));
    }

Back to your deployHomeNative() function you can now trigger the _getEncodedCreationCodeNative() function underneath where your deployed the implementation contract. The output of the _getEncodedCreationCodeNative() function will be the creation code of your proxy contract.

bytes memory proxyCreationCode = _getEncodedCreationCodeNative(msg.sender, newTokenImpl, _burnRate, _txFeeRate);

With the proxyCreationCode now available, you can call _create3() once again (exactly as you did for the implementation contract) and pass in the proxyCreationCode as the first parameter and the SALT_PROXY as the salt value. Let's also store the address of the deployed proxy in a storage variable called s_nativeProxy.

// Deploy the proxy
newTokenProxy = _create3(proxyCreationCode, SALT_PROXY);
if (newTokenProxy == address(0)) revert DeploymentFailed();

s_nativeToken = newTokenProxy;

Now that you have stored the address of the proxy you can go back to the top of the deployHomeNative() function and add in a quick check to make sure that no native token has been deployed before. If one has been deployed then you can revert the transaction.

if (s_nativeToken != address(0)) revert TokenAlreadyDeployed();

Awesome! At this point once you call the deployHomeNativeFunction() you should now be able to deploy an upgradable version of the NativeToken stablecoin. But there is still more to do! Recall, that you want to be able to send cross-chain transactions with this token via ITS.

ITS Integration

To integrate your token with ITS you will need to deploy a token manager. A Token Manager is a separate contract that will help facilitate the integration of your token with ITS. Some of its responsibilities include setting flow limits (akin to rate limits) for your token, locking, burning, and minting tokens for cross-chain transactions. A token cannot send cross-chain transactions via ITS unless it has been successfully registered with its own unique token manager.

To deploy a token manager for your token you can simply call the function deployTokenManager() which is defined on the ITS contract that you passed into your initialize function.

The deployTokenManager() takes the following params. First, it needs a salt, this salt will be used to generate your tokens unique interchainTokenId. This token will be used to track your authentic token deployment across all chains that your token is wired up to do cross-chain transfers. Next, you need to pass in the destination chain in case you're doing a cross-chain deployment of the token manager. In this case, you're deploying the token manager for the chain you're already on since there is no destination chain needed you can simply pass in an empty string here. You then need to pass in the type of token manager you want. For this demo you can use the LOCK_UNLOCK token manager, this will lock your token on the home chain and unlock that token when it's bridged back from one of the remote chains. Next, you need to pass in the params. This is a bytes encoding of the address that will be the operator of the token and the address of the token itself. The operator is a role that allows a given address to adjust flow limits for the token. The fifth and final parameter is the gasValue this will be used to pay for the cost of a cross-chain token transfer, since you are doing a cross-chain deployment you can keep this as zero.

Still, in your deployHomeNative() function, you can call the deployTokenManager() function like this

s_its.deployTokenManager(
    S_SALT_ITS_TOKEN,
    '',
    ITokenManagerType.TokenManagerType.LOCK_UNLOCK,
    abi.encode(msg.sender.toBytes(), newTokenProxy),
    0
);

You can add a new event at the very bottom of the function to mark a successful token deployment and registration and that is it! The completed function should now look like this.

    function deployHomeNative(uint256 _burnRate, uint256 _txFeeRate) external onlyAdmin returns (address newTokenProxy) {
        if (s_nativeToken != address(0)) revert TokenAlreadyDeployed();

        bytes32 SALT_PROXY = 0x000000000000000000000000000000000000000000000000000000000000007B; //123
        bytes32 SALT_IMPL = 0x00000000000000000000000000000000000000000000000000000000000004D2; //1234

        // Deploy implementation
        address newTokenImpl = _create3(type(NativeToken).creationCode, SALT_IMPL);
        if (newTokenImpl == address(0)) revert DeploymentFailed();

        // Generate Proxy Creation Code
        bytes memory proxyCreationCode = _getEncodedCreationCodeNative(msg.sender, newTokenImpl, _burnRate, _txFeeRate);

        // Deploy proxy
        newTokenProxy = _create3(proxyCreationCode, SALT_PROXY);
        if (newTokenProxy == address(0)) revert DeploymentFailed();
        s_nativeToken = newTokenProxy;

        // Deploy ITS
        bytes32 tokenId = s_its.deployTokenManager(
            S_SALT_ITS_TOKEN,
            '',
            ITokenManagerType.TokenManagerType.LOCK_UNLOCK,
            abi.encode(msg.sender.toBytes(), newTokenProxy),
            0
        );

        emit NativeTokenDeployed(newTokenProxy, tokenId);
    }

Great! At this point when this function is called you will have successfully deployed an upgradeable NativeToken AND connected it to the Interchain Token Service!

Conclusion

In this section, you have built a custom ERC20 token that can burn tokens at a set burn rate for each token transfer and accrue proportional rewards for token holders. The token's roles are controlled by the Access Control contract. Finally, you wrote up a factory contract to deploy your custom token as an upgradable token using create3 to have a predictable contract address and integrated your newly deployed token with ITS.

In part two, you will continue to build out your Token Factory so that you can deploy your custom token on other blockchains.

The complete code for this section can be found here.

Make sure that you have done the following first:

• Downloaded the axelard binary and made it executable with chmod a+x axelard

• Downloaded the tofnd binary and made it executable with chmod a+x tofnd-darwin-[version]

• Downloaded the wasmvm (libwasmvm) library

The solution is simple: Don’t symlink or create an alias to the binary. Just cd into the directory that your executable binary is in and run it with its full name.

For example, if you have the executable axelard binary in your Downloads folder, cd into the Downloads folder and run ./axelard version instead of running axelard version from any folder.

To check that things are working:

• Instead of axelard version, run ./axelard version

• Instead of axelard q wasm libwasmvm-version, run ./axelard q wasm libwasmvm-version

• Instead of tofnd --help, run tofnd-darwin-[version] --help

Celebrating 2 Million Cross-Chain Transactions and 13 million Blocks

Special thanks to all the protocols, builders, and early adopters who have contributed to the growth of the Axelar ecosystem! We now have over 1.5 million testnet transactions. 🦾 This is just the beginning ⏩ Visit https://axelarscan.io for more.

Developer Content Highlights

We've just published several relevant technical articles and documentation updates.

Amplifier

• Verifier rewards: Understand the Amplifier rewards contract.

• Rewards for Amplifier chain integrators: Learn how to add funds to the rewards pool of an Amplifier-integrated chain.

ITS

• Interchain Token Service Roadmap: Our roadmap includes migrations to governance, deploying advanced token management features, and expanding support for more chains.

Axelar Gas Service

• Estimate and Pay Gas: Learn how gas estimation works, types of Axelar gas payment and how you can pay gas

Additional chain support

• Axelar Adds Support for Polygon Amoy and Linea Sepolia: Axelar now supports Polygon Amoy (Sepolia) and Linea Sepolia on testnet.

Developer Event Highlights

The Axelar team has been traveling the world to empower developers. Here are a few highlights from our talks:

• Build a Farcaster Frame to bridge ERC-20 token with ITS

• Lagos Blockchain week

• Send Cross-chain Messages with Axelar GMP

Upcoming event: How to Build an Advanced ITS Token

In this workshop, you will learn about building advanced cross-chain contracts with ITS. Join us for a walkthrough on how to build a customized ERC20 token equipped with cross-chain functionality. We will then deploy an upgradeable token with advanced functionality.

Inspired by real-world use cases, the token can take two forms: an advanced token for chains where regulators may approve you to operate and a more straightforward canonical token that can be upgraded to the more advanced token when you're approved to operate on that chain.

Don’t forget to set a reminder here for the event!

We have a lot more planned for the upcoming months, so you don’t want to miss out. To stay up to date on the latest Axelar news, make sure you are subscribed to this Developer Newsletter.

The Ethereum community maintains two primary public testnets: Sepolia, one of Ethereum’s most prominent proof-of-stake (PoS) testnets, and Goerli, which was recently sunsetted.

We are happy to announce that Axelar now supports Polygon Amoy (Sepolia) and Linea Sepolia on testnet. This follows our previous announcement, "Goerli Deprecation and New Ethereum Sepolia, Layer 2 Sepolia Support with Axelar," aimed at continuing our support for developers building innovative applications. Check the full list of supported networks here.

Sepolia Test Network on Axelar

The deprecation of Goerli and the shift towards Sepolia and L2 support represent a significant milestone in Ethereum's development. These changes underscore our commitment to providing our community with the most advanced and efficient tools.

We understand that transitions can be challenging, but we are here to support you every step of the way. Our team is committed to making the transition smooth for developers and users. We provide resources, documentation, and support throughout the process. Please open an issue on our Github support repository if you need additional help.

Stay tuned for more updates, and thank you for being a part of this journey with us.

Axelar Interchain Amplifier now integrates with Rollkit

The Axelar Foundation has announced an integration with Celestia Labs, simplifying multichain interoperability for sovereign blockchains built with Rollkit, the first sovereign rollup framework. This collaboration supports the modular blockchain vision, enabling seamless multichain development for new blockchains.

This integration of Rollkit and Axelar Interchain Amplifier will introduce interoperability toolkits connecting rollups across EVM, Cosmos, Bitcoin, Polkadot, and beyond. Interop Labs, the initial developer of the Axelar network, will build the necessary smart contracts and tooling to integrate Interchain Amplifier with Rollkit, further advancing Web3 scalability and user experience.

ICYMI: Axelar Interchain Amplifier: Now live on Devnet!

Developer Content Highlights

We've just published several relevant technical articles and documentation updates:

• Onboard your IBC-compatible chain: Follow these steps to onboard your Cosmos or IBC-compatible chain to the Axelar network.

• Axelar Executable Overview: Learn about the Axelar Executable Contract, a component of the Axelar General Message Passing (GMP) flow.

• Test ITS locally with Axelar Examples: Learn how to test Interchain Token Service locally with the axelar-examples repository.

Events we’ve attended

The Axelar team has been traveling the world to empower developers. Here are a few highlights from our talks:

• Send Cross-chain Messages with Axelar GMP

• Lisk Blockchain Incubation event

• Ethereum Frontiers Africa event with Vitalik and Ethereum core team

• Til conf - Building the future of Web: From Websites to dApp with JavaScript

  Upcoming event: Build a Farcaster Frame to Send Multichain Messages with Axelar GMP

In this workshop, you will learn about building Farcaster frames and building a multichain messaging frame with Axelar GMP.

Don’t forget to set a reminder for the event!

We have a lot more planned for the upcoming months, so you don’t want to miss out. To stay up to date on the latest Axelar news, make sure you are subscribed to this Developer Newsletter.

We're thrilled that the axelar-examples repository now supports the Interchain Token Service (ITS) for local and testnet testing. This repository is a comprehensive collection of cross-chain DApps and smart contracts examples that utilize the Axelar protocol. This update allows developers to locally test the Interchain Token Service features with their new or custom tokens.

How it works

To begin, you'll need to clone the axelar-examples repository to your local machine and follow the instructions in the README. We've configured five different networks — Ethereum, Avalanche, Moonbeam, Fantom, and Polygon — for testing, so you should be all set.

Features

Some of the ITS examples in the examples folder include:

• Custom Token Example: This example demonstrates how to create a custom interchain token with ITS.

• Canonical Token Example: This example demonstrates how to implement a canonical token using the Lock/Unlock token manager.

• New Interchain Token Example: This example demonstrates how to deploy and send interchain tokens connected across EVM chains.

• Interchain Token Executable Example: This example demonstrates how to relay a message alongside a token from a source chain to a destination chain through the Interchain Token Service.

What's next

• Check out some of the other examples in the axelar-examples repository, such as the ones in the example and example-web folders. You'll find comprehensive documentation and code examples to kickstart your projects.

Get help

If you have any questions or concerns, open an issue in our support repository. We're here to help.

The following examples are configured for Hardhat based the axelar-examples repo. Feel free to replicate some of these tests in your own interchain applications.

Run the tests

Axelar Local Dev contains tests for the Call Contract, Call Contract With Token, and NFT Linker examples. Make sure you are in the evm directory before running the npx hardhat test command for each example you want to test.

For example, to run the NFT Linker example:

npx hardhat test nft-linker/tests/NftLinker.test.js

Testing interchain contracts

There are a few things to keep in mind when testing contracts with cross-chain functionality:

• Make sure that you have a local network running for each chain. You can create a new local network with the createNetwork command on Axelar Local Dev.

• Interchain transactions are triggered with the relay() function. The logic you are testing on the destination chain will not execute until the transaction is relayed.

What's next

• Check out the Foundry Axelar GMP integration with Axelar Local Dev.

Get support

If you have any questions or concerns, open an issue in our support repository. We're here to help.