Stateless Eligibility Verification: Cryptographic Approaches

Why Stateless Verification Matters

Legacy systems verify eligibility by querying databases, creating a four-step process: user/agent initiates transaction, system queries external database, database returns eligibility status, and system authorizes or denies transaction. This approach creates critical problems for agent-based systems:

• Latency: Database queries add milliseconds to transaction time
• Availability: If database is down, transactions fail
• Centralization: Single point of failure and control
• Privacy: Merchants learn information beyond yes/no verification
• Coordination: Cross-border transactions require multiple database queries

Stateless verification flips this: instead of querying databases, the user/agent provides cryptographically signed proofs of eligibility. The merchant verifies the proofs locally.

Proof-Based Eligibility Architecture

Instead of querying a database, users submit cryptographic proofs. Each proof contains the eligibility claim, issuer signature, proof type, Merkle root, user ID, proof path, validity window, and issuer signature.

Proof Techniques

Merkle Tree Proofs: User is included in a verified tree of all eligible entities. Issuer publishes tree root; user provides path to root. Proof size: O(log n). Most commonly used due to simplicity and efficiency.

Zero-Knowledge Proofs: Prove a property (e.g., age > 21) without revealing the actual value. Strong privacy guarantees.

Signed Attestations: Issuer signs claim: "User XYZ is eligible for benefit Y". Simple but requires trusting issuer.

Accumulator Proofs: Compact cryptographic proof of membership in a set. More efficient than Merkle trees for large sets.

Commitment Proofs: User commits to eligibility data via hash. Can later prove commitment was valid without revealing original data.

Verification Process

1. Merchant receives eligibility proof from user/agent
2. Check issuer's signature using issuer's public key (cached or retrieved)
3. Verify proof is not expired and was issued after some cutoff date
4. For Merkle proofs: recompute hash path. For ZK: verify proof satisfies claim
5. Optional: query revocation registry to ensure proof hasn't been revoked

Real-World Implementation: Age-Verified Purchase

Legacy approach: Customer shows ID, retailer scans ID number, retailer queries DMV database, DMV responds with yes/no, retailer completes or denies transaction.

Stateless approach with AffixIO: Customer obtains age-verified proof from DMV once (valid 6 months), downloads proof to phone, initiates purchase with proof submitted, retailer verifies proof locally, transaction completes in milliseconds.

Benefits: Speed (microseconds vs network latency), Privacy (merchant learns only "age >= 21"), Offline capability (works without connection), and Scaling (no central bottleneck).

Proof Freshness and Revocation

One challenge with stateless proofs is ensuring they remain valid through time-bound proofs that expire after N months, revocation registries where issuers publish revoked proofs, proof rotation by issuers periodically, and real-time anchors for high-risk transactions.

Privacy Considerations

Stateless verification offers significant privacy advantages: no tracking (issuer doesn't know when/where user uses proof), minimal disclosure (merchant learns only yes/no), user control (user chooses when to share proof), and ZK enhancements (further hide eligibility criteria).

Cross-Border and Cross-Domain Verification

Stateless verification enables verification across domains without central coordination through multi-issuer support, proof composition (combine multiple proofs), and no intermediary needed.

The Future: Universal Proof Formats

As stateless verification matures, we'll see standardized proof formats, proof exchanges as markets, proof aggregation services, and decentralized verification nodes competing on speed and cost.