In this guide, we’ll build exactly that: a Telegram trading bot that executes swaps on a custom DEX deployed to the Sonic Testnet and enriches the experience with Covalent’s GoldRush API. Here is the Test version: @GoldrushAPISonicChainDEX_bot

By the end of this tutorial, you will have:

• A minimal DEX (Uniswap V2 style) deployed on Sonic Testnet

• A working Telegram bot that can quote, swap, and check balances

• Integrated Covalent GoldRush APIs to show prices in USD, portfolio breakdowns, and recent transactions

This is a hands-on build and a great demonstration of how on-chain execution and Covalent’s off-chain enrichment create powerful developer tools.

Prerequisites

To follow along, you’ll need:

• Node.js (v18+)

• A Telegram account and bot token from @BotFather

• A Sonic Testnet wallet with tokens (get some at the Sonic faucet)

• Remix IDE (remix.ethereum.org) for deploying contracts

• A Covalent API key (free at CovalentHQ)

We’ll use a test wallet throughout—never paste your mainnet keys into tutorials.

Minimal DEX on Sonic

Sonic Testnet doesn’t ship with a default router, I have deployed a minimal Uniswap V2-style DEX, which you can also rely on.

Smart Contracts

ROUTER_V2=0x2e7f682863a9DCb32Dd298cCf8724603728d0edd
TOKEN_A=0x6c1C9a79AA84EB4026D80337a5EeC2677E367c2e
TOKEN_B=0x89b7Bc09d97Fc0A64b6EcBb7E2995f528F584312

Initialize the Project

Create a new project folder and install dependencies:

mkdir sonic-goldrush-dex

cd sonic-goldrush-dex

npm init -y

npm install telegraf ethers node-fetch dotenv

We’ll use:

• telegraf for Telegram bot commands

• ethers for contract calls

• node-fetch for API calls

• dotenv for environment config

To add Environment Variables Cceate a .env file in the project root and add the following:

BOT_TOKEN=123456:ABC...           # Telegram bot token from @BotFather
PRIVATE_KEY=0xabc123...           # Sonic Testnet wallet private key
RPC_URL=https://rpc.testnet.soniclabs.com
CHAIN_ID=14601
ROUTER_V2=0xYourRouterAddress
TOKEN_WS=0xTokenAAddress          # map TokenA to “WS”
TOKEN_USDC=0xTokenBAddress        # map TokenB to “USDC”
COVALENT_API_KEY=ckey_xxx
COVALENT_CHAIN_ID=sonic-testnet
COVALENT_QUOTE=USD

• BOT_TOKEN allows your Node.js bot to speak to Telegram.

• PRIVATE_KEY signs transactions on Sonic Testnet.

• ROUTER_V2, TOKEN_WS, and TOKEN_USDC point to the contracts you deployed.

• COVALENT_* configure GoldRush for price + portfolio enrichment.

The bot doesn’t need full ABIs. Save this as abi.js:

module.exports = {

  ERC20_ABI: [
    "function name() view returns (string)",
    "function symbol() view returns (string)",
    "function decimals() view returns (uint8)",
    "function totalSupply() view returns (uint256)",
    "function balanceOf(address) view returns (uint256)",
    "function allowance(address,address) view returns (uint256)",
    "function approve(address,uint256) returns (bool)",
    "function transfer(address,uint256) returns (bool)",
    "function transferFrom(address,address,uint256) returns (bool)"
  ],

  ROUTER_V2_ABI: [
    "function getAmountsOut(uint amountIn, address[] calldata path) view returns (uint[] memory amounts)",
    "function swapExactTokensForTokens(uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline) returns (uint[] memory amounts)",
    "function addLiquidity(address,address,uint,uint) returns (uint liquidity)",
    "function removeLiquidity(address,address,uint) returns (uint,uint)"
  ]
};

This keeps the bot lightweight while still able to interact with ERC-20s and the Router.

Bot Core (Quotes, Swaps, Balances)

In index.js, we start with environment validation and setup:

require('dotenv').config();

const { Telegraf } = require('telegraf');
const { ethers } = require('ethers');
const fetch = require('node-fetch');
const { ERC20_ABI, ROUTER_V2_ABI } = require('./abi');

// validate & parse env

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL, process.env.CHAIN_ID);
const wallet   = new ethers.Wallet(process.env.PRIVATE_KEY, provider);
const router   = new ethers.Contract(process.env.ROUTER_V2, ROUTER_V2_ABI, wallet);
const TOKENS = { WS: process.env.TOKEN_WS, USDC: process.env.TOKEN_USDC };

We now add helpers:

• parseToken() → resolve a symbol or address

• toUnits / fromUnits → convert user input into correct decimals

• getAmountsOut() → router price quotes

• ensureAllowance() → auto-approve router if not approved

• swapExactTokens() → main swap function with slippage + deadline

Telegram commands

• /start → shows wallet and commands

• /price <A> <B> <amount> → quotes a trade

• /buy <A> <B> <amount> → executes a swap

• /balance <token> → shows ERC-20 balance

• /slippage <bps> → sets tolerance per chat

• /deadline <mins> → sets deadline per chat

At this point, you can quote and trade tokens from Telegram.

Enrich with Covalent GoldRush

Raw on-chain data is functional but not human-friendly. Enter Covalent GoldRush.

We add a generic covalentFetch:

async function covalentFetch(path, params = {}) {
  const qs = new URLSearchParams({ key: process.env.COVALENT_API_KEY, ...params }).toString();
  const url = https://api.covalenthq.com/v1/${process.env.COVALENT_CHAIN_ID}/${path}?${qs};
  const r = await fetch(url);
  const j = await r.json();
  return j;
}

USD Prices

async function covalentLatestPriceByContract(contractAddress) {
  const path = pricing/historical_by_addresses_v2/USD/${contractAddress}/;
  const j = await covalentFetch(path, { "page-size": 1 });
  const series = j?.data?.items?.[0]?.prices || [];
  const last = series[series.length - 1];
  return last?.price ?? null;
}

Portfolio balances

async function covalentPortfolio(address) {
  const j = await covalentFetch(`address/${address}/balances_v2/`, { "quote-currency": "USD", nft: false });
  return j?.data?.items || [];
}

Transactions

async function covalentLatestTxs(address, n=5) {
  const j = await covalentFetch(`address/${address}/transactions_v3/`, { "page-size": n });
  return j?.data?.items || [];
}

/gold Commands

We group analytics under /gold:

• /gold price <token> → latest USD/token from Covalent

• /gold portfolio → token balances with USD values

• /gold txs me 5 → last 5 transactions

For example:

/gold portfolio

Portfolio (USD):
WS: 5000 (~$4900.00)
USDC: 2500 (~$2500.00)

Demo Run

1. Start the bot:

node index.js

2. Run the following prompts in Telegram:

• /price WS USDC 1 → “1 WS → 0.99 USDC (~0.99 USD)”

• /buy WS USDC 1 → “Swap sent ✅ tx: 0x1234…abcd”

• /gold txs me 3 → shows last 3 bot wallet transactions

Now your Telegram chat is a full trading and analytics interface.

Conclusion

We combined on-chain execution (a minimal Sonic DEX + swaps) with off-chain enrichment (Covalent GoldRush) inside a Telegram bot.

Developers now have a blueprint to build high-frequency bots, portfolio dashboards, or automated strategies—all in a chat UX. Get your Covalent API key at covalenthq.com/platform and start experimenting today.

Recently, I encountered a scenario where I needed to clean and validate data submitted via a form. The intent was to source developers, and therefore, the Form fields included names, emails, GitHub profiles, etc. Due to the nature of the form being made public, many responses were received, including from non-developers. The response was in thousands, so a db cleanup was then activated. To achieve the cleanup, I initiated a process of vetting the responses using GitHub profiles to ensure the information provided was accurate and meaningful. Using JavaScript and the GitHub API, I developed a solution that:

1. Verified if a GitHub profile exists.

2. Checked if the profile has more than three repositories.

3. Checked if the profile has made more than five commits across all repositories.

4. Exported the results to a CSV file for further processing.

This tutorial walks you through the process of building this solution.

Prerequisites

Before diving into the code, make sure you have the following:

1. Node.js installed on your machine.

2. A GitHub Personal Access Token (optional but recommended to avoid hitting API rate limits). You can create one by following GitHub's guide.

3. Basic knowledge of JavaScript and Node.js.

Set Up the Project

Initialize the Project

Open your Terminal to start a new project

mkdir github-profile-vetting
cd github-profile-vetting

npm init -y

npm install axios

Create the Script File

Create a file named vetProfiles.js and paste the following code. Below is a breakdown of each function in the script:

Import the required Libraries

const axios = require('axios');
const fs = require('fs');
const path = require('path');

axios is used to make HTTP requests to GitHub's API endpoints, allowing the script to fetch data.

fs enables file creation and writing, which is crucial for exporting the processed data (in this case, to a CSV file) that can be shared or analyzed further.

path ensures the portability of file paths across operating systems without path-related errors.

Set Up the Axios Instance

// GitHub API base URL
const GITHUB_API_BASE_URL = 'https://api.github.com';

// Replace with your GitHub personal access token (optional but recommended for higher rate limits)
const GITHUB_PERSONAL_ACCESS_TOKEN = 'your_personal_access_token';

const axiosInstance = axios.create({
  baseURL: GITHUB_API_BASE_URL,
  headers: GITHUB_PERSONAL_ACCESS_TOKEN
    ? { Authorization: `Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}` }
    : {},
});

This initializes an Axios instance with the base URL for GitHub's API. If a personal access token is provided, it includes an Authorization header for authenticated requests, which helps avoid API rate limits.

Function: checkGitHubProfile

async function checkGitHubProfile(username) {

  try {
    const userResponse = await axiosInstance.get(`/users/${username}`);
    const publicReposCount = userResponse.data.public_repos;

    if (publicReposCount <= 3) {
      return { username, exists: true, meetsCriteria: false, isProspect: true, reason: 'Less than 3 repositories' };
    }

    let totalCommits = 0;
    let page = 1;

    while (true) {
      const reposResponse = await axiosInstance.get(`/users/${username}/repos`, {
        params: { per_page: 100, page },
      });

      const repos = reposResponse.data;
      if (repos.length === 0) break;

      for (const repo of repos) {
        const commitsResponse = await axiosInstance.get(`/repos/${repo.owner.login}/${repo.name}/commits`, {
          params: { author: username, per_page: 1 },
        });
        totalCommits += commitsResponse.headers['x-total-count']
          ? parseInt(commitsResponse.headers['x-total-count'], 10)
          : 0;
      }
      page++;
    }

    if (totalCommits <= 5) {
      return { username, exists: true, meetsCriteria: false, isProspect: true, reason: 'Less than 5 commits' };
    }
    return { username, exists: true, meetsCriteria: true, isProspect: false, reason: 'Meets all criteria' };
  } catch (error) {
    if (error.response && error.response.status === 404) {
      return { username, exists: false, meetsCriteria: false, isProspect: false, reason: 'Profile does not exist' };
    }
    return { username, exists: false, meetsCriteria: false, isProspect: false, reason: 'Error occurred' };
  }
}

This function checks if a GitHub profile exists and evaluates it based on repository count and commit history.

• 1. Verify if the profile exists using the /users/:username endpoint.

     2. Check the number of public repositories.

     3. Fetch commit data from each repository and calculate the total commits.

     4. Return the result, including whether the profile meets the criteria.

Function: checkProfiles

async function checkProfiles(profiles) {

  const results = [];

  for (const username of profiles) {
    const result = await checkGitHubProfile(username);
    results.push(result);
  }

  const csvContent = [
    'Username,Exists,MeetsCriteria,IsProspect,Reason',
    ...results.map(r => `${r.username},${r.exists},${r.meetsCriteria},${r.isProspect},"${r.reason}"`),
  ].join('\n');

  const outputPath = path.join(__dirname, 'github_profiles_check.csv');
  fs.writeFileSync(outputPath, csvContent);

  console.log(`Results exported to ${outputPath}`);
}

This function processes multiple GitHub profiles and generates a CSV file with the results. It iterates through the list of usernames and calls checkGitHubProfile for each. The response is then formatted into a CSV string and exported to a file named github_profiles_check.csv

Example Usage

const githubProfiles = ['octocat', 'torvalds', 'nonexistentprofile'];
checkProfiles(githubProfiles);

Pass some GitHub profiles to the checkProfiles function with a list of sample usernames in an array string.

Run the Script

node vetProfiles.js

The script will verify each GitHub profile and check for repositories and commits. The results will be exported to a CSV file named github_profiles_check.csv.

Export and Analyze the Data

• Open the CSV file in Google Sheets or Excel to review the results.

• Use Conditional Formatting in Google Sheets to highlight cells where MeetsCriteria is TRUE.

• Use the COUNTIF function to count how many profiles meet the criteria:

    =COUNTIF(ColumnA:ColumnZ, "TRUE")
  

Lessons Learned

This process helped clean up and validate user-submitted data efficiently. The GitHub API allowed me to automate a significant part of the work, reducing manual effort and errors. The experience reinforced the importance of leveraging APIs to streamline workflows.

Conclusion

By combining JavaScript, the GitHub API, and some simple scripting, I was able to build a powerful tool to vet GitHub profiles and export the results for analysis. This tutorial can be adapted to other use cases requiring data validation and processing.

Feel free to modify the script to suit your needs and happy coding!

Introduction

In this second part of the tutorial, I'll guide you through building a Frontend application using Next.js to interact with the smart contract you deployed in Part 1. This frontend will allow users to connect their MetaMask wallets, make predictions, place bets, and see the results of their game.

Prerequisites:

Before diving into the tutorial, ensure you have the following:

• A basic understanding of React and Next.js.

• Node.js and npm installed on your machine.

• The Smart Contract deployed to the Linea Sepolia Testnet (from Part 1).

• The Smart Contract address and ABI from the deployed contract.

Step 1: Setting Up the Next.js Project

1. Create a New Next.js Project:

Open your terminal and create a new Next.js project and navigate to the project directory using the following command:

npx create-next-app prediction-game && cd prediction-game

2. Install Dependencies:

Install the viemjs for interacting with the blockchain:

npm install viem ethers

3. Install Tailwind CSS for styling:

npx tailwindcss init -p

Configure Tailwind by adding the following to your tailwind.config.js:

