What is Harmony VRF

Harmony brings the technology of VRF (Verifiable Random Function) natively on chain to create a optimal solution for randomness that is unpredictable, unbiasable, verifiable and immediately available. Harmony VRF is a unique construction based on our existing cryptographic primitive of BLS signatures which makes the computation efficient without extra burden to our network validators. Harmony VRF is available for every single block and any smart contract can access the random output through a precompiled contract without paying additional fees.

VRF is a cryptographic invention to solve the problem of onchain randomness. VRF introduces the cryptographic construction where a private key SK is used to work on an arbitrary message and produce a unique and random output along with a proof. The validity of the random output can be verified by any one who knows the corresponding public key PK and the proof.

Harmony supports the on-chain verifiable random source based on VRF (Verifiable Random Function). Specifically, for every new block, the block producing validator computes a VRF based on his private key and the latest block hash to produce a 32-bytes VRF output and 96-bytes proof. The VRF output and proof are concatenated as a 128-bytes data and put in the VRF field of the header of the newly proposed block.

How to Access Harmony VRF within Smart Contract

The VRF data are available to be consumed by any chain clients by querying the block header. We also exposed the VRF data in the smart contract level via a new EVM precompiled contract at address 0xff. Any smart contract on Harmony can access it with following solidity assembly code:

  function vrf() public view returns (bytes32 result) {
    uint[1] memory bn;
    bn[0] = block.number;
    assembly {
      let memPtr := mload(0x40)
      if iszero(staticcall(not(0), 0xff, bn, 0x20, memPtr, 0x20)) {
        invalid()
      }
      result := mload(memPtr)
    }
  }

Note the input of the precompiled contract at 0xff is the block number for which the VRF is requested. The block number should only be within the last 256 blocks. If a block number outside this range is provided, the current block's VRF will be returned.

How Harmony VRF is Constructed

Harmony builds on the existing cryptographic primitive of BLS signatures which are currently used for block signing and consensus to create an efficient and secure VRF construction. The BLS-based VRF works as follows. Given a VRF input M, a BLS private key SK is first used to sign on M to produce a signature S=sign(SK, M). Then the signature is hashed with sha256 to produce the VRF random output R=hash(S), and the signature itself becomes the VRF proof P=S. The VRF output R can be verified with the proof P by checking that P is the correct signature from PK on message M and that hash(P)=R. More formally, the BLS-based VRF construction (Keygen, Compute, Verify) can be specified as follows:

• Keygen(r) → (PK, SK). The BLS key generation algorithm produces a pair of public key PK and private key SK.

• Compute(SK, M): Hash(Sign(SK, M)) → (R, P). The computation of VRF output R is the hashing of the signature signed with the private key SK on message M. The VRF proof P equals the signature from Sign(SK, M).

• Verify(PK, M, R, P): SigVerify(PK, P, M)=True & Hash(P)=R. The verification of the VRF works by checking 1) the VRF proof P is the correct signature from public key PK and message M; 2) the VRF output R equals the hash of P.

What Harmony VRF Brings to your Dapps

Harmony VRF brings the opportunity for developers to build trust-worthy and fair Dapps and protocols on chain. To name a few potential applications using VRF:

1. Make blockchain games provably fair and entertaining by using VRF to generate random game scenarios, distribute loot fairly and shuffle players unpredictably.

2. Randomly and fairly assign tasks or assets to participants of DAO, DeFi or NFT.

3. Select a random sample of protocol validators or governance voters from all participants for consensus or decentralized governance.

With Harmony VRF, a new realm of randomness-based trust-worthy applications can be built natively on Harmony blockchain. Developers with a security-focused mindset can feel safe to build applications using Harmony’s secure on-chain randomness. It’s guaranteed by cryptography with verifiable proof that no malicious participants are able to predict or influence the random outcome and make unfair profits. Additionally, Harmony VRF is available on every block of all 4 shards in Harmony and is easily accessible through a simple smart contract call without extra fee.

