AFFIXIO
Stateless verification
Stateless eligibility verification
Eligibility checks traditionally copy records into every downstream system. Stateless verification returns a signed outcome and leaves source data where it belongs. AffixIO issues allow or deny with ML-DSA-65 signatures and Merkle audit, with zero PII at the verifier by default.
Definition
Stateless eligibility verification means the verifier receives allow or deny plus proof metadata without retaining a standing database of personal records.
Field note. Central eligibility stores become breach targets. Stateless proofs answer yes or no without retaining source documents.
What stateless means in practice
The verifier does not retain a standing eligibility database of personal records by default. It checks signatures, evaluates the presented proof, and returns allow or deny. Source systems remain authoritative for the underlying attributes.
Noir circuits can prove predicates such as age or programme membership without exporting the raw attributes to the gate. ML-DSA-65 signs the outcome so counterparties can trust it later.
Where teams apply it
Government programme gates, retail age checks, partner API access, and agent eligibility all fit the pattern. Compare AffixIO with traditional verification databases when procurement asks why you are not standing up another silo.
Start in the sandbox with a yes/no circuit, then map issuer and verifier roles to your existing systems of record.
Rollout notes for stateless eligibility
Place issue at consent or policy satisfaction, then verify at the first external boundary. Deny should return a stable code for support. Allow should attach Merkle metadata to the record your finance or ops team already stores.
When WAN is unreliable, run local verify with cached keys and sync Merkle inclusion later. Offline QR and edge agents use the same spent-proof rules as online gates.
Design gap
Why every vendor ends up with a copy
Repeat queries push teams to cache identity locally. That cache becomes a breach target and a retention liability, even when the business only needed a yes or no.
Record sprawl
Each partner that needs eligibility often receives a full extract, not a scoped outcome.
Stale caches
Local copies drift from the source of truth and create false allows or denies.
Audit ambiguity
Logs of lookups are not the same as a signed decision an auditor can re-verify.
Regulatory pressure
Minimisation principles favour outcomes over document retention at every boundary.
Verifier posture
Eligibility checks without a central identity vault
Regulators and partners want proof someone met criteria, not a copy of every document that proved it. AffixIO issues stateless eligibility proofs verifiers can check offline, with Merkle audit on the transaction.
Keep source of truth upstream
Issuer systems hold records. AffixIO verifies outcomes downstream.
Choose the predicate
Age, membership, agent policy, or custom circuit from the catalogue.
Issue and verify
Mint proofs, present at the gate, receive signed allow or deny.
Retain only audit refs
Store Merkle references, not document images, at the verifier.
Launch gates
Readiness checks for stateless eligibility
- Confirm which attributes must never leave the issuer.
- Select circuits that match the business predicate.
- Configure zero PII retention at verifier endpoints.
- Document allow/deny handling for operators.
- Compare against KYC-database approaches for stakeholders.
Security FAQ
Questions on stateless eligibility
What does stateless mean here?
The verifier does not retain a standing eligibility database of personal records by default.
Does this replace regulated KYC?
No. Issuers still perform regulated checks. AffixIO verifies outcomes without re-copying documents.
Can we run on-prem?
Yes. The SDK supports issue and verify on infrastructure you control.
How is this audited?
Merkle-anchored proof references can be re-checked without reconstituting PII at the gate.
Deepen here
Pages that support stateless eligibility
Privacy and identity
More privacy and identity briefs
Prototype stateless eligibility gates
Run issue and verify on an eligibility circuit, then attach the verifier to your entry or checkout boundary.