module.exports = {
content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Add Tailwind to your global CSS file in styles/globals.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

Step 2: Setting Up the Environment Variables

Create a .env.local file in your project root:

Store your Smart Contract address:

NEXT_PUBLIC_CONTRACT_ADDRESS=0xYourContractAddress

Add the ABI File:

Create a new file named abi.js in the root directory.

Copy the ABI of your smart contract (from Part 1) and paste in an export const declaration.

export const ABI = [//paste ABI here]

Step 3: Connecting to MetaMask

Create a MetaMask Connection Component:

In your pages/index.js, remove all the template code. Set up a basic structure to connect to MetaMask:

import { useState } from "react";
import {
  createWalletClient,
  custom,
} from "viem";
import { lineaSepolia } from "viem/chains";

export default function Home() {
  const [client, setClient] = useState(null);
  const [address, setAddress] = useState(null);
  const [connected, setConnected] = useState(false);

  const connectToMetaMask = async () => {
    if (typeof window !== "undefined" && typeof window.ethereum !== "undefined") {
      try {
        await window.ethereum.request({ method: "eth_requestAccounts" });
        const walletClient = createWalletClient({
          chain: lineaSepolia,
          transport: custom(window.ethereum),
        });
        const [userAddress] = await walletClient.getAddresses();
        setClient(walletClient);
        setAddress(userAddress);
        setConnected(true);
        console.log("Connected account:", userAddress);
      } catch (error) {
        console.error("User denied account access:", error);
      }
    } else {
      console.log("MetaMask is not installed or not running in a browser environment!");
    }
  };

  return (
    <main
      className={`flex min-h-screen flex-col items-center justify-between p-24`}
    >
      {!connected ? (
        <button
          onClick={connectToMetaMask}
          className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
        >
          Connect Wallet
        </button>
      ) : (
        <div>
          <p>Connected as: {address}</p>
        </div>
      )}
    </main>
  );
}

This component allows users to connect their MetaMask wallet.

Step 4: Building the Form for the play Method

Add the Form UI:

Modify your Home component to include a form that allows users to input their prediction and bet amount. We will add various states to manage the form inputs.

import ABI from "../abi";

const publicClient = createPublicClient({
  chain: lineaSepolia,
  transport: http(),
});

export default function Home() {
...
  // Add new States
  const [houseBalance, setHouseBalance] = useState(null);
  const [prediction, setPrediction] = useState("");
  const [betAmount, setBetAmount] = useState("");
  const [transactionHash, setTransactionHash] = useState("");

    const handlePlay = async (event) => {
      event.preventDefault();

      if (!client || !address) {
        console.error("Client or address not available");
        return;
      }

      try {
        const { request } = await publicClient.simulateContract({
          account: address,
          address: process.env.NEXT_PUBLIC_CONTRACT_ADDRESS,
          abi: ABI,
          functionName: "play",
          args: [parseInt(prediction, 10)],
          value: parseEther(betAmount),
        });

        if (!request) {
          console.error("Simulation failed to return a valid request object.");
          return;
        }

        console.log("Simulation successful. Request object:", request);

        const hash = await client.writeContract(request);
        setTransactionHash(hash);
        console.log(`Transaction sent: ${hash}`);

        const receipt = await client.waitForTransactionReceipt({hash});
        console.log(`Transaction confirmed: ${receipt.transactionHash}`);
      } catch (error) {
        console.error("Simulation or transaction failed:", error);
      }
    };

    return (
      <div>
        <form onSubmit={handlePlay} className="mt-4">
          <div className="mb-4">
            <label className="block text-gray-700 text-sm font-bold mb-2">
              Prediction (0-9):
            </label>
            <input
              type="number"
              min="0"
              max="9"
              value={prediction}
              onChange={(e) => setPrediction(e.target.value)}
              required
              className="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
            />
          </div>
          <div className="mb-4">
            <label className="block text-gray-700 text-sm font-bold mb-2">
              Bet Amount (in ETH):
            </label>
            <input
              type="text"
              value={betAmount}
              onChange={(e) => setBetAmount(e.target.value)}
              required
              className="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
            />
          </div>
          <button
            type="submit"
            className="bg-green-500 hover:bg-green-700 text-white font-bold py-2 px-4 rounded"
          >
            Play
          </button>
        </form>

        {transactionHash && (
          <p className="mt-4">Transaction sent: {transactionHash}</p>
        )}
      </div>
    );
}

Form Input: Users can input their prediction (a number between 0 and 9) and the amount they want to bet.

Transaction Handling: The form submits the data, simulates the transaction, and sends it if successful. The transaction hash is displayed on the UI.

Step 5: Handling Contract Events

Fetch and Display Game Results:

Add a function to handle events emitted by the contract:

const fetchGameEvents = async (blockNumber, transactionHash) => {
  try {
    const logs = await publicClient.getContractEvents({
      client: publicClient,
      address: process.env.NEXT_PUBLIC_CONTRACT_ADDRESS,
      abi: ABI,
      eventName: "GamePlayed",
      fromBlock: blockNumber,
      toBlock: blockNumber,
    });

    if (logs.length > 0) {
      const event = logs[0];
      const { args } = event;
      const { player, amount, prediction, houseNumber } = args;
      setGameResult(`Game Played: Player ${player} predicted ${prediction}, House Number: ${houseNumber}, Bet Amount: ${amount}`);
    }

    const wonLogs = await publicClient.getContractEvents({
      client: publicClient,
      address: process.env.NEXT_PUBLIC_CONTRACT_ADDRESS,
      abi: ABI,
      eventName: "GameWon",
      fromBlock: blockNumber,
      toBlock: blockNumber,
    });

    if (wonLogs.length > 0) {
      setGameResult(`You won the game!`);
    }

    const lostLogs = await publicClient.getContractEvents({
      client: publicClient,
      address: process.env.NEXT_PUBLIC_CONTRACT_ADDRESS,
      abi: ABI,
      eventName: "GameLost",
      fromBlock: blockNumber,
      toBlock: blockNumber,
    });

    if (lostLogs.length > 0) {
      setGameResult(`You lost the game.`);
    }
  } catch (error) {
    console.error("Failed to fetch game events:", error);
  }
};

This function listens for the GamePlayed, GameWon, and GameLost events and updates the UI with the appropriate message.

Update the States, the play function and the UI to display the results.

 // State to store game result
    const [gameResult, setGameResult] = useState("");

 // After confirmation in handle play, fetch and handle events
    await fetchGameEvents(receipt.blockNumber, receipt.transactionHash);

 // In the UI After Hash is displayed, return Game Result
    {gameResult && (
      <p className="mt-4">{gameResult}</p>
    )}

Step 6: Running the Application

Start the Development Server:

Run the following command to start the Next.js development server

npm run dev

Open your browser and navigate to http://localhost:3000.

Testing the App:

Connect your MetaMask wallet, place bets, and see the game results in real-time.

Conclusion:

In this second part of the tutorial, you've built a complete Frontend application for your blockchain-based prediction game using Next.js. Users can connect their MetaMask wallets, place bets, and view game results directly in the browser. You've successfully bridged the gap between blockchain and web development, creating a seamless user experience.

Feel free to customize and extend this application further. You might want to add features like historical game data, leaderboards, or more sophisticated game mechanics.

You can find the complete code here. Live Website.

Happy coding! 🚀

In this tutorial, I'll guide you through writing and deploying a Solidity Smart Contract on the Linea blockchain. This smart contract will form the backbone of a simple prediction game where users can wager Ether, make predictions, and either win or lose based on the outcome.

Prerequisites:

Before diving into the tutorial, ensure you have the following:

• Basic knowledge of Solidity and Smart Contracts.

• Familiarity with Ethereum development tools like Remix, MetaMask, and a code editor (e.g., VS Code).

• MetaMask wallet installed and connected to the Linea Sepolia Testnet.

• Some test Ether in your MetaMask wallet for deployment and testing.

  Please note: You need some Ether on Linea Mainnet to get Test Ether on the Linea Faucets.

Step 1: Setting Up Your Development Environment

1. Install MetaMask:

   • If you haven't already, install the MetaMask browser extension.

   • Connect MetaMask to the Linea Sepolia testnet. You can add the Linea Sepolia network by visiting ChainList . You can optionally add Linear Network information using the following details:

     • Network Name: Linea Sepolia

     • New RPC URL: https://rpc.sepolia.linea.build

     • Chain ID: 59141

     • Currency Symbol: ETH

2. Access Remix IDE:

   • Open Remix IDE in your browser.

     Remix is an online IDE that allows you to write, compile, and deploy Solidity Smart Contracts directly from your browser.

Step 2: Writing the Smart Contract

Let's start by writing the Solidity smart contract for the prediction game.

1. Create a New File:

   • In Remix, create a new file named PredictionGame.sol.

2. Write the Contract:

   • Copy and paste the following Solidity code into your new file:

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

    contract PredictionGame {
        address public owner;
        uint256 public houseBalance;

        event GamePlayed(address indexed player, uint256 amount, uint256 prediction, uint256 houseNumber);
        event GameWon(address indexed player, uint256 amountWon);
        event GameLost(address indexed player, uint256 amountLost);

        constructor() {
            owner = msg.sender;
        }

        modifier onlyOwner() {
            require(msg.sender == owner, "Only the owner can call this function");
            _;
        }

        modifier sufficientFunds(uint256 amount) {
            require(msg.value >= amount, "Insufficient funds to play");
            _;
        }

        function depositToHouse() public payable onlyOwner {
            houseBalance += msg.value;
        }

        function withdrawHouseFunds(uint256 amount) public onlyOwner {
            require(amount <= houseBalance, "Not enough funds in the house");
            houseBalance -= amount;
            payable(owner).transfer(amount);
        }

        function generateRandomNumber() private view returns (uint256) {
            return uint256(keccak256(abi.encodePacked(block.timestamp, block.prevrandao, msg.sender))) % 10;
        }

        function play(uint256 userPrediction) public payable sufficientFunds(0.0001 ether) {
            require(houseBalance >= msg.value * 10 / 100, "House doesn't have enough balance to cover potential winnings");
            require(msg.value >= 0.0001 ether, "Must bet at least 0.0001 Ether");
            require(userPrediction >= 0 && userPrediction <= 9, "Prediction must be between 0 and 9");

            uint256 houseNumber = generateRandomNumber();
            emit GamePlayed(msg.sender, msg.value, userPrediction, houseNumber);

            if (userPrediction == houseNumber) {
                uint256 winnings = msg.value + msg.value * 10 / 100;
                houseBalance -= winnings - msg.value;
                payable(msg.sender).transfer(winnings);
                emit GameWon(msg.sender, winnings);
            } else {
                uint256 loss = msg.value * 15 / 100;
                houseBalance += loss;
                payable(owner).transfer(loss);
                payable(msg.sender).transfer(msg.value - loss);
                emit GameLost(msg.sender, loss);
            }
        }

        receive() external payable {
            houseBalance += msg.value;
        }
    }

Step 3: Understanding the Smart Contract

This contract allows users to wager an amount and predict a number between 0 and 9, where they are playing "against the house." If the user guesses correctly, they win their bet amount plus 10% from the house. If they lose, the house takes 15% of their bet. The "house" stakes an amount in the Smart Contract that users can wager against.

• Key Functions:

  • depositToHouse: Allows the owner of the Smart Contract to deposit Ether into the house balance.

  • withdrawHouseFunds: Allows the owner to withdraw Ether from the house balance.

  • play: The primary function where users place their bet and make a prediction.

  • generateRandomNumber: Generates a pseudo-random number between 0 and 9.

  • receive: Fallback function to receive Ether.

Step 4: Compiling the Smart Contract

1. Compile the Contract:

   • In Remix, navigate to the "Solidity Compiler" tab on the left sidebar.

   • Ensure the correct Solidity version (^0.8.18) is selected.

   • Click "Compile PredictionGame.sol".

   • You should see a green checkmark next to the compilation button if there are no errors.

Step 5: Deploying the Smart Contract to Linea Sepolia

1. Deploy the Contract:

   • Go to the "Deploy & Run Transactions" tab in Remix.

   • Ensure the "Environment" is set to "Injected Web3" (MetaMask should be connected).

   • Select the PredictionGame contract from the dropdown.

   • Click "Deploy" and confirm the transaction in MetaMask.

2. Verify Deployment:

   • Once the transaction is confirmed, your contract will be deployed on the Linea Sepolia network.

   • Copy the contract address for use in the next part of the tutorial.

Step 6: Interacting with the Smart Contract

1. Interacting via Remix:

   • In the "Deploy & Run Transactions" tab, you'll see the deployed contract under "Deployed Contracts".

   • You can interact with the contract by calling functions like play, depositToHouse, withdrawHouseFunds, and houseBalance.

2. Testing the Contract:

   • Test the play function by making predictions and placing bets.

   • Use houseBalance to check the balance of the contract and withdrawHouseFunds to withdraw funds as the owner.

Conclusion:

In this first part of the tutorial, you learned how to write a Solidity smart contract for a prediction game and deploy it to the Linea Sepolia Testnet. You also tested the Smart Contract to ensure it works as expected. You can find my Smart Contract version here.

In the next part of the tutorial, we'll build a frontend application using Next.js to interact with this Smart Contract. The application will allow users to connect their wallets, place bets, and see the outcomes.

In this article, we will build a Tipping Contract that you can deploy on any EVM compatible chain. The contract will ensure the following:

• You can receive tips/payments/donations in any ERC20 Tokens.

• You can withdraw the Tokens from the contract to your Externally Owned Address (EOA) also known as your Wallet Address.

• As the owner of the contract, you are the only one who can carry out the withdrawal function.

• You can set the minimum tips/payment/donations amount.

The breakdown above has given an insight into the full functionality of the Smart Contract we are going to build. You can immediately get a sense of the various functions we will write, the modifiers, events that we will also want to be emitted, and the original constructor arguments we will deploy the contract with. To be certain that we are aligned in that regard, here are the functions:

• ReceiveTips(): This is the function that users will call and send tips to the Smart Contract.

• WithdrawTips(): This is the function that you will call to withdraw tips sent to the Smart Contract.

• getContractBalance(): This is the function you can call to ascertain the amount of an ERC20 token balance in your Smart Contract.

• UpdateWithdrawAddress(): This is the function where you can set a new address to withdraw tokens and send to.

With each of the functions, we can immediately understand the various events that we want to emit.

• Receive

• WithDraw

OK. It is important to note that your approach to building Dapps might be different. Some developers will rather jump straight into an IDE and start hacking away on their keyboards, but, as the popular saying goes: “Measure Twice, and cut once.”

The next step will be to open our Remix IDE and start to write the Smart Contract code:

As with every Smart Contract, we begin by declaring the License type used, and the solidity version using a pragma statement.

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.19;

This contract is set up so that creatives can receive any ERC20 Tokens, for this to be possible in the Smart Contract that we want to deploy, we have to create an interface that will enable us to interact with an already deploy an instance of an ERC20 token. To do this, we will be using the OpenZeppelin library. Import the library:

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

The IERC20 is the interface all ERC20 implementations should conform to. That is typically made in the name, decimal and token symbols convention. You can read the EIP20 to learn more. The SafeERC20 is a wrapper around the IERC20 interface that eliminates the need to handle boolean return values.

In this contract, we are going to ensure that only the owner of the contract can carry out certain functions such as withdrawal and changing the EOA of the owner. To do this, we will also import an OpenZeppelin library for access control.

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

Having completed the steps above, we can start writing the Smart Contract

contract TipMe {
...
}

The first step in writing the main contract is to declare an instance of the interface using the SafeERC20 wrapper, as we will use this for a tranferFrom() method call, and also the Interface for token we will deploy as an example in this lesson.

using SafeERC20 for IERC20;

Instantiate the ERC20 protocol using the interface from OpenZepellin:

IERC20 public token;

The token will be set in the constructor argument, with an already deployed token address parsed as an argument to the interface.

constructor (IERC20 _token) {
  token = _token;
}

In the constructor, we parse the token by data type. It is an ERC20 token and not an address. Its functions can be accessed via the interface IERC20, hence why its data type.

Now the contract looks like this:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.19;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract TipMe {

using SafeERC20 for IERC20;
IERC20 public token;

  constructor (IERC20 _token) {
      token = _token;
  }

}

We will write our functions, with the first function being the receiveTips function

function receiveTips(uint256 _amount) public payable returns(uint256) {
  require(_amount > 0, “Amount MUST be more than 0”);
  token.safeTransferFrom(address(msg.sender), address(this), _amount);
  return _amount;
}

In the receiveTips(), any EOA that holds an ERC20 can call the function and deposit any amount greater than zero. The deposited amount is held in the contract. It is important to illustrate that before any ERC20 token can be deposited by an address into a Smart Contract, it is crucial for the address to call approve() function on the token contract, with the Smart Contract as receiver before the Smart Contract can call safeTransferFrom().

Next step, we can then update the function to emit an event on a successful deposit.

First, we will create an emit event method. Add the following line after the constructor arguments

event TipReceived(address sender, uint256 amount);

Add the following line to the end of receiveTips() function just before the return statement:

emit TipReceived(msg.sender, _amount);

Whenever a tip is sent to the contract, it will emit the Receive event detailing the EOA that sent the tip, and the tip amount.

The next function is the withdrawTips function. The withdrawTips function is to enable the contract owner to withdraw all tips that they have received. This function has a unique property wherein only the contract owner should be able to make a withdrawal.

function withdrawTips(uint256 _amount) public onlyOwner returns(uint256) {
        require(_amount > 0, "Amount MUST > 0");
        token.approve(msg.sender, _amount);
        token.safeTransfer( msg.sender,  _amount);
        return _amount;
}

This function is different from the receiveTips function in the following ways:

• Only the owner of the Smart Contract can call this function.

• We can call the approve method for the token to carry out the transfer method. We do not have to go to the token contract to do this.

Other than that, it is not so much different as, you can set the amount to withdraw, use a require statement to ensure that said amount is greater than zero.

We will also add an event to log successful withdrawals. Add the following event:

event WithDrawalSuccessfull(uint256 amount);

Add the following line to the end of wthdrawTips() function just before the return statement:

emit WithDrawalSuccessfull(_amount);

The next function is the getContractBalance(), which you can call to ascertain the amount of an ERC20 token balance in your Smart Contract.

function getContractBalance() public view returns(uint){
       return IERC20(token).balanceOf(address(this));
 }

The last function required is where you can change the owner address to a different EOA. The OpenZeppelin ownable library already offers the opportunity for a user address to be set by default and offers a method called transferOwnership. We can write a new function called changeOwner which you can wrap a function around and make the call.

function changeOwner(address _owner) public returns(bool) {
    transferOwnership(_owner);
    return true;
}

Note that you can only call this function once, and then the owner address is changed.

Here is the full contract:

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

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";


contract Tip is  Ownable {

    using SafeERC20 for IERC20;
    IERC20 public token;

    constructor(IERC20 _token){
        token = _token;
    }


    event TipReceived(address sender, uint256 amount);
    event WithDrawalSuccessfull(uint256 amount);


    function receiveTips(uint256 _amount) public payable returns(uint256){
        require(_amount > 0, "Amount MUST > 0");
        token.safeTransferFrom(address(msg.sender), address(this), _amount);
        emit TipReceived(msg.sender, _amount);
        return _amount;
    }

    function withdrawTips(uint256 _amount) public onlyOwner returns(uint256){
        require(_amount > 0, "Amount MUST > 0");
        token.approve(msg.sender, _amount);
        token.safeTransfer( msg.sender,  _amount);
        emit WithDrawalSuccessfull(_amount);
        return _amount;
    }

    function getTokenBalance() public view returns(uint){
        return IERC20(token).balanceOf(address(this));
    }

    function changeOwner(address _owner) public returns(bool) {
        transferOwnership(_owner);
        return true;
    }

}

In the next article, we will build a front end to interact with the contract.

According to the React Developer Docs:

If you want to build a new app or a new website entirely with React, NextJS is one of the recommended React-powered frameworks popular in the community.

In this article, I’ll introduce NextJS, and we will build a simple app that fetches data from an API and displays it to a UI. It is an app that displays information on Countries, listing the Country Name, Capital and Flag.We will make use of the https://restcountries.com/ API. This article assumes that you have build applications in ReactJS, and want to learn how to start building applications with NextJS.

This tutorial is useful for you if you want to understand how to make fetch API queries and pass down props to components in NextJS using plain ReactJS without TypeScript.

To start our project, create a directory where you wish the project to live, and start a NextJS project

mkdir rest-countries-example && cd rest-countries-example

npx create-next-app@latest

The following prompts will run, select the answers I highlighted in CAPS.

What is your project named? rest-countries-example

Would you like to use TypeScript? NO / Yes

Would you like to use ESLint? NO / Yes

Would you like to use Tailwind CSS? No / YES

Would you like to use src/ directory? No / YES

Would you like to use App Router? (recommended) No / YES

Would you like to customize the default import alias? No / YES

What import alias would you like configured? @/*

We have selected not to use TypeScript, and do not have ESLINT setup for the project, and we will use Tailwind, App Router (as against Page Routing) and as a result, have our files located in a directory called src.

Open a terminal and run the following commands

npm run dev

Open your browser and go to https://localhost:3000 to see the project running.

Our Project Folder looks like this:

You can explore the tailwind.config.js file to see how Tailwind is configured for use in the application.

Open the page.js app. Remove the default code and leave a div with Hello World text in the component. Check your browser to the updated page with the text Hello World displayed on the screen.

export default function Home() {
    return (
            <div><p>Hello World!</p></div>
    );
}

There are 2 phases to our project. In the first phase, we will write a function to fetch the responses from the API, we can test the success of the calls by console logging the responses and also by parsing to the UI. We will create a UI using tailwind-style components, and render the responses to a beautiful UI. We will then create a component to demonstrate how to pass down props, which is no different from how it is done using plain ReactJS.

A steep learning curve for learning to build on NextJs is understanding the difference between Server Components and Client Components. As a result of the Reacts Hook useEffect which we will use in our app, we are leveraging Client components. Therefore, at the top of the pages.js we have to indicate this using the use client directive. At the top of the pages.js file add the line:

“use client”;

Phase 1.

We will use the JavaScript fetch API in our method to call the Rest Countries API. When the response is returned, we will hold the response in a useState array. Thus, as we write the method, we will also create a useState hook. We will also use the useEffect hook to prevent our page from rerendering.

const [countries, setCountries] = useState([]);

const getCountries = async () => {
    const response = await fetch(
        https://restcountries.com/v3.1/all
    );
    const data = await response.json();
    setCountries(data);
};

useEffect(() => {
    getCountries();
}, []);

console.log(countries);

Open the Developer Tools on your Browser to see the Countries logged into the console.

Phase 2:

We have the data being returned from the API and parsed to the app, the next step is to create a beautiful UI using Tailwind CSS, and map over the responses in the Countries array held in the app state.

<div className={`grid gap-4 grid-cols-3 grid-rows-3 m-6`}>
    {recipes.map((result) => (
        <div className="max-w-sm rounded overflow-hidden shadow-lg" key={result.flag}>
            <p className="text-gray-900 text-xl">{result.name.common}</p>
            <p className="text-gray-700"> Capital: {result.capital}</p>
        </div>
    ))}
</div>

Now, you have a UI Displaying the Countries, and their respective capital.

At the onset of the article, we will display the Countries Name, Capital and Flag. Displaying images in NextJS provides a great learning curve. NextJS has it’s own Image component for handling image display. To use the component in our project, we have to import it:

import Image from 'next/image'

The component has its own default attributes such src, width, height etc. In our case where we are consuming an API that parses image assets, we have to configure our NextJS app to render the images from the URL paths we are parsing the image assets.

Open the next.config.js file where we will configure an Image Component attribute called remotePatterns. remotePatterns protects your application from malicious users. The configuration is required in order to use external images. This ensures that only external images parsed to remotePatterns can be served from the Next.js Image Optimization API. Update your next config like so:

const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "flagcdn.com",
        port: "",
        pathname: "/w320/**",
      },
      {
        protocol: "https",
        hostname: "*.wikimedia.org",
        port: "",
        pathname: "/**",
      },
    ],
  },
};

Next, we will update the UI to display the flags. Right above the <p> tags, add the following Image component:

<Image
 src={flag}
 alt="Country flag"
 width={3200}
 height={100}
/>

The app is updated, and we can view the Countries Map. Name and Capital.

To illustrate the lesson on parsing down props to components, we can create a Countries component, move our Countries UI information to it, and pass down the props via the Component.

Create a file countries.js. We want to return the Country information, we can simply copy the code used in displaying the info to the UI in pages.js. Update the component:

import React from "react";
import Image from "next/image";


export function Countries({ label, flag, capital }) {
   return (
    <div className="max-w-sm rounded overflow-hidden shadow-lg">
      <Image
        src={flag}
        alt="Sunset in the mountains"
        width={3200}
        height={100}
      />
      <p className="text-gray-900 text-xl">{label}</p>
      <p className="text-gray-700"> Capital: {capital}</p>
    </div>
  );
}

In our pages.js app, import the Countries component

import { Countries } from "@/components/recipes";

Update the information being mapped over:

{recipes.map((result) => (
     <Recipes
          key={result.flag}
          label={result.name.common}
          flag={result.flags.png}
          capital={result.capital}
     />
))}

Now, the props are passed down via the component, and rendered by the Countries UI.

If you made it to the end of this lesson, Congratulations! The key learning takeaways is an understanding of how to use ReactJS Hooks in your NextJs app, handling image using the Image Component, and using the renderPatterns to “whitelist” addresses where you are parsing image assets via an API.

Here is the entire app for reference:

pages.js

"use client";

import { useState, useEffect } from "react";
import { Countries } from "@/components/countries";


export default function Home() {
  const [countries, setCountries] = useState([]);
  const getCountries = async () => {
    const response = await fetch(
      https://restcountries.com/v3.1/all
    );

    const data = await response.json();
    setCountries(data);
  };


  useEffect(() => {
    getCountries();
  }, []);


   return (
    <>
      <div className={`grid gap-4 grid-cols-3 grid-rows-3 m-6`}>
        {recipes.map((result) => (
          <Recipes
            key={result.flag}
            label={result.name.common}
            flag={result.flags.png}
            capital={result.capital}
          />
        ))}
      </div>
    </>
  );
}

Program Overview

The Web3 Master Program was a six-week intensive training series aimed at equipping participants from across Africa with the skills and knowledge needed to navigate the dynamic landscape of blockchain and Web3 technologies. The program covered a wide range of topics, from the fundamentals of blockchain to advanced smart contract security considerations.

Program Breakdown

1. Week 1: Blockchain Basics by Amowe Busayo

2. Week 2: Binance Smart Chain by ME!

3. Week 3: Solidity Programming by A.Q Fatma

4. Week 4: Smart Contract Development by ME, again! 🥳

5. Week 5: Building a Decentralized Application by Godspower Eze

6. Week 6: Smart Contract Security by Ephraim Chukwu

Achievements

- Participant Engagement: The program attracted an impressive registration of over 400 participants hailing from diverse regions across Africa. This indicated a strong interest in blockchain and Web3 technologies within the continent.

- Curriculum Development: As the architect of the program, I meticulously designed the course curriculum to ensure a seamless progression of topics, catering to both beginners and those seeking more advanced insights.

- Instructor Collaboration: I sourced and collaborated with expert instructors for each week's topic. This ensured that participants received the highest quality instruction from practitioners deeply immersed in their respective fields.

- Teaching Contribution: During the course, I personally delivered two classes, including a code lab session. My direct involvement in teaching solidified my connection with participants and allowed me to impart knowledge from a practical standpoint.

Conclusion

The Web3 Master Program marked a significant milestone in the enhancement of blockchain and Web3 literacy within Africa. The program's reach, content quality, and my direct contribution as a course instructor underscored my commitment to nurturing developer communities and fostering education within the Web3 ecosystem.

I am grateful for the opportunity to have spearheaded this initiative and contributed to the growth of blockchain awareness and expertise in the African region.

I have encountered the problem of verifying Smart Contracts when I use external libraries like OpenZeppelin or ChainLink. You will find that the simple process of using the explorer verification options doesn't work and neither will attempting the verification via the CLI. In this article, I'll demonstrate the use of the Flattened Smart Contracts feature available in Remix IDE to carry out the verification of a Smart Contract.

Smart Contract

Go to Open Zeppelin, and open the Smart Contract Wizard. We will build a simple Access Control with ONLY OWNER modifier can transferOwnership of the Smart Contract

Open the Remix IDE and paste the code:

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

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

contract MyContract is Ownable {
    constructor(address initialOwner) {
        transferOwnership(initialOwner);
    }
}

Compile the Smart Contract. Add your MetaMask to Remix via the Injected Provider option.

Deploy the Smart Contract to any selected Testnet of your choice. The deployed Smart Contract gives us access to the following functions:

RenounceOwnership , transferOwnership and owner

Verification

If we attempt to verify the Contract on Etherscan, it will give us an error:

To fix this error, we will "flatten the Smart Contract". The Flattener plugin is an “internal plugin” in the Remix IDE making it a part of the Remix codebase.

Prior to the update, it was required to be loaded as a plugin in the Plugin Manager, but can now just right-click on a file in the File Explorer to pop up the context menu. The Flattener is available as the Flatten option in the context menu.

Flatten Smart Contract

Open the Remix IDE, left click on the Smart Contract file in directory and click on Flatten This will generate a "flattened" version of the codebase which we can pass to EtherScan for Verification.

Copy the contents of the flattened version of the codebase and follow the steps to do the EtherScan verification.

// File: @openzeppelin/contracts/utils/Context.sol
// OpenZeppelin Contracts v4.4.1 (utils/Context.sol)
pragma solidity ^0.8.0;

/**
 * @dev Provides information about the current execution context, including the
 * sender of the transaction and its data. While these are generally available
 * via msg.sender and msg.data, they should not be accessed in such a direct
 * manner, since when dealing with meta-transactions the account sending and
 * paying for execution may not be the actual sender (as far as an application
 * is concerned).
 *
 * This contract is only required for intermediate, library-like contracts.
 */
abstract contract Context {
    function _msgSender() internal view virtual returns (address) {
        return msg.sender;
    }

    function _msgData() internal view virtual returns (bytes calldata) {
        return msg.data;
    }
}

// File: @openzeppelin/contracts/access/Ownable.sol
// OpenZeppelin Contracts (last updated v4.9.0) (access/Ownable.sol)
pragma solidity ^0.8.0;

/**
 * @dev Contract module which provides a basic access control mechanism, where
 * there is an account (an owner) that can be granted exclusive access to
 * specific functions.
 *
 * By default, the owner account will be the one that deploys the contract. This
 * can later be changed with {transferOwnership}.
 *
 * This module is used through inheritance. It will make available the modifier
 * `onlyOwner`, which can be applied to your functions to restrict their use to
 * the owner.
 */
abstract contract Ownable is Context {
    address private _owner;

    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    /**
     * @dev Initializes the contract setting the deployer as the initial owner.
     */
    constructor() {
        _transferOwnership(_msgSender());
    }

    /**
     * @dev Throws if called by any account other than the owner.
     */
    modifier onlyOwner() {
        _checkOwner();
        _;
    }

    /**
     * @dev Returns the address of the current owner.
     */
    function owner() public view virtual returns (address) {
        return _owner;
    }

    /**
     * @dev Throws if the sender is not the owner.
     */
    function _checkOwner() internal view virtual {
        require(owner() == _msgSender(), "Ownable: caller is not the owner");
    }

    /**
     * @dev Leaves the contract without owner. It will not be possible to call
     * `onlyOwner` functions. Can only be called by the current owner.
     *
     * NOTE: Renouncing ownership will leave the contract without an owner,
     * thereby disabling any functionality that is only available to the owner.
     */
    function renounceOwnership() public virtual onlyOwner {
        _transferOwnership(address(0));
    }

    /**
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Can only be called by the current owner.
     */
    function transferOwnership(address newOwner) public virtual onlyOwner {
        require(newOwner != address(0), "Ownable: new owner is the zero address");
        _transferOwnership(newOwner);
    }

    /**
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Internal function without access restriction.
     */
    function _transferOwnership(address newOwner) internal virtual {
        address oldOwner = _owner;
        _owner = newOwner;
        emit OwnershipTransferred(oldOwner, newOwner);
    }
}

// File: MyContract.sol
//SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract MyContract is Ownable {
    constructor(address initialOwner) {
        transferOwnership(initialOwner);
    }
}

AND, that is how it is done, Ladies and Gentlemen, Boys and Girls! 🥂

Reference: https://medium.com/remix-ide/remix-ide-v0-30-0-release-8ee6bb8bcb5f

function( params ) { args }

The difference between the structure of functions in Solidity and JavaScript is that Solidity being a statically typed programming language has extra requirements for defining the data types of params, return statements, and args, and also has to be indicated by what is called visibility levels.

Solidity Functions are the executable units of code. Functions are usually defined inside a contract, but they can also be defined outside of contracts. Functions outside of a contract, also called “free functions”, always have implicit internal visibility.

contract HelloWorld {
    function send(string _greeting) public returns(string memory) {
   // ...
   }
}

// Helper function defined outside of a contract
function helper(uint x) pure returns (uint) {
    return x * 2;
}

Function Visibility

In the above example, you can see that the function defined in the contract has what is called a visibility type. Visibility type is best understood given the explanation that Function calls in Solidity are categorized into 2:

1. Functions that make state changes to the EVM. These are generally referred to as “External Functions”

2. Functions that do not make state changes to the EVM are also referred to as “Internal Functions”

These 2 general categories of functions then give rise to 4 different function visibility types:

• External

• Public

• Internal

• Private

External:

External functions are part of the contract interface, which means they can be called from other contracts and via transactions. An external function f cannot be called internally (i.e. f() does not work, but this.f() works).

contract Apple { 
function externalFunc() external pure returns (string memory) {
        return "external function called";
    }
}

contract Bee {
  address contractApple = “0x….”;

  function callExternalFuncInApple() internal view returns(string memory) {

  const B = contractApple.externalFunc();
  return B; //this will return the string "external function called"
  }
}

The above example illustrates 2 different contracts, where one function with the visibility of external can be called in another separately deployed contract.

Public:

Public functions are part of the contract interface and can be either called internally or via message calls i.e. any contract that inherits the contract where the public function exists and address account can call these kinds of functions.

contract Apple {
    function publicFunc() public pure returns (string memory) {
        return "public function called";
    }
}

Internal:

Internal functions can only be accessed from within the current contract or contracts deriving from it i.e. inside contracts that inherit the contract holding the internal function. They cannot be accessed externally. Since they are not exposed to the outside through the contract’s ABI, they can take parameters of internal types like mappings or storage references.

Contract Apple {
    function internalFunc() internal pure returns (string memory) {
        return "internal function called";
    }
}

Private:

Private functions are like internal ones but they are not visible in derived contracts i.e Private functions can only be called within the instance of the deployed contract.

contract Bees {
    function privateFunc() private pure returns (string memory) {
        return "private function called";
    }

    function testPrivateFunc() public pure returns (string memory) {
        return privateFunc();
    }
}

In addition to learning about Function Visibility, it is essential to talk about the ability of function types to modify state. State mutability is a concept in Solidity that defines the behavior of functions and how they interact with data stored on the blockchain. The two major state mutability modifiers in solidity are:

• View

• Pure

View Functions:

Functions can be declared view in which case they promise not to modify the state.

Pure Functions:

Functions can be declared pure in which case they promise not to read from or modify the state. In particular, it should be possible to evaluate a pure function at compile-time given only its inputs

contract ViewAndPure {

    uint public x = 1;

    // will not modify the state.
    function addToX(uint y) public view returns (uint) {
        return x + y;
    }

    // will not modify or read from the state.
    function add(uint i, uint j) public pure returns (uint) {
        return i + j;
    }
}

Again, pure function can not read state variables and also cannot write to state variables whereas a View function can read state variable but can not modify it.

Where to use various visibility types?

The choice of the use of any of the 4 visibility types is up to the Developer, a handy guide is:

public - use for functions that any contract and address account can call.

private - use only for functions used inside the contract to define such functions

internal- use this for functions only inside the contract that inherits an internal function

external - use for functions that any deployed contract and address account can call.

Function Modifiers

Modifiers can be used to change the behaviour of Solidity functions in a declarative way. For example, you can use a modifier to automatically check a condition prior to executing the function i.e. Modifiers are code that can be run before and/or after a function call.

Modifiers are inheritable properties of contracts and may be overridden by derived contracts, but only if they are marked virtual.

Modifiers can be used to: Restrict access, Validate inputs and Guard against reentrancy hacks.

You can think of a Modifier as an argument passed against a function that could have also been a part of the function. Modifiers are very useful in scenarios where multiple functions have the same line of code passed to them.

contract Bees {

  address owner;

  constructor ( ) {
    owner = msg.sender
  }

  function setName(_greeting) public {
      require(msg.sender == owner)
      const newGreeting = _greeting
  } 

  function updateGreeting(_greeting) public {
      require(msg.sender == owner)
      const newGreeting = _greeting
  } 

}

In the above example, you can see the line require(msg.sender == owner) repeated, which implies that even if we have over 50 different functions that we require only the owner of the deployed contract to be the only person able to call it, we will have to repeat the same line of code over and over again. A way to keep this short is the use of function modifiers.

// Modifier to check that the caller is the owner of the contract.
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        // Underscore is a special character only used inside a    function modifier and it tells     
      //Solidity to execute the rest of the code.
        _;
    }

