Airdrop Says Eligible but You Cannot Claim: 12 Troubleshooting Steps

Quick answer: If an airdrop checker says you are eligible but the claim will not go through, there is rarely one universal cause. Common failures include connecting the wrong address, using the wrong network or RPC, claiming outside the official window, relying on outdated points or pool rules, a broken wallet session, insufficient gas, a transaction stuck pending, a contract revert, or confusing “claimable” with “unlocked and tradable.” Troubleshoot in this order: official source → eligibility → wallet → network → front end → transaction → contract → vesting.

Security warning: Do not trust anyone who slides into your Discord DMs after you post that your claim is broken. A real moderator does not need your seed phrase, private key, wallet JSON, remote-desktop access, or a screen share. Treat every “sync wallet,” “validate assets,” “activate claim,” or “fix eligibility” link as phishing until independently verified.

Why Can an Eligible Wallet Still Fail to Claim?

“Eligible” only means an eligibility system believes an address meets a particular set of conditions. It does not prove that the claim contract is currently executable or that tokens should immediately appear in the wallet. The eligibility checker, claim front end, distribution contract, vesting contract, and token liquidity are separate layers. A mismatch in address, network, time, rules, or contract state at any layer can create an “eligible but cannot claim” result.

For example, the checker may be reading an old snapshot or cached response while the contract is paused. You may have checked Address A but connected Account B. A legacy liquidity pool may no longer earn points. Tokens may already sit in a vesting contract but have not reached their unlock date. The claim transaction may even have succeeded while the wallet simply failed to display the token.

What We Found in Chinese-Language Web3 Discord Communities

In August 2026, this project reviewed publicly visible discussions in several Chinese-language Web3 Discord communities. The additional sample dated August 14, 2026 included 0xFORCE Club, ETHTaipei, Almanak, and Saturn. The research covered public channels, official announcements, and visible user reports only; no private or paid channels were accessed.

Almanak’s Chinese channel contained several real-world claim complaints: users reported being unable to claim an allocation earned through staking COOKIE, failing to create a wallet, seeing assets remain locked after the expected date, being unable to find the withdrawal flow, and receiving tokens they could not sell. One user also reported receiving at least five unsolicited DMs after asking for help publicly—a familiar pattern in which fake support accounts swarm anyone who posts “claim not working.”

The Saturn sample showed how rule changes can break assumptions about eligibility. The project repeatedly warned that an older USDC/sUSDat Curve pool had stopped earning points and LPs needed to migrate to a new FXSwap pool. An old points screenshot or outdated farming guide may still look convincing, but it does not prove that a wallet meets the final distribution rules.

Research takeaway: an Eligible badge is the start of the investigation, not proof of payment. The actual outcome depends on current rules, the correct address, the correct network, the claim window, contract state, and transaction execution.

Start With the Symptom: What Kind of Claim Failure Is This?

12 Troubleshooting Steps for an Airdrop That Will Not Claim

Step 1: Verify the Claim Page Through Official Sources

Before connecting a wallet or signing anything else, confirm that you are on the real claim portal. Do not enter from a Discord DM, search ad, forwarded group message, shortened URL, or a stranger’s “claim repair” tutorial.

Use a three-source check:

1. Does the project’s official website link directly to the claim page?
2. Does the official X account or Discord announcement channel publish the same domain?
3. Do the domain, subdomain, HTTPS status, and spelling match exactly?

Discord advises users not to click suspicious links from unknown senders, run unfamiliar code or software, or scan unverified QR codes. Users can also restrict DMs from server members. See Discord’s scam-prevention guidance.

Stop immediately if: the page asks for a seed phrase or private key, tells you to download a “claim fixer,” asks you to run a terminal command, disable security software, share your screen, or pay an activation fee, tax, or deposit.

Step 2: Save Evidence Before Retrying

Do not mash refresh and sign the same request repeatedly. Capture the current state first. The front end may update, the campaign may close, or a Discord post may be edited or deleted.

Record at least:

• the public wallet address;
• the full claim-page URL;
• a screenshot of eligibility and displayed allocation;
• local time and UTC time;
• network name and Chain ID;
• wallet, extension, and browser versions;
• the exact error message;
• the transaction hash if one exists.

Redact seed phrases, private keys, cookies, login tokens, API keys, and personal identity data. In a team environment, dedicated browser profiles and operation logs can show who used which public address, on which chain, and at what time without exposing secret material.

