Custom Airdrop Eligibility Dashboard Development

Custom Airdrop Eligibility Dashboard Development

We build a dashboard that doesn't just show "eligible or not" but provides users with actionable steps to improve their score before the snapshot. It's a powerful retention tool: users see how many points they have, what actions they can still take, and how far they are from the next tier. Technically, it's an aggregator of data from multiple on-chain sources with caching—because a real on-chain query for every address on every visit would kill any RPC. Our experience—over five years in Web3 and 30+ successful projects—guarantees stability and scalability. Get a consultation to discuss the architecture for your protocol.

The dashboard not only displays status but also gives actionable recommendations: "You need two more votes on Snapshot and $500 in volume to reach the gold tier." This feedback increases user engagement and the likelihood of further participation in the ecosystem. We build in flexibility: scoring rules and tiers are configurable to fit any project's tokenomics.

How the Airdrop Eligibility Dashboard Works

Architecture: Data Sources

The Graph subgraph is the primary source for on-chain activity. The subgraph indexes contract events and provides a GraphQL API. Data for the dashboard:

query UserActivity($address: String!) { user(id: $address) { totalVolume transactionCount firstInteractionTimestamp liquidityProvisions { amount timestamp pool { id symbol } } referrals { count totalVolume } } } 

Queries to The Graph are free up to a limit, fast (<200ms), and don't burden RPC nodes.

The Snapshot.org API is used for tracking governance participation. We obtain the list of a user's votes in a given space. For on-chain balance checks, we use viem's multicall—it batches multiple calls into one RPC request:

import { createPublicClient, http } from 'viem' import { mainnet } from 'viem/chains' const client = createPublicClient({ chain: mainnet, transport: http() }) const results = await client.multicall({ contracts: [ { address: TOKEN_ADDRESS, abi: erc20Abi, functionName: 'balanceOf', args: [userAddress] }, { address: STAKING_ADDRESS, abi: stakingAbi, functionName: 'stakedAmount', args: [userAddress] }, { address: VESTING_ADDRESS, abi: vestingAbi, functionName: 'vestingInfo', args: [userAddress] }, ] }) 

One HTTP request instead of three—critical under high traffic. Saves up to 66% on RPC calls.

Scoring System and Criteria

Eligibility is usually multi-factor. A typical structure:

interface EligibilityScore { total: number breakdown: { volumeScore: number // 0-40 points: trading volume loyaltyScore: number // 0-20 points: first interaction date governanceScore: number // 0-20 points: Snapshot votes referralScore: number // 0-10 points: referred users holdingScore: number // 0-10 points: token holding } tier: 'bronze' | 'silver' | 'gold' | 'platinum' estimatedAllocation: bigint | null // null until announced missingCriteria: string[] } 

missingCriteria is the most useful part for the user. "You need two more Snapshot votes and $500 in volume for the next tier"—that's actionable information.

Backend: Caching and API

On-chain data doesn't change every second—caching is mandatory.

async function getUserEligibility(address: string): Promise<EligibilityScore> { const cacheKey = `eligibility:${address.toLowerCase()}` const cached = await redis.get(cacheKey) if (cached) return JSON.parse(cached) const [subgraphData, snapshotVotes, onchainBalances] = await Promise.all([ fetchSubgraphData(address), fetchSnapshotVotes(address), fetchOnchainBalances(address), ]) const score = calculateScore(subgraphData, snapshotVotes, onchainBalances) await redis.setex(cacheKey, 300, JSON.stringify(score)) return score } 

A TTL of 5 minutes is sufficient for most data. For snapshot data after the deadline, cache forever. This reduces RPC load and speeds up page loading.

Frontend: React Dashboard

The dashboard is built on React using wagmi and RainbowKit. The EligibilityDashboard component receives data via React Query, caches it on the client, and displays a tier progress bar, score breakdown, and list of missing criteria. Users see not only their current status but also the potential allocation (estimatedAllocation) if the airdrop has been announced.

Merkle Distribution and Claim

After the airdrop announcement—claim interface. Standard scheme: a MerkleDistributor contract, proof generated on the server:

import { StandardMerkleTree } from '@openzeppelin/merkle-tree' async function getMerkleProof(address: string): Promise<{ proof: string[], amount: bigint }> { const tree = await loadMerkleTree() const [index, [addr, amount]] = tree.entries().find(([, [a]]) => a.toLowerCase() === address.toLowerCase()) return { proof: tree.getProof(index), amount: BigInt(amount) } } 

On the frontend, the Claim button is activated if !isClaimed && proof !== null. After claiming, we display the tx hash and update the status via useWaitForTransactionReceipt. Contracts undergo auditing (Slither, Mythril, Echidna) and testing for reentrancy and flash loan attacks. Order dashboard development—we guarantee security and performance.

Why Order Dashboard Development from Us?

We don't just copy open-source solutions. Each dashboard is designed for a specific protocol: unique metrics, integrations with partner systems, tokenomics features. Our workflow includes:

Total from three to six weeks depending on complexity. We'll evaluate your project for free—just reach out.

What's Included?

• Backend API development with caching (Redis, Node.js/Python)
• Integration with The Graph, Snapshot, RPC (Ethereum, L2)
• Scoring system and tiers with custom rules
• Frontend dashboard (React, Next.js, wagmi, RainbowKit)
• Merkle distribution and claim interface
• Documentation and team training
• Post-launch support

Contact us to discuss your project. In 80% of cases, we offer a solution cheaper and faster than hiring a separate team. Get a consultation—and we'll select the optimal architecture for your budget.