The functions can thus be rewritten as:

function setName(_greeting) public onlyOwner {
    const newGreeting = _greeting
} 

function updateGreeting(_greeting) public onlyOwner {
   const newGreeting = _greeting
}

Conclusion

That is all there is about Functions Visibility, Types and Modifiers. Congratulations if you read to the very end of this article. You can rely on the guide to understand what visibility types to set your functions and also how to write custom function modifiers. If you have any questions, you can message me on Twitter @emma_odia I look forward to hearing from you! Cheers!

This article assumes that you already know how to write Smart Contracts. For our example, we will deploy a Simple Storage Smart Contract and a message retrieval contract. This will aid in understanding how to interact with multiple contracts relying on each other.

This article requires that you have Hardhat installed.

1. Create a Directory, cd into it and start a Hardhat project.

    mkdir SampleProject && cd SampleProject
   
    npm init hardhat -y
   

2. Open the project in a Terminal, you will find a default TimeLock Contract. For our first scenario, we are deploying a single Smart Contract. Replace the TimeLock Smart Contract, with a Simple Storage Smart Contract:

    // SPDX-License-Identifier: GPL-3.0
    pragma solidity ^0.8.19;
   
    contract SimpleStorage {
        uint storedData;
   
        function set(uint x) public {
            storedData = x;
        }
   
        function get() public view returns (uint) {
            return storedData;
        }
    }
   

   It is a Simple Contract that stores a number and returns a number.