Step 3: Compare the Eligible Address With the Connected Address

This is one of the most common and most overlooked causes. A wallet extension may contain several accounts, and one recovery phrase may derive many addresses. Checking eligibility with Address A does not mean the claim page is currently connected to Address A.

Compare at least the first six and last six characters. Do not rely on an ENS name, wallet label, or avatar. Also check:

• whether eligibility belongs to an EVM, Solana, or other-chain address;
• whether activity came from a Safe, multisig, smart account, or proxy address;
• whether the eligible address and recipient address are intentionally different;
• whether a hardware wallet is using the correct derivation path;
• whether the dApp actually has permission to access the right account.

MetaMask lets users choose the accounts and networks a dApp may access. “Wallet connected” does not automatically mean “correct account authorized.” See the MetaMask dApp connection guide.

Step 4: Confirm the Network, Chain ID, Gas Token, and RPC

An eligibility checker may read Ethereum data while the actual claim takes place on Arbitrum, Base, Optimism, BNB Chain, Solana, or a project-specific network. On the wrong network, the button may remain disabled, balances may look wrong, or the wallet may fail to construct the intended transaction.

Check in this order:

1. the claim network named in the official announcement;
2. the network currently enabled for that specific claim dApp;
3. the Chain ID against official documentation;
4. whether the RPC is responsive and synced to the latest blocks;
5. whether the wallet holds the native gas token on that network.

MetaMask now manages network connections per dApp, so different dApps can use different networks at the same time. Check the network assigned to the claim dApp rather than relying only on the wallet’s portfolio view. See MetaMask’s network-switching guide.

Step 5: Recheck the Snapshot, Points Rules, Sybil Results, and Migration Requirements

Do not rely on an old influencer thread, a historical points screenshot, or a farming spreadsheet that has not been updated. Read the latest official announcement and check whether the project changed:

• the snapshot date or block;
• minimum points, volume, active months, or identity requirements;
• regional restrictions, address-type exclusions, or disallowed activity;
• the final Sybil, bot, or sanctions-screening result;
• whether an old pool, contract, NFT, or quest stopped earning points;
• whether users must migrate, bind an identity, submit proof, or complete another verification;
• whether the checker still shows cached data while the back end or contract has been updated.

In the Saturn sample from our Discord research, an older Curve pool stopped earning points and users had to migrate to a new pool. “I had points earlier” and “I meet the final distribution criteria” are not the same statement.

If the project offers an appeal window, read the appeal rules and submit verifiable evidence. Do not pay strangers for “Sybil removal,” “manual whitelist insertion,” or an “inside appeal channel.”

Step 6: Check the Claim Window, Timezone, Campaign Status, and Pause State

A disabled Claim button may simply mean the time condition is not satisfied. Confirm:

• the official start and end time;
• whether the project uses UTC, local time, or another timezone;
• whether claiming opens by role, batch, season, or address cohort;
• whether preregistration, KYC, terms acceptance, or delegation is required;
• whether the project temporarily paused the contract or front end;
• what happens to unclaimed tokens after the deadline.

Do not let a countdown timer create artificial urgency. A genuine emergency announcement should be verifiable across the website, official social account, and announcement channel—not only in a DM from a self-proclaimed moderator.

Step 7: Separate Eligibility, Claim, Distribution, Vesting, Unlock, and Trading

Many “claim failed” reports are actually users collapsing five different stages into one:

If the page says Claimed but no spendable balance appears, inspect Token Transfers, internal transactions, vesting-contract balances, and the recipient address on the block explorer. If tokens arrived but cannot be sold, confirm that transfers are enabled, a legitimate pool exists, liquidity is sufficient, and the token contract does not restrict transfers.

Step 8: Make Sure the Wallet Has Enough Native Gas

Having a large stablecoin balance does not mean the wallet has gas. Ethereum requires ETH; Arbitrum and Base generally use ETH; BNB Chain uses BNB; other networks may use their own native assets. A low gas balance can prevent submission or cause the wallet simulation to fail.

Check that:

• the gas token is on the correct chain, not a similarly named asset elsewhere;
• the balance includes a reasonable buffer above the estimate;
• you have not manually lowered the gas limit;
• you are not submitting multiple identical claims during congestion;
• a supposedly gasless claim still has a functioning relayer or sponsor.

Etherscan explains that an out-of-gas transaction does not complete the intended state change, while the gas already consumed is still charged. See Etherscan’s failed-transaction guide.