Envio is a feature-rich indexing solution that provides developers with a seamless and efficient way to index and aggregate real-time or historical blockchain data for any EVM. The indexed data is easily accessible through custom GraphQL queries, providing developers with the flexibility and power to retrieve specific information.

Envio offers native support for Harmony (both testnet and mainnet) and has been designed to support high-throughput blockchain applications that rely on real-time data for their business requirements.

Designed to optimize the user experience, Envio offers automatic code generation, flexible language support, quickstart templates, and a reliable cost-effective hosted service.

Indexers on Envio can be written in JavaScript, TypeScript, or ReScript.

Envio HyperSync

Envio supports HyperSync on Harmony mainnet.

HyperSync is an accelerated data query layer for the Harmony blockchain, providing APIs that bypass JSON-RPC for 20-100x faster syncing of historical data. HyperSync is used by default in Envio's indexing framework, with the use of RPC being optional. Using HyperSync, application developers do not need to worry about RPC URLs, rate-limiting, or managing infrastructure and can easily sync large datasets in a few minutes, something that would usually take hours or days using RPC.

HyperSync is also available as a standalone API for data analytic use cases. Data analysts can interact with the HyperSync API using JavaScript, Python, or Rust clients and extract data in JSON, Arrow, or Parquet formats. For more information, visit the HyperSync documentation here.

Key Features

• Contract Import: Autogenerate the key boilerplate for an entire Indexer project off a single or multiple smart contracts. Deploy within minutes.

• Multi-chain Support: Aggregate data across multiple networks into a single database. Query all your data with a unified GraphQL API.

• Asynchronous Mode: Fetch data from off-chain storage such as IPFS, or contract state (e.g. smart contract view functions).

• Quickstart Templates: Use pre-defined indexing logic for popular OpenZeppelin contracts (e.g. ERC-20).

Getting Started

Users can choose whether they want to start from a quickstart template, perform a subgraph migration, or use the contract import feature.

The following files are required from the user to run the Envio indexer:

• Configuration (defaults to config.yaml)

• GraphQL Schema (defaults to schema.graphql)

• Event Handlers (defaults to src/EventHandlers.* depending on the language chosen)

These files are auto-generated according to the template and language chosen by running the envio init command.

Contract Import Tutorial

This walkthrough explains how to initialize an indexer using a single or multiple contracts that are already deployed on a blockchain. This process allows a user to quickly and easily start up a basic indexer and a queryable GraphQL API for their blockchain application within a few minutes.

Intialize your indexer

cd into the folder of your choice and run

envio init

Name your indexer

? Name your indexer:

Choose the directory where you would like to setup your project (default is the current directory)

? Set the directory:  (.) .

Select Contract Import as the initialization option.

? Choose an initialization option
  Template
  SubgraphMigration
> ContractImport
[↑↓ to move, enter to select, type to filter]

? Would you like to import from a block explorer or a local abi?
  Block Explorer
> Local ABI
[↑↓ to move, enter to select, type to filter]

Block Explorer option only requires user to input the contracts address and chain of the contract. If the contract is verified and deployed on one of the supported chains, this is the quickest setup as it will retrieve all needed contract information from a block explorer.

Please note: Block explorer option currently only supports networks with etherscan. If the network doesnt have etherscan, you can proceed using the Local ABI option.

Choosing Local ABI option will allow you to point to a JSON file containing the smart contract ABI. The Contract Import process will then populate the required files from the ABI.

Specify the directory of JSON file containing ABI

? What is the path to your json abi file?

Choose which events to include in the config.yaml file

? Which events would you like to index?
> [x] ClaimRewards(address indexed from, address indexed reward, uint256 amount)
  [x] Deposit(address indexed from, uint256 indexed tokenId, uint256 amount)
  [x] NotifyReward(address indexed from, address indexed reward, uint256 indexed epoch, uint256 amount)
  [x] Withdraw(address indexed from, uint256 indexed tokenId, uint256 amount)