3. Compile the Smart Contract to confirm that there are no errors. Run the following command:

    npm hardhat compile
   

4. Given that the Smart Contract has successfully compiled, the next step is to write a script that will help us deploy the Smart Contract, and also to configure the network or networks where we want to deploy the Smart Contract. First the script.

    const hre = require("hardhat");
    async function main() {
        const Contract = await hre.ethers.getContractFactory("SimpleStorage");
        const contract = await Contract.deploy();
   
        await contract.deployed();
        console.log(`Contract deployed to ${contract.address}`);
    }
   
    main()
        .then(() => process.exit(0))
        .catch((error) => {
             console.error(error);
             process.exitCode = 1;
    });
   

   Hardhat library offers the ability to interact with the EthersJS Ethereum Libary, which allows developers to interact with the Ethereum blockchain in a simple way.

In this script, we are calling an instance of it, and making the methods available. You can see the various methods available here.

The Line hre.ethers.getContractFactory("SimpleStorage"); gives us access to the Smart Contract, and the hardhat wrapper is wrapped around the EthersJS ContractFactory Class

The ContractFactory is used to deploy a Contract to the blockchain. It gives access to the deploy() method. Once the contract is deployed, the console log statement prints the address to the console.

The error catch is implemented on the function, and it will throw any errors and fail to complete the process.

The next step is to specify the network where you want your Smart Contract to be deployed.

1. To configure the networks or networks where we want the Smart Contract deployed, open the hardhat.config.js file, and you will find the module.export instance only contains the solidity version. We can add a network object to specify the list of networks where we want to deploy the Smart Contract.

   It is important to note the following:

• You need the private keys of an EOA to deploy a Smart Contract and enough native token to pay for the transaction.

• If you are deploying to a network other than localhost, you will need the service of a Node Provider, that will help you bundle your transaction into a Block. To use the services of a Node Provider, you have to sign up to use the services of the Node Provider, and get an API Key. Popular Node Providers are Alchemy and Infura.

• You will also be required to parse your private keys to the Node Provider. To hide your keys, you can simply use the dotenv library.

For this next step, have a Private Key ready. In the hardhat.config.js file, add a new object called networks, in the first example, we will deploy to the Ganache Local Blockchain:

    module.exports = {
      solidity: "0.8.18",
      networks: {
        ganache: {
          url: "http://127.0.0.1:8545",
          chainId: 1337,
          accounts: [
                 "0x<your-private-key>",
          ],
        },
      },
    };

The networks typically contains the following object keys: network name, it’s url, your private private key which when pasting, you can precede with 0x. Go back to terminal, and deploy the Smart Contract, using the command:

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

Your Smart Contract will successfully deploy to the local Ganache Blockchain.

To deploy to other networks, as mentioned earlier, you will need API Keys from a Node Provider. Just as the Ganache Network was specified (You do not need a Node Provider to interact with the Ganache Blockchain, as it is running on your Machine), you will specify the network information, and in the url, pass the Node Provider endpoint for interacting with the blockchain. For example to deploy to the Sepolia network:

    sepolia: {
          url: https://eth-sepolia.g.alchemy.com/v2/${ALCHEMY_KEY},
          accounts: [PRIVATE_KEY],
        },

Then run the command:

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

1. To deploy multiple Smart Contracts, where one Smart Contract Address needs to be parsed as an argument to the next Smart Contract, you do not need multiple scripts. You can deploy the contract one before the other, and parse the address of an already deployed contract to another.

Given an example where you have 2 Smart Contracts: TokenContract.sol and StakingContract.sol, and you need to pass TokenContract address to StakingContract at deployment. Where StakingContract has the following constructor arguments:

     constructor(
       TokenContract _token,
       uint256 _tokenPerBlock,
       uint256 _startBlock
     )

Here is the Script to run the deployment:

    const hre = require("hardhat");

    async function main() {
        const TOKEN = await hre.ethers.getContractFactory("TokenContract");
        const token = await TOKEN.deploy(10000000);

        await token.deployed();
        console.log("Token deployed to:", token.address);

        const Contract = await hre.ethers.getContractFactory("StakingContract");
        const contract = await Contract.deploy(token.address, 10000, 1);

        await contract.deployed();
        console.log("Contract deployed to:", contract.address);
    }

    main()
         .then(() => process.exit(0))
         .catch((error) => {
            console.error(error);
            process.exit(1);
    });

You will observe that the code runs synchronously as a result, the success of the first request will return, and make the token.address of the first contract available for use in the second.

You can follow this guide, and implement deploying multiple Smart Contracts numbers over two.

In this article, I have walked you through how you can easily deploy a single contract, or multiple contracts to a local Ganache Blockchain for testing, or to a Testnet or Mainnet Blockchain using a Node Provider.

Ethereum is now using the Proof of Stake (PoS) consensus mechanism and previously used the Proof of Work consensus (PoW) mechanism. The PoW consensus relied on "Node Validators" who create blocks of transactions relying upon heavy mathematical algorithms where the Validator will calculate the block difficulty in order to validate a Block. The more computing power the node validator has, the better its chance of calculating a new block. This process requires a lot of computing power and, as a result, large energy consumption. PoS was then proposed as an alternative consensus mechanism.

PoS requires validators to stake ETH. The validators then check that new blocks proposed for the Ethereum network are not malicious. The Validator is also held to account by other network actors to ensure that no validator proposes the wrong block information. The staked ETH is used as collateral, such that when a validator authorizes/proposes a bad block, their staked ETH is then slashed. In the Proof of Stake mechanism, there is thus no need for heavy computation to propose new Blocks, thus leading directly to direct energy consumption in the Ethereum network.

The Ethereum network was not "switched off, then updated" for the merge. A famous analogy used to describe the merge event is that of a racing car whose engine was switched from a diesel engine to an electrical engine while the car is being driven on a highway; This underscores the level of the technical difficulty of the merge event. To achieve this, the newly proposed PoS mechanisms had to undergo critical testing alongside the PoW mechanism.

The Ethereum engineers proposed a road map that started with introducing a separate Ethereum chain called the "Beacon Chain" in December 2020. The PoS model was then used on the Beacon chain. The Ethereum Mainnet was still running on the PoW model at the time, and both chains ran parallel. This was so that errors that could happen due to the switch to the PoS model were quickly discovered. In the course of running the Beacon chain, "Shadow forks" were also implemented. Shadow forks were running PoS, and when bugs were found, they were immediately dropped.

The extensive testing continued, and in the course of the time, Testnets were successfully migrated to the PoS without any resultant errors. The significant change occurred when the Beacon chain was merged into the mainnet with all the state history and finalized at Block 15537394.

What are NFTs?

I make a personal recommendation to developers to always read the ethereum improvement proposals on the website: eips.ethereum.org, there you will find that prior to settling on the name choice of “NFTs”, one of the first name choices was the word “Deeds”. In legal terms “A deed is a legal document that grants ownership to a piece of real estate or other property asset.” An understanding of NFTs as deeds opens up the developer to a plethora of use cases that can be builT using NFTs. Popular today is ownership of tokenized art. A user can own many NFTs deployed across multiple chains and deployed by various contracts. To demonstrate or check ownership of such assets by a user, one has to go to various blockchain explorers and input the user address to return all the NFTs owned by the user of that particular chain. This is a problem that NFTPort has solved using her APIs.

