What to do when you miss a snapshot

The gas came to a bit under twenty dollars. Nine transactions, four wallets, forty minutes, every single one of them sent after I read that a snapshot I had been working toward was taken eleven days earlier.

None of those transactions could reach the measurement. I knew that while I was signing them.

The miss itself was free. The forty minutes were not, and that hour is the part almost nobody writes about.

Nothing you send afterwards reaches the file

I have written separately about how snapshots actually work, the difference between a single block read and a windowed measurement, and why the exact block is almost never published in advance. Go there for the mechanics. This piece starts one step later, at the moment you discover you were outside the window.

The only property that matters here is that a taken snapshot is finished. What it recorded became a file on a server, or a merkle root, and neither of those updates. There is no partial credit, no late submission, no route by which the record gets rewritten because you tried hard eleven days afterwards.

Everybody knows this. It stops nobody, which tells you the problem is not an information problem.

The burst writes something down

Here is the half people skip.

My nine transactions are permanent. They sit on chain, timestamped, in the history of four addresses I am still going to be using next year. So the panic bought nothing, and then it left a record.

The record is legible. Four addresses that had been quiet for weeks all becoming busy inside the same forty minute stretch, immediately after a public announcement. I am not going to build the case here for how timing gets read as a clustering signal, that is a subject of its own, but a synchronised burst is among the easier things to spot in block data and it carries a date on it.

Which means the next programme can see it. So can the next season, and the next team that decides to score a set of addresses. Twenty dollars was the cheap half of the bill. The part I cannot do anything about is that the pattern is not deletable.

“You missed it” describes three different situations

When someone tells you the snapshot has passed, they are describing one of at least three things and usually have not worked out which.

One is an announced snapshot that genuinely closed. The team published a block height, or a date, or an eligibility checker you can paste an address into, and you get a yes or a no back. That one is over in the plainest sense of the word.

Another is a rolling or multi snapshot programme. Points systems, seasons, anything that samples repeatedly across months. You have missed one read out of many, or the opening weeks of a season that has not ended. Nothing permanent has happened to you here at all, the panic is entirely unwarranted, and the single action that would genuinely hurt is the one people take: compressing three months of activity into an afternoon, inside a system built to reward the opposite.

The third is a programme where the criteria were never published. A token gets announced, a chat concludes the snapshot must have happened at some point, and everyone repeats it to each other until it sounds settled. Nobody in that chat knows the window. They do not know the weighting, whether balances or behaviour were read, or whether the team has stopped measuring at all. They are guessing, confidently and at volume.

I once watched a chat decide a window had closed, and then watched an eligibility page turn up six weeks later running on a window that had extended a further month past the day everyone gave up. Half the people who wrote it off spent that month doing nothing, on the say so of a group with no more information than they had.

That third case is more common than the other two put together, and it is the one that generates the most certainty.

What is actually worth doing in each

For the closed retroactive one, run every address you own through the checker, including the ones you had forgotten about. I have twice found an address that qualified for something I had already written off, on the strength of activity from more than a year earlier that I never connected to the programme. Checkers are free. Use them on the whole set, not the two wallets you remember.

Then look at whether the same team has anything live. A project that has just distributed a token frequently has a second season, a staking programme, or a governance process starting. That is a real question. The closed snapshot is not.

For the rolling programme, do what you would have done that week anyway. That is the whole instruction. If you were using the protocol once a fortnight, keep using it once a fortnight. Whatever rate you were on before the news is the rate that got you counted in the reads you did catch.

For the unpublished criteria case, you do not have enough information to act on and neither does anybody telling you it is over. Treat the situation as unchanged. If you were genuinely using the thing before the announcement, carry on at the same pace. If you were not, an announcement is a bad reason to start.

In all three, the recommended action sits somewhere between very little and none.

The hour after you find out

This is the position I expect to get argued with about: the hour after you find out is the most dangerous hour in airdrop farming, and doing nothing is usually the strongest move available inside it.

Patience is not the reason. The reason is that every action taken in that hour is taken on information you do not have, aimed at a measurement that has either closed or is still open in a shape you cannot see, and it goes onto a permanent record either way.

The test I use is whether I would have sent the same transaction the previous Tuesday, before the news. If yes, send it. If the announcement is the only reason it exists, the announcement is writing my history for me.

There is a second effect worth naming. That hour sets a baseline. If loud news reliably produces a burst out of you, that is simply how you behave now, and it will happen again the next time a chat gets excited.

So I give myself a day. Nothing signed for twenty four hours after news of that kind. It is a dull rule that does one thing: it removes the specific hour in which I am reliably stupid.

The reason this keeps happening

People miss snapshots because they are tracking projects in their head. Which protocols they are on, roughly how recently, whether the last real interaction was six weeks ago or four months, held loosely in memory across twenty or thirty names.

That does not survive contact with anything. The first news of a token arrives as a surprise, and the surprise is what produces the burst.

The fix is a written record with dates in it. Protocol, wallet, what you did, when. Mine is a sheet and it takes about ten minutes a week. I have a separate piece on the weekly routine it sits inside, so I will not rebuild that here beyond saying that hardly anybody keeps one, and it converts finding out late into a lookup instead of a fire drill.

Where the rule failed

The Tuesday above was not my first attempt at this.

Roughly seven months earlier I did a near identical thing on a different protocol and afterwards wrote myself a note saying wait a day. I never read the note again, because I had no habit that involved reading it. A rule you write once with no trigger attached is a diary entry.

What actually stopped me the second time was not discipline. I ran out of gas on the third wallet, had to go and bridge, and the bridging took long enough that I came back to my senses partway through.

So my record here is one accidental save and one clean failure. And the sample is small: a couple of years, a few dozen programmes, one distribution I properly cared about. I can describe the mechanism. I cannot tell you what any of it pays, and nobody who says otherwise knows either.

The same reflex somewhere else entirely

I run mobile proxy lines and a rack of Android phones for a living, and this reflex showed up there first.

A modem stops answering. The instinct is to reboot the machine, which takes about thirty other live ports down with it, most of them belonging to customers who were having a perfectly good morning. The event that upset me was one port. The action I wanted to take was the largest one within reach, because the thing I actually wanted, which was for the modem to have not dropped, was already gone.

The fix in that business was the same as the fix here. I keep a per port log with dates, so when a customer tells me their line was down last Tuesday I look it up rather than arguing from memory. Every line has a cost sheet behind it too: about ten dollars a month for the SIM, roughly a dollar fifty of modem depreciation. I know those numbers because I wrote them down once and have not had to guess since.

A snapshot is the same situation with a different vocabulary. The measurement is closed and cannot be argued with. The only thing still moving is what you do next, and that is being recorded.

The trackers, the sheet, and the rest of how I run this are on the home page.

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