[↑↓ to move, space to select one, → to all, ← to none, type to filter]

Specify which chain the contract is deployed on

? Choose network:
> <Enter Network Id>
  ethereum-mainnet
  goerli
  optimism
  base
  bsc
  harmony
v polygon
[↑↓ to move, enter to select, type to filter]

Enter in the name for the contract

? What is the name of this contract?

Enter in the address of the contract

? What is the address of the contract?
[Use the proxy address if your abi is a proxy implementation]

Note if you are using a proxy contract with an implementation, the address should be for the proxy.

Select the continuation option

? Would you like to add another contract?
> I'm finished
  Add a new address for same contract on same network
  Add a new network for same contract
  Add a new contract (with a different ABI)
[Current contract: BribeVotingReward, on network: harmony]

The Contract Import process will prompt the user whether they would like to finish the import process or continue adding more addresses for same contract on same network, addresses for same contract on different network or a different contract.

For more information on contract import feature, visit the documentation here.

Envio Indexer Examples

Click here for Envio Indexer Examples.

Getting Help

Indexing can be a rollercoaster, especially for more complex use cases. Our engineers are available to help you with your data availability needs.

Join our growing community of elite builders, and find peace of mind with Envio.

• Discord

• Email: hello@envio.dev

How to Interact with BandChain from Harmony Smart Contracts

We will go through each of these steps:

1. Requesting data using BandChain.js library

2. Using BandChain data in EVM Smart Contract in Harmony

Requesting data using BandChain.js library

BandChain provides the BandChain.js JavaScript library so developers can submit data requests right from their dApp client.

Once BandChain has successfully executed the requested oracle script, it will return the data and EVM proof payload back to the client to then be passed to our smart contracts in harmony blockchain.

Here is an example simple Node file requesting data using the library that queries the current Bitcoin(BTC) price from BandChain.

const BandChain = require('@bandprotocol/bandchain.js');
const { Obi } = require('@bandprotocol/obi.js');//BandChain POA mainnet endpoint URL
//const endpoint = 'http://poa-api.bandchain.org';
//BandChain dev-net endpoint URL
const endpoint = 'http://guanyu-devnet.bandchain.org/rest';const getBTCPrice = async () => {
 // Instantiating BandChain with REST endpoint
 const bandchain = new BandChain(endpoint);// Create an instance of OracleScript with the script ID
 const oracleScript = await bandchain.getOracleScript(76);// Create a new request, which will block until the tx is confirmed
 try {
   const minCount = 3;
   const askCount = 4;
   const mnemonic =
     'panther winner rain empower olympic attract find satoshi meadow panda job ten urge warfare piece walnut help jump usage vicious neither shallow mule laundry';
   const requestId = await bandchain.submitRequestTx(
     oracleScript,
     {
       symbol: 'BTC',
     },
     { minCount, askCount },
     mnemonic
   );
   // Get final result (blocking until the reports & aggregations are finished)
   const finalResult = await bandchain.getRequestResult(requestId);
   let result = new Obi(oracleScript.schema).decodeOutput(
     Buffer.from(finalResult.response_packet_data.result, 'base64')
   );
   console.log('RequestID: ' + requestId);
   console.log(result);
 } catch {
   console.error('Data request failed');
 }
};getBTCPrice();

Now let’s go through each section of the code.

Import the library and declare the necessary variables:

const BandChain = require('@bandprotocol/bandchain.js');
const { Obi } = require('@bandprotocol/obi.js');

The code requires two libraries:

• @bandprotocol/obi.js: a helper library to assist us when encoding/decoding data to/from Band Protocol’s OBI standard

• @bandprotocol/bandchain.js: the library that we’ll be using to make the queries to BandChain

Now, set the request parameters:

// BandChain devnet endpoint URL
const endpoint = 'http://guanyu-devnet.bandchain.org/rest';
// Mnemonic of the account to make the query from.
const mnemonic =
 'panther winner rain empower olympic attract find satoshi meadow panda job ten urge warfare piece walnut help jump usage vicious neither shallow mule laundry';// Request parameters
