De Solana Attestation Service is het gedeelde systeem van Solana voor on-chain credentials: een manier waarop een vertrouwde partij kan zeggen “deze wallet is door de KYC gekomen” of “deze wallet is van een professionele belegger”, in een vorm die elke app kan controleren. De dienst ging in mei 2025 live op mainnet, aangekondigd door de Solana Foundation en de Solana Identity Group, en draait als één open programma. Deze gids legt credentials, schema’s en attestaties uit, hoe Solana Explorer ze toont, waarvoor ze worden gebruikt en wat je over privacy moet weten voordat een van je wallets er een draagt.
Wat is de Solana Attestation Service?
De Solana Attestation Service (SAS) is een open, permissionless protocol voor verifieerbare credentials die claims aan wallets koppelen. Een uitgever controleert iets off-chain, zoals identiteit, locatie of een beleggersstatus, en legt het resultaat on-chain vast als een attestatie die andere apps kunnen lezen.
Het programma staat op 22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG, en de code is opensource in de solana-attestation-service-repository. Tot de launchpartners die in de aankondiging van de Solana Foundation worden genoemd, horen onder meer Civic, Solid, Solana.ID, Trusta Labs, Sumsub en Range. De centrale belofte van die aankondiging is hergebruik: voldoe één keer aan een eis en neem de credential daarna mee naar andere platforms zonder opnieuw te verifiëren.
Waarom is dat relevant voor explorers? Omdat attestaties gewone Solana-accounts zijn. Iedereen kan ze openen, lezen wie ze heeft uitgegeven en controleren of ze nog geldig zijn. Dat is krachtig voor transparantie, en precies daarom moet je begrijpen wat erin staat.
Credentials, schema’s en attestaties uitgelegd
SAS gebruikt drie accounttypen. Een credential bepaalt wie mag uitgeven, een schema bepaalt wat een attestatie bevat, en een attestatie is de claim zelf. Alle drie zijn eigendom van het SAS-programma.
Credential. Dit is het autoriteitsaccount van de uitgever. Het noemt de bevoegde ondertekenaars, de sleutels die onder die uitgever attestaties mogen aanmaken. Een KYC-provider draait doorgaans één credential en wisselt ondertekenaars wanneer dat nodig is.
Schema. Een schema is een sjabloon dat aan een credential hangt. Het benoemt elk veld en het bijbehorende datatype. Volgens de broncode van het programma ondersteunen schema’s 26 datatypen, van integers zoals U8 en I64 tot booleans, strings en vectoren van elk daarvan. Een schema kan zo simpel zijn als één boolean met de naam kycPassed, of een klein setje velden zoals een landcode en een verificatieniveau. Schema’s kunnen worden geversioneerd en gepauzeerd.
Attestatie. De attestatie is de claim. Het account bewaart een nonce (vaak de wallet van het subject), de credential en het schema waar hij bij hoort, de databytes die bij het schema passen, de ondertekenaar die hem uitgaf, een vervaltijdstempel waarbij nul “geen vervaldatum” betekent, en optioneel een token account als de attestatie is getokeniseerd, zodat hij ook als token in de wallet van de houder kan verschijnen (onze gids voor de token-explorer legt uit hoe token accounts werken). Het accountadres is een PDA, afgeleid van credential, schema en nonce, dus een app kan de attestatie voor een bepaalde wallet vinden zonder te zoeken.
De instructies van het programma volgen die structuur: credential aanmaken, schema aanmaken, attestatie aanmaken, attestatie sluiten, bevoegde ondertekenaars wijzigen, status of versie van een schema wijzigen, plus getokeniseerde varianten. De officiële documentatie over attestaties beschrijft het model en linkt naar de SDK.
Zo werkt explorer-support voor SAS-attestaties
Solana Explorer, onderhouden door de Solana Foundation, decodeert SAS-accounts standaard. Open je een account dat eigendom is van het SAS-programma, dan herkent hij of het een attestatie, credential of schema is en toont hij de velden in leesbare kaarten in plaats van ruwe bytes.
Die ondersteuning is terug te zien in de opensourcecode van de explorer, die het officiële pakket sas-lib gebruikt om de drie accounttypen te decoderen, en die attestatiekaarten heeft voor zowel accounts als instructies. In de praktijk betekent dat:
- Open je een attestatie, dan zie je de credential, het schema, de ondertekenaar, de vervaldatum en de gedecodeerde data.
- Open je een schema, dan zie je de veldnamen en typen, zodat je precies ziet wat een uitgever vastlegt.
- Open je een credential, dan zie je de autoriteit van de uitgever en de bevoegde ondertekenaars.
- Open je een transactie die SAS aanroept, dan zie je de instructie in leesbare vorm.
Dat past bij de algemene kracht van Solana Explorer als naslagwerk voor ruwe, gedecodeerde accountdata; de rest van de functies bespreken we in onze review van Solana Explorer. Range, een van de launchpartners, toont attestatiecontext in zijn eigen onderzoekstools. Ondersteuning in Solscan, Orb en andere explorers was bij onze controle niet bevestigd, dus vertrouw je daarop, test dan eerst met een bekend attestatieadres. Onze ranglijst van Solana explorers laat zien wat elke tool goed decodeert.
Tip: Wil je controleren of een wallet een bepaalde attestatie heeft, dan heb je de adressen van de credential en het schema van de uitgever nodig. Daarmee, en met de wallet als nonce, ligt het attestatieadres vast, en kun je het direct openen in Solana Explorer of in onze zoektool plakken om te bevestigen dat het bestaat.
Toepassingen: KYC-vlaggen, geschiktheid en reputatie
De belangrijkste toepassingen zijn herbruikbare KYC, regionale geschiktheid, controle van beleggersstatus, Sybil-resistentie en reputatie. In elk geval leest een app een ja/nee-claim of een kleine hoeveelheid data, in plaats van zelf documenten te verzamelen.
KYC-vlaggen. Een gereguleerde app kan eisen dat een wallet een attestatie heeft van een goedgekeurde KYC-uitgever. De gebruiker doorloopt de KYC één keer bij de uitgever; elke app die aan de regels voldoet, leest dezelfde vlag. Geografische geschiktheid. Sommige producten mogen in bepaalde landen niet worden aangeboden. Een attestatie die zegt “geen inwoner van beperkte regio X” laat een app de toegang afschermen zonder een paspoort op te slaan. Beleggersstatus. Getokeniseerde effecten en sommige fondsen zijn beperkt tot professionele of gekwalificeerde beleggers, en een attestatie kan die status dragen.
Sybil-resistentie. Airdrops en governance-stemmingen hebben last van één persoon met honderden wallets. Een proof-of-personhood-attestatie laat een project mensen tellen in plaats van adressen. Reputatie. DAO’s kunnen attestaties uitgeven voor bijdragen, en DePIN-netwerken kunnen apparaten of locaties attesteren. Omdat attestaties accounts zijn, kunnen programma’s ze binnen een transactie controleren, niet alleen in een web-front-end.
Wat betekent dit voor Europese gebruikers?
In de EU moeten cryptodienstverleners sinds het einde van de MiCA-overgangsperiode op 1 juli 2026 een vergunning hebben; in Nederland houdt de AFM daar toezicht op. Zulke partijen moeten hun klanten kennen, en herbruikbare attestaties zijn een van de manieren waarop on-chain apps die verplichting in de toekomst efficiënter kunnen invullen. Tegelijk staat privacy in Europa hoog op de agenda: een schema dat meer vastlegt dan nodig is, schuurt al snel met het principe van dataminimalisatie. Voor Nederlandse en Belgische gebruikers is het advies daarom hetzelfde als overal, maar met extra nadruk: kijk wat er precies in het schema staat voordat je een attestatie accepteert.
Privacy: wat is openbaar en wat niet?
SAS is zo ontworpen dat gevoelige persoonsgegevens bij de uitgever blijven en alleen de claim on-chain gaat. Alles wat wel on-chain gaat, is openbaar, blijft permanent in de ledgerhistorie staan en is gekoppeld aan een walletadres.
De Solana Foundation omschrijft het doel als draagbare credentials zonder gevoelige data on-chain bloot te geven. Of dat lukt, hangt af van een goed schemaontwerp. Het dataveld van de attestatie bevat wat het schema definieert. Ontwerpt een uitgever een schema met één enkele boolean, dan leert de chain alleen dat een wallet bij een bepaalde uitgever een bepaalde check heeft doorstaan. Slaat een schema een geboortedatum of naam op, dan kan iedereen met een explorer die gegevens lezen.
Een paar praktische punten voordat je een attestatie accepteert:
- Lees het schema. Open het in Solana Explorer en bekijk de veldnamen en typen. Minder en grovere velden zijn beter.
- Denk aan koppelbaarheid. Zelfs een boolean verraadt dat een wallet door een uitgever met naam is geverifieerd. Wil je bepaalde activiteit ongekoppeld houden, gebruik er dan een aparte wallet voor.
- Historie verdwijnt niet. Het sluiten van een attestatie verwijdert het account, maar de transacties die hem aanmaakten en sloten blijven in de ledger en in explorers die historie indexeren.
- Check de vervaldatum. Een attestatie zonder vervaldatum (waarde nul) blijft geldig tot de uitgever hem sluit.
Het is dezelfde afweging die de hele chain maakt: transparantie in ruil voor verifieerbaarheid. Onze gids voor de wallet-explorer laat zien hoeveel van de historie van een wallet iedereen nu al kan zien, en dat is nuttige context voordat je er identiteitsclaims aan toevoegt.
Zo lees je een SAS-attestatie stap voor stap
Een attestatie lezen vraagt vier checks: wie hem uitgaf, wat erin staat, of hij nog geldig is en of de ondertekenaar bevoegd was. Solana Explorer toont alle vier op één scherm.
Begin bij het attestatieadres. Controleer dat de owner van het account het SAS-programma 22zo…4BdG is; is dat niet zo, dan is het geen SAS-attestatie, wat de pagina ook beweert. Open de gekoppelde credential en vergelijk de uitgever met degene die je verwacht; uitgevers publiceren hun credential-adressen in hun documentatie. Open het gekoppelde schema en lees de velden. Terug op de attestatie lees je de gedecodeerde data en de vervaldatum, en controleer je dat de ondertekenaar in de lijst met bevoegde ondertekenaars van de credential staat.
Werk je programmatisch, dan zijn dezelfde checks een paar getAccountInfo-aanroepen plus decoderen met de SDK. Onze gids over de Solana explorer API vergelijkt RPC- en indexeropties om accounts op schaal op te halen, en de gids voor de programma-explorer legt uit hoe je het SAS-programma zelf bekijkt, inclusief upgrade authority en verificatiestatus. Bij onze controle op 23 september 2026 vermeldde de verificatie-API van OtterSec een gekoppelde repository-commit voor het SAS-programma, maar meldde hem nog niet als geverifieerd.
Waar SAS past in de Solana-stack
SAS is infrastructuur, geen app. Het geeft uitgevers en apps een gemeenschappelijk formaat, en explorers één programma om te decoderen. De waarde groeit met het aantal uitgevers en apps dat afspreekt het te gebruiken.
Voor gebruikers is de zichtbare verandering minder herhaalde identiteitscontroles en meer apps die gereguleerde producten on-chain kunnen aanbieden. Voor ontwikkelaars vervangt het losse allowlists door een standaard accountlayout. De officiële site attest.solana.com bundelt de documentatie en tooling. Ben je nog nieuw in het lezen van on-chain accounts, begin dan met onze uitleg voor beginners over wat een Solana explorer is, en kom daarna terug bij een attestatie: de velden vallen dan snel op hun plek.
Door de researchdesk van SolscannerBijgewerkt · Reviewmethodiek