What is a token claim portal?
A token claim portal is a branded web page, on your own domain, where eligible holders claim tokens you owe them, with eligibility settled on-chain. It replaces a manual bulk send with a self-serve flow: you publish who is eligible, and each holder connects a wallet and claims their own allocation. The eligibility check happens in the smart contract, so the page cannot hand out tokens to a wallet that was not on the list.
You use a claim portal whenever you owe tokens to many wallets at once: an airdrop, a public sale delivery, a rewards payout, or a vesting unlock. The alternative, pushing tokens to every address yourself, is slower, far more expensive in gas, and turns one fat-fingered list into an irreversible mistake. A claim portal makes the distribution auditable and lets holders verify their own allocation before they sign.
How does a token claim portal work?
A token claim portal works by committing the eligibility list on-chain, then letting each holder prove they belong to it. There are two standard methods. A Merkle claim hashes the full list of address and amount pairs into a tree and stores only the 32-byte root in the contract; each claimer submits a short proof that their leaf is in that tree. A signature claim has a trusted backend sign each eligible claim off-chain, and the contract verifies the signature with ECDSA at claim time.
Both are pull-based: the holder sends the claim transaction and pays its gas, and the contract releases tokens only if the proof or signature checks out. The Merkle approach is the on-chain default because the list itself never has to go on-chain. OpenZeppelin's MerkleProof library is the widely used building block for verifying these proofs, and a proof grows only as about log2(n) hashes, so a list of a million wallets needs a proof of roughly twenty hashes.
Merkle claim vs signature claim: which should you use?
Use a Merkle claim when the eligibility list is fixed at launch, and a signature claim when eligibility is dynamic or decided at claim time. A Merkle tree is fully on-chain-verifiable and needs no live server once deployed, which makes it the safer default for a one-shot airdrop or sale delivery. A signature scheme is more flexible for rolling eligibility, but it depends on a signer key you must keep secure, because anyone who steals that key can mint valid claims.
| Merkle claim | Signature claim | |
|---|---|---|
| Eligibility set | Fixed at deploy | Can change over time |
| Trust assumption | Trustless after deploy | Trusts an off-chain signer key |
| Live backend needed | No | Yes, to sign claims |
| Proof on-chain cost | Proof of about log2(n) hashes | One signature check (ECDSA) |
| Best for | Airdrops, sale deliveries, fixed lists | Rolling rewards, gated or conditional claims |
For most token distributions the Merkle claim wins on simplicity and on having no key to lose. Reserve signatures for cases where you genuinely cannot fix the list in advance.
How do you make a token claim safe?
You make a token claim safe by enforcing every rule in the contract and failing closed. The portal interface is a convenience; the contract is the source of truth. That means three checks live on-chain: the wallet is eligible (valid Merkle proof or signature), the allocation has not already been claimed, and the claim window is open. If any check fails, the transaction reverts and no tokens move.
Beyond the access checks, a safe claim contract uses an audited token-transfer path such as OpenZeppelin's SafeERC20, follows the checks-effects-interactions pattern to block reentrancy, and marks an allocation as claimed before it sends tokens. It should also be auditable: claims emit events so anyone can reconcile what was distributed against the original list. Saleium's claim contracts are part of the same CertiK-audited stack behind ChainGPT Pad, which has settled 50 IDOs and $12.7M raised.
What does a token claim cost in gas?
A token claim costs the holder one transaction, and it costs the issuer almost nothing per recipient. This is the structural advantage of a claim portal over a push distribution. In a push, you pay gas for every transfer, so a 100,000-wallet airdrop is 100,000 transfers you fund. In a pull, you deploy one contract and fund the token balance; each holder pays for their own claim, and wallets that never claim cost you nothing further.
The on-chain work of a Merkle claim is small: verify a proof of about log2(n) hashes, check the claimed flag, and transfer the tokens. Because proof size grows logarithmically, the per-claim cost barely changes whether your list has a thousand wallets or a million. That predictability is why exchanges and large protocols default to claim contracts for big distributions.
How do you handle unclaimed tokens and a claim deadline?
You handle unclaimed tokens by setting a claim deadline up front and giving the project a way to sweep the remainder afterward. Partial claims are normal, not a failure. When Uniswap made 400 UNI claimable by 251,534 historical addresses in September 2020, Dune Analytics found 90.8% claimed within the first month, yet roughly 30,000 wallets still had not claimed more than two years later. Optimism's first airdrop reached 248,699 eligible addresses and also saw a meaningful share go unclaimed.
So plan for leftovers. Announce the claim window clearly, remind holders before it closes, and use a contract that lets you reclaim unclaimed tokens to a treasury after the deadline rather than stranding them forever. If you want claimed tokens to keep unlocking over time instead of releasing all at once, pair the claim with a vesting schedule.
How do you stop Sybil and bot claims?
You stop Sybil claims before the list is finalized, not at claim time. Because eligibility is committed in the Merkle root or signed by your backend, the filtering happens when you build the list: deduplicate wallets, apply on-chain activity thresholds, and remove addresses that look like one actor splitting across many wallets. The contract then only honors the wallets you kept.
This step is now standard practice. Before distributing ZRO, LayerZero removed 803,273 wallets, about 59% of applicants, as Sybil. You do not need that scale of filtering for a project airdrop, but the principle holds: a claim portal is only as fair as the eligibility list behind it, so spend your effort there. Combine snapshot rules, allowlists, and optional KYC for regulated sales.
How do claim portals handle vesting, cliffs and linear unlocks?
Claim portals handle vesting by releasing only the amount that has unlocked at the moment of each claim. Instead of claiming the full allocation once, a holder claims what has vested so far and returns later for more. The contract tracks the schedule: nothing during the cliff, then a linear or monthly release until the allocation is fully unlocked.
This matters for sales, team and investor allocations, and long-tail rewards, where dumping the entire supply at once would crater the price. Combining an allowlist claim with on-chain vesting in one branded flow keeps the holder experience simple while the unlock rules stay enforced by the contract. See how on-chain token vesting models cliffs and linear schedules, or read token vesting 101 for the full picture, if you need the allocation to release gradually.
What makes a token claim smooth for holders?
A smooth token claim removes every reason a holder would hesitate before signing. The portal should detect the wallet's current network and offer a one-tap switch to the right chain, show the exact allocation and its claim status before the user commits, and give a clear confirmation with a transaction link afterward. Holders should never have to guess whether they are eligible or whether the claim went through.
Trust signals matter as much as mechanics. Holders are wary of claim links because phishing sites imitate them, so running the portal on your own domain, under your own brand, with a verifiable contract address, is part of what makes a claim feel safe to complete. A branded claim portal on your own domain reads as legitimate in a way a random link never will.
Token claim portal checklist before you go live
Run this checklist before opening claims:
- Finalize and Sybil-filter the eligibility list, then freeze it.
- Commit the list as a Merkle root, or wire a secured signer for dynamic claims.
- Deploy the audited claim contract on the chain your token lives on.
- Fund the contract with the full claimable balance.
- Set and publish the claim deadline and the unclaimed-token sweep path.
- If allocations should release over time, attach the vesting schedule.
- Verify the contract and publish its address so holders can check it.
- Test a real claim end to end, including the already-claimed and wrong-network reverts.
- Brand the portal on your own domain and announce the verified link widely.
Get the eligibility list and the fail-closed contract right, and the rest of a token launch follows. A claim portal is the safest, cheapest way to put tokens in the right hands at scale, and it is one line on the full crypto launchpad checklist.