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.
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.
| Layer | PDA Derivation | Purpose | Government Analogue |
|---|---|---|---|
| Credential | authority + name | Top-level issuer identity | Ministry of Justice |
| Schema | credential + name + version | Data template definition | Certificate format spec |
| Attestation | credential + schema + nonce | Individual citizen claim | Legal 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.
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.
| Dimension | Hyperledger Aries/Indy | SAS on Solana |
|---|---|---|
| Credential location | Mobile wallet (off-chain) | On-chain PDA |
| If device is lost | Credential gone | Still on-chain, re-fetchable |
| Verification method | Agent-to-agent protocol | Single RPC call |
| Infrastructure needed | Aries agents + Indy ledger + wallet app | Any Solana RPC endpoint |
| Consortium required | Yes (governance agreements) | No (public chain) |
| Server crash impact | Verification may fail | Credential 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
fetchMaybeAttestationreturnsexists: 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
| Feature | Indy Revocation Registry | SAS Account Deletion |
|---|---|---|
| Mechanism | Cryptographic accumulator update | Close PDA instruction |
| Propagation | Batch sync (minutes to hours) | ~400ms (Solana finality) |
| Stale window | Yes (until sync completes) | None (instant state change) |
| Proof requirement | Non-revocation proof per verification | Account existence check |
| Storage cost | Accumulates (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:
| # | Check | What It Validates |
|---|---|---|
| 1 | Owner Check | Account owner == SAS Program (22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG) |
| 2 | Schema Match | Parsed schema matches expected_schema in jurisdiction config |
| 3 | Expiry Check | Attestation expiry > current timestamp |
| 4 | Citizen Binding | Nonce (citizen pubkey) matches case applicant |
| 5 | Commitment Root | Poseidon hash of all credential fields verified |
The client-side verification script performs an exhaustive 8-point check:
- Attestation Exists: Confirms the PDA is actively live on-chain
- Issuer Authenticity: The signer mathematically matches the expected government public key
- Credential Address: Validates the top-level credential hierarchy
- Schema Match: Ensures the data template exactly matches the required
[12, 12, 8]layout - Nonce Verification: The nonce securely matches the citizen's pubkey (or hashed national ID)
- Jurisdiction Enforcement: Confirms the parsed jurisdiction equals the required region (e.g., "DE")
- Liveness Check: Validates
expiry > now - 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.
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
| Metric | IBM Verify (Centralized IAM) | Hyperledger Aries/Indy | SAS + Adduce |
|---|---|---|---|
| Cost per user | $1.92-2.27/month | Consortium infrastructure | $0.004 per credential |
| Vendor lock-in | Proprietary SAML/OIDC | Consortium governance | None (public chain) |
| Credential location | Central identity vault | Mobile wallet | On-chain PDA |
| Revocation speed | Admin action + propagation | Accumulator sync (mins-hrs) | ~400ms (account deletion) |
| Stale window | Cache TTL dependent | Yes (batch sync) | None |
| Privacy model | Access-control | ZK accumulators (CL sigs) | Groth16 proofs (256 bytes) |
| Cross-border | Federation agreements | Multi-ledger coordination | Any Solana RPC endpoint |
| Server crash impact | Identity system down | Wallet still works, verification fragile | Credential 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.