Solana Attestation Service : comment les attestations apparaissent dans les explorateurs

Le Solana Attestation Service est le système commun de Solana pour les attestations on-chain : un moyen pour un tiers de confiance d’affirmer « ce portefeuille a passé le KYC » ou « ce portefeuille appartient à un investisseur qualifié », sous une forme que n’importe quelle application peut vérifier. Il est en service sur le mainnet depuis mai 2025, annoncé par la Solana Foundation et le Solana Identity Group, et fonctionne comme un programme ouvert unique. Ce guide explique ce que sont les credentials, les schémas et les attestations, comment Solana Explorer les affiche, à quoi ils servent, et ce qu’il faut savoir sur la confidentialité avant qu’un de vos portefeuilles n’en porte une.

Qu’est-ce que le Solana Attestation Service ?

Le Solana Attestation Service (SAS) est un protocole ouvert et sans permission d’attestations vérifiables qui relient des affirmations à des portefeuilles. Un émetteur vérifie quelque chose hors chaîne, comme une identité, une localisation ou un statut d’investisseur, et inscrit le résultat on-chain sous forme d’attestation lisible par d’autres applications.

Le programme se trouve à l’adresse 22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG, et son code est open source dans le dépôt solana-attestation-service. Parmi les partenaires de lancement cités dans l’annonce de la Solana Foundation figurent notamment Civic, Solid, Solana.ID, Trusta Labs, Sumsub et Range. La promesse centrale de l’annonce, c’est la réutilisation : satisfaire une exigence une fois, puis présenter l’attestation sur d’autres plateformes sans nouvelle vérification.

Pourquoi est-ce important pour les explorateurs ? Parce que les attestations sont des comptes Solana ordinaires. N’importe qui peut les ouvrir, voir qui les a émises et vérifier si elles sont toujours valides. C’est un atout majeur pour la transparence, et c’est aussi pour cela qu’il faut comprendre ce qu’elles contiennent.

Credentials, schémas et attestations : les trois briques

SAS utilise trois types de comptes. Un credential définit qui peut émettre, un schéma définit ce que contient une attestation, et l’attestation est l’affirmation elle-même. Les trois sont détenus par le programme SAS.

Credential. C’est le compte d’autorité de l’émetteur. Il liste les signataires autorisés, c’est-à-dire les clés habilitées à créer des attestations au nom de cet émetteur. Un prestataire KYC gère généralement un credential et fait tourner ses signataires selon ses besoins.

Schéma. Un schéma est un modèle rattaché à un credential. Il nomme chaque champ et son type de données. D’après le code source du programme, les schémas prennent en charge 26 types de données, des entiers comme U8 et I64 aux booléens, chaînes de caractères et vecteurs de chacun de ces types. Un schéma peut se limiter à un seul booléen appelé kycPassed, ou compter quelques champs, comme un code pays et un niveau de vérification. Les schémas peuvent être versionnés et mis en pause.

Attestation. L’attestation, c’est l’affirmation. Son compte stocke un nonce (souvent le portefeuille du sujet), le credential et le schéma auxquels elle se rattache, les octets de données conformes au schéma, le signataire qui l’a émise, un horodatage d’expiration où zéro signifie « sans expiration », et un compte de token facultatif si l’attestation a été tokenisée, ce qui permet de la voir aussi comme un token dans le portefeuille de son détenteur (notre guide de l’explorateur de tokens explique le fonctionnement des comptes de tokens). L’adresse du compte est un PDA dérivé du credential, du schéma et du nonce : une application peut donc retrouver l’attestation d’un portefeuille donné sans aucune recherche.

Les instructions du programme reflètent cette structure : créer un credential, créer un schéma, créer une attestation, fermer une attestation, modifier les signataires autorisés, changer le statut ou la version d’un schéma, ainsi que des variantes tokenisées. La documentation officielle sur les attestations décrit le modèle et renvoie vers le SDK.

Comment les explorateurs prennent en charge les attestations SAS

Solana Explorer, maintenu par la Solana Foundation, décode nativement les comptes SAS. Quand vous ouvrez un compte détenu par le programme SAS, il reconnaît s’il s’agit d’une attestation, d’un credential ou d’un schéma, et affiche les champs dans des cartes lisibles plutôt qu’en octets bruts.

Cette prise en charge est visible dans le code open source de l’explorateur, qui utilise le paquet officiel sas-lib pour décoder les trois types de comptes et comprend des cartes d’attestation pour les comptes comme pour les instructions. Concrètement :

• Ouvrir une attestation affiche son credential, son schéma, son signataire, son expiration et ses données décodées.
• Ouvrir un schéma affiche le nom et le type de ses champs : vous voyez exactement ce qu’un émetteur enregistre.
• Ouvrir un credential affiche l’autorité de l’émetteur et ses signataires autorisés.
• Ouvrir une transaction qui appelle SAS affiche l’instruction sous une forme lisible.

Cela s’inscrit dans le point fort général de Solana Explorer, la référence pour les données de comptes brutes et décodées ; nous détaillons le reste de ses fonctionnalités dans notre avis sur Solana Explorer. Range, l’un des partenaires de lancement, présente le contexte des attestations dans ses propres outils d’investigation. La prise en charge par Solscan, Orb et les autres explorateurs n’était pas confirmée lors de notre vérification : si vous comptez sur eux, testez d’abord avec une adresse d’attestation connue. Notre classement des explorateurs Solana indique ce que chaque outil décode bien.

Cas d’usage : KYC, éligibilité et réputation

