Der Solana Attestation Service ist Solanas gemeinsames System für On-Chain-Nachweise: ein Weg, auf dem eine vertrauenswürdige Stelle sagen kann „diese Wallet hat KYC bestanden“ oder „diese Wallet gehört einem qualifizierten Anleger“, und zwar in einer Form, die jede App prüfen kann. Er ging im Mai 2025 im Mainnet live, angekündigt von der Solana Foundation und der Solana Identity Group, und läuft als ein einziges offenes Programm. Dieser Ratgeber erklärt Credentials, Schemas und Attestierungen, zeigt, wie Solana Explorer sie darstellt und wofür sie genutzt werden, und sagt dir, was du zum Datenschutz wissen solltest, bevor eine deiner Wallets eine Attestierung trägt.
Was ist der Solana Attestation Service?
Der Solana Attestation Service (SAS) ist ein offenes, erlaubnisfreies Protokoll für überprüfbare Nachweise, die Aussagen mit Wallets verknüpfen. Ein Aussteller prüft etwas off-chain, etwa Identität, Wohnort oder Anlegerstatus, und hält das Ergebnis on-chain als Attestierung fest, die andere Apps lesen können.
Das Programm liegt unter 22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG, und der Code ist Open Source im Repository solana-attestation-service. Zu den Launch-Partnern, die die Ankündigung der Solana Foundation nennt, gehören unter anderem Civic, Solid, Solana.ID, Trusta Labs, Sumsub und Range. Das zentrale Versprechen der Ankündigung ist Wiederverwendbarkeit: eine Anforderung einmal erfüllen und den Nachweis dann auf andere Plattformen mitnehmen, ohne sich erneut zu verifizieren.
Warum ist das für Explorer relevant? Weil Attestierungen ganz normale Solana-Accounts sind. Jeder kann sie öffnen, nachlesen, wer sie ausgestellt hat, und prüfen, ob sie noch gültig sind. Das ist stark für die Transparenz, und genau deshalb solltest du verstehen, was in ihnen steht.
Credentials, Schemas und Attestierungen erklärt
SAS nutzt drei Account-Typen. Ein Credential legt fest, wer ausstellen darf, ein Schema legt fest, was eine Attestierung enthält, und die Attestierung ist die Aussage selbst. Alle drei gehören dem SAS-Programm.
Credential. Das ist der Autoritäts-Account des Ausstellers. Er listet die autorisierten Unterzeichner, also die Schlüssel, die unter diesem Aussteller Attestierungen erstellen dürfen. Ein KYC-Anbieter betreibt typischerweise ein Credential und wechselt die Unterzeichner bei Bedarf.
Schema. Ein Schema ist eine Vorlage, die an ein Credential gebunden ist. Es benennt jedes Feld und seinen Datentyp. Laut Quellcode des Programms unterstützen Schemas 26 Datentypen, von Ganzzahlen wie U8 und I64 über Booleans und Strings bis zu Vektoren all dieser Typen. Ein Schema kann so schlicht sein wie ein einzelner Boolean namens kycPassed oder aus wenigen Feldern bestehen, etwa einem Ländercode und einer Verifizierungsstufe. Schemas lassen sich versionieren und pausieren.
Attestierung. Die Attestierung ist die Aussage. Ihr Account speichert eine Nonce (oft die Wallet des Subjekts), das zugehörige Credential und Schema, die Datenbytes passend zum Schema, den ausstellenden Unterzeichner, einen Ablaufzeitpunkt (null heißt: kein Ablauf) und optional einen Token-Account, falls die Attestierung tokenisiert wurde. Dann erscheint sie zusätzlich als Token in der Wallet des Inhabers; wie Token-Accounts funktionieren, erklärt unser Ratgeber zum Token-Explorer. Die Account-Adresse ist eine PDA, abgeleitet aus Credential, Schema und Nonce, sodass eine App die Attestierung zu einer bestimmten Wallet ohne Suche findet.
Die Instruktionen des Programms spiegeln diese Struktur: Credential erstellen, Schema erstellen, Attestierung erstellen, Attestierung schließen, autorisierte Unterzeichner ändern, Status oder Version eines Schemas ändern, dazu tokenisierte Varianten. Die offizielle Doku zu Attestierungen beschreibt das Modell und verlinkt das SDK.
So funktioniert die Explorer-Unterstützung für SAS-Attestierungen
Solana Explorer, gepflegt von der Solana Foundation, dekodiert SAS-Accounts nativ. Öffnest du einen Account, der dem SAS-Programm gehört, erkennt der Explorer, ob es sich um eine Attestierung, ein Credential oder ein Schema handelt, und zeigt die Felder in lesbaren Karten statt als Rohbytes.
Diese Unterstützung ist im Open-Source-Code des Explorers sichtbar. Er nutzt das offizielle Paket sas-lib, um die drei Account-Typen zu dekodieren, und enthält Attestierungs-Karten für Accounts wie für Instruktionen. In der Praxis heißt das:
- Eine Attestierung zeigt Credential, Schema, Unterzeichner, Ablauf und dekodierte Daten.
- Ein Schema zeigt Feldnamen und Typen, sodass du genau siehst, was ein Aussteller erfasst.
- Ein Credential zeigt die Autorität des Ausstellers und die autorisierten Unterzeichner.
- Eine Transaktion, die SAS aufruft, zeigt die Instruktion in lesbarer Form.
Das passt zur generellen Stärke von Solana Explorer als Referenz für rohe, dekodierte Account-Daten; den Rest des Funktionsumfangs behandeln wir in unserem Test des Solana Explorer. Range, einer der Launch-Partner, zeigt Attestierungs-Kontext in seinen eigenen Analyse-Tools. Unterstützung in Solscan, Orb und anderen Explorern war bei unserem Check nicht bestätigt. Wenn du dich auf diese Tools verlässt, teste sie also zuerst mit einer bekannten Attestierungsadresse. Unser Ranking der Solana-Explorer zeigt, was jedes Tool gut dekodiert.
Tipp: Um zu prüfen, ob eine Wallet eine bestimmte Attestierung trägt, brauchst du die Credential- und Schema-Adressen des Ausstellers. Mit diesen und der Wallet als Nonce ist die Attestierungsadresse deterministisch, und du kannst sie direkt in Solana Explorer öffnen oder in unser Such-Tool einfügen, um zu bestätigen, dass sie existiert.
Anwendungsfälle: KYC-Flags, Berechtigungen und Reputation
Die wichtigsten Anwendungsfälle sind wiederverwendbares KYC, regionale Berechtigung, Nachweise zum Anlegerstatus, Sybil-Resistenz und Reputation. In jedem Fall liest eine App eine Ja/Nein- oder kleine Datenaussage, statt selbst Dokumente einzusammeln.
KYC-Flags. Eine regulierte App kann verlangen, dass eine Wallet eine Attestierung von einem zugelassenen KYC-Aussteller besitzt. Der Nutzer durchläuft KYC einmal beim Aussteller, und jede regelkonforme App liest dasselbe Flag. Wer in Deutschland schon einmal bei mehreren Krypto-Anbietern ein Video-Ident durchlaufen hat, versteht sofort den Reiz dieser Idee. Geografische Berechtigung. Manche Produkte dürfen in bestimmten Ländern nicht angeboten werden. Eine Attestierung mit der Aussage „nicht wohnhaft in gesperrter Region X“ lässt eine App den Zugang steuern, ohne einen Reisepass zu speichern. Anlegerstatus. Tokenisierte Wertpapiere und manche Fonds sind qualifizierten oder professionellen Anlegern vorbehalten, und eine Attestierung kann diesen Status tragen.
Sybil-Resistenz. Airdrops und Governance-Abstimmungen leiden darunter, dass eine Person Hunderte Wallets betreibt. Eine Proof-of-Personhood-Attestierung erlaubt es einem Projekt, Menschen statt Adressen zu zählen. Reputation. DAOs können Attestierungen für Beiträge ausstellen, und DePIN-Netzwerke können Geräte oder Standorte bestätigen. Weil Attestierungen Accounts sind, können Programme sie innerhalb einer Transaktion prüfen, nicht nur in einem Web-Frontend.
Ob eine SAS-Attestierung im konkreten Fall die gesetzlichen KYC-Pflichten eines Anbieters erfüllt, entscheidet nicht das Protokoll, sondern die jeweilige Aufsicht. In Deutschland ist das für Kryptodienstleister die BaFin, EU-weit bildet MiCA den Rahmen.
Datenschutz: was öffentlich ist und was nicht
SAS ist so konzipiert, dass sensible persönliche Daten beim Aussteller bleiben und nur die Aussage on-chain landet. Alles, was on-chain landet, ist aber öffentlich, dauerhaft in der Ledger-Historie und mit einer Wallet-Adresse verknüpft.
Die Solana Foundation beschreibt das Ziel als übertragbare Nachweise, ohne sensible Daten on-chain offenzulegen. Ob das gelingt, hängt am Schema-Design. Das Datenfeld der Attestierung enthält, was das Schema festlegt. Entwirft ein Aussteller ein Schema mit einem einzigen Boolean, erfährt die Chain nur, dass eine Wallet bei einem bestimmten Aussteller irgendeine Prüfung bestanden hat. Speichert ein Schema ein Geburtsdatum oder einen Namen, kann jeder mit einem Explorer diese Daten lesen.
Für Nutzer in der EU ist das auch eine Frage der DSGVO: Daten, die einmal in einer öffentlichen Blockchain stehen, lassen sich praktisch nicht mehr löschen. Seriöse Aussteller werden deshalb schon aus eigenem Interesse möglichst sparsame Schemas wählen, und du solltest genau darauf achten.
Einige praktische Punkte, bevor du eine Attestierung akzeptierst:
- Lies das Schema. Öffne es in Solana Explorer und sieh dir Feldnamen und Typen an. Weniger und gröbere Felder sind besser.
- Denk an die Verknüpfbarkeit. Selbst ein Boolean verrät, dass eine Wallet von einem namentlich bekannten Aussteller verifiziert wurde. Soll manche Aktivität unverknüpft bleiben, nutze dafür eine separate Wallet.
- Die Historie verschwindet nicht. Das Schließen einer Attestierung entfernt den Account, die Transaktionen zum Erstellen und Schließen bleiben aber im Ledger und in Explorern, die Historie indexieren.
- Prüf den Ablauf. Eine Attestierung ohne Ablauf (Wert null) bleibt gültig, bis der Aussteller sie schließt.
Das ist derselbe Kompromiss, den die ganze Chain eingeht: Transparenz gegen Überprüfbarkeit. Unser Ratgeber zum Wallet-Explorer zeigt, wie viel von der Historie einer Wallet schon heute jeder sehen kann. Das ist nützlicher Kontext, bevor du ihr Identitätsaussagen hinzufügst.
Eine SAS-Attestierung Schritt für Schritt lesen
Eine Attestierung zu lesen erfordert vier Checks: wer sie ausgestellt hat, was sie aussagt, ob sie noch gültig ist und ob der Unterzeichner autorisiert war. Solana Explorer zeigt alle vier auf einem Bildschirm.
Beginne bei der Attestierungsadresse. Prüf, ob der Owner des Accounts das SAS-Programm 22zo…4BdG ist; wenn nicht, ist es keine SAS-Attestierung, egal was die Seite behauptet. Öffne das verknüpfte Credential und gleiche den Aussteller mit dem ab, den du erwartest; Aussteller veröffentlichen ihre Credential-Adressen in ihrer Doku. Öffne das verknüpfte Schema und lies die Felder. Zurück bei der Attestierung liest du die dekodierten Daten und den Ablauf und prüfst, ob der Unterzeichner in der Liste der autorisierten Unterzeichner des Credentials steht.
Wenn du programmatisch arbeitest, sind dieselben Checks ein paar getAccountInfo-Aufrufe plus Dekodierung mit dem SDK. Unser Ratgeber zur Solana Explorer API vergleicht RPC- und Indexer-Optionen, um Accounts in großem Umfang abzurufen, und der Ratgeber zum Programm-Explorer erklärt, wie du das SAS-Programm selbst untersuchst, einschließlich Upgrade Authority und Verifizierungsstatus. Bei unserem Check am 23. September 2026 führte die Verifizierungs-API von OtterSec für das SAS-Programm einen verknüpften Repository-Commit, meldete es aber noch nicht als verifiziert.
Wo SAS im Solana-Stack einzuordnen ist
SAS ist Infrastruktur, keine App. Es gibt Ausstellern und Apps ein gemeinsames Format und Explorern ein einziges Programm zum Dekodieren. Der Nutzen wächst mit der Zahl der Aussteller und Apps, die sich darauf einigen.
Für Nutzer zeigt sich die Änderung in weniger wiederholten Identitätsprüfungen und mehr Apps, die regulierte Produkte on-chain anbieten können. Für Entwickler ersetzt SAS einmalige Allowlists durch ein standardisiertes Account-Layout. Die offizielle Seite unter attest.solana.com bündelt Doku und Tools. Wenn dir das Lesen von On-Chain-Accounts insgesamt noch neu ist, starte mit unserer Einsteiger-Erklärung, was ein Solana Explorer ist, und komm dann zu einer Attestierung zurück: Die Felder ergeben danach schnell Sinn.
Von der Solscanner-RedaktionAktualisiert · Testmethodik