Solana Attestation Service primary sources
Reviewed: 2026-05-10 UTC
Core product framing
- https://attest.solana.com/
- Official SAS website.
- Used to confirm the top-level actor model: issuer, SAS program, holder, and verifier.
- Also used to confirm the project’s positioning as reusable credential infrastructure for compliance, identity, and trust use cases on Solana.
Launch framing and intended ecosystem role
- https://solana.com/news/solana-attestation-service
- Official Solana launch announcement for SAS.
- Best source in this pass for portable-credential framing, stated use cases, and the bootstrapping coalition behind the protocol.
- Especially useful for the claims that SAS is permissionless, meant for reusable KYC/compliance/reputation credentials, and launched under the Solana Identity Group umbrella.
Repo-level protocol source
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/README.md
- Sparse, but still the canonical protocol repository landing page.
- Used to confirm the official repository, IDL-generation path, and client-generation workflow.
Onchain interface / registry structure
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/idl/solana_attestation_service.json
- Best single source for actual protocol structure in this pass.
- Used to confirm the core instructions:
CreateCredential,CreateSchema,ChangeSchemaStatus,ChangeAuthorizedSigners,ChangeSchemaDescription,ChangeSchemaVersion,CreateAttestation,CloseAttestation,TokenizeSchema, andCreateTokenizedAttestation. - Most analytically useful detail: SAS explicitly separates credential authority, schema lifecycle, signer management, attestation issuance, and tokenization.
Official workflow examples
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/examples/rust/attestation-flow-guide/README.md
- Used to confirm the intended lifecycle from demo code: create, manage, verify, and close credentials / attestations.
- Also useful for confirming the existence of both standard and tokenized attestation flows.
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/examples/rust/attestation-flow-guide/standard-demo/src/main.rs
- Best source for the standard lifecycle in code.
- Used to confirm PDA derivation for credentials, schemas, and attestations; Borsh-serialized attestation payloads; expiry handling; and verification by reading the attestation account.
- https://raw.githubusercontent.com/solana-foundation/solana-attestation-service/master/examples/rust/attestation-flow-guide/tokenization-demo/src/main.rs
- Best source for the tokenized branch.
- Used to confirm schema and attestation mint PDAs, SAS-derived mint authority, recipient token-account delivery, and Token-2022 extension usage for credential-style token behavior.
Main takeaways from this pass
- SAS’s core reusable primitive is not just “KYC on Solana,” but a credential registry that separates issuer authority, schema governance, signer authorization, attestation state, and optional tokenized delivery.
- The biggest hidden control surfaces are authorized-signer admission, schema versioning / pause authority, verifier-side credential acceptance policy, and the reputational gatekeeping around which issuers matter.
- The tokenization branch is analytically important because it turns attestations from pure registry entries into wallet-distributed credential objects with token metadata and extension logic.
- SAS is therefore a useful comparison class for Ethereum-oriented attestation systems because it exposes the same schema / issuer / verifier questions in a Solana-native program-and-token-account environment.