Les principaux cas d’usage sont le KYC réutilisable, l’éligibilité géographique, la vérification du statut d’investisseur, la résistance aux attaques Sybil et la réputation. Dans chaque cas, l’application lit une réponse oui/non ou une petite donnée au lieu de collecter elle-même des documents.

Indicateurs KYC. Une application régulée peut exiger qu’un portefeuille détienne une attestation émise par un prestataire KYC agréé. L’utilisateur fait son KYC une seule fois auprès de l’émetteur ; toutes les applications conformes lisent le même indicateur. Éligibilité géographique. Certains produits ne peuvent pas être proposés dans certains pays. Une attestation indiquant « non résident de la région restreinte X » permet à une application de filtrer l’accès sans conserver de passeport. Pour un utilisateur français, belge ou suisse, c’est précisément le type de contrôle qu’exigent souvent les services financiers soumis à une réglementation nationale ou européenne. Statut d’investisseur. Les titres tokenisés et certains fonds sont réservés aux investisseurs qualifiés ou professionnels, et une attestation peut porter ce statut.

Résistance Sybil. Les airdrops et les votes de gouvernance souffrent des personnes qui gèrent des centaines de portefeuilles. Une attestation de preuve d’humanité permet à un projet de compter des personnes plutôt que des adresses. Réputation. Les DAO peuvent émettre des attestations pour des contributions, et les réseaux DePIN peuvent attester d’appareils ou de localisations. Comme les attestations sont des comptes, les programmes peuvent les vérifier au sein d’une transaction, et pas seulement dans une interface web.

Confidentialité : ce qui est public, ce qui ne l’est pas

SAS est conçu pour que les données personnelles sensibles restent chez l’émetteur et que seule l’affirmation soit inscrite on-chain. Tout ce qui est inscrit on-chain est public, conservé durablement dans l’historique du registre et relié à une adresse de portefeuille.

La Solana Foundation présente l’objectif comme des attestations portables sans exposition de données sensibles on-chain. Le mécanisme repose sur une bonne conception des schémas. Le champ de données de l’attestation contient ce que le schéma définit. Si un émetteur conçoit un schéma avec un seul booléen, la blockchain apprend seulement qu’un portefeuille a passé un contrôle auprès d’un émetteur. Si un schéma stocke une date de naissance ou un nom, ces données sont lisibles par quiconque dispose d’un explorateur. Pour un résident européen, cela pose aussi la question de la compatibilité avec le RGPD, puisqu’une donnée inscrite dans l’historique d’une blockchain ne peut pas être effacée : raison de plus pour exiger des schémas minimalistes.

Quelques points pratiques avant d’accepter une attestation :

• Lisez le schéma. Ouvrez-le dans Solana Explorer et examinez le nom et le type des champs. Moins il y a de champs, et plus ils sont grossiers, mieux c’est.
• Pensez à la traçabilité. Même un simple booléen révèle qu’un portefeuille a été vérifié par un émetteur identifié. Si vous voulez qu’une partie de votre activité reste sans lien, utilisez un portefeuille séparé.
• L’historique ne disparaît pas. Fermer une attestation supprime le compte, mais les transactions qui l’ont créée et fermée restent dans le registre et dans les explorateurs qui indexent l’historique.
• Vérifiez l’expiration. Une attestation sans expiration (valeur zéro) reste valide jusqu’à ce que l’émetteur la ferme.

C’est le compromis de toute la blockchain : la transparence au service de la vérifiabilité. Notre guide de l’explorateur de portefeuilles montre tout ce que chacun peut déjà voir de l’historique d’un portefeuille, un contexte utile avant d’y ajouter des affirmations d’identité.

Lire une attestation SAS pas à pas

Lire une attestation demande quatre vérifications : qui l’a émise, ce qu’elle affirme, si elle est toujours valide et si le signataire était autorisé. Solana Explorer affiche les quatre sur un seul écran.

Partez de l’adresse de l’attestation. Confirmez que le propriétaire du compte est le programme SAS 22zo…4BdG ; sinon, ce n’est pas une attestation SAS, quoi qu’en dise la page. Ouvrez le credential lié et comparez l’émetteur à celui que vous attendez ; les émetteurs publient l’adresse de leur credential dans leur documentation. Ouvrez le schéma lié et lisez ses champs. De retour sur l’attestation, lisez les données décodées et l’expiration, puis vérifiez que le signataire figure bien dans la liste des signataires autorisés du credential.

Si vous travaillez par programme, les mêmes vérifications se résument à quelques appels getAccountInfo suivis d’un décodage avec le SDK. Notre guide des API d’explorateurs Solana compare les options RPC et indexeurs pour récupérer des comptes à grande échelle, et le guide de l’explorateur de programmes explique comment inspecter le programme SAS lui-même, y compris son autorité de mise à jour et son statut de vérification. Lors de notre contrôle du 23 septembre 2026, l’API de vérification d’OtterSec associait un commit de dépôt au programme SAS, mais ne le signalait pas encore comme vérifié.

La place de SAS dans l’écosystème Solana

SAS est une infrastructure, pas une application. Il offre aux émetteurs et aux applications un format commun, et aux explorateurs un programme unique à décoder. Sa valeur augmente avec le nombre d’émetteurs et d’applications qui acceptent de l’utiliser.

Pour les utilisateurs, le changement visible sera moins de vérifications d’identité répétées et davantage d’applications capables de proposer des produits régulés on-chain. Pour les développeurs, il remplace les listes blanches ad hoc par une structure de compte standard. Le site officiel attest.solana.com rassemble la documentation et les outils. Si la lecture de comptes on-chain est nouvelle pour vous, commencez par notre guide débutant qu’est-ce qu’un explorateur Solana, puis revenez à une attestation : ses champs prendront vite tout leur sens.