# Front End Integration This guide walks through integrating a frontend application with the verification-gated airdrop contracts deployed in the previous step. The goal is to connect a wallet-based UI to the **MockAirdropProtocol** contract so users can: * Connect their wallet * Request Humanity verification (when needed) * Claim tokens exactly once after verification > This guide explains the integration flow. > > For full setup commands, monorepo structure, and UI details, refer to the frontend repository README. > > ## What you will build By completing this section, you will: * Configure the frontend to target your deployed contracts * Connect the dApp to Humanity networks * Enable the verification → claim user flow * Run the application locally or deploy it to production ## Frontend responsibilities The frontend is responsible for **orchestrating user actions**, not enforcing rules. On-chain enforcement is handled entirely by the contracts. The frontend must: * Connect user wallets * Read verification and eligibility state from the blockchain * Trigger verification and claim transactions * Provide clear UX feedback for each step Let's begin by installing our Front End dApp project ```bash git clone https://github.com/humanity-developers/verification-airdrop-dapp cd verification-airdrop-dapp && bun install ``` Then let's configure our .env file ```bash # Required - WalletConnect Project ID # Get yours at https://cloud.walletconnect.com/ VITE_WALLETCONNECT_PROJECT_ID=your_project_id_here # Required - Network Configuration # --------------------------------------------------------- # Testnet: # Chain ID: 7080969 # RPC URL: https://humanity-testnet.g.alchemy.com/public # # Mainnet: # Chain ID: 6985385 # RPC URL: https://humanity-mainnet.g.alchemy.com/public # --------------------------------------------------------- VITE_CHAIN_ID=7080969 VITE_RPC_URL=https://humanity-testnet.g.alchemy.com/public # Required - Contract Addresses VITE_AIRDROP_CONTRACT_ADDRESS=0x... VITE_TOKEN_CONTRACT_ADDRESS=0x... ``` ## Inputs required from the on-chain setup Before starting, make sure you have the following values from the **Smart Contracts Setup** step: * `AIRDROP_CONTRACT_ADDRESS` * `TOKEN_CONTRACT_ADDRESS` * `CHAIN_ID` * `RPC_URL` * `VITE_WALLETCONNECT_PROJECT` (get it from ) These values are injected into the frontend via environment variables. ### Step 1 — Configure network and contracts The frontend is chain-agnostic and configured entirely through environment variables. You will set: * Target network (testnet or mainnet) * RPC endpoint * Deployed contract addresses Why this matters: * The frontend never “discovers” contracts automatically * Explicit configuration avoids accidental interaction with the wrong network * Makes switching environments trivial > ℹ️ Only variables prefixed with VITE\_ are exposed to the client. We can now fire up our application by running ```bash bun dev ``` Our application should be visible at **** ### Step 2 — Wallet connection and network handling The dApp uses modern Web3 tooling to handle wallet interactions: * Wallet connection (MetaMask, WalletConnect, etc.) * Network detection and switching * Transaction signing and submission From the user’s perspective: 1. User opens the app 2. Connects a wallet 3. Is prompted to switch networks if needed Why this matters: * Verification and claims only work on the correct chain * Network mismatches are the most common source of UX friction ### Step 3 — Reading verification & eligibility state Once a wallet is connected, the frontend queries the airdrop contract to determine: * Whether the user is already verified * Whether the user has already claimed * Whether verification is required | Contract state | UI behavior | | -------------- | ------------------------------ | | Not verified | Show “Verify” action | | Verified | Show “Claim” action | | Claimed | Disable actions / show success | Why this matters: * Users should never submit transactions that will revert * Clear state-driven UI reduces failed transactions ### Step 4 — Triggering verification If the user is not yet verified: * The frontend sends a transaction to the airdrop contract * The contract forwards the request to the Humanity Verification Oracle * Verification fees are paid from the Fee Escrow (not the user) Important UX notes: * The frontend should: * Show pending state * Allow users to re-check status * Avoid duplicate requests > 💡 In production systems, you may complement this with off-chain indexing or notifications. ### Step 5 — Claiming the airdrop Once verification is confirmed: * The frontend enables the **Claim** action * User submits a transaction to the airdrop contract * Tokens are transferred directly to the user’s wallet On-chain guarantees: * Each address can only claim once * Claims revert if verification is missing * Claims revert if the contract is out of tokens ## Local development flow Typical local workflow: 1. Configure environment variables 2. Start the frontend dev server 3. Connect a testnet wallet 4. Walk through verify → claim flow 5. Inspect transactions in the block explorer This allows you to validate: * Wallet UX * Network configuration * Contract integration * Verification logic ## Deployment options The frontend is a static web application and can be deployed to: * Vercel (recommended) * Netlify * Cloudflare Pages * Any static hosting provider Deployment requires: * Setting the same environment variables used locally * Ensuring the target chain RPC is accessible from the browser ## Common integration pitfalls * **Wrong contract address** Always double-check proxy addresses, not implementation addresses. * **Wrong chain ID** Wallet may connect successfully but transactions will fail. * **Insufficient escrow funding** Verification requests will fail if the Fee Escrow is empty. * **Airdrop contract not funded** Claims will revert if token balance is zero. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.humanity.org/developer-guides-and-tutorials/on-chain-guides/verified-airdrop-dapp-reference-implementation/front-end-integration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.