Solana Attestation Service

Solana program and clients for issuing, verifying, and revoking on-chain attestations.

An issuer registers a Credential holding its name and the set of authorized signers. Under that credential it publishes a Schema: a field layout, field names, and a description that together define the shape of the data being attested. Authorized signers then write Attestation accounts conforming to that schema, each bound to a nonce and an optional expiry, and can close them to revoke.

A schema can additionally be tokenized. Tokenizing mints an SPL Token-2022 group mint for the schema; attestations issued against it mint a soulbound token to the subject, so wallets and existing token tooling can display an attestation without knowing anything about this program. Holding the token proves neither that the attestation is genuine nor that it is still valid: anyone can create a Token-2022 mint with the same extensions and metadata, and the token carries no expiry. A verifier must take the Attestation address from the token's attestation metadata field, check that the token's mint is the PDA derived from attestationMint and that address, fetch the Attestation account, check that this program owns it and that its credential and schema are the ones expected, and compare its expiry against the on-chain clock (0 means it never expires). Tokenized attestations use the NonTransferable, MetadataPointer, GroupMemberPointer, PermanentDelegate, and MintCloseAuthority extensions. The group's max_size, set once by TokenizeSchema, caps how many tokenized attestations the schema can ever issue: closing one does not free its slot, and the program has no instruction to raise the cap, so pick a size that covers the schema's whole lifetime.

Lifecycle changes are emitted as events through a self-CPI rather than sol_log, which keeps them out of the truncated log buffer so indexers can read them reliably.

This repository contains:

• A Rust Solana program built with Pinocchio
• IDL and client generation via Codama
• A TypeScript client (@solana/attestation) in clients/typescript
• A Rust client (solana-attestation) in clients/rust
• Worked examples in examples/

22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG

Print it from source at any time with just program-id.

A schema's layout is an array of numeric type identifiers; fieldNames names each one positionally. A layout of [12, 0, 12] with field names ["name", "age", "country"] defines a String, a U8, and a String.

solana-attestation-service/
├── program/                 # Rust Solana program (Pinocchio)
│   ├── src/
│   │   ├── processor/       # Instruction handlers
│   │   │   └── shared/      # Account checks, PDA and data utilities
│   │   ├── state/           # Credential, Schema, Attestation accounts
│   │   ├── instructions.rs  # Codama instruction definitions (IDL source)
│   │   ├── entrypoint.rs    # Discriminator routing
│   │   ├── events.rs        # Event definitions
│   │   └── constants.rs     # Seeds and program constants
├── idl/                     # Codama-generated IDL (committed)
├── clients/
│   ├── typescript/          # @solana/attestation SDK + tests
│   └── rust/                # solana-attestation
├── integration_tests/       # Rust integration tests
├── examples/                # Rust and TypeScript attestation flow guides
├── scripts/                 # IDL processing and client generation
├── .github/                 # CI workflows and shared setup action
├── .githooks/               # pre-push: format and lint checks
└── justfile                 # Task runner

git clone git@github.com:solana-foundation/solana-attestation-service.git
cd solana-attestation-service
just setup
just build
just test

just setup checks for pnpm, cargo, and cargo-build-sbf.

Rust is pinned in rust-toolchain.toml, Node.js in .nvmrc, and pnpm in the packageManager field of package.json.

just --list shows every recipe.

Generated client sources under clients/*/src/generated/ are not committed. They are produced from the IDL by just generate-clients and bundled into the published packages. The IDL itself is committed, and just check-generated fails if it has drifted from the program source.

TypeScript:

pnpm add @solana/attestation

import { findCredentialPda, findSchemaPda, serializeAttestationData } from '@solana/attestation';

The package re-exports the Codama-generated instruction builders, account decoders, and PDA finders (findCredentialPda, findSchemaPda, findAttestationPda, findSchemaMintPda, findAttestationMintPda, findEventAuthorityPda, findSasAuthorityPda), plus hand-written schema-driven codecs (getAttestationDataCodec, serializeAttestationData, deserializeAttestationData). It is built on @solana/kit v8, declared as a peer dependency.

Rust:

cargo add solana-attestation

use solana_attestation::instructions::*;

End-to-end walkthroughs live in examples/typescript/attestation-flow-guides and examples/rust/attestation-flow-guide.

A program that gates on an attestation receives the Attestation account in the transaction and checks it itself. The issuers in this repository's examples pass the subject's wallet as the nonce, which makes the attestation for a subject derivable from (credential, schema, subject). The Rust client builds for SBF with default features:

use solana_account_info::AccountInfo;
use solana_address::Address;
use solana_attestation::{accounts::Attestation, programs::SOLANA_ATTESTATION_SERVICE_ID};
use solana_program_error::ProgramError;

const ATTESTATION_DISCRIMINATOR: u8 = 2;

pub fn verify_attestation(
    account: &AccountInfo,
    credential: &Address,
    schema: &Address,
    subject: &Address,
    now: i64,
) -> Result<Attestation, ProgramError> {
    let (expected, _) = Address::find_program_address(
        &[b"attestation", credential.as_ref(), schema.as_ref(), subject.as_ref()],
        &SOLANA_ATTESTATION_SERVICE_ID,
    );
    if account.key != &expected || account.owner != &SOLANA_ATTESTATION_SERVICE_ID {
        return Err(ProgramError::InvalidAccountData);
    }
    let attestation = Attestation::try_from(account).map_err(|_| ProgramError::InvalidAccountData)?;
    if attestation.discriminator != ATTESTATION_DISCRIMINATOR
        || attestation.credential != *credential
        || attestation.schema != *schema
        || (attestation.expiry != 0 && attestation.expiry <= now)
    {
        return Err(ProgramError::InvalidAccountData);
    }
    Ok(attestation)
}

Pass Clock::get()?.unix_timestamp as now. The decoder does not check the discriminator, so the caller must. The credential you pass is the issuer you trust: anyone can create a credential and schema, so the check is only as strong as that choice. A closed attestation has no account, so revocation needs no extra check. Pausing a schema stops new issuance but does not invalidate existing attestations.

Publishing is manual. Publish Rust Client and Publish TypeScript Client are workflow_dispatch only, gated on a green test run and a branch guard, default to a dry run, and authenticate to the registries over OIDC.

Report vulnerabilities privately through the process in SECURITY.md, not in a public issue.

Read CONTRIBUTING.md before opening a pull request. Changelogs are kept per artifact: the program, the Rust client, and the TypeScript client.

MIT.