Reading a snapshot announcement for what it does not say

The announcement is a legal document wearing a marketing outfit

A snapshot announcement is usually three sentences on Twitter and a longer post on the project’s blog or Mirror page. The short version always says the same thing: a snapshot is coming, hold your tokens, don’t sell. What it rarely says is the part that actually determines who gets included: the exact criteria, the exact block or timestamp, and what counts as a disqualifying pattern.

That gap is not always an accident. Teams that have already built a sybil-detection pass on their side benefit from vagueness. If they published the exact wallet-age threshold or the exact clustering heuristic, farmers would route around it in a day. So the announcement tells you the outcome they want (organic holders, real users) without telling you the mechanism they’ll use to sort for it. Reading around that gap is the actual skill here.

What the announcement almost always states clearly

A few pieces of information are usually unambiguous, because the team needs them to be:

• The snapshot block height or date, sometimes both.
• The chain or chains included, if the project is multi-chain.
• A minimum holding period, if one exists (“must have held since block X”).
• Whether staked, LP, or bridged positions count.

These are operational facts. Get them wrong and your entire farming plan for that project is wasted, so treat this part of the post as the one thing worth screenshotting and archiving with a timestamp, since announcement posts get edited or deleted more often than people expect.

What the announcement almost never states

The vague part is everything downstream of “who qualifies.” Specifically:

• The exact sybil or bot filter being applied, and its thresholds.
• Whether wallets funded from the same source (CEX withdrawal, bridge, or another wallet) get flagged.
• Whether timing patterns (identical transaction intervals, identical gas amounts, identical contract call sequences across wallets) factor in.
• Whether the team is doing this analysis themselves or outsourcing it to a chain-analytics vendor.
• What the appeals process looks like, if there is one.

None of this is a conspiracy. It’s the same reason a company doesn’t publish its fraud-detection rules: publishing them defeats the purpose. But it means the announcement is optimized to look complete while leaving out the one variable that decides whether your wallets get treated as one user’s farm or a hundred organic accounts.

How the clustering actually works, in general terms

Chain analysis for sybil detection isn’t magic and it isn’t secret sauce specific to any one team. It’s a handful of well-known techniques, usually stacked:

Funding source clustering. If ten wallets all received their initial gas from the same CEX withdrawal transaction, or from the same funding wallet in sequence, that’s a graph edge. Enough edges between enough wallets and they get grouped into one cluster regardless of what each wallet does afterward.

Behavioral fingerprinting. Wallets that call the same contracts in the same order, with the same gas settings, at intervals that are suspiciously regular (every wallet swaps exactly 6 hours after the last), read as scripted. Humans are messier than that by default.

Timing correlation. Even without shared funding, wallets that transact within seconds of each other across many separate sessions start to look coordinated. A single coincidence means nothing. A pattern across weeks does.

Network-level signals. This is where proxy and device setup matters. If wallets connect from the same IP, the same subnet, or an ASN known for hosting rather than residential traffic, that’s another edge in the graph. It’s not proof by itself, but it stacks with the other signals.

None of these signals condemn a wallet on their own. Clustering algorithms score accumulated evidence. A team publishing “we check funding source” would be technically true and still useless information, because the real filter is how many signals stack together and where the threshold sits, and that threshold is the thing they will never publish.

The defensive read: what to actually do with an announcement

Given that the mechanism is opaque, the useful move is not to guess at the algorithm. It’s to reduce your own signal correlation regardless of what any specific project checks for. This is infrastructure hygiene, not an evasion technique, and it applies the same way whether or not you’re farming a particular announcement:

Separate funding paths. Don’t fan out from one CEX withdrawal to twenty wallets in one transaction batch. Stagger it, use different funding wallets, or use different on-ramps entirely.

Separate network paths. Running wallets from a shared consumer connection with rotating mobile IPs behaves differently on a graph than a block of datacenter IPs. This is why proxy quality actually matters for this use case, not because a specific proxy “beats detection,” but because your traffic pattern is one input among several. A residential or mobile-carrier IP pool sitting on a real device or cloud phone looks like ordinary retail traffic; a rack of datacenter IPs on the same subnet looks like infrastructure, because it is infrastructure.

Separate behavioral timing. If every wallet in your set performs the same actions in the same order at the same interval, that regularity is itself the signal, independent of funding or IP. Varying session timing and action order reduces one whole category of correlation.

None of this guarantees inclusion in any snapshot. It reduces the number of correlated signals a clustering pass has to work with, which is a different and more honest claim.

Reading the fine print without over-reading it

There’s a failure mode on the other side too: treating every ambiguous sentence in an announcement as a hidden threat. Most teams aren’t running sophisticated graph analysis in-house. Many outsource it to a third-party chain-analytics vendor, and some do nothing more than a manual review of the top few hundred wallets by activity. The size of the airdrop, the size of the team, and whether they’ve been burned by farming before (public complaints in a prior season are a real signal) tell you more about how seriously to take the sybil language than the wording of the post itself.

Check for these markers when sizing up how seriously a team is enforcing: - Prior season retro posts mentioning wallets clawed back or excluded. - Job postings or team bios mentioning a chain-analytics background. - Whether the project has an existing partnership with a known analytics vendor. - Whether the announcement mentions an appeals or review window at all. Its absence usually means decisions are final and unexplained.

What this means for how you track a project

Treat every snapshot announcement as two documents layered on top of each other: the stated rules, which you follow exactly and archive, and the unstated filter, which you defend against with infrastructure hygiene rather than trying to reverse-engineer. Don’t read a vague sybil clause as a guarantee you’ll get flagged, and don’t read a silent one as a guarantee you won’t.

This is also why keeping your own records matters more than watching the announcement thread. Log which wallet funded which, on what network path, and roughly when. If a project does publish exclusion criteria after the fact, or a retro report naming clawback categories, that log is what lets you actually learn something instead of just guessing at what happened.

If you want the operational side of this covered in more depth, wallet separation, proxy setup, and how to read a project’s post-snapshot retro is what this site tracks.

Get new guides and videos first — join the Telegram channel.