← All posts
2026-05-0812 min

Solana Attestation Service (SAS) for Government: The IBM Verify Equivalent on a Public Chain

Solana Attestation Service (SAS) for Government: The IBM Verify Equivalent on a Public Chain

For technical evaluators and system architects tasked with modernizing government credential infrastructure.

For technical evaluators and system architects tasked with modernizing government infrastructure, the digital identity landscape has traditionally presented a binary choice. On one side are massive, centralized Identity and Access Management (IAM) platforms like IBM Verify, which provide robust identity governance, lifecycle management, and adaptive risk evaluation. On the other side are fragmented, highly experimental decentralized identity networks that often fail to scale in production environments.

When deploying systems at a national scale—such as the certificate-based legal aid systems operating across 9 countries and covering over 500 million citizens—the centralized model reveals severe economic and architectural friction points. Traditional enterprise IAM suites typically rely on subscription-based pricing models, often costing upwards of $1.92 to $2.27 per user per month for standard lifecycle and single sign-on capabilities. Furthermore, these centralized identity vaults create massive vendor lock-in, forcing government ministries to tether their core trust infrastructure to proprietary SAML and OIDC endpoints maintained by a single corporate entity.

$0.004
Per credential issuance (SAS)
$1.92+
Per user/month (IBM Verify)
400ms
Global settlement
0
Vendor lock-in

SAS: The Public-Chain Identity Primitive

The Solana Attestation Service (SAS) fundamentally shatters this dichotomy. Launched in May 2025 through a collaboration between the Solana Foundation, Civic, and the global verification platform Sumsub, SAS is a purpose-built, decentralized identity protocol. It offers the exact same core functionality as an enterprise IAM suite—schema registries, deterministic addressing, credential issuance, and lifecycle management—but it executes these functions entirely on a public blockchain.

In the Adduce protocol, we didn't build our credential infrastructure from scratch—we built ON SAS. For government IT departments, this is the IBM Verify equivalent: permissionless, on a public chain, at 1/100th the infrastructure cost.

It requires no vendor lock-in, no ongoing licensing fees, and no proprietary middleware.

The Three-Layer PDA Architecture

To understand why SAS is uniquely suited for enterprise government applications, one must examine how it anchors data to the blockchain. Unlike early Web3 identity attempts that tried to force complex JSON documents into rudimentary smart contracts, SAS utilizes Solana's highly efficient Program Derived Addresses (PDAs) to create a structured, three-layer data hierarchy.

LayerPDA DerivationPurposeGovernment Analogue
Credentialauthority + nameTop-level issuer identityMinistry of Justice
Schemacredential + name + versionData template definitionCertificate format spec
Attestationcredential + schema + nonceIndividual citizen claimLegal aid certificate

In the Adduce codebase, this architecture is implemented through the sas-lib toolkit, generating a highly modular and predictable credential lifecycle:

// Layer 1: Credential — issuer identity
const [credentialAddress] = await deriveCredentialPda({
  authority: signer.address,
  name: "legal-aid-credential",
});

// Layer 2: Schema — data structure definition
// Layout bytes: [12, 12, 8] → String, String, i64
const [schemaAddress] = await deriveSchemaPda({
  credential: credentialAddress,
  name: "legal-aid-eligibility",
  version: 1,
});

// Layer 3: Attestation — individual citizen claim
const [attestationAddress] = await deriveAttestationPda({
  credential: credentialAddress,
  schema: schemaAddress,
  nonce: citizen.address,  // binds attestation to citizen's wallet
});

When a court authority calls SAS, it creates this Attestation PDA containing the citizen's public key, the strict schema data (jurisdiction, eligibility_tier, expiry_date), the issuer's cryptographic signature, and an expiry timestamp. Because this occurs natively on the Solana execution layer, the total infrastructure cost for this issuance is a mere $0.004.

On-Chain vs. In-Wallet: Why SAS Beats Hyperledger Aries

A critical architectural distinction between SAS and other decentralized identity frameworks—such as Hyperledger Aries and Indy—is where the ultimate source of truth resides.

