The Solana Attestation Service is Solana’s shared system for on-chain credentials: a way for a trusted party to say “this wallet passed KYC” or “this wallet belongs to an accredited investor” in a form any app can check. It went live on mainnet in May 2025, announced by the Solana Foundation and the Solana Identity Group, and it runs as a single open program. This guide explains credentials, schemas and attestations, how Solana Explorer displays them, what they are used for, and what you should know about privacy before a wallet of yours carries one.
What is the Solana Attestation Service?
The Solana Attestation Service (SAS) is an open, permissionless protocol for verifiable credentials that link claims to wallets. An issuer checks something off chain, such as identity, location or accreditation, and records the result on chain as an attestation that other apps can read.
The program lives at 22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG, and the code is open source in the solana-attestation-service repository. Launch partners named in the Solana Foundation announcement include Civic, Solid, Solana.ID, Trusta Labs, Sumsub and Range, among others. The announcement’s central promise is reuse: meet a requirement once, then carry the credential to other platforms without verifying again.
Why does this matter for explorers? Because attestations are ordinary Solana accounts. Anyone can open them, read who issued them, and check whether they are still valid. That is powerful for transparency, and it is also why you need to understand what is inside them.
Credentials, schemas and attestations explained
SAS uses three account types. A credential defines who may issue, a schema defines what an attestation contains, and an attestation is the claim itself. All three are owned by the SAS program.
Credential. This is the issuer’s authority account. It lists the authorised signers, the keys allowed to create attestations under that issuer. A KYC provider would typically run one credential and rotate signers as needed.
Schema. A schema is a template tied to a credential. It names each field and its data type. According to the program source, schemas support 26 data types, from integers such as U8 and I64 to booleans, strings and vectors of each. A schema might be as simple as one boolean called kycPassed, or a small set of fields such as a country code and a verification level. Schemas can be versioned and paused.
Attestation. The attestation is the claim. Its account stores a nonce (often the subject’s wallet), the credential and schema it belongs to, the data bytes that match the schema, the signer who issued it, an expiry timestamp where zero means no expiry, and an optional token account if the attestation was tokenised, so it can also appear as a token in the holder’s wallet (our token explorer guide explains how token accounts work). The account address is a PDA derived from the credential, schema and nonce, so an app can find the attestation for a given wallet without a search.
The program’s instructions mirror this structure: create credential, create schema, create attestation, close attestation, change authorised signers, change schema status or version, and tokenised variants. The official attestations docs describe the model and link to the SDK.
How explorer support for SAS attestations works
Solana Explorer, maintained by the Solana Foundation, decodes SAS accounts natively. When you open an account owned by the SAS program, it recognises whether it is an attestation, a credential or a schema and shows the fields in readable cards instead of raw bytes.
This support is visible in the explorer’s open-source code, which uses the official sas-lib package to decode the three account types, and includes attestation cards for both accounts and instructions. In practice, that means:
- Opening an attestation shows its credential, schema, signer, expiry and decoded data.
- Opening a schema shows its field names and types, so you can see exactly what an issuer records.
- Opening a credential shows the issuer’s authority and authorised signers.
- Opening a transaction that calls SAS shows the instruction in a readable form.
This fits Solana Explorer’s general strength as the reference for raw, decoded account data; we cover the rest of its feature set in our Solana Explorer review. Range, one of the launch partners, surfaces attestation context in its own investigation tools. Support in Solscan, Orb and other explorers was not confirmed when we checked, so if you rely on them, test with a known attestation address first. Our ranked list of Solana explorers covers what each tool decodes well.
Tip: To check whether a wallet carries a specific attestation, you need the credential and schema addresses from the issuer. With those and the wallet as nonce, the attestation address is deterministic, and you can open it directly in Solana Explorer or paste it into our lookup tool to confirm it exists.
Use cases: KYC flags, eligibility and reputation
The main use cases are reusable KYC, regional eligibility, accreditation checks, Sybil resistance and reputation. In each case an app reads a yes-or-no or small data claim instead of collecting documents itself.
KYC flags. A regulated app can require that a wallet holds an attestation from an approved KYC issuer. The user completes KYC once with the issuer; every compliant app reads the same flag. Geographic eligibility. Some products cannot be offered in certain countries. An attestation that says “not a resident of restricted region X” lets an app gate access without storing a passport. Accreditation. Tokenised securities and some funds are limited to accredited or professional investors, and an attestation can carry that status.
Sybil resistance. Airdrops and governance votes suffer from one person running hundreds of wallets. A proof-of-personhood attestation lets a project count people instead of addresses. Reputation. DAOs can issue attestations for contributions, and DePIN networks can attest to devices or locations. Because attestations are accounts, programs can check them inside a transaction, not only in a web front end.
Privacy considerations: what is public, what is not
SAS is designed so that sensitive personal data stays with the issuer, and only the claim goes on chain. Everything that does go on chain is public, permanent in the ledger history, and linked to a wallet address.
The Solana Foundation describes the goal as portable credentials without exposing sensitive data on chain. The mechanism depends on good schema design. The attestation’s data field holds whatever the schema defines. If an issuer designs a schema with a single boolean, the chain learns only that a wallet passed some check with some issuer. If a schema stores a date of birth or a name, that data is readable by anyone with an explorer.
Some practical points before accepting an attestation:
- Read the schema. Open it in Solana Explorer and look at the field names and types. Fewer, coarser fields are better.
- Remember linkability. Even a boolean reveals that a wallet was verified by a named issuer. If you want some activity to stay unlinked, use a separate wallet for it.
- History does not disappear. Closing an attestation removes the account, but the transactions that created and closed it remain in the ledger and on explorers that index history.
- Check expiry. An attestation with no expiry (value zero) stays valid until the issuer closes it.
This is the same trade-off the whole chain makes: transparency for verifiability. Our wallet explorer guide shows how much of a wallet’s history anyone can already see, which is useful context before adding identity claims to it.
How to read an SAS attestation step by step
Reading an attestation takes four checks: who issued it, what it says, whether it is still valid, and whether the signer was authorised. Solana Explorer shows all four on one screen.
Start from the attestation address. Confirm the account owner is the SAS program 22zo…4BdG; if it is not, it is not an SAS attestation, whatever the page says. Open the linked credential and check the issuer against the one you expect; issuers publish their credential addresses in their docs. Open the linked schema and read the fields. Back on the attestation, read the decoded data and the expiry, and check that the signer appears in the credential’s list of authorised signers.
If you work programmatically, the same checks are a few getAccountInfo calls plus decoding with the SDK. Our Solana explorer API guide compares RPC and indexer options for fetching accounts at scale, and the program explorer guide explains how to inspect the SAS program itself, including its upgrade authority and verification status. At our check on 23 September 2026, the OtterSec verification API listed a linked repository commit for the SAS program but did not yet report it as verified.
Where SAS fits in the Solana stack
SAS is infrastructure, not an app. It gives issuers and apps a common format, and it gives explorers a single program to decode. The value grows with the number of issuers and apps that agree to use it.
For users, the visible change is fewer repeated identity checks and more apps that can offer regulated products on chain. For developers, it replaces one-off allowlists with a standard account layout. The official site at attest.solana.com collects the docs and tooling. If you are new to reading on-chain accounts at all, start with our beginner explainer on what a Solana explorer is, then come back to an attestation and the fields will make sense quickly.
By the Solscanner research deskUpdated · Review methodology