Wat is een airdrop-snapshot en hoe beïnvloedt die je aanspraak

Veel mensen missen een airdrop niet omdat ze niets deden, maar omdat ze het te laat deden. Het werk was af, de tokens bleven uit, en pas bij het checken bleek dat al hun handelingen na "dat ene moment" vielen. Dat vervelende moment is de snapshot. Hij werkt als de bel bij een examen die aangeeft dat je moet inleveren: alles wat je voor de bel schreef telt, alles wat je erna nog snel opschrijft leest de surveillant niet meer. Een snapshot begrijpen komt in de kern neer op begrijpen wanneer die inleverbel klinkt, volgens welke regels er wordt geteld, en waarom je die bel vaak niet vooraf hoort.

Dit stuk hoort bij de basis en legt een concrete zaak uit: wat een snapshot is, waarom projecten hem zo graag gebruiken, hoe je de snapshottijd te weten komt, of je na een gemist moment nog iets kunt doen, en welke misverstanden erover rondgaan. Na afloop snap je waarom ik telkens herhaal dat je bij een retroactieve airdrop niet op het laatste moment kunt improviseren, maar het van je gewone, echte gebruik moet hebben. De oorzaak zit precies in dit mechanisme.

Wat een snapshot precies is

Een blockchain is een grootboek dat onophoudelijk wordt aangevuld: om de zoveel tijd wordt er een nieuw blok gebundeld waarin de transacties uit die periode worden vastgelegd. Het ethereum-mainnet produceert ongeveer elke 12 seconden een blok (preciezer gezegd een slot), dus dit grootboek slaat elke twaalf tellen een bladzijde om. Een snapshot is dat het project een bepaalde bladzijde uitkiest (een bepaalde blokhoogte) en de status van alle relevante adressen aan het einde van die bladzijde exact vastlegt: wie hoeveel van een bepaald asset bezit, wie met een bepaald protocol interacteerde, wie wat gestaket had, alles bevroren op dat ene moment.

Een vergelijking: een snapshot is geen video, maar een foto. Hij geeft niet om hoe je daarvoor handelde of daarna deed, maar kijkt alleen naar hoe je eruitzag op het moment dat de sluiter klikte. Dus een adres dat een blok voor de snapshot nog aan de voorwaarden voldeed en de tokens pas na de snapshot wegboekte, telt gewoon mee. Andersom: alles wat je pas na de snapshot bijdoet, staat niet op de foto. Daarom is "blokhoogte" nauwkeuriger dan "een tijdstip", want een blockchain telt op blokken, en tijd is maar een grove omrekening. Wil je blokken, transacties en adressen vanaf de basis begrijpen, dan legt de documentatie van de Ethereum Foundation het schoon uit (wat is een blok), en de uitleg over status en transacties is ook het lezen waard (wat is een transactie).

Je kunt dit zelf verifieren. Typ een willekeurig adres in op Etherscan en je ziet bij elke transactie het bijbehorende bloknummer, de tijd en het contract waarmee werd geinteracteerd (etherscan.io). Zodra het project de snapshot-blokhoogte bekendmaakt, kun je met de block explorer nakijken of jouw kernactie voor of na het snapshotblok viel. Hoe je met de checkpagina en de block explorer je aanspraak nakijkt, heb ik in een ander stuk beschreven (zo controleer je of je in aanmerking komt).

Waarom projecten er de aanspraak mee bepalen

Een project kan best zeggen "wie ons ooit gebruikte krijgt tokens", dus waarom moet er per se een tijdstip aan vast? Omdat het zonder dat tijdstip niet netjes uit te voeren is. Een snapshot lost een paar heel praktische problemen op.