In the Hyperledger Aries architecture, verifiable credentials are traditionally issued directly into a user's mobile wallet application. The ledger is only used to store the public DIDs and schema definitions. While this promotes absolute data sovereignty, it introduces massive operational fragility for government systems. If a citizen loses their phone, their credential is gone. If the verifying party needs to establish the credential's validity, they often require active, agent-to-agent communication.

The SAS difference: The attestation lives ON-CHAIN as a Solana account owned by the SAS Program. Even if the issuing court's centralized database crashes, or the ministry's hardware goes offline, the credential remains 100% verifiable because the proof is anchored to the decentralized Solana ledger.

Verification requires only a single RPC call to fetch the PDA. There are no complex Aries agents to spin up, no proprietary mobile wallet requirements, and no massive consortium memberships to negotiate.

DimensionHyperledger Aries/IndySAS on Solana
Credential locationMobile wallet (off-chain)On-chain PDA
If device is lostCredential goneStill on-chain, re-fetchable
Verification methodAgent-to-agent protocolSingle RPC call
Infrastructure neededAries agents + Indy ledger + wallet appAny Solana RPC endpoint
Consortium requiredYes (governance agreements)No (public chain)
Server crash impactVerification may failCredential still live on-chain

Revocation: Account Deletion vs. Revocation Registries

The most profound advantage of the SAS architecture becomes apparent when addressing the hardest problem in digital identity: credential revocation.

How do you prove that a credential—which might be stored on an offline device—has not been revoked by the government since it was issued? In traditional decentralized identity networks like Hyperledger Indy, revocation is managed through highly complex cryptographic structures known as Revocation Registries and zero-knowledge accumulators.

This accumulator architecture inevitably leads to the "stale window" problem—a dangerous lag time where a revoked credential might still pass verification because the local registry hasn't synced, or the batch hasn't propagated.

SAS eliminates this complexity through the uncompromising finality of the Solana state machine. We don't use revocation registries. We delete the account.

// Revocation: one instruction, instant, global
const closeIx = getCloseAttestationInstruction({
  payer: issuer,
  authority: issuer,
  credential: credentialAddress,
  schema: schemaAddress,
  attestation: attestationAddress,
});

// After execution:
const after = await fetchMaybeAttestation(rpc, attestationAddress);
console.log("Exists:", after.exists);  // false
// All downstream instructions immediately fail
  • Instant & Global: Revocation propagates globally in ~400ms, compared to seconds for Fabric peer gossip or weeks for paper-based notification
  • Binary Certainty: No "non-revocation proofs" to calculate. If the PDA exists, the credential is live. If fetchMaybeAttestation returns exists: false, the credential is dead. All downstream smart contract instructions immediately and permanently fail.
  • Rent Recovery: The underlying SOL rent is reclaimed—Fabric data persists indefinitely, SAS cleans up after itself
FeatureIndy Revocation RegistrySAS Account Deletion
MechanismCryptographic accumulator updateClose PDA instruction
PropagationBatch sync (minutes to hours)~400ms (Solana finality)
Stale windowYes (until sync completes)None (instant state change)
Proof requirementNon-revocation proof per verificationAccount existence check
Storage costAccumulates (data persists)SOL reclaimed on close

On-Chain Validation: 5-Point + 8-Point Verification

While SAS provides the robust infrastructure for holding and revoking the attestation, enterprise applications require strict verification parameters. Adduce achieves this through a combination of off-chain zero-knowledge proofs and rigid on-chain validation.

When a lawyer attempts to link a citizen's credential to an active case, the verification process does not rely on human oversight. The Adduce protocol (deployed on Devnet at 3f1yBTY6xb6ESdzzb9LxAozv7uVsj9Y9AMEpnAwKJRNV) executes a 5-point on-chain validation within the link_credential instruction:

#CheckWhat It Validates
1Owner CheckAccount owner == SAS Program (22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG)
2Schema MatchParsed schema matches expected_schema in jurisdiction config
3Expiry CheckAttestation expiry > current timestamp
4Citizen BindingNonce (citizen pubkey) matches case applicant
5Commitment RootPoseidon hash of all credential fields verified

