SAS Attestations

Reading the Anchor PDA directly works for any program that knows where to look. SAS—the Solana Attestation Service—is the standard composability primitive that lets any program read a verification result without knowing anything specific about Entros.

What SAS is

The Solana Attestation Service is a protocol for issuing structured, on-chain attestations against a wallet. An issuer (someone with credentials) attaches a schema (a typed record) to a wallet. Any consumer can then look up the attestation and read its fields.

Entros publishes one attestation per successful verification. The attestation is what most integrators read; the Anchor PDA is the underlying source of truth.

The Entros credential and schema

Two on-chain accounts identify the Entros attestation source:

• Credential PDA—GaPTkZC6JEGds1G5h645qyUrogx7NWghR2JgjvKQwTDo (devnet)
• Schema PDA—EPkajiGQjycPwcc3pupqExVdAmSfxWd31tRYZezd8c5g (devnet)

The schema fields:

The attestation PDA is derived from the credential, schema, and user wallet:

// SAS_PROGRAM_ID = new PublicKey("22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG")
const [attestationPda] = PublicKey.findProgramAddressSync(
  [
    new TextEncoder().encode("attestation"),
    credentialPda.toBuffer(),
    schemaPda.toBuffer(),
    userWallet.toBuffer(),
  ],
  SAS_PROGRAM_ID,
);

Why integrators read attestations, not the Anchor

Three reasons.

Stable interface. SAS is a Solana-wide primitive. A program already wired to read SAS attestations from any issuer can read Entros without knowing the Entros program IDs or account layouts.

Schema versioning. If the Anchor's internal layout changes—adding a field, reorganizing offsets—the SAS schema is the integrator-facing contract. The schema is versioned independently of the underlying program.

Single-call composability. An integrator that gates on multiple attestation types (e.g. KYC + verified human) can fan out reads through one SAS-aware function rather than hand-rolling each program's account layout.

The read path

The SDK ships a single function that handles derivation, fetching, deserialization, and expiry:

import { verifyEntrosAttestation } from "@entros/pulse-sdk";

const attestation = await verifyEntrosAttestation(walletAddress, connection);

if (!attestation || !attestation.isHuman) {
  // no verification on file, or expired
}

if (attestation.trustScore < 250) {
  // verified, but below your threshold
}

verifyEntrosAttestation returns null if no attestation exists, or { isHuman, trustScore, verifiedAt, mode, expired }. Expired attestations are returned with expired: true rather than null, so applications can choose whether to require freshness.

Expiry

Attestations carry an expiry timestamp, configurable per attestation. The default issued by the executor is 30 days from the verification timestamp. After expiry, the attestation account remains on-chain but expired === true. Re-verifying refreshes both the Anchor state and the attestation.

Walletless mode

Walletless mode still exists for low-stakes CAPTCHA-equivalent surfaces, but it does not write to the Solana Attestation Service. Every SAS attestation is now bound to a wallet that signed an ownership proof at issue time — /attest requires wallet_address, nonce, signature, and message together on every call. The earlier walletless-on-SAS path was removed because it created a griefing surface where any caller could issue an attestation against any target wallet pubkey without proof of control.

Walletless integrations that need a one-shot human signal rely on the executor's client-side ephemeral receipt — short-lived, not persisted on chain. For any gate that depends on the temporal-identity claim (re-verification cadence, accumulated score, returning-operator reasoning), require a wallet-connected verification.

Where to look next

• Integrate: SAS attestation—code-level integration, attestation lookup, threshold examples
• Concepts: Anchor PDA—what the attestation is a snapshot of
• Reference: SDK—full signature of verifyEntrosAttestation and related helpers