Airdrop Snapshot: What It Is, Why the Date Is Hidden, What If You Missed It

An airdrop snapshot is the moment a project «photographs» the blockchain and decides whose activity counts. Everything that happened before that block goes into the calculation; everything after does not. To understand what a crypto snapshot is and why it attracts so many rumors, it helps to separate three things: the mechanics of freezing data, the project's policy on announcing the date, and how all of that affects what you do.

This article explains how snapshots work technically and organizationally. It does not predict dates for specific projects and does not guarantee that being included in a snapshot means an allocation. Not financial or legal advice.

What a snapshot is

Technically, a snapshot is the state of the blockchain at a specific block height. The project picks a block number (or a timestamp tied to one) and exports all the data it needs for the calculation: balances, transaction history, contract interactions, pool positions. That data is then processed off-chain: criteria are applied, allocations are computed, Sybil clusters are filtered out.

Importantly, a snapshot is not an on-chain action you could notice. The blockchain stores its entire history, so a project can «take a snapshot» retroactively at any time — simply pull the data at a block from a week ago. Hence the first rule: if a snapshot has been announced, it has already happened, and your position in it can no longer change.

There are also non-block snapshots: for off-chain activity (points, tasks, testnets) the project freezes the state of its own database as of a certain date. The mechanics are the same — a boundary after which actions no longer count.

Why the date is not announced

Projects almost never announce the snapshot date in advance, and there is a rational reason. If the date is known, activity concentrates in the final days before it: wallets show up, do the bare minimum, and disappear. Such a snapshot captures not users but a queue for the reward.

A hidden date makes natural activity more valuable than tuned activity. Someone who uses the product regularly will be in any snapshot. Someone waiting for a signal to make three transactions risks missing it or being filtered for «living only during the campaign» — a pattern covered in detail in the article on Sybil filters.

This is also where the rumor market comes from. Any «insider» snapshot date circulating in chats is most likely either invented or already past. It cannot be verified, and acting on it is pointless: if it is correct, you are already too late; if not, you have wasted resources.

What counts in a snapshot

The project alone decides which data to extract, and that is determined by the criteria. Typical categories:

Balances and holdings. How much of which asset an address holds at the block. Often with a minimum holding duration — in which case a series of blocks is checked, not one.
Interaction history. Number of transactions with the project's contracts, volume, variety of functions used, first and last block of activity.
Positions in the protocol. Liquidity in pools, open loans, stake, delegations — at the snapshot or averaged over a period.
Off-chain data. Points, completed tasks, linked accounts — if the project tracked them.

What usually does not count: transactions still pending at the block, activity on networks the project does not index, and actions that formally occurred but contradict the criteria (for example, opening and immediately closing a position). Separately: a project may snapshot by one criterion and then filter the result by another — appearing in the export does not mean appearing in the recipient list.

Multiple snapshots and continuous activity

Many projects have moved away from a single snapshot toward a series or continuous tracking. The reasons are the same: one block is easy to «optimize» for, a series of ten random blocks over six months is not.

Common schemes: multiple snapshots with averaging (the mean across all of them counts), cumulative snapshots (each adds points that are summed), seasons (each season is a separate snapshot and separate allocation), and continuous time-weighted tracking, where what matters is not the position at a moment but its integral over the period.

The practical conclusion is a single one: the more complex the tracking scheme, the less any individual moment matters and the more regularity does. If a project has announced a season, that generally means a snapshot at the end of the season or several within it. How this is reflected in project statuses is covered in the article on airdrop statuses.

If you missed the snapshot

First, what will not work. Activity after an announced snapshot will not be included, no matter how much of it there is. Filing an appeal with the argument «I didn't know the date» does not work either: criteria are applied to data, not to intentions.

What is worth checking:

Whether the snapshot was the only one. If the project runs seasons or multiple snapshots, the next one may count current activity. Read the primary source, not a retelling.
Whether there are substantive appeals. Some projects review cases where a wallet was wrongly caught by the Sybil filter or the data was extracted incorrectly. This only works when there is a provable error on the project's side.
Whether the activity remains in your history. It does not disappear: other projects in the same ecosystem sometimes count interactions with neighboring protocols, and the project may come back with a retroactive bonus later.

If none of this applies, the snapshot is missed, and the best thing to do is not to change your behavior for the next rumor. Regular use of products you actually need covers any snapshot without guessing dates. CoinDropster records a project's move to the Snapshot status as soon as official information appears, so you learn about it from the primary source rather than a chat. See tracked airdrops →