• Er moet een duidelijke deadline zijn om de rekening te maken. Om per adres een aandeel uit te rekenen, is er een uniform "rekenmoment" nodig. Zonder snapshot verandert de lijst voortdurend, valt het aandeel niet te berekenen en is uitkeren onmogelijk.
• Het voorkomt een stormloop zodra het nieuws eruit is. Kondig je vooraf aan "wie na die datum gebruikt heeft recht", dan komen er gegarandeerd hordes adressen binnenstormen om massaal te farmen. Door de snapshot op een niet-openbaar moment in het verleden te leggen, filter je een flink deel van de puur speculatieve adressen eruit en houd je gebruikers over die dichter bij echt zitten.
• Het beloont echt gebruik in plaats van vertoon achteraf. Het project wil de mensen die het sowieso al gebruikten. Doordat de snapshot ongemerkt wordt gemaakt, scheidt hij precies de "echte gebruiker" van "wie het gerucht hoorde en snel kwam poseren".
• De status is herleidbaar en publiek verifieerbaar. Omdat de on-chain-geschiedenis openbaar is, kan iedereen onafhankelijk nagaan wat de status van een adres op het snapshotblok was, waardoor de uitkeringsregels lastiger stiekem te manipuleren zijn.

Deze motieven begrijpen is nuttig, want het verklaart direct waarom "taken doen betekent gegarandeerd een airdrop" een gevaarlijke aanname is: het project belooft nooit iets, de regels worden misschien pas achteraf vastgesteld, en de snapshot is mogelijk allang gemaakt. Zie on-chain-gebruik als een "goedkope poging" en niet als een "gegarandeerd rendement", dan zit je met de juiste instelling. Wil je je activiteit meer op die van een echte gebruiker laten lijken in plaats van machinaal farmen, lees dan het stuk dat daar speciaal over gaat (echte on-chain-activiteit).

Hoe je de snapshottijd te weten komt (meestal pas achteraf)

Dit is het meest frustrerende, maar onvermijdelijke punt: bij de meeste retroactieve airdrops wordt de snapshottijd niet vooraf bekendgemaakt, en tegen de tijd dat jij het weet is de deadline vaak al voorbij. De reden stond in de vorige sectie: vooraf publiceren maakt het filteren van speculanten zinloos. Voor dit soort airdrops is er dus geen enkele mogelijkheid om "op de klok" te werken. De enige betrouwbare aanpak is het protocol dat je ziet zitten gewoon in het dagelijks leven echt gebruiken.

Is er dan niets over te weten te komen? Zo zwart-wit is het ook niet, het hangt van het type af.

• Retroactieve airdrop: de snapshottijd wordt meestal pas bij de officiele aankondiging meegedeeld, in de trant van "we hebben op die datum en op die blokhoogte een foto gemaakt". Wat je dan kunt doen is niet iets bijdoen, maar met die blokhoogte je status van toen nakijken.
• Taak- of puntenprogramma: de regels zijn relatief transparant, soms met een aankondiging als "punten worden tot die datum geteld", vergelijkbaar met een halfopen snapshotvenster. Onthoud wel: "punten worden mogelijk niet ingewisseld", punten zijn geen tokens.
• Holder- of governance-snapshot: zulke worden vaak wel vooraf aangekondigd, zodat wie in aanmerking komt zich kan voorbereiden. Bepaalde governance-stemmingen of verdelingen melden bijvoorbeeld vooraf op welk blok er een foto van de houders wordt gemaakt.

Wat het type ook is, de enige betrouwbare bron voor de snapshottijd is de officiele aankondiging van het project. Elk privebericht, groepsbericht of zoekadvertentie dat je een "snapshottijd" geeft met een link erbij om "snel te handelen of te checken", is hoogst verdacht, want dat is vaak phishing. Echt van nep-officiele kanalen onderscheiden is op zich een vak (officiele kanalen herkennen). Zodra het project de blokhoogte bekendmaakt, is zelf nakijken met een block explorer het veiligst, bijvoorbeeld door het bloknummer van je transactie te vergelijken. Wil je de begrippen rond adressen, autorisaties en het intrekken daarvan scherp hebben voordat je gaat checken, dan is revoke.cash een schone praktische bron (revoke.cash).

Snapshot gemist, maak je nog kans?

Eerst het meest voorkomende geval: is de snapshot van een retroactieve airdrop eenmaal voorbij, dan is er voor deze ronde in principe geen ruimte meer om iets goed te maken. De foto is gemaakt, wat je erna bijdoet verschijnt er niet op. Dat klinkt hard, maar het accepteren scheelt je een hoop omwegen: geef geen geld en gas meer uit om "de snapshot na te jagen", dat is verspilde moeite.

Maar "deze keer geen kans" is niet hetzelfde als "voortaan nooit meer". Een paar routes die wel geldig blijven:

• Hetzelfde project kan latere batches of nieuwe fases hebben. Sommige protocollen keren in meerdere rondes uit of starten na een nieuwe functie een nieuwe incentiveronde. Deze snapshot heb je gemist, maar vanaf nu echt gebruiken kan voor de volgende fase nog steeds op tijd zijn.
• Andere projecten hebben nog geen foto gemaakt. Er zijn altijd vroege protocollen die gebruikers verzamelen. Ga je nu echt gebruiken, dan is dat voor hun mogelijke toekomstige snapshot "activiteit van voor de snapshot". Het draait altijd om je gewone gedrag, niet om improviseren.
• Een enkel project opent een naclaim- of bezwaarvenster. Denk aan bezwaar tegen een onterechte sybil-markering, of gefaseerd claimen. Zulke info haal je alleen uit de officiele aankondiging, en geloof nooit een privebericht dat "voor je checkt, claimt of bezwaar maakt", dat is vrijwel altijd oplichting.
• Zie een misser als een goedkope les. Als je alleen wat gas en tijd betaalde en het misliep, is de schade klein. Waar je echt blij mee mag zijn, is dat je in de paniek van het "snapshot najagen" geen bezittingen aan een phishingpagina bent kwijtgeraakt.

Nog een mentale kanttekening: zelfs als je de snapshot haalde en echt tokens kreeg, moet je ze niet als binnengehaald geld zien. Dat airdroptokens naar nul gaan is heel goed mogelijk en gebeurt vaak; de prijs wordt door niemands belofte beschermd. Verzilver wat je kunt vastzetten zo snel mogelijk en zie de rest als een onzekere meevaller. Wat een airdrop is en hoe het hele traject verloopt, kun je als beginner eerst in mijn overzicht lezen (beginnersgids voor airdrops), waarin verzilveren, belasting en het naar-nul-risico worden uitgewerkt.

Een paar hardnekkige misverstanden over snapshots

Het woord snapshot klinkt simpel, maar er gaan opvallend veel misverstanden over rond. Ik zet ze los op een rij om recht te zetten, zodat je geen tijd verspilt of in een valkuil trapt.

Van deze punten zijn "meerdere wallets openen" en "op een vreemde snapshotlink klikken" het schadelijkst. De eerste leidt tot een sybil-markering, waarbij zelfs het hoofdadres dat op zich wel in aanmerking kwam meegesleurd kan worden; over het echte risico daarvan heb ik apart geschreven (echte on-chain-activiteit raakt dit ook). De tweede loodst je regelrecht in approval-phishing. Phishing onder het mom van "snapshot of aanspraak" is een andere kant van hetzelfde spel als de nep-airdrop; ik raad je sterk aan die uitleg te lezen (nep-airdrops en approval-phishing). Vermoed je dat een adres al een gevaarlijke autorisatie tekende, trek die dan snel in met een officiele tool zoals revoke.cash (revoke.cash).

Wil je het begrip "snapshot" wat systematischer plaatsen, kijk dan naar twee soorten bronnen. De ene behandelt het als algemeen financieel concept, zoals de uitleg van Investopedia over het airdrop-mechanisme (Investopedia: Airdrop). De andere is de off-chain governance-tool die projecten vaak gebruiken; veel governance-snapshots draaien daarop (Snapshot-documentatie). De mechanismen verschillen, maar het kernidee "op een bepaald moment een lijst of stemgewicht vastleggen" is hetzelfde.

Terug naar die inleverbel uit het begin. Een snapshot klinkt niet later omdat jij haast hebt, en verandert zijn oordeel niet omdat jij iets nadoet. Wat je wel in de hand hebt, is niet de bel, maar of je in het dagelijks leven echt gebruikt, en of je bij elk bericht over "snapshot of aanspraak" de grens bewaakt van niet zomaar tekenen en niet zomaar autoriseren. Doe je die twee dingen goed, dan grijp je niet naast door het mechanisme en verlies je in de paniek van het snapshot najagen niet je hele wallet. Wil je meteen doorlopen naar het nakijken of dit adres aan de voorwaarden voldoet, dan gaat het volgende stuk daar precies over (zo controleer je of je in aanmerking komt voor een airdrop).