Forem: Idris Olubisi💡

Midnight MCP - AI-assisted development for Compact smart contracts

Idris Olubisi💡 — Tue, 24 Feb 2026 13:03:27 +0000

AI coding assistants like Claude, GitHub Copilot, and Cursor have transformed how developers write code. But they have a fundamental limitation: they only know what was in their training data.

Compact, Midnight's smart contract language, isn't in that training data. When you ask an AI assistant to write a Compact contract, it hallucinates. It invents syntax that doesn't exist, references functions that were never defined, and produces code that fails at compile time.

Midnight MCP solves this problem.

What is MCP?

The Model Context Protocol (MCP) is an open standard that allows AI assistants to access external tools and data sources. Instead of relying solely on training data, an AI assistant with MCP can query live documentation, search codebases, and call APIs.

Midnight MCP is an MCP server purpose-built for Midnight development. It gives AI assistants:

Indexed knowledge of 102 Midnight repositories
Real compiler validation before showing you code
Semantic search across documentation and examples
Version-aware syntax references for Compact

When you ask Claude to write a Compact contract, it queries Midnight MCP for the correct syntax, generates the code, validates it against the real compiler, and only shows you working code.

The problem with AI-generated Compact code

Consider this prompt:

"Write a simple counter contract in Compact"

Without Midnight MCP, an AI assistant might generate:

contract Counter {
    state count: Int = 0;

    function increment(): Void {
        count = count + 1;
    }
}

This looks plausible. It's also completely wrong:

Compact uses ledger for state, not state.
There is no Int type in Compact. It uses Uint<32>, Field, and other specific types.
Void doesn't exist. Compact uses [] for the unit type.
State mutations require witness functions, not direct assignment.

The AI hallucinated a language that resembles Solidity but isn't Compact. A developer unfamiliar with Compact might spend hours debugging code that was never valid.

Install Midnight MCP

Midnight MCP requires no API keys and installs in under 60 seconds. Add the appropriate configuration to your AI assistant based on the tool you use.

Claude Desktop

On macOS, edit ~/Library/Application Support/Claude/claude_desktop_config.json. Add the following configuration to enable Midnight MCP:

{
  "mcpServers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

Cursor

Create or edit .cursor/mcp.json in your project root. You can also configure it globally at ~/.cursor/mcp.json on macOS/Linux or %USERPROFILE%\.cursor\mcp.json on Windows. Add the following configuration:

{
  "mcpServers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

VS Code with GitHub Copilot

Create or edit .vscode/mcp.json in your project. Add the following configuration to connect Copilot to Midnight MCP:

{
  "servers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

After adding the configuration, restart your AI assistant. You now have access to 29 Midnight-specific tools.

How Midnight MCP works

Midnight MCP operates as a local server that connects your AI assistant to Midnight's ecosystem.

When you ask for a Compact contract:

The AI assistant calls midnight-get-latest-syntax to retrieve current Compact syntax.
It generates code using the correct patterns.
It calls midnight-compile-contract to validate against the real compiler.
If compilation fails, it reads the error, fixes the code, and retries.
You receive verified, working code.

This compile-validate-fix loop happens automatically. You never see the broken intermediate versions.

Real compiler integration

Most code-generation tools rely on pattern matching and hope. Midnight MCP validates code against the actual Compact compiler hosted.

The compiler catches errors that static analysis cannot, including:

Type mismatches: Using Field where Uint<64> is expected
Sealed field violations: Attempting to access sealed state incorrectly
Disclose rule errors: Missing or malformed privacy annotations
Unbound identifiers: References to undefined variables or types

When the compiler returns an error, the response includes the exact line number and column:

success: false
message: "Line 12:8 - unbound identifier 'totalSupply'"
errorDetails:
  line: 12
  column: 8
  errorType: error

The AI assistant uses this information to fix the code and try again.

Graceful fallback

If the hosted compiler is unavailable, Midnight MCP falls back to static analysis. The response indicates which validation method was used:

validationType: "compiler"           # Real compiler validation
validationType: "static-analysis-fallback"  # Compiler unavailable

You always receive validation. The tool never fails silently.

Semantic search across 102 repositories

Today, Midnight MCP indexes every non-archived repository in the Midnight ecosystem:

All 88 repositories from midnightntwrk.
14 community and partner repositories, including OpenZeppelin contracts and hackathon winners.

The search is semantic, not keyword-based. For example, a prompt like "find code that handles shielded transactions" returns relevant results even if those exact words don't appear in the code.

Prompt: "How do I implement a token with transfer limits?"

midnight-search-compact returns:
- Token contract examples from midnight-examples
- Rate limiting patterns from community repos
- Relevant documentation sections

29+ tools for Midnight development

Midnight MCP provides 29 tools organized by function.

Search tools

Use these tools to find code, documentation, and examples across the Midnight ecosystem.

Tool	Purpose
`midnight-search-compact`	Search Compact language code across indexed repos
`midnight-search-docs`	Search official Midnight documentation
`midnight-search-typescript`	Search TypeScript SDK implementations
`midnight-fetch-docs`	Fetch live documentation from docs.midnight.network

Analysis tools

Use these tools to validate, analyze, and review Compact contracts.

Tool	Purpose
`midnight-compile-contract`	Validate code against the real Compact compiler
`midnight-analyze-contract`	Run 15 static security checks
`midnight-review-contract`	AI-powered security review
`midnight-extract-contract-structure`	Parse contract structure and exports

Generation tools

Use these tools to create new contracts and documentation.

Tool	Purpose
`midnight-generate-contract`	Generate contracts from natural language descriptions
`midnight-document-contract`	Generate documentation in Markdown or JSDoc format

Repository tools

Use these tools to access files and syntax references from Midnight repositories.

Tool	Purpose
`midnight-get-file`	Retrieve files from any indexed Midnight repository
`midnight-get-file-at-version`	Get file content at a specific version
`midnight-compare-syntax`	Compare syntax between Compact versions
`midnight-get-latest-syntax`	Current Compact syntax reference
`midnight-get-repo-context`	Everything needed to start coding (compound tool)
`midnight-list-examples`	List available example contracts

Version management tools

Use these tools to manage upgrades and track changes between Compact versions.

Tool	Purpose
`midnight-upgrade-check`	Full upgrade analysis (compound tool)
`midnight-check-breaking-changes`	Identify breaking changes between versions
`midnight-get-migration-guide`	Step-by-step migration instructions

Resources and prompts

Beyond tools, Midnight MCP provides nine built-in resources and five interactive prompts.

Resources are always-available references that provide quick access to syntax and examples:

midnight://syntax/latest      Current Compact syntax
midnight://examples/counter   Counter contract example
midnight://examples/token     Token contract example
midnight://docs/compact       Compact language reference

Prompts are templates for common tasks that guide you through specific workflows:

create-compact-contract      Start a new contract
debug-compact-error          Fix compilation errors
security-review              Full security audit
compare-compact-versions     Migration assistance

Architecture

Midnight MCP is built for reliability:

Token efficiency: Outputs YAML by default (20-30% fewer tokens than JSON)
Compound tools: Single calls that combine multiple operations
Graceful degradation: Falls back to cached data when services are unavailable
Progress notifications: Real-time updates during long operations

The codebase is fully tested with 206 tests across 10 test suites.

What's next

Midnight MCP is open source and actively developed. The roadmap includes:

Full ZK circuit output parsing from compiler results.
Contract deployment directly from AI chat.
TypeScript SDK integration for automatic prover code generation.
Local devnet interaction for querying balances and submitting transactions.

Learn more

Explore the source code and contribute:

→ GitHub repository

→ npm package

→ API documentation

Midnight MCP is a community project. Contributions, issues, and feature requests are welcome.

Depth Over Trend

Idris Olubisi💡 — Tue, 08 Apr 2025 18:06:31 +0000

Idris Olubisi💡

Apr 7 '25

Depth Over Trend

#webdev #beginners #productivity #learning

Comments 1

5 min read

Depth Over Trend

Idris Olubisi💡 — Mon, 07 Apr 2025 11:00:00 +0000

This isn't a typical blog I write, but I'm going to share some raw thoughts along with rhetorical questions that you might find useful and helpful.

It's interesting to see how fast the ecosystem moves today, which has made me think a lot over the past few months about what comes next. Yes, what comes after accomplishments?

What comes after reaching the goal you set a year or two ago?

What comes after overcoming your biggest challenge, whether in skills or leadership??

Have you ever thought about the different phases of the internet we've experienced over the years and wondered what the developers from those times are doing today? Let me take you back a bit. You might know about our various internet phases: from 1995 to 2000 (Web1), 2000 to 2020 (Web2, which is still active), and now Web3 and Web5 up to the present.

Yes, Web5. If this is your first time hearing about Web5, you can learn about it with this breakdown from Adewale Abatti (Acekyd).

It's fascinating to see how things have changed over time. But can you guess what the different eras have in common? Please take a moment to think about it.

The tech skill!

Yes, tech skills are transferable skills you can own, nurture, and improve without worrying about the next iteration of the internet or trends. Before I stray too far, let me bring you back to why you're reading this: it's about valuing depth over trends or, simply put, Depth over Trend. However, you prefer to call it.

Let's talk about what's important, what you need, and why you need it. I will also share what I have learned from the past months of thinking about what truly matters, using the history I mentioned earlier. As you all know, data don’t lie.

Depth vs Trend

To explain this concept the way I think about it, and how I believe everyone reading this should subconsciously think about it, is to use the idea of trade.

"Depth" refers to the volume and liquidity at different price levels in the order book, while "Trend" refers to the overall direction of price movement over time. Think of it this way: trends are what everyone can see. They're the apparent upward or downward movements that catch attention. People chase trends because they're visible and exciting - like jumping on the AI bandwagon or whatever’s hot on Twitter this week.

But depth? That's where the real value sits. It’s having deep knowledge or capability that persists regardless of market conditions. Trends come and go, but depth gives you staying power.

What makes them similar is that both can lead to success. You can make quick wins following trends like day traders can profit from momentum. But the difference is sustainability.

Depth wins in the long run because it builds compounding value. While trend-chasers constantly restart with each new wave, depth-focused players build foundations that strengthen over time. When the trend inevitably shifts, those without depth get washed out, while those with substantive knowledge or skills remain valuable.

As Warren Buffett says - when the tide goes out, you discover who’s been swimming naked. Depth is your protection when trends reverse.

Why should you care?

Even if you think all that matters is money, who doesn't like money? Understanding the difference between depth and trends isn’t just academic. It directly impacts where you invest your limited time and energy.

Chasing trends without depth is like buying into market momentum without understanding fundamentals. Sure, you might catch some upside, but you're essentially gambling. When the music stops, you're left without a chair.

Trends often shine a lot, and if you aren't careful as a builder, founder, or developer, it's very easy to get carried away with them. But then, I know what you might be thinking: ” Everyone is doing it”, ” It’s the next big thing,” “I don’t want to miss out,” and all that. But in reality, there are different phases of life, the same as tech and the tech ecosystem in general.

Depth, on the other hand, is compound interest for your career and business. Each layer of deep understanding builds on previous layers, creating compounding returns that trends can't can't.

Take developers who studied fundamental programming concepts versus those who just learned the trending framework of the month. When React inevitably gives way to the next big thing, guess who adapts faster? The ones with depth.

Or consider founders who deeply understand customer problems versus those chasing funding trends. When venture capital dried up in 2022-2023, companies with genuine market depth survived while trend-chasers ran out of runway.

The market eventually rewards depth not because it's virtuous but because it's viable. And in an increasingly noisy world where everyone chases the same trends, depth is your unfair advantage.

Every person who created something different focused on depth, which often comes from a deep work state—a flow state of continuous, focused work. With trends, you stay at the top. It only requires shallow work to produce something of substance. - Blessing Adesiji

What can you do differently?

Stop treating tech like a fashion show. Take a breath instead of reflexively jumping on every new framework, language, or platform that trends on X(Formerly Twitter).

Ask yourself: "Does it solve a fundamental problem, or is it just shiny?"

It doesn’t mean you should isolate yourself and not keep abreast of what's going on around you.

Develop your Bulls***t detector. When everyone's hypineveryone's thing, that's your cue that's skeptical. The real opportunities often lie in areas others overlook because they're too busy following the crowd.

Allocate your learning time like an investment portfolio:

70% toward deepening your understanding of fundamentals that won't change.
20% tailoring adjacent skills that complement your core.
10% experimenting with trends.

Build relationships with people who prioritize depth. You become the average of the five people you spend the most time with, so surround yourself with depth-seekers who ask hard questions rather than trend-followers who chase easy answers.

Perhaps most importantly, be willing to be temporarily uncool. The paradox is that ignoring what's trendy positions you to catch more immense, meaningful waves later.

Self Reflection

Take a moment to audit your recent decisions. How many were made because "everyone is doing it" versus a ”deep understanding of underlying value”?

Look at your skill set critically. If the tech landscape dramatically changed tomorrow, which of your abilities would remain valuable? Those are your depth areas.

Consider your heroes in tech. Are they known for riding trends or creating fundamental value regardless of market conditions? What can you learn from their approaches?

Ask yourself the uncomfortable question: "Am I building something that will matter in five years?" If not, you might be optimizing for trends over depth.

Finally, depth isn't just technical knowledge; it's understanding people, problems, and principles. The most profound insights often come from connecting dots across disciplines rather than narrowing down to what's happening.

The choice between depth and trend is not a career strategy. It's a philosophy about how you want to contribute to the world. Choose wisely.

Olanetsoft ✍️

[Boost]

Idris Olubisi💡 — Mon, 24 Mar 2025 14:10:16 +0000

5 Must-Watch Tutorials to Build Your SaaS App in 2025

Femi-ige Muyiwa for Hackmamba ・ Feb 27

#tutorial #webdev #productivity #programming

Multichain Real-World Asset (RWA) Lending with Axelar GMP

Idris Olubisi💡 — Wed, 16 Oct 2024 12:05:14 +0000

Today, we see many different networks, each with its own strengths and limitations. This has created significant challenges, leading to scattered liquidity and complicated user experiences, especially in Real World Asset (RWA) lending.

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 different blockchains, going 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 who were 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:

Real estate
Commodities (e.g., gold, oil)
Fine art
Intellectual property
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:

Increased liquidity: Assets that were previously difficult to divide or trade can now be easily bought and sold in smaller fractions.
Broader accessibility: Investors can access a wider range of assets with lower capital requirements.
Improved transparency: Blockchain technology provides a clear, immutable record of ownership and transactions.
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:

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.
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.
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 for loans, 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(
        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(
        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, the integration of 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

Cross-Chain Governance with OpenZeppelin Governor and Axelar

Idris Olubisi💡 — Tue, 08 Oct 2024 13:50:03 +0000

Multichain applications are becoming the new norm, but managing governance across these networks remains a significant challenge. For decentralized applications (dApps) with deployments on multiple blockchains, ensuring an easy governance processes while maintaining security, liveness, and resistance to censorship is a complex task. This challenge is particularly evident in projects like Uniswap, which has extensively assessed cross-chain platforms to secure its governance across diverse networks. Through this, they discovered Axelar's robust infrastructure as the key solution.

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 designed 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:

InterchainProposalSender (on source chain): Encodes and sends proposals to other chains.
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 by enabling them to call any function on interconnected chains seamlessly.

With GMP, developers gain the ability to:

Call a contract on chain A and interact with a contract on chain B.
All in one gas payment for cross-chain calls
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 the 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 `InterchainProposalSender` 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:

To interface with Axelar's Gateway and Gas Service for cross-chain communication.
To provide a method for sending proposals to other chains, including the necessary gas payments.
To encode the proposal data in a format that can be understood and executed on the destination chain.

Now, let's proceed to 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 `GovernanceToken` contract

To vote on a proposal requires having voting power, and allowing a user to have this voting power, you need to create the GovernanceToken contract. This token will:

Provide voting power to token holders.
Implement the ERC20 standard with additional voting and permit capabilities.
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 `ThresholdContract` contract

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

Store a threshold value that can be updated through governance.
Provide a function to update the threshold.
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 `CrossChainGovernor` contract

The CrossChainGovernor contract is the most important in 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 thresholds to be updated 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(
        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

Merkle Proofs: A Simple Guide

Idris Olubisi💡 — Mon, 03 Jun 2024 00:10:51 +0000

You have millions of unique images in your gallery, each representing a piece of private or personal data stored on your phone. After an incident, you lost your device, but it was returned to you after many months, with claims that the images hadn't been tampered with.

Verifying the authenticity of each image in this gallery could be difficult, right? How can they prove the images haven't been manipulated, or how can you confirm everything is as it should be? That's where Merkle's proofs come into play, as they offer a solution to verify the integrity of large datasets without the need to inspect each item individually.

In this tutorial, you will learn about Merkle proofs, how to create them using a Merkle Tree, and how to implement Merkle proofs for whitelisting email addresses using JavaScript.

To understand how Merkle proofs help verify the authenticity and integrity of your data without the need to check each piece individually, such as your image gallery, as discussed earlier, you first need to understand the structure that underpins them: the Merkle Tree.

What is a Merkle Tree?

A Merkle Tree, also known as a hash tree, is a binary tree structure used to verify a data set's integrity effectively. It was a concept named after the computer scientist Ralph Merkle, who patented it in 1979.

This binary tree structure has each leaf node representing a block of data or a piece of information. Instead of containing the data directly, the internal nodes hold a cryptographic hash of their child nodes. The tree is built by repeatedly hashing pairs of child nodes until a single root hash is achieved.

Components of Merkle Tree

Merkle Tree image by Teemu Kanstrén

A Merkle tree has three different components, as shown in the image above Merkle root, Merkle branches, and Merkle leaves. Let's take a look at what they are.

Merkle root is derived from hashing together the child hashes beneath it and down to the leaves. It is a single hash on its own that represents the top of the Merkle tree, as shown in the image above and is often used to store block headers in blockchain content without downloading the entire block.
In a Merkle tree, we have Merkle branches, intermediate nodes between Merkle roots and Merkle leaves. Each branch node is created by hashing together the hashes of its child nodes. These branches form the connections between the leaves (where the data resides) and the Merkle root, making it easier to ensure that the Merkle tree can be efficiently traversed and verified.
Merkle leaves are the nodes at the bottom layer of the Merkle tree. They contain hashes of the actual data stored. The leaves are the foundation of the Merkle tree, as their hashes are combined and rehashed to produce the hashes of the nodes above them, ultimately leading to the Merkle root.

Additionally, we have the Data nodes, a layer representing how data is supplied to start the process before it hashed in the next layer(Merkle leaves), which is the Merkle leaves, as shown in the image.

What is a Merkle Proof?

A Merkle proof is a method used to verify the presence and integrity of specific data within a dataset using a Merkle tree. It comprises a single data block (leaf), a series of hashes from the tree (branches), and the Merkle root.

While Merkle proof is used to verify the presence of specific data within a dataset using a Merkle tree, here are some areas where Merkle proof can be applied.

In a distributed system for data verification
Secure communication protocols
Data storage solution
Cryptocurrencies and blockchain

Implementing a Merkle Proof for Whitelisting Email Addresses

Let's implement a Merkle proof for whitelisting email addresses in this section.

Prerequisite

Node.js and its package manager NPM, version 18. Verify Node.js is installed by running the following terminal command: node -v && npm -v
A basic understanding of JavaScript

Project Setup and Installation

Navigate to any directory of your choice, and then run the following commands to create a new folder and change the directory into the folder:

mkdir merkle-proof-tutorial
cd merkle-proof-tutorial

Next, you need to install the merkletreejs and crypto-js libraries, which will be needed to create a Merkle tree and hash data using the following command:

npm i merkletreejs crypto-js

Create a new file proof.js feel free to name it whatever you want, but for this tutorial, you will name it proof.js.

Import Libraries

You will be using the merkletreejs and crypto-js libraries in this example to create a Merkle tree and hash the data, respectively.

Navigate into the proof.js file and add the following code snippet:

const { MerkleTree } = require('merkletreejs')
const SHA256 = require('crypto-js/sha256')

Create a List of Emails to Be Whitelisted

You need to create a list of emails to be whitelisted. In this example, you will add three emails, but it could be millions of emails, depending on the data you want to test with. Add the following code snippet to create an array of three email addresses:

//...

// List of email addresses to be whitelisted
const emails = ["example1@mail.com", "example2@mail.com", "example3@mail.com"];

Convert Emails to Hashes and Build the Merkle Tree

Next, you need to convert each email into a hash and create the Merkle tree using the hashed emails with the following code snippet:

//...

// Convert each email into a hash
const leaves = emails.map(email => SHA256(email));

// Create the Merkle Tree using the hashed emails
const tree = new MerkleTree(leaves, SHA256);

// Get the root and convert it to a hexadecimal string
const root = tree.getRoot().toString('hex');

Add Function to Verify Whitelisted Emails

In the previous step, you created a tree for the addresses; next, you must create a function to prove if an email is part of the whitelisted emails.

Create a function verifyEmail:

//...

// Function to verify if an email is whitelisted
const verifyEmail = (email) => {
  // Hash the email to be verified
  const hashedEmail = SHA256(email);

  // Get the proof for the hashed email from the tree
  const proof = tree.getProof(hashedEmail);

  // Verify the proof against the root of the tree; returns true if valid, false otherwise
  const verified = tree.verify(proof, hashedEmail, root);

  // Log the result to the console
  console.log(`${email} is ${verified ? "whitelisted" : "not whitelisted"}.`);
};

In the code snippet, you created a function verifying whether an email is whitelisted. To do this, you:

Hashed the email to be verified using SHA256
Got the proof for the hashed email using the getProof method
Verified the proof against the root of the tree

Here is what the complete code looks like:

const { MerkleTree } = require("merkletreejs");
const SHA256 = require("crypto-js/sha256");

// List of email addresses to be whitelisted
const emails = ["example1@mail.com", "example2@mail.com", "example3@mail.com"];

// Convert each email into a hash
const leaves = emails.map((email) => SHA256(email));

// Create the Merkle Tree using the hashed emails
const tree = new MerkleTree(leaves, SHA256);

// Get the root and convert it to a hexadecimal string
const root = tree.getRoot().toString("hex");

// Function to verify if an email is whitelisted
const verifyEmail = (email) => {
  // Hash the email to be verified
  const hashedEmail = SHA256(email);

  // Get the proof for the hashed email from the tree
  const proof = tree.getProof(hashedEmail);

  // Verify the proof against the root of the tree; returns true if valid, false otherwise
  const verified = tree.verify(proof, hashedEmail, root);

  // Log the result to the console
  console.log(`${email} is ${verified ? "whitelisted" : "not whitelisted"}.`);
};

Test the Verification Function

In this section, you will test the verification function with a whitelisted and non-whitelisted email.

Test with a whitelisted email address by calling the verifyEmail function inside the script file.

//...

verifyEmail("example2@mail.com");  // Expected output: "example2@mail.com is whitelisted."

To run the script, use the following command:

node proof.js

The result printed on the console will return a response as shown below, indicating the email address is whitelisted because it is part of the emails we added to the email array.

Next, test with an email that is not whitelisted.

//...

verifyEmail("x@mail.com"); 
// Expected output: "x@mail.com is not whitelisted."

You should see a response indicating the email is not whitelisted, as shown below. This is because it wasn't part of the emails whitelisted, meaning there is no proof for the email address to indicate it was part of the tree.

Conclusion

In this tutorial, you learned about Merkle proofs, how they can be used to ensure the integrity of datasets in applications, how to create them using a Merkle Tree, and how to implement Merkle proofs for whitelisting email addresses using JavaScript.

References

Celebrating One Year Working on Axelar: Building the Interoperability Future

Idris Olubisi💡 — Thu, 11 Apr 2024 14:42:16 +0000

gm builders!

It's been a while since I published my last piece of content here. I'm back—not to dwell on the gap but to share my excitement for what lies ahead. Above all, I'm celebrating a year as a Developer Advocate working on Axelar with the best engineers and teams in web3. Woohoo 🥳

As I sit down to pen this reflection, I'm reminded of the countless stories where individuals embark on journeys filled with unknowns, armed with nothing but a heart full of dreams and a relentless drive to explore. This narrative resonates universally, mirroring the essence of human curiosity and our innate desire to push beyond the familiar confines of our world.

Exactly one year ago, I found myself at the threshold of such an adventure with Axelar. Much like the protagonist of a story who steps into a new realm, I was filled with a blend of excitement and uncertainty.

In this blog post, I invite you to join me on a retrospective voyage through my first year at Axelar. It's a story of growth, learning, and the relentless pursuit of building bridges in the digital world.

The Motivation

In the early days, we had Bitcoin, Vitalik and his team take significant steps to enrich the developer ecosystem by enabling applications to leverage the blockchain through smart contracts. This sparked immense excitement in the "crypto" space, particularly among builders and the curious. It means that whether you were actively involved in the space or not, you couldn't ignore the buzz about NFTs, haha.

Fast forward to late 2021, I became really curious about what powers NFTs. At that time, the space saw an unprecedented boom, and it was everywhere. However, as a backend developer, I used my curiosity to focus on learning about the technology rather than the "hype." Discovering blockchain and its amazing features that could be leveraged made me dive deep into the "Rabbit Hole," and the rest was history.

But there was a problem; wait, what?

Yes, I'll discuss the problem in one of the sections of this post; keep reading.

Back to my motivations, Axelar wasn't just another company; it promised a quest toward building the future of interoperability—a concept as vast and uncharted as the deepest oceans or the farthest galaxies in our collective imagination.

This journey at Axelar became my canvas, on which I've painted days of rigorous challenges, moments of unprecedented innovation, and the unyielding pursuit of something truly groundbreaking. It's a tale not unlike those of explorers of old, who set sail to discover new worlds or scientists on the cusp of breakthroughs that could redefine the boundaries of what we believe is possible.

First-Year Milestone

The list is looooooooooooong!

One of my greatest achievements so far has been collaborating with incredibly talented, brilliant, and passionate engineers and leaders under the guidance of my manager, Stephen Fluin, and the DevRel Team. We've made significant improvements to the current system, focusing on developer experience, supporting developers and partners, and fostering community and leadership, among many other areas. It's already been a year, but it still feels like day one. ;)

During this period, I've learned a great deal about Axelar. I've assisted partners with integration, enabling them to launch on the mainnet. I've delivered numerous talks and workshops internationally and locally, created boilerplate projects for building and testing cross-chain transactions locally or on testnets using Foundry, hosted and judged several hackathons, enhanced developer documentation to support developer success, and worked with top industry leaders, projects, and products.

Additionally, I've built strong relationships, increased developer engagement, gathered feedback to enhance our products, and contributed significantly to developing our developer community, among many other activities.

💡It's just day 0, with many more exciting updates to come.

Building the Interoperability Future

In the previous step, I mentioned there was a problem, and I promised to discuss it. The issue is well-known in the blockchain space, where all blockchain ecosystems, including both EVM and non-EVM chains, operate in isolation. These are great solutions that many products use, but there isn't a way to connect these ecosystems together in a decentralized manner without compromising security, decentralization, or the developer experience.

Guess what? We have an answer, and that's Axelar, connecting over 60+ chains, improving developer experience, security through decentralization, and much more.

That's not all; developing with Axelar Virtual Machine elevates the whole process of connectivity, supporting Interchain Maestro and Interchain Amplifier.

What does this mean for the future of interoperability?

With the Interchain Amplifier, developers can deploy and manage their multi-chain dApp instances using the Interchain Token Service, which went live on the mainnet in January. Additionally, the Interchain Amplifier, recently launched, offers a permissionless model and service. This allows anyone to easily create a connection to the Axelar network and all its interconnected chains.

Why I'm Excited

Everything, YES, everything. One of my greatest aspirations in life and as a professional is always to make an impact and provide solutions to help humanity.

Tiny changes, Remarkable Results - JamesClear

If you're also working on Axelar and reading this, thank you for being amazing and for all the support so far.

To the tech community, tech Twitter, Developer DAO, and all the builders, a big thank you for your support. It means a lot to me.

Gracias!

How to Use Cloud Functions to Automate GitHub Moderation

Idris Olubisi💡 — Tue, 05 Dec 2023 11:49:36 +0000

In today's world, automated tools enhance productivity and ensure task consistency while maintaining accuracy. When managing repositories on GitHub, moderation can become tedious, especially as the number of issues open each day increases.

What if there were a way to bring automation to this process, streamlining the workflow and ensuring timely responses? Appwrite Functions — a potent tool to supercharge our GitHub moderation tasks — is all we need.

In this tutorial, we‘ll learn how to automate GitHub moderation using Appwrite Functions and the "GitHub issue bot" template. We‘ll also cover customizing the comments the bot posts when creating an issue and tailoring it to our preferred response. Finally, we’ll discuss how to monitor the performance of the Appwrite function.

Prerequisites

We’ll need a few things to fully understand the concepts presented in this tutorial:

A basic understanding of JavaScript
A GitHub account
An Appwrite account

Getting started

First, let’s create a GitHub repository; this will serve as the workspace for our Appwrite Function to perform and await new issues. Here's how:

Log into GitHub.
Click the New Repository button.
Name it github_moderation.
Click Create Repository.

Setting up a webhook

With the repo set up, let’s establish the webhook. Webhooks are automated systems that allow external services to track changes and send data within a system. Here, we’ll set up a webhook to monitor actions within the repository to listen to events closely.

To do this, navigate to the Settings tab of the repository and click Webhooks as shown below.

Next, we need to set the webhook with the following details:

Click Add webhook.
For the Payload URL, enter https://sample.com/.
Choose application/json for Content type.
Type in myTopSecret for the Secret.

Note: The https://sample.com URL is a placeholder; we will replace it with our Appwrite Function domain later. It's also important to note the secret we entered, as it will be used when configuring the Function.

Next, change the event option to Let me select individual events, select Issues, and Add webhook.

Create an access token

We must create an access token for our Function to connect to GitHub and securely monitor activities via the Webhook. To do this, click the Settings menu under the profile drawer and navigate to the Developer settings section.

Navigate to the Fine-grained tokens tab and click the Generate new token button.

Input github_moderation as the name, and change the Repository access to All Repository.

Scroll to the Repository permissions section in the Issues category, change the permission to Read and Write, and then click the Generate token button to create it.

After completing these steps, GitHub will generate an access token for us. Store this token securely; we will need it when creating our Function.

All set with GitHub! Let’s create a cloud function on Appwrite in the following step.

Create a Cloud Function on Appwrite

To make the process seamless, Appwrite offers two options for creating functions. We can create a function from scratch, allowing for extensive customization, or we can choose from a set of templates with support for various runtimes, making it more convenient. In our case, we will create from a template.

To do this, we need to log into our Appwrite console, click the Create project button, input github_moderation as the name, and then Create.

Next, navigate to the Functions tab, select the Templates tab, locate the GitHub issue bot, and click Create function.

Input GitHub issue bot as the function name, select Node.js - 16.0 as the runtime, and click Next.

Input the GitHub token and secret we generated earlier and continue.

Select Add to existing repository, connect to GitHub, select the github_moderation repository, and continue.

Accept the default branch and directory and then Create.

That’s it! Appwrite will automatically scaffold a function, deploy it, and push the corresponding source code to the specified repository on creation, as shown below.

Update the webhook payload URL and issue comment

With our function deployed, we can get the domain on which it will run and use it as our Payload URL. To do this, navigate to the Domain tab and copy the URL as shown below.

Next, we need to update our Webhook URL on GitHub with the copied URL.

Finally, to customize the comment that the bot will post when an issue is created, navigate to the Code tab and modify the src/main.js as shown below:

Next, update the following code snippet to the main.js file.

import GithubService from './github.js';
import { throwIfMissing } from './utils.js';

export default async ({ res, req, log, error }) => {
     throwIfMissing(process.env, ['GITHUB_WEBHOOK_SECRET', 'GITHUB_TOKEN']);

 const github = new GithubService();

 if (!(await github.verifyWebhook(req))) {
      error('Invalid signature');
      return res.json({ ok: false, error: 'Invalid signature' }, 401);
 }

 if (!github.isIssueOpenedEvent(req)) {
      log('Received non-issue event - ignoring');
      return res.json({ ok: true });
 }

 await github.postComment(
    req.body.repository,
    req.body.issue,
    `Thank you for helping us improve our project, someone from our team will respond soon!` //UPDATE THE COMMENT HERE
 );

  return res.json({ ok: true });
};

Now that it's set up, we can try it out by opening an Issue in the **github_moderation** repository.

Additionally, we can check the Appwrite function's performance and the GitHub webhook's operation, as shown below.

As mentioned above, Appwrite allows the flexibility to create custom functions from scratch and offers numerous templates. These templates are a game-changer, providing developers with flexibility and a head start and enabling them to rapidly develop and customize functionalities in new and existing applications using Appwrite's functions.

Additionally, the range of templates available supports multiple programming languages, giving developers a broad spectrum of options within the Appwrite ecosystem.

Conclusion

In this tutorial, we provided a step-by-step guide on how to use Appwrite Cloud Functions for automating GitHub moderation. We also demonstrated how to customize the comments the bot posts when creating an issue, tailoring it to our preferred response. Additionally, we discussed how to monitor the Appwrite function's performance and the GitHub webhook's operation via the dashboard.

These resources might also be helpful:

How to Set up Telesign for SMS in Appwrite

Idris Olubisi💡 — Tue, 12 Sep 2023 13:25:11 +0000

Improving user engagement and interaction in web applications is crucial, and seamless communication is key. In today's interconnected digital world, SMS is still a powerful way to reach users quickly and efficiently. Incorporating this strong communication tool into a web application powered by Appwrite is easy.

In this article, we will discover the process of authenticating users through their phone numbers with the help of Appwrite's phone authentication APIs and Telesign. Find the project repository here.

Technology Overview

Telesign is an identity and customer engagement solution that provides sets of APIs for registering and verifying users using SMS, Voice, and phone number intelligence.

Prerequisites

To fully grasp the concepts presented in this tutorial, the following are required:

Basic understanding of JavaScript and React
Docker installed
Telesign account

Getting started

To create a Next.js starter project, we should first navigate to the desired directory and run the command below in our terminal.

    npx create-next-app@latest setup-telesign-for-sms-in-appwrite && cd setup-telesign-for-sms-in-appwrite

After running the command, we will be prompted to answer sets of questions. We can do so as shown below:

Would you like to use TypeScript? <No>
Would you like to use ESLint? <No> 
Would you like to use Tailwind CSS? <Yes>
Would you like to use `src/` directory? <Yes>
Would you like to use App Router? (recommended) <Yes>
Would you like to customize the default import alias? <Yes>
What import alias would you like configured? @/* <Press Enter>

The command creates a Next.js project called next_telesign and navigates into the project directory.

Next, we need to add Appwrite as a dependency. To do this, run the command below:

    npm install appwrite

Set up Telesign as an SMS provider

Let's begin by logging in to our Telesign portal and making sure to save the Customer ID and API Keys.

Lastly, we need to create and verify a test number. Any number we configure and verify here can receive SMS. To do this, we need to navigate to the **Manage test numbers** screen.

Click the **Add a Number** button, input the required details, **Submit**, and **Verify**.

Configure and create a project on Appwrite

To get started, first, we need to create an Appwrite instance in a preferred directory by running the command below:

    docker run -it --rm \
        --volume /var/run/docker.sock:/var/run/docker.sock \
        --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
        --entrypoint="install" \
        appwrite/appwrite:latest

On creation, we should see an appwrite folder with two files.

Secondly, we need to add Telesign as an SMS provider by modifying the environment variables in the .env file as shown below:

    _APP_SMS_PROVIDER=sms://<REPLACE WITH CREDENTIAL ID>:<REPLACE WITH API KEYS>@telesign
    _APP_SMS_FROM=<REPLACE WITH THE PHONE NUMBER WE USED IN WHEN VERIFYING TELESIGN>

We must also ensure that the API Key provided by Telesign is URL encoded because it contains non-alphanumeric characters. To do this, we can navigate to the URLEncoder online platform, paste our API key, click the Encode button, and then copy the resulting encoded format.

Lastly, we need to sync the changes we made on the .env file with our Appwrite server. To do this, we must run the command below inside the appwrite directory.

    docker-compose up -d

Set up a project on Appwrite
To get started, we need to navigate to the specified hostname and port http://localhost:80, log in, click the Create project button, input next_telesign as the name, and then click **Create**.

Appwrite + Telesign in Next.js

Let's begin by going to our project's main directory and creating a new folder named helper. Inside this folder, create a file called utils.js and insert the code snippet provided below:

import { Client, Account } from "appwrite";

//create client
const client = new Client();
client.setEndpoint("http://localhost/v1").setProject("REPLACE WITH PROJECT ID");

//create account
const account = new Account(client);

//authenticate user with phone number
export const phoneAuth = (phone_number) => {
  return account.createPhoneSession("unique()", phone_number);
};

//validate phone session
export const validateSMS = (userID, secret) => {
  return account.updatePhoneSession(userID, secret);
};

The snippet above does the following:

Imports the required dependency.
Uses the Client and Account class to set up an Appwrite instance by specifying the endpoint and corresponding project ID.
Creates a phoneAuth and validateSMS function that uses the createPhoneSession and updatePhoneSession methods to create a user and validate the user using the code sent via SMS, respectively.

Secondly, we need to update the page.js file inside the app directory to include states and methods required by our application.

    "use client";
import Head from "next/head";
import { useState } from "react";
import { phoneAuth, validateSMS } from "../../helper/utils";

export default function Home() {
  const [value, setValue] = useState({
    phone: "",
    otp: "",
  });
  const [user, setUser] = useState(null);
  const [isPhoneVerify, setIsPhoneVerify] = useState(false);
  const [isLoading, setIsLoading] = useState(false);
  const handleChange = (e) => {
    setValue({ ...value, [e.target.name]: e.target.value });
  };

  const handleSubmit = (e) => {
    e.preventDefault();
    setIsLoading(true);
    phoneAuth(value.phone)
      .then((res) => {
        setUser(res.userId);
        setIsPhoneVerify(true);
        setIsLoading(false);
      })
      .catch((e) => {
        alert("Error getting phone session!", e);
        setIsLoading(false);
      });
  };

  const handleValidatePhone = (e) => {
    e.preventDefault();
    setIsLoading(true);
    validateSMS(user, value.otp)
      .then((res) => {
        alert(
          `User successfully verified using for user with ID ${res.userId}, country Code ${res.countryCode}, and expires on ${res.expire}`,
        );
        setIsLoading(false);
      })
      .catch((e) => {
        alert("Error validating session!", e);
        setIsLoading(false);
      });
  };

  return (
    <div className="w-screen h-screen bg-white">
      //UI AND IMPLEMENTATION GOES HERE
    </div>
  );
}

The snippet above does the following:

Imports the required dependencies
Creates state properties to manage application state
Creates a handleChange function to control inputs
Creates a handleSubmit function that uses the phoneAuth function to create a user
Creates a handleValidatePhone function that uses the validateSMS function to verify the created user using the secret key sent via SMS

Lastly, we need to update the UI to display forms for creating and verifying users dynamically.

//IMPORTS GOES HERE

export default function Home() {
  //STATES AND METHOD GOES HERE

  return (
    <div className="w-screen h-screen bg-white">
      <Head>
        <title>Appwrite + Telesign </title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main className="py-4 px-4 lg:py-10 lg:px-10 w-full">
        <div className="flex justify-center mb-8">
          <h1 className="text-2xl font-medium text-gray-700">
            Appwrite + Telesign
          </h1>
        </div>
        <section className="flex justify-center">
          {isPhoneVerify ? (
            <div className="px-4 py-2 border rounded-lg w-full lg:w-2/4">
              <div className="border-b h-8 mb-4">
                <h3 className="text-gray-700">Verify phone number</h3>
              </div>
              <form onSubmit={handleValidatePhone}>
                <fieldset>
                  <label className="text-sm text-gray-400 mb-4 block">
                    OTP
                  </label>
                  <input
                    name="otp"
                    className="border w-full rounded-sm mb-6 p-2"
                    required
                    value={value.otp}
                    onChange={handleChange}
                    type="tel"
                  />
                </fieldset>
                <button
                  className="text-sm text-white px-8 py-2 rounded-sm bg-blue-600 hover:bg-blue-700"
                  disabled={isLoading}
                >
                  Validate OTP
                </button>
              </form>
            </div>
          ) : (
            <div className="px-4 py-2 border rounded-lg w-full lg:w-2/4">
              <div className="border-b h-8 mb-4">
                <h3 className="text-gray-700">
                  Authenticate with your phone number
                </h3>
              </div>
              <form onSubmit={handleSubmit}>
                <fieldset>
                  <label className="text-sm text-gray-400 mb-4 block">
                    Phone number
                  </label>
                  <input
                    name="phone"
                    className="border w-full rounded-sm mb-6 p-2"
                    required
                    value={value.phone}
                    onChange={handleChange}
                    type="tel"
                  />
                </fieldset>
                <button
                  className="text-sm text-white px-8 py-2 rounded-sm bg-blue-600 hover:bg-blue-700"
                  disabled={isLoading}
                >
                  Submit
                </button>
              </form>
            </div>
          )}
        </section>
      </main>
    </div>
  );
}

Now that we have completed that task, we may begin running a development server using the following command:

    npm run dev

We should have something similar to what is shown below.

Conclusion

This post discussed how to set up phone authentication in Next.js using Appwrite and Telesign. With Appwrite, developers can save application development time by leveraging intuitive authentication APIs without the associated technical overheads.

These resources might also be helpful:

Build a Full Stack Interchain dApp with Next.js, Solidity & Axelar

Idris Olubisi💡 — Thu, 06 Jul 2023 12:49:40 +0000

Today's blockchain ecosystem is characterized by many blockchain networks operating independently, each with unique features and functionalities. However, this fragmentation presents challenges regarding seamless communication and collaboration between these networks. To overcome these barriers, a vital element that has emerged is a programmable blockchain interoperability layer.

The programmable blockchain interoperability layer bridges different blockchain networks, facilitating the exchange of information and assets securely and efficiently. It enables smooth interaction by providing a standardized framework for cross-chain communication, allowing various blockchain networks to interoperate seamlessly.

In this tutorial, you will learn how to build a full-stack interchain decentralized application with Next.js, Solidity, and Axelar General message passing to send messages from one blockchain to another.

For a quick start, you can find the complete code for this tutorial on GitHub. However, in the video provided below, you can see the completed app that offers users the ability to:

Connect their wallet
Enter their desired message for cross-chain interaction
Send the message from Binance to Avalanche

Getting Started with Axelar General Message Passing

Axelar's General Message Passing (GMP) feature empowers developers by enabling them to call any function on interconnected chains seamlessly.

With GMP, developers gain the ability to:

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

Prerequisite

Before getting started, you need the following prerequisites:

Node.js and its package manager NPM, version 18*. Verify Node.js is installed by running the following terminal command: node -v && npm -v
A basic understanding of JavaScript, Solidity, and React/Next.js

Project Setup and Installation

To start the project setup and installation quickly, clone this project on GitHub. Make sure you're on the starter branch using the following command:

git clone <https://github.com/axelarnetwork/fullstack-interchain-dapp>

Next, install the project locally after cloning it using the following command in your terminal.

Here's how you can install the project using npm:

cd fullstack-interchain-dapp && npm i && npm run dev

Next.js will start a hot-reloading development environment accessible by default at http://localhost:3000.

Building a Smart Contract with Hardhat and Axelar GMP

In this section, you will build an interchain smart contract leveraging the Axelar GMP feature to send messages from one chain to another.

Navigate to the project's root folder you cloned in the previous step, and then run the following commands to create a new Hardhat project.

mkdir hardhat
cd hardhat
npm install --save-dev hardhat

Let's get a sample project by running the command below:

npx hardhat

We'll go with the following options:

What do you want to do?

✔ Create A JavaScript Project

✔ Hardhat project root:

? Do you want to add a .gitignore? (Y/n) › y

? Do you want to install this sample project's dependencies with npm (hardhat @nomicfoundation/hardhat-toolbox)? (Y/n) › y

The @nomicfoundation/hardhat-toolbox plugin bundles all the commonly used packages and Hardhat plugins recommended to start developing with Hardhat.

Just in case it didn't install automatically, install this other requirement with the following command:

npm i @nomicfoundation/hardhat-toolbox

Next, install @axelar-network/axelar-gmp-sdk-solidity for Axelar General Message Passing SDK in Solidity and dotenv with the following command:

npm i @axelar-network/axelar-gmp-sdk-solidity dotenv

To ensure everything works, run the command below in the hardhat directory.

npx hardhat test

You will see a passed test result in our console.

Delete Lock.js from the test folder and delete deploy.js from the scripts directory. After that, go to contracts and delete Lock.sol.

The folders themselves should not be deleted!

Create a SendMessage.sol file inside the contracts directory and update it with the following code snippet. When using Hardhat, file layout is crucial, so pay attention!

// SPDX-License-Identifier: MIT
// SPDX license identifier specifies which open-source license is being used for the contract
pragma solidity 0.8.9;

// Importing external contracts for dependencies
import { AxelarExecutable } from '@axelar-network/axelar-gmp-sdk-solidity/contracts/executable/AxelarExecutable.sol';
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 { IERC20 } from '@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IERC20.sol';

contract SendMessage is AxelarExecutable {

    string public value;
    string public sourceChain;
    string public sourceAddress;

    IAxelarGasService public immutable gasService;

    constructor(address gateway_, address gasReceiver_) AxelarExecutable(gateway_) {
        // Sets the immutable state variable to the address of gasReceiver_
        gasService = IAxelarGasService(gasReceiver_);
    }

    function sendMessage(
        string calldata destinationChain,
        string calldata destinationAddress,
        string calldata value_
    ) external payable {

        bytes memory payload = abi.encode(value_);

        if (msg.value > 0) {
            gasService.payNativeGasForContractCall{ value: msg.value }(
                address(this),
                destinationChain,
                destinationAddress,
                payload,
                msg.sender
            );
        }
        // Calls the Axelar gateway contract with the specified destination chain and address and sends the payload along with the call
        gateway.callContract(destinationChain, destinationAddress, payload);
    }

    function _execute(
        string calldata sourceChain_,
        string calldata sourceAddress_,
        bytes calldata payload_
    ) internal override {
        // Decodes the payload bytes into the string value and sets the state variable for this contract
        (value) = abi.decode(payload_, (string));

sourceChain = sourceChain_;
        sourceAddress = sourceAddress_;
    }
}

In the code snippet above we:

Create a SendMessage contract that extends the AxelarExecutable contract
Import AxelarExecutable, IAxelarGateway, IAxelarGasService from the @axelar-network/axelar-gmp-sdk-solidity library.
Define four state variables: value, sourceChain, sourceAddress, and gasService. The gasService state variable is immutable and can only be set during contract deployment.
Initialize the gasService variable with the provided gasReceiver_ address.
Create a sendMessage function that takes three string parameters: destinationChain, destinationAddress, value_ and it utilizes gasService.payNativeGasForContractCall with native gas (Ether).
Utilized the gateway contract's callContract function with the specified destinationChain, destinationAddress, and payload parameters.
The _execute function decodes the payload bytes into the value string and updates the state variables sourceChain and sourceAddress.

Setup Deployment Script

Next, create a deploy.js file in the scripts folder and add the following code snippet:

// We require the Hardhat Runtime Environment explicitly here. This is optional
// but useful for running the script in a standalone fashion through `node <script>`.
//
// You can also run a script with `npx hardhat run <script>`. If you do that, Hardhat
// will compile your contracts, add the Hardhat Runtime Environment's members to the
// global scope, and execute the script.
const hre = require("hardhat");

async function main() {
  const SendMessage = await hre.ethers.getContractFactory("SendMessage");
  const sendMessage = await SendMessage.deploy(
    "",
    ""
  );

  await sendMessage.deployed();

  console.log(`SendMessage contract deployed to ${sendMessage.address}`);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

In the code snippet above:

The main function has the SendMessage contract factory obtained using hre.ethers.getContractFactory.
The sendMessage contract is deployed using the SendMessage.deploy method with two strings as arguments.
await sendMessage.deployed() statement ensures that the deployment is completed before moving forward.
The deployed contract's address is logged into the console.

Setup Remote Procedure Call (RPC) to Testnet

Remote Procedure Call (RPC) is a protocol used for communication between client and server systems in a network or blockchain environment. It enables clients to execute procedures or functions on remote servers and receive the results. RPC abstracts the underlying network details and allows clients to invoke methods on servers as if they were local.

Before you proceed to set up RPC, create a .env file using the command below:

touch .env

Ensure you are in the hardhat directory before running the command above.

Inside the .env file you just created, add the following key:

PRIVATE_KEY= // Add your account private key here

Getting your private account key is easy. Check out this post.

Next, set up RPC for Binance and Avalanche networks by updating the hardhat.config.js file with the following code snippet:

require("@nomicfoundation/hardhat-toolbox");
require("dotenv").config({ path: ".env" });
require("solidity-coverage");

const PRIVATE_KEY = process.env.PRIVATE_KEY;

// This is a sample Hardhat task. To learn how to create your own go to
// <https://hardhat.org/guides/create-task.html>
task("accounts", "Prints the list of accounts", async (taskArgs, hre) => {
  const accounts = await hre.ethers.getSigners();

  for (const account of accounts) {
    console.log(account.address);
  }
});

// You need to export an object to set up your config
// Go to <https://hardhat.org/config/> to learn more

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.9",
  networks: {
    bsc: {
      url: "<https://data-seed-prebsc-1-s1.binance.org:8545>",
      chainId: 97,
      accounts: [PRIVATE_KEY],
    },
    avalancheFujiTestnet: {
      url: "<https://avalanche-fuji-c-chain.publicnode.com>",
      chainId: 43113,
      accounts: [PRIVATE_KEY],
    },
  },
  mocha: {
    timeout: 10000000000,
  },
};

You have successfully configured RPC for Binance and Avalanche test networks, you will proceed with the smart contract deployment to those networks in the following step.

Deploy Smart Contract to Binance and Avalanche Network

In this section, you will deploy the smart contract to Binance and Avalanche Testnet. However, before you proceed, you need to specify the Axelar Gateway Service and the Gas Service Contract in the SendMessage.deploy() method within the deploy.js file you created earlier.

You can find the Axelar Gas Service and Gateway contracts list for all the chains Axelar currently supports here.

You also need a faucet for your Binance and Avalanche accounts to ensure successful contract deployment. To obtain the Binance faucet, visit this link, and for the Avalanche faucet, access it here.

Deploy to Binance Testnet

Update the deploy.js file inside the scripts folder to deploy to Binance testnet with the following code snippet:

//...

async function main() {
  //...

  // Update arguments with the Axelar gateway and
  // gas service on Binance testnet
  const sendMessage = await SendMessage.deploy(
    "0x4D147dCb984e6affEEC47e44293DA442580A3Ec0",
    "0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6"
  );

  //...
}

//..

To deploy the contract on the Binance testnet, run the following command:

npx hardhat run scripts/deploy.js --network bsc

For example, the contract address will be displayed in your console: 0xC1b8fC9208E51aC997895626b0f384153E94f2A7.

Deploy to Avalanche Fuji Testnet

Update the deploy.js file inside the scripts folder to deploy to Avalanche testnet with the following code snippet:

//...

async function main() {
  //...

  // Update arguments with the Axelar gateway and
  // gas service on Avalanche testnet
  const sendMessage = await SendMessage.deploy(
    "0xC249632c2D40b9001FE907806902f63038B737Ab",
    "0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6"
  );

  //...
}

//..

To deploy the contract on the Avalanche testnet, run the following command:

npx hardhat run scripts/deploy.js --network avalancheFujiTestnet

The contract address will be displayed on your console; for example, 0x2a03DCB9B24431d02839822209D58262f5e5df52. Make sure to save both deployed contract addresses, as you will need them for front-end integration.

Integrating a Nextjs Frontend Application with Smart Contract

In the previous steps, you successfully built and deployed the smart contract. Now, it's time to interact with it from the front end, just as you would typically interact with decentralized applications on the web.

You already have the Next.js frontend project cloned, and the configuration for WAGMI and Rainbowkit is set up. This means you can proceed to update the existing application and connect your smart contract for testing.

Implementing Write Smart Contract Functionality

Interacting with our contract is quite simple from the front-end application, thanks to WAGMI, RainbowKit, and ethers.

Create a .env.local file in the root directory using the command below:

touch .env.local

Ensure you are in the root directory before running the command above.

Inside the .env.local file you just created, add the following key:

NEXT_PUBLIC_AVALANCHE_RPC_URL=https://avalanche-fuji-c-chain.publicnode.com
NEXT_PUBLIC_BSC_CONTRACT_ADDRESS=<BSC_CONTRACT_ADDRESS>
NEXT_PUBLIC_AVALANCHE_CONTRACT_ADDRESS=<AVALANCHE_CONTRACT_ADDRESS>

Replace <BSC_CONTRACT_ADDRESS> with the contract address, you deployed to the Binance testnet and replace <AVALANCHE_CONTRACT_ADDRESS> with the contract address, you deployed to the Avalanche Fuji Testnet earlier in this tutorial.

Next, implement the write functionality for the smart contract, add the following code snippet to the index.js file located in the pages directory.

//...

const BSC_CONTRACT_ADDRESS = process.env.NEXT_PUBLIC_BSC_CONTRACT_ADDRESS;
const AVALANCHE_CONTRACT_ADDRESS =
  process.env.NEXT_PUBLIC_AVALANCHE_CONTRACT_ADDRESS;
const AVALANCHE_RPC_URL = process.env.NEXT_PUBLIC_AVALANCHE_RPC_URL;

export default function Home() {
//...

const [message, setMessage] = useState(""); 
const [sourceChain, setSourceChain] = useState(""); 

const { config } = usePrepareContractWrite({ // Calling a hook to prepare the contract write configuration
  address: BSC_CONTRACT_ADDRESS, // Address of the BSC contract
  abi: SendMessageContract.abi, // ABI (Application Binary Interface) of the contract
  functionName: "sendMessage", // Name of the function to call on the contract
  args: ["Avalanche", AVALANCHE_CONTRACT_ADDRESS, message], // Arguments to pass to the contract function
  value: ethers.utils.parseEther("0.01"), // Value to send along with the contract call for gas fee
});

const { data: useContractWriteData, write } = useContractWrite(config); 

const { data: useWaitForTransactionData, isSuccess } = useWaitForTransaction({ 
  hash: useContractWriteData?.hash, // Hash of the transaction obtained from the contract write data
});

const handleSendMessage = () => {
  write(); // Initiating the contract call

  toast.info("Sending message...", {
    position: "top-right",
    autoClose: 5000,
    hideProgressBar: false,
    closeOnClick: true,
    pauseOnHover: false,
    draggable: true,
  });
};

useEffect(() => {
    const body = document.querySelector("body");
    darkMode ? body.classList.add("dark") : body.classList.remove("dark");

    isSuccess
      ? toast.success("Message sent!", {
          position: "top-right",
          autoClose: 7000,
          closeOnClick: true,
          pauseOnHover: false,
          draggable: true,
        })
      : useWaitForTransactionData?.error || useContractWriteData?.error
      ? toast.error("Error sending message")
      : null;
  }, [darkMode, useContractWriteData, useWaitForTransactionData]);

return (
    //..
   )
}

In the code snippet above:

Two state variables, message and sourceChain, are declared using the useState hook to hold the message content and source chain, respectively.
The usePrepareContractWrite hook is called to prepare the configuration for a contract write operation. It takes several parameters, such as the BSC contract address, ABI, function name, arguments, and value.
useContractWrite hook retrieves the contract write data and the write function based on the configuration obtained from the previous step.
useWaitForTransaction hook is called to wait for the transaction to be mined. It takes the hash of the transaction obtained from the contract write data.
handleSendMessage function is defined, which initiates the contract call by invoking the write function.
useEffect hook performs actions when certain dependencies change to display toast notifications for successful or failed message sending.

Update the Send button and textarea with the following code snippet to send messages and retrieve the data to be sent.

//...

return (
    //...
    <div className="border border-gray-300 rounded-lg p-8 m-2 ">
        <h2 className="text-2xl font-bold mb-4">Send Message 📓 </h2>
        <textarea
            //...
            onChange={(e) => setMessage(e.target.value)}
        />
        <button
            //...
            onClick={() => handleSendMessage()}
         >
            Send
        </button>
     </div>
    //...
  );
}

Implementing Read Smart Contract Functionality

In the previous step, you implemented the functionality for writing to a smart contract from the front end. This section will teach you how to implement the functionality for reading data from a smart contract.

Update the index.js with the following code snippet:

//...

export default function Home() {
  //...

  const [value, setValue] = useState("");

  const provider = new ethers.providers.JsonRpcProvider(AVALANCHE_RPC_URL); // Create an instance of JsonRpcProvider with Avalanche RPC URL

  const contract = new ethers.Contract(
    AVALANCHE_CONTRACT_ADDRESS, 
    SendMessageContract.abi,

    provider
  );

  async function readDestinationChainVariables() {
    try {
      const value = await contract.value(); 
      const sourceChain = await contract.sourceChain();

      setValue(value.toString()); // Convert the value to a string and store it
      setSourceChain(sourceChain); // Store the source chain
    } catch (error) {
      toast.error("Error reading message"); // Display an error toast if reading fails
    }
  }

  useEffect(() => {
    readDestinationChainVariables(); // Call the function to read destination chain variables

    //...
  }, [darkMode, useContractWriteData, useWaitForTransactionData]);

  return (
    //...

        {value ? ( // Add value here
              <>
                //...
              </>
            ) : (
              <span className="text-red-500 ">waiting for response...</span>
         )}
  );
}

In the code above,

An instance of the JsonRpcProvider class from the ethers.js library is created using the Avalanche RPC URL (AVALANCHE_RPC_URL) as the parameter.
An instance of the Contract class from the ethers.js library is created, representing a contract on the Avalanche network. It takes parameters such as the contract address (AVALANCHE_CONTRACT_ADDRESS), ABI (SendMessageContract.abi), and provider.
An asynchronous function named readDestinationChainVariables is defined. It attempts to read the contract's value and source chain variables using the value() and sourceChain() functions, respectively.
If an error occurs during the reading process, a toast notification with the message "Error reading message" is displayed.
The useEffect hook calls the readDestinationChainVariables function when certain dependencies change.

Trying the Application

Hurray 🥳 , you have successfully built and deployed a full-stack interchain decentralized application.

You can find the GMP transaction on Axelarscan Testnet here and the complete code for this project on GitHub.

What Next?

This post covered the utilization of Axelar's General Message Passing with callContract, but that's not all the General Message Passing can do.

You can always explore other functionalities like callContractWithToken, SendToken, Deposit addresses, NFT Linker, JavaScript SDK, etc.

If you've made it this far, you're awesome! You can also tweet about your experience building or following along with this tutorial to show your support to the author and tag @axelarcore.

Conclusion

This tutorial taught you how to build a full-stack interchain decentralized application using Next.js, Solidity, and Axelar's General Message Passing. You learned how to deploy and send messages from Binance to Avalanche test networks and interact with them through a Next.js frontend application.

Reference

Designing a User-Friendly Course Catalog With Pink Design and Nuxt

Idris Olubisi💡 — Mon, 08 May 2023 11:42:17 +0000

Creating a course catalogue that is both visually appealing and easy to use can be a challenge. However, with the combination of Pink Design and Nuxt.js, we can design an excellent and intuitive catalogue for users.

In this article, we'll learn how to build a course catalogue that allows users to search, filter through the available courses, and view course descriptions & prerequisites.

Sandbox

We completed this project in a Code Sandbox; fork and run it to get started quickly.

GitHub repository

Olanetsoft / Course-Catalog-With-Pink-Design-Nuxt.js

This is a project of an article to build a course catalogue that allows users to search and filter through available courses, view course descriptions and prerequisites.

Course-Catalog-With-Pink-Design-and-Nuxt

Build Setup

# install dependencies
$ yarn install

# serve with hot reload at localhost:3000
$ yarn dev

# build for production and launch server
$ yarn build
$ yarn start

# generate static project
$ yarn generate

For detailed explanation on how things work, check out the documentation.

Special Directories

You can create the following extra directories, some of which have special behaviors. Only pages is required; you can delete them if you don't want to use their functionality.

`assets`

The assets directory contains your uncompiled assets such as Stylus or Sass files, images, or fonts.

More information about the usage of this directory in the documentation.

`components`

The components directory contains your Vue.js components. Components make up the different parts of your page and can be reused and imported into your pages, layouts and even other components.

More information about the usage of this directory…

View on GitHub

Getting Started with Nuxt.js

Nuxt.js is the bedrock of our Vue.js project, providing structure and flexibility while allowing us to scale confidently.

It is extensible, offering a robust module ecosystem and hooks engine. Integrating our REST or GraphQL endpoints, favourite CMS, CSS frameworks, and other third-party applications is seamless.

Project Setup and Installation

To create a new project, we will use the command below to scaffold a new project:

    npx create-nuxt-app <project-name>

A series of prompts will appear as a result of the command. Here are the defaults we recommend:

The command above creates a new Nuxt.js project.

Next, we navigate to the project directory and start the development server using the command below.

    cd <project name> && yarn dev

Nuxt.js will start a hot-reloading development environment accessible by default at http://localhost:3000.

Appwrite Pink Design Setup

To set up an Appwrite pink design in this project, we will configure our project using the Appwrite pink design CDN. Navigate to the nuxt.config.js in the root directory and add the following configuration.

    export default {
      // Global page headers: https://go.nuxtjs.dev/config-head
      head: {
         //...
        link: [
          { rel: "icon", type: "image/x-icon", href: "/favicon.ico" },
          {
            rel: "stylesheet",
            href: "https://unpkg.com/@appwrite.io/pink",
          },
          {
            rel: "stylesheet",
            href: "https://unpkg.com/@appwrite.io/pink-icons",
          },
        ],
      },

     //...
    };

Creating a Sample Course Catalogue JSON

In this step, we will create a sample course catalogue which we will utilize in our application as a database for our courses. In the project's root, create a new JSON file called courses.json and add the following course sample.

    [
      {
        "id": 1,
        "title": "Introduction to Web Development",
        "description": "Learn the basics of web development with HTML, CSS, and JavaScript.",
        "level": "Beginner",
        "prerequisites": [],
        "category": 1
      },
      {
        "id": 2,
        "title": "Advanced Web Development",
        "description": "Build complex web applications with React, Node.js, and MongoDB.",
        "level": "Intermediate",
        "prerequisites": ["Introduction to Web Development"],
        "category": 1
      },
      {
        "id": 3,
        "title": "Introduction to Mobile Development",
        "description": "Learn the basics of mobile development with React Native and Expo.",
        "level": "Beginner",
        "prerequisites": ["Introduction to Web Development"],
        "category": 2
      },
      {
        "id": 4,
        "title": "Data Analysis with Python",
        "description": "Learn how to analyze and visualize data using Python and Pandas.",
        "level": "Intermediate",
        "prerequisites": ["Introduction to Web Development"],
        "category": 3
      },
      {
        "id": 5,
        "title": "User Interface Design Fundamentals",
        "description": "Learn the basics of user interface design with Sketch.",
        "level": "Beginner",
        "prerequisites": [],
        "category": 4
      },
      {
        "id": 6,
        "title": "Cloud Computing with AWS",
        "description": "Learn how to deploy and scale web applications on Amazon Web Services.",
        "level": "Intermediate",
        "prerequisites": ["Introduction to Web Development"],
        "category": 5
      }
    ]

In the sample data above, we have the identifier for each record id, a title, category, description, level, prerequisites, and category.

Designing the layout for the Course Catalogue

Let's design an aesthetically appealing design for the course catalogue in this section by updating the pages/index.vue with the following code snippet.

    <template>
      <div>
        <div class="container">
          <div class="sidebar">
            <!-- Sidebar content goes here -->
           </div>
          <div class="content">
             <!-- Search and Course list goes here -->
          </div>
        </div>
        <div class="course-modal" v-if="selectedCourse">
          <div class="modal-content">
            <!-- Modal goes here -->
          </div>
        </div>
      </div>
    </template>

Let's add CSS by creating a new file called styles.css in the root directory and updating it with the following CSS snippet.

Import the style by updating the pages/index.vue with the following code snippet.

    <template>
      <!--  -->
    </template>

    <style>
    @import '@/styles.css';
    </style>

Developing the Functionality to Retrieve All Courses

In the previous step, we successfully designed the application layout; now, we will implement the functionality to retrieve all courses from the JSON file we created earlier.

Inside the pages/index.vue file, update it with the following code snippet.

    <template>
      <div>
        <div class="container">
          <div class="sidebar">

          </div>
          <div class="content">
            <h1 class="course-catalogue-title">
              Course Catalog With Pink Design and Nuxt.js
            </h1>
             <!-- Search goes here -->
            <div class="courses">
              <div
                class="course-card"
                v-for="course in filteredCourses"
                :key="course.id"
              >
                <div class="card" @click="openCourseModal(course)">
                  <div class="card-content">
                    <h3 class="title">{{ course.title }}</h3>
                    <div class="description">{{ course.description }}</div>
                    <div class="details">
                      <div class="level">{{ course.level }}</div>
                    </div>
                  </div>

                </div>
              </div>
            </div>
          </div>
        </div>
        </div>
        <div class="course-modal" v-if="selectedCourse">
          <div class="modal-content">
           <!-- Modal goes here -->
          </div>
        </div>
      </div>
    </template>
    <!--  -->

    <!-- Importing data from a JSON file named courses.json -->
    <script>
    import coursesData from '../courses.json'

    export default {
      // Defining the data property of the component
      data() {
        // Returning an object with a key of 'courses' and its value set to the imported coursesData
        return {
          courses: coursesData,
        }
      },
    }
    </script>

In the code snippet above,

We import data from a JSON file named courses.json.
The data() function returns an object with the key of courses and its value set to the imported coursesData variable.

We should have something similar to what is shown below.

Adding a Search and Filter by Category feature to the Course Catalog

In the sources, we have different categories. Let's implement the course filtering search functionality to filter based on the course category by updating the pages/index.vue file with the following code snippet.

In the code snippet above we:

Utilized the imported JSON file with course data
Defined a Vue.js component that uses the imported course data as its initial state
Created component's data properties, which include search searchQuery, categories, and the currently selected category
Defined a computed property that filters courses based on the search query and currently selected category
Returned the filtered courses in the component's computed property

We are almost there! We can retrieve all courses and search and filter courses but we can't view individual courses yet, let's implement that in the following step.

Implementing the Course View Functionality

To implement course view functionality, we will add a modal to view the course content whenever a user clicks on an individual course. Let's update the pages/index.vue file with the following code snippet.

    <template>
      <div>
        <div class="container">
          <!-- //... -->
        </div>
        <div class="course-modal" v-if="selectedCourse">
          <div class="modal-content">
            <span class="close-modal" @click="closeCourseModal">&times;</span>
            <h2 class="modal-title">{{ selectedCourse.title }}</h2>
            <div class="modal-description">{{ selectedCourse.description }}</div>
            <div class="details">
              <div class="modal-level">{{ selectedCourse.level }}</div>
            </div>
            <div class="modal-prerequisites">
              <h3>Prerequisites</h3>
              <ul v-if="selectedCourse.prerequisites.length">
                <li
                  v-for="prerequisite in selectedCourse.prerequisites"
                  :key="prerequisite"
                >
                  {{ prerequisite }}
                </li>
              </ul>
              <p v-else>None</p>
            </div>
          </div>
        </div>
      </div>
    </template>

    <script>
    // Import courses data from JSON file
    import coursesData from "../courses.json";
    export default {
      data() {
        return {
          //...
          selectedCourse: null,
        };
      },
      methods: {
        //...
        openCourseModal(course) {
          this.selectedCourse = course;
        },
        closeCourseModal() {
          this.selectedCourse = null;
        },
      },
      computed: {
        //...
      },
    };
    </script>

    //...

In the code snippet above,

The course list container dynamically generates a course element for each course in the filtered course list using v-for
Each course element has an on-click event that triggers the @click="openCourseModal(course)" method
The selectedCourse variable is set to the course object to display the modal using the openCourseModal method
The selectedCourse becomes null when the close modal icon is clicked, which triggers the closeCourseModal method

Testing the application, we should have something similar to what is shown below.

Conclusion

This post demonstrated how to design a user-friendly course catalogue with pink design and Nuxt.js. Additionally, you learned how to search, filter through the available courses, and view course descriptions and prerequisites.

Forem: Idris Olubisi💡

Midnight MCP - AI-assisted development for Compact smart contracts

What is MCP?

The problem with AI-generated Compact code

Install Midnight MCP

Claude Desktop

Cursor

VS Code with GitHub Copilot

How Midnight MCP works

Real compiler integration

Graceful fallback

Semantic search across 102 repositories

29+ tools for Midnight development

Search tools

Analysis tools

Generation tools

Repository tools

Version management tools

Resources and prompts

Architecture

What's next

Learn more

Depth Over Trend

Depth Over Trend

Depth Over Trend

Depth vs Trend

Why should you care?

Self Reflection

[Boost]

5 Must-Watch Tutorials to Build Your SaaS App in 2025

Femi-ige Muyiwa for Hackmamba ・ Feb 27

Multichain Real-World Asset (RWA) Lending with Axelar GMP

What is a Real-world Asset (RWA)?

Prerequisites

Create a Mock RWA Token

Create a Mock RWA Oracle

Create the Lending Pool Contract

Import Necessary Contracts

Add State Variables, Structs, and Events

Implement the Constructor

Create a Multichain Loan Function

Create Repay Cross-Chain Loan Function

Implement Interest Calculation Function

Create the _executeWithToken Function

Implement _createLoanInternal Function

Implement _execute Function for Incoming Cross-chain Message

Testing the Lending Pool Contract

Deploy Mock RWA Token

Mint RWA tokens

Deploy RWAOracle Contract

Set RWA Token Value

Deploy the Lending Pool Contract on the Fantom Testnet

Deploy the Lending Pool Contract on the Celo Testnet

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

Approve Lending Pool Contract to Spend the Asset to Be Borrowed

Fund the Destination Contract with the Asset to be Borrowed

Call initiateCrossChainLoan on the Lending Pool Contract on Fantom Network

Call repayCrossChainLoan on Lending Pool Contract on Celo Tesnet

Conclusion

References

Cross-Chain Governance with OpenZeppelin Governor and Axelar

Prerequisites

What is the OpenZeppelin Governor Contract?

Interchain Governance Orchestrator

Getting started with Axelar General Message Passing

Project setup and installation

Create and initialize a project

Install Hardhat and the AxelarJS SDK

Initialize a Hardhat project

Build the smart contracts

Build the InterchainCalls library

Build the InterchainProposalSender contract

Build the GovernanceToken contract

Build the ThresholdContract contract

Build the CrossChainGovernor contract

Contract declaration and imports

State variables and events

Add a constructor

Add whitelisting and proposal threshold update

Add execute threshold proposal function

Create the `_executeWithToken` Function

Implement `_createLoanInternal` Function

Implement `_execute` Function for Incoming Cross-chain Message

Call `repayCrossChainLoan` on Lending Pool Contract on Celo Tesnet

Build the `InterchainCalls` library

Build the `InterchainProposalSender` contract

Build the `GovernanceToken` contract

Build the `ThresholdContract` contract

Build the `CrossChainGovernor` contract

Add `_execute` function

Create `MockAxelarGateway.sol`

Create `MockAxelarGasService.sol`

Create the `CrossChainGovernor.test.js` file

Setting up the contract instances with `beforeEach`