When a project changes the snapshot time multiple times, the final airdrop eligibility calculation is usually based on the last officially announced snapshot time and rules, provided the project operates transparently. The snapshot essentially "freezes" the on-chain state at a specific block height, serving as the sole basis for later distribution. If changes occur, how on-chain eligibility is calculated depends on the following three situations.
Step 1: Confirm the Final Snapshot Time – Rules Generally Follow the Latest Announcement
This is the most straightforward case. If the project explicitly announces a "final snapshot time" or "final snapshot block height", the airdrop eligibility will be calculated based on the on-chain state at that moment.
What to do: Find the project's latest official announcement about the snapshot and confirm the final snapshot date and block height.
How to do it: Look for the most recent announcement containing words like "Snapshot", "Eligibility", or "Final" on the project's official blog, X (Twitter), or Discord channel.
Completion standard: Obtain a clear final snapshot time point. For example, Treehouse officially confirmed that S2 season airdrop eligibility is determined by the final snapshot block at 02:00 UTC on April 25, 2026. Platform-based events like Binance Super Earn also perform multiple random snapshots during the activity, but the total snapshot period is fixed.
Step 2: Determine if "Eligibility Changes" Are Involved – Pre-Snapshot Actions Can Affect Final Eligibility
Sometimes, a simple "time change" comes with an "eligibility change". Actions taken before or after the snapshot can both affect the final allocation.
What to do: Check whether the project has announced any changes to the "eligibility criteria" between two snapshots.
How to do it:
Case A: Holding required for a period before the snapshot (to prevent last-minute accumulation). Floki's airdrop rules state that addresses holding FLOKI tokens on the snapshot day are eligible, but if any tokens were transferred or sold during the snapshot window (August 22 to August 29), the address will be disqualified. In this case, only the final snapshot balance is considered, but the transaction history during the pre-snapshot window is reviewed.
Case B: Points, not token balance, determine eligibility. Renzo's airdrop rules emphasize that eligibility is determined by the ezPoints balance in the wallet at the snapshot time, not the ezETH balance. If a user stopped accumulating points before the snapshot, it could affect eligibility.
Case C: Eligibility depends on voting participation records. If a requirement was based on past "voting" or "governance participation" over a period, that condition is already closed at the time of the snapshot; any subsequent voting does not count.
Completion standard: You clearly know whether you need to meet a condition "at the snapshot state" or maintain certain behavioral conditions continuously before the snapshot.
Common Failure Reasons
The biggest risk is acting based on the first announced snapshot time while missing a later change to the final snapshot time. For example, the project initially says the snapshot is on May 1, so you add to your position on April 30, but then the project moves the snapshot earlier to April 25, making your extra funds completely wasted. The solution is: "consult the latest official announcement and trust only official channels".
Step 3: Dealing with Complex "Front-Running Style" Rules – Eligibility and Allocation May Be Calculated Separately
Some complex projects design multi-stage snapshots and weighted rules, where on-chain eligibility is the result of a specific formula.
What to do: Check whether the rules involve complex calculations like "eligibility condition" + "base allocation" + "multiplier".
How to do it: Certain complex projects (e.g., zkSync) use an "Eligibility → Base Allocation → Multiplier" model for airdrop rules. The snapshot is mainly used to calculate the "base allocation" (such as time-weighted average balance), but the "multiplier" may depend on whether specific NFTs were held or specific protocols were used at the snapshot time. Rules are often opaque and can easily benefit "front-running". In this case, eligibility is calculated based on the data at the last snapshot, but your final allocation may be the result of combining data and weights from multiple snapshots.
Completion standard: You understand whether your airdrop allocation "depends only on the last snapshot data" or "requires meeting multiple conditions to trigger multipliers".
Verification Methods After the Operation
The most crucial step is to obtain "evidence" at the moment of the final snapshot. If you still held a position or points at the final snapshot time, your eligibility for the final allocation should already be locked in. You can:
Keep on-chain records: Save the transaction hash (TxID) of interactions with the protocol around the snapshot time.
Screenshot the official announcement: Save a screenshot of the official announcement showing the final snapshot time.
Check the official eligibility page: If the project provides an eligibility check page (usually opens before TGE), enter your wallet address to confirm.
Next Steps
After the snapshot, on-chain operations usually no longer affect the already-determined eligibility and base allocation. You can then decide whether to continue interacting. If the project announces a "second snapshot" or "rule update" after the snapshot, go back to "Step 1" and reassess. If you continue heavy interactions after the snapshot but the rules only count the last snapshot, those new interactions might be invalid.