What is NFTPort?

NFTPort grants users ONE API Key to unlock access to NFTs across multiple chains. NFTPort prides itself on its ability to “Bring your NFT application to market in hours instead of months.” In this guide, we will rely on one of the API endpoints available in NFTPort and build a user dashboard where you can parse any ethereum address and return all the NFTs owned by that address. We will build the entire DApp using one API in the suite of APIs from NFTPort.

Sample DApp

We will build a simple app using HTML and JS. The app will call the API: Retrieve NFTs owned by an account

This endpoint Returns NFTs owned by a given account (i.e. wallet) address. It is useful for: For checking if a user owns a specific NFT and then unlocking specific activity. Adding NFT portfolio section to your apps.

The next step will walk you through building a simple dapp.

HTML

Using any code editor of your choice, kindly create a folder and create the following files index.html and index.js. In the index.html file, paste the following code.

<html>
  <head>
    <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
    <script type="module" src="index.js"></script>
  </head>
  <body>
    <div class="container">
      <div class="row">
        <div class="col-sm-12">
          <h1>Sample DApp</h1>
          <form id="setData">
            <div class="form-group">
              <label for="setDataInput">Enter Address into the Input:</label>
              <input id="setDataInput" type="text" class="form-control"></input>
            </div>
            <button type="submit" class="btn btn-primary">Submit</button>
          </form>
          <div>Total NFTs held: <span id="totalNFTs"></span></div>
        </div>
      </div>
    </div>
  </body>
</html>

If you are using vscode as your primary editor, use the liveserver extension to launch the app, you will see the following screen:

This is a landing page where a user can input any ethereum address and return all the NFTs held by that address. The next step is to write javascript code that will return the data to the user. Follow the sequence of steps to gain a firm understanding of the process.

JavaScript

1. Go to the NFTPort website and sign up to get a free API Key.

2. Open your index.js file and enter the code:

   const options = {
   method: 'GET',
   headers: {
   'Content-Type': 'application/json',
   Authorization: 'your-api-key'
   }
   };
   
   fetch('https://api.nftport.xyz/v0/accounts/address?chain=ethereum', options)
   .then(response => response.json())
   .then(response => console.log(response))
   .catch(err => console.error(err));
   

   This is a GET request where a call is made to the Retrieve NFTs owned by an account endpoint. The endpoint url is https://api.nftport.xyz/v0/accounts/address?chain=ethereum where address can be any ethereum externally owned address, and the chain we are exploring is ethereum. The Fetch API is used to query the endpoint and the response is formatted to json before it is logged to the console in this step.

   Copy any ethereum address from etherscan and enter it into the address, the url will look like this https://api.nftport.xyz/v0/accounts/0x….?chain=ethereum

3. Open the browser page where the index file is running, and open the console. You will see an object response. Click on the object to see all the data return by the endpoint.

   

   

   You can also click on the nfts dropdown where you will see all the json values returned: contract_address, token_id and contract_name

4. To return more data, there is the include query where you can add the option to return nft metadata to the url path.

   https://api.nftport.xyz/v0/accounts/address?chain=ethereum&include=metadata
   

   This returns more information about the token.

   

   

5. We have successfully confirmed that we can connect to the API using our API KEY, query an endpoint and return data to the app using the fetch api. The next step is to write a function that will take any address parsed as an argument and when a user clicks submit return the response. Add the following code to index.js

   …
   const $setData = document.getElementById("setData");
   $setData.addEventListener("submit", (e) => {
   e.preventDefault();
   
   const data = e.target.elements[0].value;
   console.log(data);
   });
   

   The is a DOM manipulation script where the user targets the form by its id setData. An event listener is added with an action triggered by submit, where an async function is run and whatever is parsed into the input is logged to the console. Go ahead and test it out by typing anything into the input field.

6. The next step is to ensure that we can parse an ethereum address into the input and it will be resolved as part of the api url query. This will be done in a try catch block inside the event listener. In this step, we will refactor the code we have already written, and add the URL object query method to create a url path that can be resolved using the fetch api. Make the function inside the event listener an async function. Delete or comment out the fetch method already in the code, and add the following lines inside the event listener function.

   const url = new URL(
     `https://api.nftport.xyz/v0/accounts/${data}?chain=ethereum&include=metadata`
   );
   try {
     const response = await fetch(url, options);
     const results = await response.json();
     console.log(results);
   } catch (error) {
     console.log(error);
   }
   

   Copy any ethereum address and enter it into the input, click ‘submit’, the response will be logged to the console! From the point, you can build any UI to return the data to users via the interface.

   In this sample dapp, we will return the data via a simple table that will list the following:

   • Contract Address
   • Token Name
   • Token ID
   • Image URL
   • Contract Creator Address
   • Total Number of NFTs held by the address

7. To return the total number of nfts held by the address, we will target the <span> tag on the frontend, this has an id totalNFTs, target the totalNFTs id from the DOM using:

   let $totalNFTs = document.getElementById("totalNFTs");
   

   add the following code to the try block:

   $totalNFTs.innerHTML = results.total;
   

   You will see the total number of NFTs returned to the UI.

   

   The final step is to return the remaining data to the UI using the table.

8. Add the following line into the index.html file under the Total NFTs div

   <table id="tokenTable" class="table table-striped"></table>
   

   This is a <table> div from getBootstrap that creates a pleasant looking table, we have assigned it an id tokenTable.

9. Target the DOM using the tokenTable id

   let tableRef = document.getElementById("tokenTable");
   tableRef.innerHTML = `<thead class="thead-dark">
              <tr>
                  <th>Contract Address</th>
                  <th>Token Name</th>
                  <th>Token ID</th>
                   <th>Image URL</th>
                  <th>Creator Address</th>
              </tr>
          </thead>
          <tbody>
          </tbody>`;
   

Update the try block:

 const nfts = results.nfts;
 nfts.map((result) => {
       tableRef.insertRow().innerHTML =
         `<td> <a href="https://etherscan.io/address/${result.contract_address}" 
 target="_blank">${result.contract_address}</a></td>` +
         `<td> ${result.name} </td>` +
         `<td> ${result.token_id} </td>` +
         `<td> <a href="${result.metadata.image}" target="_blank">image</a></td>` +
         `<td> <a href="https://etherscan.io/address/${result.creator_address}" 
 target="_blank">${result.creator_address}</a></td>`;
     });

Enter an ethereum address and click submit!

Conclusion

Here is the complete code for your reference. In this guide, we explored the “Retrieve NFTs owned by an account” API endpoint. We explored its relevance in building NFT applications. We build a simple application to establish a primary understanding of the endpoint. In conclusion, this guide represents a frame of reference that a developer can start with and build any form of use case using the single API endpoint.

View a video demo and code walkthrough of the app here

Contents:

• Blockchain Explorers.

• Smart Contract frontend Libraries.

• EthersJS.

• Sample App using HTML and JS.

Blockchain Explorers

Different Blockchains have a User Interface where all transactions and other information (blocks, token information, contract data) are displayed in an easy to read and “interact with” format, usually a web page. The Blockchain explorer for ethereum is etherscan. According to its website: “Built and launched in 2015, it is one of the earliest and longest running independent projects built around Ethereum and its community with the mission of providing equitable access to blockchain data.”

It is vital for the Smart Contract developer to learn how to use the explorer for a particular chain that you deploy your Smart Contract code on. More so when the explorer grants the ability to upload your Smart Contract code and ABI, thus making available an interactive UI for your Smart Contract onchain.

Kindly read this guide, where I walk through deploying a Smart Contract to the Goerli testnet. In the guide, I walk you through the process of reading and writing to the Smart Contract via the explorer.

It is not an optimal process for users to read and write to your contract via an explorer. It is more convenient to build a user interface that will make the process easy. It is vital to understand how the Smart Contract information can be read and write from a chain. The ethereum.org guides sufficiently explain this process:

“In order for a software application (UI) to interact with the Ethereum blockchain - either by reading blockchain data or sending transactions to the network - it must connect to an Ethereum node.

For this purpose, every Ethereum client implements a JSON-RPC specification, so there are a uniform set of methods that applications can rely on regardless of the specific node or client implementation.

JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol. It defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments. It uses JSON (RFC 4627) as data format. [sic].”

“While you may choose to interact directly with Ethereum clients via the JSON-RPC API, there are often easier options for dapp developers. Many JavaScript and backend API libraries exist to provide wrappers on top of the JSON-RPC API. With these libraries, developers can write intuitive, one-line methods in the programming language of their choice to initialize JSON-RPC requests (under the hood) that interact with Ethereum.”

Smart Contract Frontend Libraries

The frontend JavaScript Library for interacting with Smart Contracts and building UIs are Web3JS and EthersJS

Web3JS: “web3.js is a collection of libraries that allow you to interact with a local or remote ethereum node using HTTP, IPC or WebSocket.”

EthersJS: “The ethers.js library aims to be a complete and compact library for interacting with the Ethereum Blockchain and its ecosystem.”

To demonstrate how EthersJS works, we will build out a Sample App using plain HTML and JavaScript. This approach allows you to learn how to interact with Smart Contracts at the basic implementation level. This approach will cement your knowledge and thus lay a proper foundation for building with other JavaScript libraries such as ReactJS and VueJS.

Sample App using HTML and JS.

For our sample dapp, we will use the Smart Contract from a previous article. It is a simple “Hello, World!” contract. We will use the Hardhat tool to compile and deploy the Smart Contract to a local blockchain, and then we will deploy it to the Goerli testnet. You can read my Guide on How to compile and deploy Smart Contracts using Hardhat.

Here are the steps:

1. Choose a dir name for your project and create one

mkdir hello_world && cd hello_world

1. Initialize a project using npm default init command:

npm init -y

1. Hardhat is a Library and will have to be installed as a project dependency:

npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox
//@nomicfoundation/hardhat-toolbox is a hardhat plugin which has everything you need for developing smart contracts.

1. Set up hardhat in the project by running the command:

npx hardhat

Select the option: “Create a javascript Project.”

1. Open the ‘hello_world’ project in your IDE of choice, the directory will look something like this:

Open the Contracts dir and create a new file: HelloWorld.sol, where .sol is an extension denoting that it is a solidity file. This is where our Smart Contract code will be written. Copy the code below into the file:

// SPDX-License-Identifier: GPL-3.0

pragma solidity ^0.8.17;

contract HelloWorld {

  address public owner;
  string greeting;

  constructor(){
    owner = msg.sender;
  }

  function setGreeting(string memory _greeting) public {
     greeting = _greeting;
  }

  function getGreeting() public view returns(string memory) {
    return greeting;
  }

}

This article assumes that you have a basic understanding of how Solidity works. If you want a line by line breakdown of this code, you can read my guide: “Welcome to Solidity!”

1. The next step is to compile of Contract. This process will generate the Contract ByteCode that gets deployed to a chain and the Contract ABI, which we will need to interact with the Contract via a UI.

npx hardhat compile

You will see a message in the terminal:

Compiling 1 file with 0.8.17

After the compilation has completed, hardhat will create two folders in the project directory: artifacts and cache. Open the artifacts dir and go to contracts/HellowWorld.sol and open the file: HelloWorld.json, here you will find the abi in an array. The last step of this session will be to deploy the Smart Contract to a local hardhat node.

1. Building Smart Contracts with Hardhat requires writing a script that is needed to indicate the network to deploy the Smart Contract. We will write a script that will deploy the Smart Contract to a local node. Open the scripts folder in the directory and create a new file deploy_helloWorld.js, add the following code to the file:

const hre = require("hardhat");

