Attestations
An attestation is the portable, on-chain proof that a wallet passed verification. It is the unit every other part of Passify reads from.
What an attestation is
An attestation links a Solana wallet to a verification result without revealing the underlying data. It is signed by Passify's attester key and stored on-chain, so any integrated platform can confirm — independently and permissionlessly — that the wallet was verified under a given schema.
Fields
| Field | Description |
|---|---|
attestation_id | Stable internal identifier, e.g. att_5m8n. |
user_pubkey | The verified wallet (base58 Solana public key). |
schema_id | What was verified, e.g. kyc_accredited_v1. |
data_hash | SHA-256 of the KYC result payload. One-way; never reversible. |
attester_pubkey | Passify's on-chain signing key. |
onchain_tx | Solana transaction signature for the attestation write. |
expires_at | When the attestation lapses and must be renewed. |
Reading an attestation by ID returns these fields:
{
"attestation_id": "att_5m8n",
"user_pubkey": "7xKXtg2...",
"schema": "kyc_accredited_v1",
"status": "verified",
"data_hash": "a1b2c3d4e5f6...",
"onchain_tx": "3kLm...xyz",
"expires_at": "2026-12-15T00:00:00Z"
}Lifecycle
- Issued — written on-chain after the KYC provider approves.
- Verified — active and within its validity window; reads return
verified. - Expired — past
expires_at; token operations are refused until renewal.
What it never contains
No name, date of birth, address, government ID, document image, or country string in plaintext. Identity data lives only with the KYC provider. The on-chain record is a hash plus the metadata above — see Security.
Common mistakes
- Treating a hash as data.
data_hashproves integrity, not contents — you cannot read identity from it. - Ignoring expiry. Always check
expires_atbefore relying on an attestation; an expired one fails enforcement. - Assuming one schema fits all. A retail check does not satisfy an accredited-only asset. Match the schema to the rule.
Last updated