The client-side verification script performs an exhaustive 8-point check:

  1. Attestation Exists: Confirms the PDA is actively live on-chain
  2. Issuer Authenticity: The signer mathematically matches the expected government public key
  3. Credential Address: Validates the top-level credential hierarchy
  4. Schema Match: Ensures the data template exactly matches the required [12, 12, 8] layout
  5. Nonce Verification: The nonce securely matches the citizen's pubkey (or hashed national ID)
  6. Jurisdiction Enforcement: Confirms the parsed jurisdiction equals the required region (e.g., "DE")
  7. Liveness Check: Validates expiry > now
  8. Consistency: Ensures the on-chain expiry matches the underlying data expiry

Raw Byte Parsing in the Anchor Program

To achieve this natively within the Rust smart contract, the Anchor program utilizes parse_sas_attestation(). Because the SAS Program utilizes deterministic byte layouts, the Adduce contract can parse the raw bytes at hardcoded offsets—specifically extracting the nonce at NONCE_OFFSET=1 and the schema data at SCHEMA_OFFSET=65.

// From programs/legal-aid/src/lib.rs
const SAS_NONCE_OFFSET: usize = 1;
const SAS_SCHEMA_OFFSET: usize = 65;

fn parse_sas_attestation(data: &[u8]) -> Result<(Pubkey, i64, Pubkey)> {
    let nonce_bytes: [u8; 32] = data[SAS_NONCE_OFFSET..SAS_NONCE_OFFSET + 32]
        .try_into().unwrap();
    let schema_bytes: [u8; 32] = data[SAS_SCHEMA_OFFSET..SAS_SCHEMA_OFFSET + 32]
        .try_into().unwrap();
    // ... extract schema, expiry, nonce_pubkey
    Ok((schema, expiry, nonce_pubkey))
}

Furthermore, the check_credential_liveness() function guarantees that the PDA still exists and is owned by the SAS program at every critical juncture, including close_case, anchor_document, and mark_paid.

Privacy Layer: ZK Proofs Over SAS Attestations

To ensure GDPR compliance and data minimisation during verification, the underlying data is shielded by a 256-byte Groth16 zero-knowledge proof. Operating over the BN254 curve with 7,883 circuit constraints, the holder proves their eligibility off-chain. The Solana execution layer then verifies this proof natively via the alt_bn128 syscall for a computational cost of approximately $0.0001.

256
Bytes per proof
7,883
Circuit constraints
$0.0001
Verification cost
3
Facts disclosed

The proof reveals only three required facts—jurisdiction, credential validity (not expired), and issuer authenticity—while keeping all other private fields (eligibility tier, exact expiry date, applicant identity, case type, all salts) completely hidden.

The Full Comparison

MetricIBM Verify (Centralized IAM)Hyperledger Aries/IndySAS + Adduce
Cost per user$1.92-2.27/monthConsortium infrastructure$0.004 per credential
Vendor lock-inProprietary SAML/OIDCConsortium governanceNone (public chain)
Credential locationCentral identity vaultMobile walletOn-chain PDA
Revocation speedAdmin action + propagationAccumulator sync (mins-hrs)~400ms (account deletion)
Stale windowCache TTL dependentYes (batch sync)None
Privacy modelAccess-controlZK accumulators (CL sigs)Groth16 proofs (256 bytes)
Cross-borderFederation agreementsMulti-ledger coordinationAny Solana RPC endpoint
Server crash impactIdentity system downWallet still works, verification fragileCredential live on-chain

Conclusion

The integration of the Solana Attestation Service with Adduce's zero-knowledge architecture represents the maturation of public blockchain infrastructure for enterprise use. Government IT leaders no longer need to accept the massive licensing costs, data silos, and centralized vulnerabilities of legacy systems like IBM Verify. Nor do they need to wrestle with the overwhelming complexity and stale-window risks of early decentralized wallets.

With an issuance cost of $0.004, global settlement in 400ms, and instant, mathematically guaranteed revocation, the technology is finally ready to meet the strict demands of global compliance.

There are no consortiums to join. There is no vendor lock-in. There is only working code.

View on npm | Documentation | GitHub

← Back to all posts