Introduction

​

Overview

​

Key Features

1. Chain Selection:
   • Choose a blockchain network (e.g., Ethereum, Polygon, or Binance Smart Chain).
   • For unsupported networks or private chains, use Customized RPC.

2. Contract ABI and Address:
   • Provide the smart contract’s ABI (Application Binary Interface).
   • Specify the contract address where the query will be sent.
3. Method Selection:
   • Choose the specific method to call from the contract’s ABI.
   • Pass the user’s wallet address as a parameter.
4. Snapshot Feature:
   • Use the Snapshot feature to lock the query at a specific block height, ensuring data consistency.
5. Real-Time Testing:
   • Use the Test Response section to send test queries and validate the results.

​

Workflow

1. Define Credential Title:
   • Enter a descriptive title to clearly indicate the purpose of the credential.
2. Choose Blockchain Network:
   • Select a supported chain or provide a customized RPC endpoint.
3. Provide Contract Details:
   • Input the target smart contract’s address and paste its ABI.
   • Select the method to call and define relevant parameters.
4. Test Configuration:
   • Simulate the query using a test address and confirm the response meets expectations.
5. Deploy and Use:
   • Save and integrate the credential into your campaign to verify user eligibility based on on-chain data.

​

Contract Method Requirements

1. stateMutability: view
   • Requirement: The method must be declared as view.
   • Reason: Galxe only calls read-only methods, which do not modify the blockchain state.
   • Use Case: Retrieve on-chain data like token balances, NFT ownership, or staking status.
   • Advantage: No gas fee required for direct calls (off-chain queries only).
2. type: function
   • Requirement: The method must be a standard callable function (function).
   • Reason: Galxe queries functions via ABI and only supports standard function types.
   • Note: Constructors or other special function types are not supported.
3. input: address
   • Requirement: The method must accept an address (address) as a dynamic input parameter.
   • Use Case: The address typically identifies the user’s wallet, a smart contract, or the owner of an asset.
   • Functionality: This parameter allows Galxe to query specific address-related data or validate logic.

{
  "constant": true,
  "inputs": [
    {
      "name": "<parameter_name>",
      "type": "address"
    }
  ],
  "name": "balanceOf",
  "outputs": [
    {
      "name": "<output_name>",
      "type": "uint256"
    }
  ],
  "stateMutability": "view",
  "type": "function"
}

​

Example Use Cases

• NFT Ownership Verification:
  • Use the balanceOf method in ERC-721 contracts to verify if a user holds a specific NFT.
• Token Holding Requirements:
  • Use the balanceOf method in ERC-20 contracts to verify if a user holds a certain amount of tokens.

• Custom Logic:
  • Check for more complex conditions, such as staking, governance participation, or other contract interactions.

​

Notes

• Snapshot Feature: Execute queries at a specific block height, useful for checking data at a specific point in time.

• Testing: Always validate your setup in the “Test Response” section before deployment.
• RPC Configuration: Ensure the selected chain or RPC endpoint is reliable, accessible, and compliant with Galxe’s CORS Check standards.