const bandchain = new BandChain(endpoint);
const oracleScript = await bandchain.getOracleScript(76);
const minCount = 3;
const askCount = 4;

Here we set the values that we will be using to make the request

• endpoint: the endpoint we will make the query to

• mnemonic: the mnemonic we will use to make the query. The associated account must have a balance to make a request

• bandchain: contains the necessary functions we’ll need to make the request

• oracleScript: object containing details of the oracle script we will be querying

• minCount: the minimum number of BandChain’s validators that responds for us to consider the request successful

• askCount: the maximum number of validators that we want to respond to the request

Now make the Oracle request and get the random hash:

const requestId = await bandchain.submitRequestTx(
   oracleScript,
   {
     symbol: 'BTC',
   },
   { minCount, askCount },
   mnemonic
 );
  // Get final result (blocking until the reports & aggregations are finished)
 const finalResult = await bandchain.getRequestResult(requestId);
 let result = new Obi(oracleScript.schema).decodeOutput(
   Buffer.from(finalResult.response_packet_data.result, 'base64')
 );
 console.log('RequestID: ' + requestId);
 console.log(result);

Finally, we execute the submitRequestTx member function of the previously declared bandchain object to make the oracle data request.

We can then do one of two things with regards to this request:

• Call getRequestResult, as we did here, to get the actual result of the request

• Call getRequestProof to get the proof bytes associated with the request

Both of these functions take in one argument, the requestID of the request you want to retrieve the result/proof from.

If the query is successful, the code should print a value similar to:

{ price: 11406282500000n },

which is the retrieved price of Bitcoin multiplied by 1 billion.

Using BandChain data in EVM Smart Contract in Harmony

Now that we know how to make a request to BandChain and retrieve the corresponding proof, we will now examine how we can use that proof in our smart contract.

The code below demonstrates an example contract that retrieves the latest price of Bitcoin from Band’s bridge contract and saves it onto the contract’s state:

pragma solidity 0.6.11;
pragma experimental ABIEncoderV2;import {Obi} from "./libraries/Obi.sol";
import {IBridge} from "./interfaces/IBridge.sol";
import {IBridgeCache} from "./interfaces/IBridgeCache.sol";
import "openzeppelin-solidity/contracts/math/SafeMath.sol";contract SimplePriceDB {
   using SafeMath for uint256;
   using ResultDecoder for bytes;
   using ParamsDecoder for bytes;IBridge bridge;
   IBridge.RequestPacket req;uint256 public price;constructor(IBridge bridge_) public {
        bridge = bridge_;req.clientId = "from_scan";
       req.oracleScriptId = 76;
       // {symbol:"BTC"}
       req.params = hex"00000003425443";
       req.askCount = 4;
       req.minCount = 4;
   }// getPrice fetches the latest BTC/USD price value from the bridge // contract and saves it to state.

   function getPrice() public {
      (IBridge.ResponsePacket memory res,) = bridge.getLatestResponse(req);
       ResultDecoder.Result memory result = res.result.decodeResult();
       price = result.px;
   }
}

Okay, now let’s break down the code.

import {Obi} from "./libraries/Obi.sol";
import {IBridge} from "./interfaces/IBridge.sol";
import {IBridgeCache} from "./interfaces/IBridgeCache.sol";
import "openzeppelin-solidity/contracts/math/SafeMath.sol";

Aside from OpenZeppelin’s SafeMath.sol, the contract we will be writing requires three helper files specific to Band’s oracle and bridge architecture: Obi.sol, Decoders.sol, and IBridgeWithCache.sol.

Obi.sol

This contains a set of functions to help serialize and deserialize binary data when interacting with the BandChain ecosystem. The full standard specification can be found on their wiki and the code on the BandChain repository.

Decoders.sol