async function main() {
  const Contract = await hre.ethers.getContractFactory("HelloWorld");
  const contract = await Contract.deploy();

  await contract.deployed();

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

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

1. The last step of this session will be to deploy the Smart Contract to a local hardhat node. Run the command: npx hardhat run --network localhost scripts/deploy_helloWorld.js You will see a message in the terminal:

Contract deployed to 0x….

The Contract has been deployed successfully! The next step is to build a UI to interact with the Contract. It is going to be a simple UI that contains an input field and a Button to send data to the deployed Contract, and a span tag to read data from the deployed Contract.

Building the UI

There are a collection of UI Libraries that developers can use to start building interfaces to connect with Smart Contracts. In this guide, we will build a UI using plain old HTML and JS. This is so that developers can understand, line by line, how the interaction works between Smart Contracts and UI at the very basic level.

To connect to the Smart Contract from the UI, we will use the ethers js to handle all the abstraction calls to the JSON-RPC.

Kindly create a directory in the root of the folder containing the Hello World files, name the directory frontend. Inside the frontend directory, create the following files: index.html, index.js and ethers.js

To add ethers js to the project, kindly visit the ethers js cdn copy the entire file and paste it inside ethers.js . It is better practice (for security reasons) to copy the ethers library to your own webserver and serve it yourself, which is what we are doing in this sample dapp.

HTML

We are going to use the BootStrap Library to build out a basic UI. Open the index.html file and paste this code:

<html>
  <head>
    <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
     <script type="module" src="index.js"></script>
  </head>
  <body>
    <div class="container">
      <div class="row">
        <div class="col-sm-12">
          <h1>Hello World!</h1>
          <form id="setGreeting">
            <div class="form-group">
              <label for="setGreetingInput">Enter Text into the Input:</label>
              <input id="setGreetingInput" type="text" class="form-control"></input>
            </div>
            <button type="submit" class="btn btn-primary">Submit</button>
          </form>
          <div>Response: <span id="greeting"></span></div>
        </div>
      </div>
    </div>
  </body>
</html>

We will walk through the code and explain each line.

This is a HTML file with a <head> and <body> section. The <head>...</head> section contains the BootStrap CDN link that enables us style the page using the BootStrap Library without writing any extra CSS. It also contains the index.js file; this is the file where we will write the JavaScript and import the ethers js library. The script type must be set to module, as it prevents any errors due to the use of the import statement in the script.

The <body>...</body> section makes use of class definitions from BootStrap to align the page content: container, row, col-sm-12 and form, you can read about them in the BootStrap docs. It also contains a form which is a simple input, and a button, the input is where the user will enter an input to be sent to the Smart Contract. The <div> containing the Response also contains a <span>...</span>, where the response from the contract will be displayed.

The next step is to write the JavaScript code.

JS

All the code here is written in the index.js file, and we will walk through it line by line. Connecting the UI to the Smart Contracts can be broken into three distinct steps: Import the Ethers JS Library Connect the Smart Contract to the UI Implement functions to Write and Read the Smart Contract.

1. Import the Ethers JS Library: At the top of the index.js file, declare the import

Import { ethers } from `./ethers.js`;

This is a named import type that makes the ethers.js library module available in the file as ethers. This imports the ethers.js Library.

1. Connect the Smart Contract to the UI: In this step, we will need the Smart Contract address, ABI, and the Ethers getSigner() to create a connection to the UI, which we will confirm via the UI console. Here is the code:

    const HelloWorldAddress = `0x…..`;
    const ABI = [
 {
      "inputs": [],
      "stateMutability": "nonpayable",
      "type": "constructor"
    },
    {
      "inputs": [],
      "name": "getGreeting",
      "outputs": [
        {
          "internalType": "string",
          "name": "",
          "type": "string"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    },
    {
      "inputs": [],
      "name": "owner",
      "outputs": [
        {
          "internalType": "address",
          "name": "",
          "type": "address"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_greeting",
          "type": "string"
        }
      ],
      "name": "setGreeting",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    }

];

    const signer = getSigner();

    const Contract = new ethers.getContractFactory(HelloWorldAddress, ABI, signer);

    console.log(Contract);

Open the developer console in the browser where the index.html file is running, and you will see the Hello World contract logged in the console. Click the drop-down arrow, and you will see all the functions deployed in the contract available as JavaScript method calls.

1. Implement functions to Write and Read the Smart Contract. There are three functions in the Smart Contract: getGreeting, owner and setGreeting. We will create a function called doGreeting and inside it, we will write instructions for setGreeting and return the response in the console, then, we will write functions to set the owner and another to return getGreeting.

function doGreeting() {
const setGreeting = document.getElementById(“setGreeting”)
const greeting = document.getElementById(“greeting”)

setGreeting.addEventListener(“submit”, e => {
    e.preventDefault;

    const greeting = e.target.element[0].value
    Contract.setGreeting(greeting); //This will write the argument to the contract.
    console.log(greeting); 
})

}

The next step is to write the function to getGreeting and set it in the <span>...</span>. Continue inside the doGreeting block:

const $getGreeting = async () => { Contract.getGreeting().then(result => { $data.innerHTML = result; }) }

To return the greeting as it is set via the $setData method, call the $getGreeting function in $setGreeting, after the console.log statement add:

$getGreeting();

The last step step in the section is to trigger a DOM event to render the javascript. At the end of the file and outside the doSomething function, add add event listener:

addEventListener(“DOMContentLoaded”, doSomething());

This means that when the DOM is completely loaded, carry out the JavaScript actions. The entire idex.js file now looks like this:

const HelloWorldAddress = `0x…..`;
    const ABI = [
 {
      "inputs": [],
      "stateMutability": "nonpayable",
      "type": "constructor"
    },
    {
      "inputs": [],
      "name": "getGreeting",
      "outputs": [
        {
          "internalType": "string",
          "name": "",
          "type": "string"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    },
    {
      "inputs": [],
      "name": "owner",
      "outputs": [
        {
          "internalType": "address",
          "name": "",
          "type": "address"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_greeting",
          "type": "string"
        }
      ],
      "name": "setGreeting",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    }

];

const signer = getSigner();
const Contract = new ethers.getContractFactory(HelloWorldAddress, ABI, signer);
console.log(Contract);


function doGreeting() {
const setGreeting = document.getElementById(“setGreeting”)
const greeting = document.getElementById(“greeting”)

setGreeting.addEventListener(“submit”, e => {
    e.preventDefault;
      const greeting = e.target.element[0].value
      Contract.setGreeting(greeting); //This will write the argument to the contract.
      console.log(greeting); 
  $getGreeting();
  })
}

const $getGreeting = async () => {
   Contract.getGreeting().then(result => {
      $data.innerHTML = result;
  })
}

Interact with the UI

You have completed a full Dapp. Written the Smart Contract and deployed it to the local Hardhat environment. Built a UI using HTML and JavaScript. You start sending content to the Contract and have it returned. As a challenge, write the function to return the owner address to the UI.

Conclusion

This guide is a learning curve to help you understand the basics of interacting with functions in solidity from any UI, by using the Ethers JS library to abstract the JSON-RPC calls. It serves as a background to understanding how you can build a UI for any contract deployed to any EVM-compatible chain.

In this guide, we will cover a few concepts in which you may already have some background knowledge.

Contents:

1. What is a Blockchain?
2. How is web2 different from web3?
3. Why web3, and what are its use cases?
4. Programming in web3
5. Solidity - Syntax Overview
6. "Hello, World!" in Solidity.

What is a Blockchain?

An insightful way to explain Blockchains is to first reiterate how the centralized internet works. The centralized internet is organized so that companies that own platforms can open their services to users and, in return, store the data of such users on their servers (databases). A typical example is Social Media companies that give users access to their platform and allow users "own space" on their servers to store their information using associated tables in a database from which they can easily retrieve the data.

A Blockchain is a decentralized distributed ledger technology where user information is not stored in centralized databases. The Blockchain is designed so that many actors can come together to participate in a decentralized network. The Blockchain is a collection of computers called nodes, with each computer running a piece of software that is not a copy of the same software running on other computers in the network. Instead, it is the actual replica (not a clone) of the software across the network. In this network, the Data on a computer in the network 'compA' is the same Data on 'compB'.

In a Blockchain network, the user data is stored using hashes and recorded on the distributed ledger. The user can interact with the Blockchain from one computer in the node, and the node will broadcast the information that the user wants to save on the Blockchain, and then all computers will take note of the Data that the user just saved on the network and keep a record of it on the ledger.

Various blockchains exist, with famous examples being Bitcoin and Ethereum. In this article, we will focus on the Ethereum blockchain. The Blockchain ledger is arranged, so that information saved on the Blockchain is chained sequentially. The point where a user saves Data on the Blockchain and other computers in the network and then records it is called a Block. Each Block is identified by a unique hash and assigned a Block number. Now, pay attention to the following illustration.

When a user saves data containing their name, e.g. "name=john doe", to the Blockchain at a point when the block number was 10001, the user can not edit the data. The Data is chained to the following block number: 10002 and so on, where n+1. Blockchain is commonly referred to as web3 due to several improvements it has over the traditional internet relayed over HTTPS, and this is one of the critical areas where web2 is different from web3.

How is web2 different from web3?

Before explaining how web2 differs from web3, it is essential to mention that web3 is not a new kind of internet. Although it uses its own set of protocols for interaction, the web3 can be accessed via web browsers over HTTPS. The difference between web2 and web3 is primary in the structural and interactional make-up.

One component in the interactional make-up of Blockchains is the use of Addresses. Given that the Blockchain is a Ledger, user interactions with Data on chain happen via the use of Addresses. Address is of 2 types: Wallet address (also called External Owned Address EOA) and Contract Addresses (Smart Contract code deployed on the Blockchain). A user is also identified by their EOA on chain.

The table below uses a comparison method to outline the differences between web2 and web3.

Web2

Web3

Why web3, and what are its use cases?

Given the listed differences between web2 and web3, one can identify many use cases in that web3 is most suited to guarantee implementations that will serve a real-world need. Such examples include Identity verification, Finance, Insurance and Ownership, to mention a few.

An identity use case involves a user entering their record on the Blockchain at a particular block number. Given that information stored on a chain cannot be edited, user identity can be verifiable in such an instance.

To build applications that can meet such use on Blockchain involves writing code that can save data on Blockchains.

Programming in web3.

Programming in web3 involves writing computer logic and pushing it on blockchains. The code cannot be edited when this piece of computer code lives on the Blockchain. The code is written as a business logic where all interactions with it respond with programmed outcomes. This code that executes the business instruction is called a Smart Contract.

In this article, you will write and deploy your first Smart Contract. You must understand the environment where Smart Contracts run and the language in which to write the code.

In Ethereum, the network, as we described earlier, has a piece of software (Operating System, if you like) called the Ethereum Virtual Machine (EVM) running in each computer (node) in the network. The EVM can only read Bytecode. The Solidity Programming Langauge is available to developers to program Smart Contracts, which are then compiled to Bytecode and deployed to the Blockchain.

Smart Contract code can be written in Solidity, Vyper and the newly released Huff programming language. Solidity is easy to learn. We are going to write our first program in Solidity. In this example, we will write and deploy the code in Remix. Remix is an interactive online tool that makes it easy to write, deploy, and interact with Smart Contract.

Solidity Syntax

Solidity is a statically typed programming language much like C++; this means that every data type in Solidity must be declared as it is initialized.

"Hello, World!" in Solidity.

For our first Smart Contract, kindly go to remix and paste the following code.

//SPDX-Licenses-Identifier: MIT
pragma solidity ^0.8.16;

contract HelloWorld {
    address public owner;
    string greeting;

     constructor(){
        owner = msg.sender;
     }

     function setGreeting() public {
        greeting = "Hello, World!";
     }

     function getGreeting() public view returns(string memory) {
        return greeting;
     }
}

This Smart Contract is written in Solidity. For developers familiar with JavaScript, you will see a similarity in the function statements. This Smart Contract implements a function that writes "Hello, World!" to the Blockchain and another that returns it. We will walk through the code and explain each line.

//SPDX-Licenses-Identifier: MIT

The Solidity Compiler encourages using machine readable SPDX license identifiers to ensure trust in Smart Contracts. This line indicates the type of licenses with which this Smart Contract is published.

pragma solidity ^0.8.16;

The pragma statement indicates the version of Solidity that the Smart Contract should be compiled in.

Contract HelloWorld {
}

The Smart Contract Logic is entirely written in curly braces initialized with the Contract keyword followed by the name of the particular Smart COntract, in this instance: HelloWorld

address public owner;

Variables in Solidity are statically typed. This line is a declaration of a variable named owner. It is of a data type address and set to a visibility type of public. Solidity functions can be specified in 4 different visibility forms: Public, External, Internal and Private. A function set as public means that anyone interacting with the Contract can call the particular function.

string greeting;

This declaration of a greeting variable of data type string. It will be used to initialize the greeting in the setGreeting function.

constructor(){
  owner = msg.sender;
}

When a Smart Contract is deployed on a Blockchain, the constructor keyword is used to initialize variables that are used in the implementation. The constructor is only run when the code is first deployed. The constructor in this example is initializing the owner variable and assigning it a particular value, msg.sender msg.sender where msg is an abbreviation for message. This keyword denotes the wallet address that pushed the Contract onto the Blockchain.

function setGreeting() public {
  greeting = "Hello, World!";
}

This is the function statement where we set the "Hello, World" greeting. When the Contract is first deployed, it will be set at a Block number on chain.

function getGreeting() public view returns(string memory) {
  return greeting;
}

This is the call to return the greeting saved on chain. There are new unique keywords here, view and returns. The view keyword indicates functions that return data and do not make further changes to the Blockchain. The returns keyword indicates the data type being returned in the function call, indicating the location it is stored, which in this case is memory.

To understand how this Smart Contract will work on an actual blockchain, we will simulate its interaction by compiling it and deploying it in Remix.

To compile the Contract, kindly click on the Solidity Compiler tab and select the compiler version from the dropdown. Click on the Compile HelloWorld button. You should see the green tick appear on the tab upon a successful compilation.

The Contract is compiled into Bytecode. You can click on the Bytecode icon to copy the Bytecode and paste it into a notepad file to view opcodes.

After the successful compilation, the next step is to deploy the Smart Contract. Click on the Deploy and Run Transactions tab. Understanding the various UI components before clicking the deploy button is essential.

ENVIRONMENT: This is the Blockchain where the Smart Contract code will be deployed. It is default set to a "London Fork" Remix Virtual Machine.

ACCOUNT: These are a set of 10 Wallet Addresses. The addresses hold test Ether. You can use any of the addresses when interacting with the Smart Contract.

GAS LIMIT: Gas is the unit of measure to ascertain the amount of computation your interaction with the Blockchain will cost. The default limit is set as 3 Million units.

VALUE: This field is used when you want to pass units of ether to spend when interacting with a Smart Contract.

Ensure that the HelloWorld Contract is highlighted in the CONTRACT dropdown. Click Deploy This will deploy your Smart Contract. You can view your deployed Contract in the Deployed Contracts section. Click on HelloWorld. This will open a dropdown where you can see all the functions written in your Smart Contract getGreeting,setGreeting, including the Owner variable.

NOTE: When a variable is initialized, and its accessibility is set to public, that variable can be returned as a view function on chain.

Click the various function buttons to interact with the Contract on chain. Begin with checking the owner and then the getGreeting. The owner will return the address highlighted in the ACCOUNT section when the Smart Contract was deployed. That is the address that owns the Smart Contract.

The getGreeting will return0. This is because we have notsetGreetingon the Blockchain; we have only deployed the Contract! Now, go ahead and clicksetGreeting. This will store "Hello, World!" on the Blockchain. Click ongetGreeting`, and it will return the text: "Hello, World!"

You have successfully deployed your first Smart Contract written in Solidity on the Blockchain. This piece of logic is a hello world program, and it can not be changed! Well, you can adjust the setGreeting function and parse in an argument such that you can return any greeting as you please.

function setGreeting(string memory _greeting) public {
  string memory s = "Hello ";
  greeting = string.concat(s, _greeting);
}

This is an update to the setGreeting function. This update has the concat keyword, used to concatenate strings. This was introduced in solidity version 0.8.12 The string s is held in memory before it is pushed on chain.

Conclusion.

This is your: "Welcome to Solidity" tutorial. This article has laid out for you a baseline that you can use to get a feel for what to expect when you start writing more Solidity code. Here are recommended references that will significantly aid your quest to learn Solidity.

Resources.

Ethereum.org Solidity Docs.

Smart Contracts are meant to be immutable! After all, that is a principal pillar on which decentralization rests. Why then do we have to need to create new versions of Smart Contracts (read upgrade)? Well, same reason why the V2 of software is better than V1. Duh! That was obvious, no?

OK! Granted. Why then do you not write another Smart Contract code and then redirect the users to a new version via the DApps frontend? Hmmm, fair point, until you have to take into account such things as:

1. Tracking state changes.

2. Developers interacting with the Smart Contract code.

3. Maintenance…

Just to mention a few reasons why upgrading Smart Contracts is necessary.

Now that the reason has been established, how then can a developer upgrade their Smart Contracts, knowing fully well that a Smart Contract once deployed to a Contract address cannot be deleted?

This is where we get into the Technical deets of upgrading Smart Contracts. We will rely on the Open Zeppelin Proxy patterns to understand the concept. It is important to note that upgrading Smart Contracts does not just mean adding code to an already existing Contract. In the example we are going to use for demonstration, we will write a Proxy Smart Contract that will point to the V2 of the contract V1. Where V2 is an updated version of V2 with all the functions still in use and more added, or some functions removed or an algorithm rewrite. The Proxy ensures that the same address is what points to V1, V2,... Vn of the said Smart Contract. This way, the user sends a txn to the Proxy Contract, which then interacts with whatever version it is pointed to. Yes, each version and the proxy are immutable!

Open Zeppelin has a great resource on explaining Proxy Contracts: https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies You can learn about the various methods for upgrading Smart Contracts by reading the article.

Introduction

In this article, I’m going to demonstrate to you the Transparent Proxy pattern. To do this, we will build a simple Contract that we will likely upgrade to new versions in the future. The Contract sets the price for a train ticket. Given that there are no rising Economic costs, the tickets cost the same wherever the destination, so there is room for increasing the Ticket Price if ever there is a need. To do this, we will follow the steps:

• Write the code for v1 of the Train Ticket Smart Contract using Hardhat and deploy it to the Goerli Testnet.

• We will use an Open Zeppelin library called the hardhat upgrades in the deployment scripts. The Hardhat upgrades contain a method called deployProxy. This method ensures that when the contract is deployed, it creates a Proxy Contract as well.

• We will then write V2 of the Contract and then using hardhat upgrades, we will call the method upgradeProxy and point the deployed Contract to the proxy contract!

The upgradeProxy method takes 2 args and any other args passed to the Contract call:

upgradeProxy(PROXY, Contract, [any args passed to the Contract])

Smart Contract v1

I have a standard practice of writing Smart Contracts in Remix and then initializing a Hardhat Project on my machine. Thus, we will write the TrainTicketV1 using Remix.

Here is TrainTicketV1.sol

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

contract TrainTicketV1 {
    uint amount;
    address public owner;

    function setOwner() public {
        owner = msg.sender;
    }

    function setTicketPrice() public {
        require(owner == msg.sender, "Only the owner can set price");
        amount = 10000000000;
    }

    function getTicketPrice() view public returns (uint){
        return amount;
    }

}

Please note that this is for illustration purposes only and should not be deployed to production, especially given the reason that you do not want to give anyone the power to set the contract address and change ticket prices!

OK! I have confirmed that the Smart Contract code works and now we are going to set up a Hardhat Project and deploy the code to the Goerli Testnet using Hardhat deploy script and Open Zeppelin Hardhat deploy.

This article assumes that you understand how to set up a Hardhat project, if you do not, kindly follow the Hardhat guides for creating a new hardhat project: https://hardhat.org/tutorial/creating-a-new-hardhat-project.html

If you used the guide above, then, Hardhat generated a Greeter.sol file in the Contracts dir. Delete the content and replace it with the TrainTicketV1 code above. If you are familiar with writing Solidity, you could be surprised that the contract is not initiated with a Constructor argument. This was a gotcha moment for me too as I got to learn that Smart Contracts that are designed to be upgraded via the Transparent Proxy pattern are not initiated with a Constructor!

We are going to deploy the Contracts to the Goerli Testnet. You can use any EOA via Metamask or Ganache UI. What you will need are the Private Keys and some ETH from the Goerli Faucet here: https://goerlifaucet.com/ N.B: You will need to have an Alchemy account to receive tokens from this faucet. This is fine anyway, as we will rely on Alchemy as a provider to deploy the Smart Contracts to Goerli.

• Wallet Private Key (from Metamask preferably) ready, check…

• Received Tokens from the Faucet, check…

Sign in to Alchemy, create a Project and get the API KEY for the Project.

Deploy Smart Contract v1

This is where we get to the section where we will use the Open Zeppelin library to deploy our Smart Contract.

We will add this dependency to the package.json file: https://www.npmjs.com/package/@openzeppelin/hardhat-upgrades

According to the documentation: “You can use this plugin in a Hardhat script to deploy an upgradeable instance of one of your contracts via the deployProxy function.” This is just as I had explained earlier!

Seeing as we are installing dependencies, kindly throw in installing the dotenv library. Shsss… It is for secrets!

After the installation has been completed (which I’m certain you know how to do, or if you have forgotten, it is

npm install --save-dev @openzeppelin/hardhat-upgrades dotenv

Now we are ready to write a script to deploy our Smart Contract to the Goerli Testnet.

• Alchemy API… Check!

To deploy to an actual network using Hardhat, we have to add a Network configuration to the hardhat.config.js file.

Deleted the tasks block of code, delete the hardhat-waffle dependency that came default with the file, add the required dependencies and update the module.exports config:

require("@nomiclabs/hardhat-ethers");
require("@openzeppelin/hardhat-upgrades");
require('dotenv').config();

const ALCHEMY_API_KEY = process.env.ALCHEMY_API_KEY;
const EOA_PRIVATE_KEY = process.env.EOA_PRIVATE_KEY;

module.exports = {
  solidity: "0.8.14",
  networks: {
    goerli: {
      url: https://eth-goerli.alchemyapi.io/v2/${ALCHEMY_API_KEY},
      accounts: [`${EOA_PRIVATE_KEY}`]
    }
  }
};

We will need the Alchemy API Keys and EOA Private Key hidden somewhere! As I mentioned earlier, it is a secret we will keep in a .env file! Remember to add the .env file to your .gitignore if you are planning to push your code using a version management tool to any cloud service.

The Alchemy API KEY and the EOA Private Key are rendered to the hardhat config file using dotenv. Dotenv uses process.env to read files from the .env file.

It is in the hardhat configuration that we also require the Hardhat upgrades and the hardhat ethers. Both are required for when we have to deploy the Smart Contract.

Now, we have the hardhat configuration ready, let’s compile the Contract to generate the artifacts and the cache dir.

$ npx hardhat compile

When the contract is successfully compiled, a success message is returned to the terminal:

Compiled 1 Solidity file successfully

Next is our deploy script! Just so you recall, we are deploying the TrainTicketV1.sol Smart Contract which as already been compiled. Open the scripts folder and delete the sample scripts file created by Hardhat. Create a new file, you can name it deploy_v1.js, add the following code:

const { ethers, upgrades } = require("hardhat");

async function main() {
  const Contract = await ethers.getContractFactory("TrainTicketV1");
  console.log("Deploying Train Tikcet v1...");

  const contract = await upgrades.deployProxy(Contract)
  await contract.deployed();
  console.log("Contract deployed to:", contract.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

Let’s breakdown what happened here line by line:

const { ethers, upgrades } = require("hardhat");

ethers is available to us as a class function on which we call the getContractFactory method. upgrades is available via the hardhat library and we call the deployProxy method on it. As has been explained earlier, deployProxy is the magic function.

await contract.deployed() is to ensure we can read the deployed contract methods if we had a frontend for instance.

To deploy the Contract to the Goerli Testnet and experience the beauty of upgrading a contract using TransferProxy, run the following command:

npx hardhat run scripts/deploy_v1.js --network goerli

It will return the console.log message prompts we added to the deploy_v1.js file

Deploying Train Ticket v1...;

When successful

Contract deployed to:", <contract.address>

Open the Goerli Testnet Explorer: https://goerli.etherscan.io

Do not go to the Contract Address immediately, first, look up the EOA that you used in deploying the Smart Contract and view the Txns that took place! Wait for it… You will find 3 txns and not 1! Haha! Fascinating!

Rank from top to bottom:

1. This is the TransparentUpgradeableProxy, this holds the Contract address where all new versions of Train Ticket will be interacted with.

2. This is the ProxyAdmin where all Transactions between upgrades and TransparentUpgradeableProxy will be routed.

3. This is the actual version 1 of the Train Ticket Contract!

To interact with the Contracts via Etherscan, we will

• Verify and Publish the Smart Contract Code

• Verify the TransparentUpgradeableProxy and set it as a Proxy (i.e The Contract that will be interacted with.)

Via Etherscan, follow the steps to verify and publish the TrainTicketV1 contract. Once verification is done, go to the Proxy Contract (i.e TransparentUpgradeableProxy), open the Contract Tab and click on the dropdown button: ‘more options’

Click on: ’Is this a Proxy?’

On the next screen, click on: ‘Verify’

Click: ‘Save’

The Contract is now verified 🎉 and you have the ‘Read As Proxy’ and ‘Write as Proxy’ buttons!

Go test it! Here is my implementation: https://goerli.etherscan.io/address/0x5f5a9b36780f111417db19ffbe2f04876344009e#code

Smart Contract v2

This is version 1 of the TrainTicket Smart Contract successfully deployed! We will deploy version 2 next. To do that, we need to

• Write TrainTicketV2.sol

• Compile the Contract.

• Write deploy_v2.js script.

• Deploy the Contract as a Proxy!

Just like eating sweet cake!

First, TrainTicketV2.sol

// SPDX-License-Identifier: GPL-3
pragma solidity ^0.8.14;

contract TrainTicketV1 {
    uint amount;
    address public owner;

    function setOwner() public {
        owner = msg.sender;
    }

    function setTicketPrice() public {
        require(owner == msg.sender, "Only the owner can set price");
        amount = 10000000000;
    }

    function getTicketPrice() view public returns (uint){
        return amount;
    }
}

If you look closely, the only difference here is the new price set for purchasing Train Tickets! Inflation? I hope not!

Compile the Contract. It should compile successfully.

Deploy v2

Next, the deploy script! Here is where it all gets interesting, watch closely. This time, name the file deploy_v2.js.

const { ethers, upgrades } = require("hardhat");

const PROXY_CONTRACT = "0x022aA95A1fB518607eEF4093Bd82eAe4dAF97337";

async function main() {
  const Contract = await ethers.getContractFactory("TrainTicketV2");
  console.log("Deploying Train Ticket v2...");

  await upgrades.upgradeProxy(PROXY_CONTRACT, Contract)
  console.log("Contract Upgraded");
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

I explained the method call getContractFactory on class ethers. What is different here is this:

• We set the PROXY_CONTRACT address so that the new version of the Train Ticket contract can point to it.

• The above is achieved when we call upgradeProxy method on upgrades class.

Deploy the new version!

npx hardhat run scripts/deploy_v2.js --network goerli

Once, you have successfully deployed as confirmed from the messages logged to the console, go take a look at the new transactions on the address, this time you will find 2.

Rank from top to bottom:

1. This is the NEW ProxyAdmin where all Transactions between upgrades and TransparentUpgradeableProxy will be routed.

2. This is the actual version 2 of the Train Ticket Contract!

If you already realized that the TransparentUpgradeableProxy from the first deployment is where you contract is pointed to, then you are a-mazing!

All, you have to do now is:

• Verify and Publish the TrainTicketV2 contract

• Set as Proxy using the same steps as above!

Once that is complete, users will be interacting with V2 of your Smart Contract! You can upgrade as much as you want up to Vn…

That my dear reader is how to upgrade a Smart Contract!

Here is my V2 implementation: https://goerli.etherscan.io/address/0x53bbdb042997ddbf2be8116e6c6d3c9205026ab7#code

Here is my Proxy Contract Implementation: https://goerli.etherscan.io/address/0x022aa95a1fb518607eef4093bd82eae4daf97337

Thank you for reading this far! If you found the content useful, please kindly share it with your network.

Source Code

You can find the complete source code here: https://github.com/emmaodia/tutorials-code/tree/main/train-ticket

• Brief Overview of NEAR

• Installing dependencies

• Smart Contract

• Frontend

• Conclusion

Brief Overview of NEAR

There are many blockchain networks which exist. This is great as it fully underscores the primary idea behind decentralization. One such Blockchain network is the NEAR Blockchain. NEAR is described as a Layer 1 (L1), sharded, proof-of-stake Blockchain. Let’s define the words used to describe NEAR in the context of use in this article.

L1

Layer 1 also commonly referred to as L1 is simply the base (primary) blockchain network for a particular protocol. It is easier to grasp the concept when it is compared side by side with Layer 2 (L2) blockchains which are protocols built on top of the L1 chains and sometimes also include sidechains and other offerings depending on the network. All transactions that take place on an L1 chain are finalized on the network according to the rules embedded in the network protocol. An example is a finality for transactions which on NEAR is 2 seconds. An L2 may be built to improve on this. The NEAR blockchain is still, at this time, an L1 solution.

Sharding

Blockchain sharding refers to a blockchain network separated/broken into smaller components called shards. Transactions are then carried out on the shards. Sharding is done to help increase the number of transactions that can be carried on a blockchain and thus leading to an increase in its throughput and possibly, latency. Harmony is an example of a blockchain that relies on sharding to increase its overall performance. As a result, each shard of Harmony is treated as its own network, holding transaction state in its block changes. Each Harmony shard has its own network id. NEAR is a sharded blockchain, unlike Harmony, NEAR shards through individual networks, do not have their own network ids. This sharding implementation of NEAR is called the Simple Nightshade.

Proof Of Stake

Blockchains as open ledgers require participants to validate all transactions which will lead to state changes. That means that all participants must reach a consensus on the data in every block. There are 2 methods for reaching consensus: Proof of Work (PoW) and Proof of State (PoS). Proof of Work consensus relies on the calculation of a mathematical algorithm using computers to validate blockchain data. This uses a lot of computing power. On the other hand, Proof of State relies on validators who have staked a bond in the blockchain network to act as data verifiers. This does not require much computation and as a result, it places a low demand on hardware. NEAR blockchain is often referred to as being carbon neutral because it uses the Proof of Stake consensus approach.

Now that we have established a definition for the NEAR blockchain, we are going to be building a DApp and deploying it on the Blockchain. Just a quick reference guide, I’ll briefly explain why sharding as technology is important to a developer’s decision in deciding on a Blockchain to build on.

Ethereum blockchain can carry out less than 20 Transactions per second. This means that the transaction finality on Ethereum is about 1.2 minutes. This is a low throughput that is associated with other challenges such as an increase in fees for validating transactions and latency. Ethereum is also an L1 solution. The NEAR blockchain was premised on solving the low throughput and latency problems for Ethereum. From the onset, the developer of the NEAR chain decided to rely on sharding to ensure that NEAR would be able to do a minimum of 2500-3000 Transactions per second, with a finality of 1.2 seconds. This is a whole lot faster than Ethereum L1. This should be given thought to developers who wish to build on an L1.

In this article, we will build a NEAR Dapp for making donations to a charity for victims of violence. The donations will include notes from the donors.

We can build Blockchains on NEAR using Rust programming language or Assembly script. We are going to be using Rust.

Installing Dependencies

First, if you have yet to, you need to install RUST on your local machine. You can follow the guide here: https://www.rust-lang.org/tools/install

Also, install the near-cli via the terminal

$ npm install -g near-cli

Please note that this article is not a guide on Rust programming language. The motif of this article is to demonstrate to you how easy it is to write Smart Contract code in Rust and deploy it on the NEAR Blockchain. NEAR has its library for spinning up projects similar to the Create React App. It is called the Create NEAR App. It is bundled with a React frontend library that has a lot of existing features for quickly building apps. We will use the Create NEAR App to demonstrate how to build the project.

Smart Contract Code

To begin writing the Smart Contract, run the command:

$ npx-create-near-app near-donor-dapp

It will prompt you to add the assembly script wasm file, respond yes.

When the dependencies have finished installing, cd into the project directory:

$ cd near-donor-dapp

If you are used to building projects using ReactJS, you will observe a similarity in the project directory. Open the project in an IDE like VSCode, the dir structure looks like this:

To have the Dapp running locally, run

$ yarn build

$ yarn run dev

Go to localhost:1234 to see the app running:

You can try interacting with the Dapp by clicking the “Sign in” button. The Dapp is running on the NEAR testnet and it is safe. When you click the button, you will be prompted to give the Dapp access to your NEAR account:

That is a default greeting DApp, you can go ahead, and interact with it!

We have successfully used the create NEAR App. Next will be to write the Smart Contract code for the implementation of the donor Dapp and deploy it to a NEAR address of our choosing.

As a guide, let’s design the Smart Contract logic using an illustration.

It is a simple DApp.

Smart Contract

The Smart Contract code will be written in Rust. Open the src folder and you will find the lib.rs file. Open the lib.rs file, you will find the example greeting contract. For our donor app, we are not going to write any tests, so you can go ahead and delete the lines of code from line 45 to the end, the tests module.

Before we delete the example greeting contract, study the comments for the implementation and the functions in the contract. There is a set_greeting method and a get_greeting method. The set_greeting method changes the state of the blockchain as it is used for sending data. The get_greeting method is a view function that does not impact the state of the blockchain.

The Near Donor app will have 3 functions:

• A function for sending tokens to a selected address. This function will take 3 arguments: amount, receiver_address and note.

• A function for getting the transactions sent to the contract.

• A view function for returning the transaction information sent on-chain.

In the lib.rs file, delete the default message line, delete the message of String data type in the Contract struct, and delete the functions inside the Default and Contract implementation you, will be left with barebones code like this:

use near_sdk::borsh::{self, BorshDeserialize, BorshSerialize};
use near_sdk::{log, near_bindgen};

// Define the contract structure
#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize)]

pub struct Contract {

}

// Define the default, which automatically initializes the contract
impl Default for Contract{

}

// Implement the contract structure
#[near_bindgen]
impl Contract {

}

I’ll go over each line of code and explain what they are meant for:

use near_sdk::borsh::{self, BorshDeserialize, BorshSerialize};

We are using the near_sdk for writing the contracts, Borsh is “a non self-describing binary serialization format. It is designed to serialize any objects to a canonical and deterministic set of bytes”. It is designed for storing contract state efficiently on the NEAR chain to save storage and gas costs.

use near_sdk::{log, near_bindgen};

These are macros in the NEAR sdk that we will be calling in our project

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize)]

The macro near_bindgen is wrapped around the struct to generate the smart contract. Every Rust contract is preceded with this macro as it allows it to make calls that change the contract state and receive calls.

pub struct Contract {...}

The public method implementation of an impl method will be defined in this struct

impl Default for Contract{ … }

Defines the default method call, which automatically initializes the contract

#[near_bindgen]
impl Contract { … }

The contract implementation will live here. The method calls for setting the state and viewing the state will be defined here.

We will add some macros to the near_sdk that we will need in the course of writing the Contract. They are: AccountId and Promise.

use near_sdk::{log, near_bindgen, AccountId, Promise, env};

AccountId is a near_sdk type definition for a user who is transferring tokens. The concept of a Promise here is similar to its use in JavaScript. env contains the information on the user who will interact with the methods in the contract. It provides an easy way to call the user address.

The contract is going to store data on-chain and that will cost gas to store. To optimize the cost of storage, we will use a LookupMap to store the data. A LookupMap stores key and value once. requires only one storage read to get the stored value.

The LookupMap is a method of the std_collection library. We will import it into the project via the near_sdk

use near_sdk::collections::LookupMap;

Now that we have added the LookupMap, we can store the key: value pair of the data type that we wish to return using the LookupMap. We will implement this in the struct for the Contract:

pub struct Contract {
  note: LookupMap<String, Vec<String>>
}

This is simply holding the note in a LookupMap. LookupMaps are non-iterable.

Define the Default impl:

impl Default for Contract{
   fn default() -> Self {
       Self { 
            note:LookupMap::new::(b"note".to_vec())
        }
   }
}

The Default stores the data parsed via the LookupMap on the chain in an ordered index of array items, identified by numbers which can easily be looked up and returned and also easily save the data as stated above.

Next, we will implement the state methods and view method for the contract! These methods will be in the impl Contract.

The easy state change method, to begin with, is the donate function:

pub fn donate(&mut self, account_id:AccountId, amount:f64) {
Promise::new(account_id).transfer(amount as u128);
}

It is a publicly called function hence, the pub definition. The function is called: donate, and it takes 2 args. The &mut self is Rust's way to confirm that it is a mutable function call. The AccountId from the near_sdk collection is parsed to account_id, this will be the wallet id of the user making a donation, the amount is of primitive data type f64.

It is a Promise call, where the transfer method is called on the account_id to transfer the specified sum which is on int type 128.

Now we can call the donate function and transfer tokens. Let’s add a heartfelt note to the donations:

pub fn note(&mut self, note_text: String, amount: String) {
let account_id = env::signer_account_id();
let user = self.note.get(account_id);
}

This is the note function, it is mutable hence the &mut self arg. It takes two argos, note_text and amount which it stores on chain. The args are of type String.

Here we see the use of the near_sdk env, it helps retrieve the details of the user who is signing the contract interaction. We declared a variable account_id to hold the amount information. The second variable user assigns the account information by calling the get() method to associate the account_id to the user in the LookupMap.

We are not done with this function as we still have to push the arg passed to the function on-chain when the function is called. There is a condition to check for when we implement this: Do we already have available information on the user calling the method?

We will use an if else statement to check for when we have the associated user information. When we do, we will push the data to a vector of arrays.

if user {
let mut list = match self.note.get(&account_id) {
Some(var) => var;
None => vec![];
};
list.push(note_text + “||” +&amount + “ NEAR.”);
self.note.insert(&account_id, &list);
} else {
let list = vec![note_text + “||” +&amount + “ NEAR.”];
self.note.insert(&account_id, &list);
}

This is an if else statement. The critical information to highlight here is the

Some(var) => var;
None => vec![]

This is the rust array macro argument which checks if a user information exists in the list variable and creates an array if it does not.

The push method sends the information on chain.

We are done with the functions that change the state of the contract and will now write our last function to view/return the data on chain. The view functions do not incur gas costs.

pub fn view_donations(self, user:String) -> Vec<String> {
match self.note.get(&user) {
Some(var) => var;
None => vec![]
}
}

This is not a mutable function as view functions are not mutable. You do have to indicate the self keyword. It takes in the user info and returns a Vec of String. This is the format in which the info was saved on-chain.

Using the match keyword, we can check through the array vectors if a user exists or not.

We are done with the functions needed for the Smart Contract. We can compile the contract and deploy it to the NEAR Testnet to interact with it. To compile the Smart Contract, run

$ yarn build

The Smart Contract will compile without errors. Every time you make a change to the Smart Contract code, you will have to compile it. When the compilation is complete, the next step will be to deploy the Smart Contract. The deployment will be done in your terminal using the near-cli.

Open a terminal and ensure you are in your project directory, First we have to login to NEAR. This is to create a connection the testnet account where we will deploy the Smart Contract. Run th e command:

$ near login

This will open a window in your browser where you will be prompted to login to your Testnet wallet. The near login command connects to the NEAR testnet by default. This is to ensure a layer of security so you do not spend actual tokens in error. To connect to the Mainnet account, you can see the instructions in the NEAR docs.

If you look closely, you will notice a difference here from where we connected to the dapp we initialized at the beginning. This is a connection to the NEAR blockchain from our computer and we are requesting full access to all the account privileges associated with our NEAR account.

To deploy the contract on-chain, run the command:

$ near deploy --wasmFile target/wasm32-unknown-unknown/release/rust_counter_tutorial.wasm --accountId YOUR_ACCOUNT_HERE

Where YOUR_ACCOUNT_HERE is the account where you deployed the code, e.g: oaikhenan.testnet

Once the contract has successfully deployed, we can begin interacting with it by calling the function via our cli using near-cli commands.

“The Blockchain is a distributed ledger system that can validate ownership of a token ensuring that a user can transfer the said token to another user and pay a small fee to mining participants in the system to verify the transaction”. I immediately saw the use case for identity management, ownership of assets, cross-border payment systems, logistics tracking, and patient management in healthcare.

That said, it is commonplace right now for a lot of people to associate Blockchain technology with crypto settlements (read: payments). The technology differentiates itself from “centralized” systems by the introduction of a token system to affirm data ownership and validate transactions. It is so much more more than payment systems. Blockchains ensures ownership of data by the use of token to verify transactions. These same tokens used for payment settlements can be used for identity verification and all other use case listed above.

One very common misconception a lot of people have is when they try to separate Blockchain technology from the “Internet”. Internet for context here refers to the HTTP protocol. Not to go so much into the explanation of the technical scope of Blockchains, it is imperative to mention that at the user level - wallet transactions, et all - Blockchains are communicated with via HTTPS procedural calls. This is not an article on nodes and RPC. More often than not we have a lot of people in recent years coming into the Blockchain for the promise of economic gain, where they hope to 10000x on a token. It is critical to mention therefore that Blockchains do not exist solely for the purpose of minting tokens and creating Billionaires “out of thin air”. The technology also exists to solve a myriad of problems in sectors as I have mentioned in the first paragraph.

Blockchains, what now?

As I mention often, it is still very much early days for Blockchains. The promise for a lot more use cases beyond just payment settlements and other financial services is enormous. It is critical that everyone gets involved. The barriers to entry (e.g Bad UX) have to be reduced. The critical component of learning how to build has to be made even simpler for developers getting into the space. The prevailing idea of using the term web3 to define the Blockchain makes it seem like a new technology that lives away from the internet needs to be addressed by stakeholders in the space. The primary reason is to ensure that more people understand that Blockchain is a technology for verification of ownership, hence: tokens exist for the purpose.

I do recommend that if you are yet to get involved in Blockchain technology, do so now! I opened my first Blockchain Wallet on the Bitcoin Network in 2015. Sad to mention that at the time, I really did not understand the token aspects of the technology. I saw a piece of tech that made cross-border settlements easier. I was blown away when I discovered Ethereum and the very fact that one can do a whole lot more with Ethereum Smart Contracts. To get started in Blockchain technology now in 2022, you have to first decide on a Blockchain network you want to partake in and open a Wallet. I’ll not recommend you join any network in particular, rather, I suggest joining any EVM compatible network and get your Wallet Address from MetaMask.

This is an opinion piece and I hope to write a whole lot more of these on Blockchain technology. You can initiate a conversation with me on Twitter to share your thoughts as well. See you in the next one. Cheers!

“I’m not one to complain about situations beyond my immediate control and ability to impact”.

🏋️‍♀️

In this article, I’m going to make a submission on how Nigerians and Africans at large can leverage the web3 technologies and “act outside of bad government policies” to create wealth and achieve democratic consensus in tandem with the rest of the world. Unfortunately, many African countries are at the mercy of bad government policies!

In this article we take about:

• What is the web3 - Explain like I am 5.
• Why do I need to pay attention? Crypto payment use case

Enter the Web3!

I’m going to explain the web3 as I would to a 5-year-old child. Let’s call the child “Themba”

Themba: What is the web3.

Me: {Struggles in my head as to how I’ll break down terms such as Democracy, Open, Trust, Transparent to a child and then takes a deep sigh} Themba… Let me tell you a story…

Themba, you recall the story I told you about the Rat and the Lion and why Lions do not eat rats? {Thema nods heads affirmatively}. Yes. I told you that the Rat released the Lion when he was caught in a trap net and the Lion promised not to eat him and also he mentioned that his descendants will never eat the descendants of the rat. The Lion gave the rat his word and he wrote it down on a piece of paper, and also he shared this same piece of information with other Lions and the rat shared his with other rats. That started the process where whenever a Lion sees the rat, the rat simply showed the Lion the piece reminding it that it cannot be eaten. Each encounter that they have is recorded on a large register and all Lions and Rats have the register to make sure no Lion eats a rat. It is a very large register when every meeting is not noted and bundles together and whenever the Rats and Lions want to know what happened on particular days there was an exchange between rats and Lions, they look up the information in the register using the bundle information. The is the web3 for Lions and Rats. They hold a piece of information, you can think of this as a Smart Contract, each encounter between a Lion and a rat is a transaction and it is written on the register which is a Ledger. When the encounters (transactions) reach a certain number they are bundled and that is a block. This makes it easy to look up information. The blocks are stringed together to keep a chain record. Making up a network (the Blockchain) where Lions and Rats hold consensus on a contract that Lions will never eat rats in an environment called the web3.

It is an OPEN process needing no INTERMEDIARIES and it is DEMOCRATIC. The Lion and the Rats agree and do not need other forest animals to ensure the Lion does not break his contract. The record exists to prove this!

Yes, that is exactly (well, maybe not so exact) what the web3 is. The most popular use case globally and which still needs to be harnessed for Africa is payments. Cross continental payments and P2P for daily transactions. Payments in the context of the Rat and Lion is then a contract which indicates that every time the Lion and Rat meet, they meet to exchange money as a form of payback for ancestor Rat saving ancestor Lion!

Solving the Money Problem

This is where I explain to you still in technical speak, but using technical analogues what the web3 means in terms of payments. Crypto as currencies on the web3 is popularly called is a coined from the root word cryptography. Which also when further broken down is formed from the word cryptic. Which means a message which is difficult to understand without clues. When a cryptic message is sent from a sender to the recipient, the sender must add a key to the message which the recipient will then use as a guide to get the meaning of the message. Thus ensuring that only the intended recipient gets a message and no one else. This is a somewhat oversimplification of what cryptocurrencies are in the light of cryptography. The point here is this: A cryptocurrency can be regarded as a number of cryptic messages written originally by miners who then send out these messages to people who want to own a piece of each message and hand over the keys to read the messages, each message (in this case a token) is regarded as a store of value and is given a price figure because it has the following properties: No one else can access the message asides from the one who holds the keys. Not even the miner When a person does a task, they can be paid using a piece of the message (token) as it is an agreed-upon value exchange commodity. It is a lot like trade by barter, wherein in this instance, I can give you a piece of cryptic message (cryptocurrency) which no one else holds in the world. A duplicate copy cannot be made of it. There is an open book (ledger) distributed globally which tracks the transfer of the crypto-message from one hand to another.

When a user can grasp the importance of owning a piece of these crypto-messages, understand why it is a store of value and wants to own a piece of it, a user will then have to join the web3, which unlike the web3 has its own particular protocols, tools and interface.

How to get into web3

In this context, getting into web3 means: “How do I convert my fiat currency to cryptocurrency?”

But first, it is important to understand that, the first set of crypto and up till now was created by miners. Now, you can buy from someone who already holds crypto to own a piece. You can also mine, though the set-up is quite expensive. This could be from a crypto exchange that you can give cash and in exchange you receive crypto. Right now, given the recent ban by the Central Bank of Nigeria on the use of crypto, you can no longer connect your Bank account to crypto exchanges to purchase crypto. There are a number of exchanges, you simply have to find the particular exchanges that serve your country.

You still are able to open an account with one of these exchanges and purchase your initial crypto from other vendors on the platform. This method is called P2P (Peer to Peer). With P2P, you send a request to purchase crypto after you have signed up and completed KYC on the platform. When you sign up with an exchange, you are given an address to hold your crypto assets. This is called a wallet address. When you request to buy crypto, you are then given a list of crypto sellers that you can then pair with, who is able to supply crypto on the exchange for cash. You then request to trade with a selected user and then they provide you with their account details while you provide them with your wallet address generated on the platform. The amount of crypto-asset you are purchasing is valued in fiat (like a forex exchange where you can see USD and your local currency pair). You send the money to the seller’s amount and they send the crypto to your wallet address.

There, you made your first crypto purchase! 🎉

A quick search on Google will return the crypto exchanges operating in your country.

Conclusion

I set out with the intent to explain the web3 to you without the mention of crypto and I achieved this using the “Rat and the Lion” story to explain contracts and transactions. After laying that foundation, I then explained web3 using crypto. Crypto still is the easiest point of entry into the web3. There are other use cases that I will share as time goes on.

I do hope you learn a thing or two from the article! Let me hear your thoughts! You can Tweet at me, Let’s connect!

Fun fact: It is said that Lions do not eat rats as the calories reward for eating rats will not fill for the energy expended chasing them! 😂