Step 9: Rebuild the Wallet-to-dApp Session

If clicking Claim produces no wallet popup, or the page keeps reading the wrong address, treat it as a session problem first:

1. close other claim tabs connected to the same wallet;
2. disconnect the dApp inside the wallet;
3. reopen the official claim page;
4. authorize only the correct account and network;
5. disable unnecessary extensions, script modifiers, or aggressive blockers;
6. if needed, test in a clean, dedicated browser profile.

Do not re-enter a seed phrase to “repair” a connection. Use an already verified wallet extension or hardware wallet in a clean browser environment with the minimum necessary extensions.

For users tracking many campaigns, a profile manager such as MostLogin can separate wallet extensions, cookies, Local Storage, bookmarks, and project sessions, reducing account mix-ups and stale-session contamination. It cannot change on-chain eligibility or bypass anti-Sybil rules.

Step 10: Separate Front-End, RPC, and Contract Failures

The key decision point is simple: Did the Claim action generate a TxHash?

• No TxHash: the failure is more likely in the front end, wallet connection, account/network permissions, signature flow, RPC request, or transaction construction.
• TxHash exists: the transaction was broadcast. Move to the block explorer and inspect Pending, Failed, Reverted, Dropped, or Success.

If there is no TxHash, try the following without exposing sensitive information:

1. check the project status page and announcement channel for a front-end outage;
2. switch to another officially supported RPC;
3. retry from a clean browser profile;
4. check whether VPN, proxy, DNS, or regional restrictions block the API;
5. record non-sensitive browser-console errors without sharing cookies or tokens.

MetaMask notes that blockchain-provider connectivity may occasionally become intermittent. Users can wait, connect to another trusted provider, or use another client. See the MetaMask RPC connectivity guide.

Do not call a Claim function directly through a block explorer unless the project’s official documentation provides the verified contract, function, parameters, and exact procedure. Many claims require a Merkle proof, signature, index, and precise amount. Guessing parameters can keep failing, while interacting with a fake contract can put assets at risk.

Step 11: Use the TxHash to Read Pending, Dropped, Reverted, or Success

A transaction hash is the most useful piece of on-chain troubleshooting evidence. Paste it into the official block explorer for the correct network.

Pending

Common causes include a low fee, network congestion, or an older pending nonce blocking the queue. MetaMask recommends closing and reopening the browser first. If the transaction is genuinely pending on-chain, the wallet’s Speed Up or Cancel controls may help. When several transactions are pending, resolve the lowest nonce—the oldest transaction—first. See MetaMask’s pending-transaction guide.

Dropped or Dropped & Replaced

A node may remove a low-fee transaction from its mempool, or a new transaction from the same address with the same nonce may replace it. Etherscan notes that once a replacement using the same nonce confirms, the earlier transaction can appear as Dropped & Replaced. See Etherscan’s explanation.

Failed or Reverted

Reverted means the contract execution did not complete and state changes were rolled back, although gas is usually still spent. Possible causes include:

• the address is not in the final Merkle root;
• the allocation, proof, index, or signature is invalid;
• the allocation was already claimed;
• the claim contract is paused or expired;
• another registration, approval, or unlock step is required first;
• the contract lacks tokens or a business condition is not satisfied;
• the gas limit is insufficient.

The explorer may show a project-defined revert reason. MetaMask also recommends inspecting failed contract transactions through the correct network’s block explorer. See the MetaMask smart-contract failure guide.

Success

Success means the transaction was written on-chain. It does not automatically mean a liquid token should appear in the wallet. Check:

• the actual recipient in Token Transfers;
• the token contract address and decimals;
• whether the call registered a claim instead of transferring tokens;
• whether tokens went to a vesting, staking, or proxy contract;
• whether the wallet needs the token imported manually;
• whether another Unlock or Withdraw step exists.

An on-chain Success is final and cannot be reversed through the wallet. Do not call Claim again just because the token is missing from the UI.

Step 12: Open an Official Ticket With the Minimum Necessary Evidence

If the issue remains after the first 11 steps, use the ticket system linked from the project website, official documentation, or announcement channel. Do not reply to a “moderator” who contacted you first.

A useful support ticket should contain:

Issue: Eligibility checker says Eligible, but Claim fails
Public address: 0x...
Network and Chain ID: ...
Claim-page URL: ...
Time observed: YYYY-MM-DD HH:MM UTC
Wallet and version: ...
Browser and version: ...
Exact error text: ...
TxHash: include it if available; otherwise write “No TxHash generated”
Already tried: address check, network switch, reconnect, gas check, announcement review
Attachments: redacted screenshots

Never submit a seed phrase, private key, wallet password, cookie, Discord token, remote-access credential, or full identity document. If anyone claims the issue cannot be fixed without your seed phrase, stop communicating, preserve evidence, and report the account.

What Should You Never Do When a Claim Fails?

• Do not keep signing transactions or messages you do not understand.
• Do not send significant additional assets into the affected wallet.
• Do not open “fix,” “sync,” or “verify” links from Discord DMs.
• Do not install unknown plugins, scripts, or remote-access tools.
• Do not import a seed phrase into another web wallet.
• Do not skip domain and contract verification because of a countdown.
• Do not confuse Claimed with Unlocked or Tradable.
• Do not automate repeated calls to a failing claim contract.

Airdrop Claim Troubleshooting Checklist

1. The official domain and announcement were cross-checked.
2. Eligibility, time, and error evidence were saved.
3. The eligible address exactly matches the connected address.
4. Network, Chain ID, RPC, and gas token are correct.
5. Final snapshot, points, migration, and Sybil rules were reviewed.
6. Claim window, timezone, and pause status were confirmed.
7. Claim, vesting, unlock, and trading were separated.
8. The wallet has enough native gas.
9. The dApp session was rebuilt in a clean environment.
10. The problem was classified as front end, RPC, or contract.
11. TxHash status and revert reason were inspected.
12. Only an official ticket received redacted evidence.

Frequently Asked Questions

Why does the eligibility page say Eligible while the contract says Not Eligible?

The eligibility page may use an old snapshot, cached data, or a different rule version, while the claim contract relies on the final Merkle root or a back-end signature. Other causes include a mismatched connected address, final Sybil filtering, an incomplete pool migration, or a claim batch that has not opened. Use the latest official announcement, verified contract state, and official support response.

What does it mean if clicking Claim produces no TxHash?

No TxHash usually means the transaction never reached the network. The failure is more likely in the front end, wallet connection, account/network permissions, signature flow, RPC, or transaction construction. Reconnecting the correct account and network is more useful than refreshing a block explorer.

Why does the wallet say there is not enough gas when it holds stablecoins?

Most networks require their native asset for gas. Ethereum, Arbitrum, and Base generally use ETH, while BNB Chain uses BNB. Stablecoins do not automatically replace the native gas token, and the asset must be on the correct network.

The transaction succeeded, but the token is missing. What should I do?

Inspect Token Transfers, the recipient address, and the token contract on the block explorer. If tokens reached the wallet, they may need to be imported using the official contract address. If they entered a vesting or staking contract, review the unlock and withdrawal rules. Never copy a token address from an unsolicited message.

Can I call the Claim Contract directly through a block explorer?

Only when official documentation provides the verified contract, function, parameters, and exact steps. Many claims require a Merkle proof, signature, index, or precise allocation. Guessing inputs can waste gas and interacting with a fake contract can compromise assets.

The unlock date passed. Why can I not withdraw?

The displayed date may be the start of a vesting cliff rather than the full release date. A project may unlock by epoch, block time, or a linear schedule. Check the vesting contract’s claimable amount, next unlock time, timezone, and withdrawal conditions.

Can MostLogin fix a failed airdrop claim?

MostLogin can isolate wallet extensions, cookies, Local Storage, proxies, and project sessions, helping rule out account mix-ups and contaminated browser state. It cannot change on-chain eligibility, unlock vested tokens, repair a project contract, or bypass anti-Sybil rules.

Conclusion

When a wallet is eligible but cannot claim, the most dangerous failure is often not technical—it is trusting a fake moderator while stressed. Verify official sources and preserve evidence first. Then work through the address, network, rules, timing, session, RPC, gas, TxHash, and contract state until the failure is narrow enough to prove.

If you manage several airdrop campaigns, keep a dedicated browser profile for each project and track its official domain, wallet address, network, snapshot, claim window, TxHash, vesting schedule, and ticket status. The goal is to reduce operator mistakes and preserve a clean audit trail—not to impersonate independent users.

Related guides: Discord airdrop scam prevention and official-link verification, proxy, WebRTC, and DNS checks, and MostLogin for airdrop research workflows.