This is what we will use to work with data related to requests made on BandChain. This will help us in extracting the various information, such as the price value, we may need from the request response from Band’s oracle. The file is available from an oracle script’s bridge code tab on the devnet explorer. For this particular example, the code is available here.

IBridgeCache.sol

The interface file for Band’s bridge contract. The code for this can also be found on the BandChain repository.

Now let’s look at the contract itself:

contract SimplePriceDB {
   using SafeMath for uint256;
   using ResultDecoder for bytes;
   using ParamsDecoder for bytes;IBridge bridge;
   IBridge.RequestPacket req;uint256 public price;constructor(IBridge bridge_) public {
        bridge = bridge_;req.clientId = "from_scan";
       req.oracleScriptId = 76;
       // {symbol:"BTC"}
       req.params = hex"00000003425443";
       req.askCount = 4;
       req.minCount = 4;
   }// getPrice fetches the latest BTC/USD price value from the bridge // contract and saves it to state.   function getPrice() public {
      (IBridge.ResponsePacket memory res,) = bridge.getLatestResponse(req);
       ResultDecoder.Result memory result = res.result.decodeResult();
       price = result.px;
   }
}

The contract itself can then be further broken down into two parts: the constructor and the main getPrice function.

Contract Constructor

constructor(IBridge bridge_) public {
    bridge = bridge_;req.clientId = "from_scan";
   req.oracleScriptId = 76;
   // {symbol:"BTC"}
   req.params = hex"00000003425443";
   req.askCount = 4;
   req.minCount = 4;
}

The contract’s constructor takes one argument, the address of the bridge contract. It then sets the various fields of the req RequestPacket variable. This req variable will be what we will use as the key to match and retrieve the price from the bridge contract. Specifically, in this case, we set req to have the following parameters.

• bridge: the address of Band’s bridge contract on the blockchain this example contract is deployed to. See this list for the chains that Band currently supports and corresponding contract addresses. You can deploy the bridge contract by yourself on the harmony chain. Bridge contract can be found here.

• clientId (“from_scan”): the unique identifier of this oracle request, as specified by the client.

• oracleScriptId (76): The unique identifier number assigned to the oracle script when it was first registered on Bandchain.

