Solana Attestation Service
- Name: Solana Attestation Service
- URL: https://attest.solana.com/
- Category: attestation infrastructure / credential registry / schema-and-signer middleware / tokenized credential rail
- Tags: solana-ecosystem
- Summary: Solana Attestation Service (SAS) is a Solana-native credential registry, not an attestation anchor. The useful split is between credential ownership, schema definition, signer authorization, attestation issuance, and optional tokenized delivery. Keep it for the Solana branch, especially where Token-2022-style credential packaging is the point, not as a general trust rail.
- What it does:
- Lets an issuing authority create a credential namespace and register one or more authorized signers for that credential
- Lets the credential authority define schemas with named fields, descriptions, layouts, versioning, and pause controls
- Lets authorized signers create attestations under a schema, with data payloads and expiry timestamps, and later close those attestations
- Derives credential, schema, and attestation accounts from program-derived addresses, making issuance legible as a registry structure rather than an opaque app database
- Supports optional tokenization of schemas and attestations, turning credentials into Token-2022-compatible assets with associated metadata and non-transferability hooks
- Positions itself as neutral, reusable credential infrastructure for KYC, jurisdiction gating, sybil resistance, accreditation, membership, and reputation use cases across Solana apps
- Key claims:
- The main mechanism split is between credential authority and authorized signers. That is more useful than the usual vague claim that an issuer simply issues attestations.
- SAS is not just a bag of records. Schema creation, description changes, versioning, and pause controls are all explicit policy surfaces.
- The example flow makes the lifecycle clear: create credential, define schema, serialize data, issue attestation, verify by reading the account, then close when done. That reads like reusable middleware, not one app backend.
Permissionlessis only partly true. Trust still concentrates in issuer reputation, signer admission, schema design, and verifier choice about which credential namespaces count.- Tokenization is the distinctive branch here. Turning schemas and attestations into Token-2022-style assets changes distribution and wallet visibility, even if it does not remove issuer or verifier discretion.
- The launch context matters too: SAS is framed as neutral infrastructure, but the current legitimacy and bootstrapping still come from a fairly concentrated Solana-aligned coalition.
- Keep the note because it cleanly separates issuer authority, schema governance, signer admission, delivery format, and verifier acceptance policy.
- Whitepaper: No canonical SAS whitepaper surfaced in this pass. The strongest primary materials reviewed were the official SAS site, the Solana launch announcement, the protocol repository README, the onchain IDL, and the official Rust example guide; see
../whitepapers/solana-attestation-service-primary-sources-2026-05-10.md. - Sources:
- https://attest.solana.com/
- https://solana.com/news/solana-attestation-service
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/README.md
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/idl/solana_attestation_service.json
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/examples/rust/attestation-flow-guide/README.md
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/examples/rust/attestation-flow-guide/standard-demo/src/main.rs
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/examples/rust/attestation-flow-guide/tokenization-demo/src/main.rs
Internal linkages
- Best upward reads for stronger shared attestation rails: ethereum-attestation-service and sign-protocol.
Practical control points
-
Control sits with credential authorities, signer admission, schema versioning, pause controls, and verifier choice about which credential namespaces count.
-
The distinctive Solana wrinkle is tokenized delivery. That changes distribution and wallet visibility, but it does not remove issuer and verifier discretion.
-
Last reviewed: 2026-06-18 UTC