• params (hex”00000003425443"): The data passed over to the oracle script for the script to use during its execution. In this case, it is hex representation of the OBI-encoded request struct

• minCount (4): The minimum number of validators necessary for the request to proceed to the execution phase

• askCount (4): The number of validators that are requested to respond to this request

getPrice Function

// getPrice fetches the latest BTC/USD price value from the bridge // contract and saves it to state.function getPrice() public {(IBridge.ResponsePacket memory res,) = bridge.getLatestResponse(req);ResultDecoder.Result memory result = res.result.decodeResult();price = result.px;}

This is then the main function that we will use to fetch the price from Band’s bridge contract and save it into our price database contract’s state. It calls the bridge contract’s getLatestResponse to retrieve the latest request response associated with a BTC/USD price request. It then uses Decoders.sol’s decodeResult method to parse that response into a struct. Finally, we save the price value from that response into the contract’s price variable.

References:

1. https://docs.bandchain.org/developer/dapp-integrations/requesting-data-from-bandchain.html#requesting-data-using-the-bandchain-js-library

2. https://docs.bandchain.org/developer/dapp-integrations/using-bandchain-data-evm.html

Examples

Examples can be found here https://github.com/harmony-one/band_oracle

Requesting data using BandChain.js library

https://github.com/harmony-one/band_oracle/blob/main/main.js

git clone https://github.com/harmony-one/band_oracle
cd band_oracle

yarn
node main.js

Using BandChain data in EVM Smart Contract in Harmony

https://github.com/harmony-one/band_oracle

git clone https://github.com/harmony-one/band_oracle
cd band_oracle

yarn
export PRIVATE_KEY=place your private key here
yarn hardhat run ./scripts/deploy.js

contract's been deployed and you can call getPrice or getMultiPrices to get actual prices

Band’s StdReference contract for testnet 0xE740092E081CA7491A46C8Aa0175446e962e2A08

mainnet contract is coming soon

Install Ganache CLI

npm install -g ganache-cli

Load Harmony networks (local, testnet, mainnet) to ganache-cli. The command below loads

ganache-cli -f http://localhost:9500 --networkId 1666700000
or for testnet
ganache-cli -f https://api.s0.b.hmny.io --networkId 1666700000
or for mainnet
ganache-cli -f https://api.s0.t.hmny.io --networkId 1666600000

Use web3.js to interact with the ganache binded harmony network

const web3 = new Web3("http://127.0.0.1:8545");
web3.eth.getBlockNumber().then(console.log)

Harmony version of the Ganache is also available here.

Harmony-React adds support for using OneWallet and MathWallet together with web3-react.

Harmony-React is not a fork of web3-react, but rather built on top of web3-react to ensure that the library can be upgraded whenever web3-react gets updated.

Using Harmony-React

Installation

Add web3-react/core and the wallets you want to use (OneWallet, MathWallet or both) to package.json:

"@web3-react/core": "latest",
"@harmony-react/mathwallet-connector": "latest",
"@harmony-react/onewallet-connector": "latest",

Install using yarn install or npm install.

Usage

Import packages:

import { OneWalletConnector } from '@harmony-react/onewallet-connector'
import { MathWalletConnector } from '@harmony-react/mathwallet-connector'

Instantiate wallets:

const onewallet = new OneWalletConnector({ chainId: 1 }) // 1 = Mainnet, 2 = Testnet
const mathwallet = new MathWalletConnector({ chainId: 1 })  // 1 = Mainnet, 2 = Testnet

Store the wallet references in a store or a suitable structure, e.g:

    this.store = {
      ...
      web3context: null,
      connectorsByName: {
        OneWallet: onewallet,
        MathWallet: mathwallet,
      }
      ...
    }

For a more in-depth implementation example check here.

Create a wallet connection/unlock modal (or other suitable UI element):

import React from "react";
import {
  DialogContent,
  Dialog,
  Slide
} from '@material-ui/core';

import Unlock from './index.jsx';

export default function UnlockModal(props) {
  const { closeModal, modalOpen } = props
  const fullScreen = window.innerWidth < 450
  const Transition = React.forwardRef((props, ref) => <Slide direction="up" {...props} ref={ref} />)

  return (
    <Dialog open={ modalOpen } onClose={ closeModal } fullWidth={ true } maxWidth={ 'sm' } TransitionComponent={ Transition } fullScreen={ fullScreen }>
      <DialogContent>
        <Unlock closeModal={ closeModal } />
      </DialogContent>
    </Dialog>
  )
}

Implement the Unlock component:

...
import { Web3ReactProvider, useWeb3React } from '@web3-react/core'
...

export default function Unlock({ closeModal }) {
  ...
  
  return (
    <div className={ classes.root }>
      <div className={ classes.closeIcon } onClick={ closeModal }><CloseIcon /></div>
      <div className={ classes.contentContainer }>
        <Web3ReactProvider getLibrary={ getLibrary }>
          <WalletComponent closeModal={ closeModal } />
        </Web3ReactProvider>
      </div>
    </div>
  )
}

And finally, implement the WalletComponent:

export default function WalletComponent({ closeModal }) {
  const context = useWeb3React()
  const localContext = store.getStore('web3context')
  var localConnector = null;
  if (localContext) {
    localConnector = localContext.connector
  }
  
  const {
    connector,
    library,
    account,
    activate,
    deactivate,
    active,
    error
  } = context;

  var connectorsByName = store.getStore('connectorsByName')

  const [activatingConnector, setActivatingConnector] = React.useState()
  useEffect(() => {
    if (activatingConnector && activatingConnector === connector) {
      setActivatingConnector(undefined);
    }
  }, [activatingConnector, connector]);

  useEffect(() => {
    if (account && active && library) {
      store.setStore({ account: { address: account }, web3context: context })
      emitter.emit(CONNECTION_CONNECTED)
    }
  }, [account, active, closeModal, context, library]);

  const [hoveredConnectorButtons, setHoveredConnectorButtons] = React.useState(new Map());
  const updateHoveredConnectorButtons = (k,v) => {
    setHoveredConnectorButtons(new Map(hoveredConnectorButtons.set(k,v)));
  }

  // useEffect(() => {
  //   if (storeContext && storeContext.active && !active) {
  //     console.log("we are deactive: "+storeContext.account)
  //     store.setStore({ account: {}, web3context: null })
  //   }
  // }, [active, storeContext]);

  // handle logic to eagerly connect to the injected ethereum provider, if it exists and has granted access already
  // const triedEager = useEagerConnect();

  // handle logic to connect in reaction to certain events on the injected ethereum provider, if it exists
  // useInactiveListener(!triedEager || !!activatingConnector);
  const width = window.innerWidth

  return (
    <div style={{ display: 'flex', flexWrap: 'wrap', justifyContent: (width > 650 ? 'space-between' : 'center'), alignItems: 'center' }}>
      {Object.keys(connectorsByName).map(name => {
        const currentConnector = connectorsByName[name];
        const activating = currentConnector === activatingConnector;
        const connected = (currentConnector === connector||currentConnector === localConnector);
        const disabled =
           !!activatingConnector || !!error;

        var url;
        var display = (hovered && connected) ? 'Disconnect' : name;
        if (name === 'OneWallet') {
          url = HarmonyLogo
        } else if (name === 'MathWallet') {
          url = MathWalletLogo
        }

        return (
          // UI to generate list of wallets
        )
      }) }

      // UI to disconnect active wallet
  )
}

For full reference implementations of Store, UnlockModal, Unlock, and WalletComponent:

• Store: https://github.com/harmony-one/token-faucet-demo-dapp/blob/main/ui/src/stores/index.jsx

• UnlockModal: https://github.com/harmony-one/token-faucet-demo-dapp/blob/main/ui/src/components/unlock/unlockModal.jsx

• Unlock: https://github.com/harmony-one/token-faucet-demo-dapp/blob/main/ui/src/components/unlock/index.jsx

• WalletComponent: https://github.com/harmony-one/token-faucet-demo-dapp/blob/main/ui/src/components/unlock/walletComponent.jsx

Getting historical data on a smart contract can be frustrating when building a dapp. The Graph provides an easy way to query smart contract data through APIs known as subgraphs. The Graph’s infrastructure relies on a decentralized network of indexers, enabling your dapp to become truly decentralized.

Harmony One is supported by The Graph.

Quick Start

These subgraphs only take a few minutes to set up. To get started, follow these three steps:

1. Initialize your subgraph project

2. Deploy & Publish

3. Query from your dapp

Here’s a step by step walk through:

1. Initialize your subgraph project

Create a subgraph on Subgraph Studio⁠

Go to the Subgraph Studio and connect your wallet. Once your wallet is connected, you can begin by clicking “Create a Subgraph”. When choosing a name, it is recommended to use Title Case: “Subgraph Name Chain Name.”

You will then land on your subgraph’s page. All the CLI commands you need will be visible on the right side of the page:

Install the Graph CLI⁠

On your local machine run the following:

npm install -g @graphprotocol/graph-cli

Initialize your Subgraph⁠

You can copy this directly from your subgraph page to include your specific subgraph slug:

graph init --studio <SUBGRAPH_SLUG>

You’ll be prompted to provide some info on your subgraph like this:

Simply have your contract verified on the block explorer and the CLI will automatically obtain the ABI and set up your subgraph. The default settings will generate an entity for each event.

2. Deploy & Publish

Deploy to Subgraph Studio⁠

First run these commands:

$ graph codegen
$ graph build

Then run these to authenticate and deploy your subgraph. You can copy these commands directly from your subgraph’s page in Studio to include your specific deploy key and subgraph slug:

$ graph auth --studio <DEPLOY_KEY>
$ graph deploy --studio <SUBGRAPH_SLUG>

You will be asked for a version label. You can enter something like v0.0.1, but you’re free to choose the format.

Test your subgraph⁠

You can test your subgraph by making a sample query in the playground section. The Details tab will show you an API endpoint. You can use that endpoint to test from your dapp.

Publish Your Subgraph to The Graph’s Decentralized Network

Once your subgraph is ready to be put into production, you can publish it to the decentralized network. On your subgraph’s page in Subgraph Studio, click on the Publish button:

Before you can query your subgraph, Indexers need to begin serving queries on it. In order to streamline this process, you can curate your own subgraph using GRT.

When publishing, you’ll see the option to curate your subgraph. As of May 2024, it is recommended that you curate your own subgraph with at least 3,000 GRT to ensure that it is indexed and available for querying as soon as possible.

Note: The Graph's smart contracts are all on Arbitrum One, even though your subgraph is indexing data from Ethereum, BSC or any other supported chain.

3. Query your Subgraph

Congratulations! You can now query your subgraph on the decentralized network!

For any subgraph on the decentralized network, you can start querying it by passing a GraphQL query into the subgraph’s query URL which can be found at the top of its Explorer page.

Here’s an example from the CryptoPunks Ethereum subgraph by Messari:

The query URL for this subgraph is:

https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK

Now, you simply need to fill in your own API Key to start sending GraphQL queries to this endpoint.

Getting your own API Key

In Subgraph Studio, you’ll see the “API Keys” menu at the top of the page. Here you can create API Keys.

Appendix

Sample Query

This query shows the most expensive CryptoPunks sold.

{
  trades(orderBy: priceETH, orderDirection: desc) {
    priceETH
    tokenId
  }
}

Passing this into the query URL returns this result:

{
  "data": {
    "trades": [
      {
        "priceETH": "124457.067524886018255505",
        "tokenId": "9998"
      },
      {
        "priceETH": "8000",
        "tokenId": "5822"
      },
//      ...

💡 Trivia: Looking at the top sales on [CryptoPunks website](https://cryptopunks.app/cryptopunks/topsales) it looks like the top sale is Punk #5822, not #9998. Why? Because they censor the flash-loan sale that happened.

Sample code

const axios = require('axios');

const graphqlQuery = `{
  trades(orderBy: priceETH, orderDirection: desc) {
    priceETH
    tokenId
  }
}`;
const queryUrl = 'https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK'

const graphQLRequest = {
  method: 'post',
  url: queryUrl,
  data: {
    query: graphqlQuery,
  },
};

// Send the GraphQL query
axios(graphQLRequest)
  .then((response) => {
    // Handle the response here
    const data = response.data.data
    console.log(data)

  })
  .catch((error) => {
    // Handle any errors
    console.error(error);
  });

Additional resources:

• To explore all the ways you can optimize & customize your subgraph for a better performance, read more about creating a subgraph here.

• For more information about querying data from your subgraph, read more here.

A quick guide on how to verify your contracts on Harmony.

Right now, we support verification only for one single solidity file - therefore, before deployment and verification, you will need to flatten all solidity sources to one file.

1. Flatten your solidity files (only for multiple files)

To flatten your solidity files we recommended to use

Or you can use any other flattener lib

2. Deploy contract to Harmony

To more easy verification we recommend to deploy contract with Harmony Remix

3. Verify contract

You can verify your contract here

Important to use correct params (the same like on deploy):

• Contract address

• Contract name

• Compiler version

• Optimizer

• Chain Type (mainnet or testnet)

• Sources

• Imported libs

Then click Submit button

If all parameters are correct - you should to see Success message, or Error if bytecodes don't equal

On Success case - you contract will verify and you will see all contract details on contract explorer page

4. Verify contract with constructor arguments (for contracts that were created with constructor parameters)

Example for Harmony Remix: