Post-quantum verification infrastructure

Post-quantum eligibility verification without holding personal data

AffixIO issues cryptographically signed yes or no eligibility proofs using Noir zero-knowledge circuits and ML-DSA-65 post-quantum signatures. Verifiers receive a binary outcome with Merkle audit evidence. No personal data is retained at the boundary. Integrate via REST API, Node.js SDK, or secure QR.

Contact Us Try the sandbox Documentation

ML-DSA-65 post-quantum signatures
Zero PII retention at the verifier
REST API and Node.js SDK
Proofs on your infrastructure

At a glance

What AffixIO provides

Post-quantum signatures (ML-DSA-65)
Zero PII retention
Proofs run on your infrastructure
API-first

Product: Stateless yes/no eligibility verification with signed cryptographic proof
Signatures: ML-DSA-65 post-quantum (NIST FIPS 204)
Proofs: Noir zero-knowledge circuits via open-source Barretenberg stack
Data retention: None at the verifier by default; in-memory API processing only
Integration: REST API, Node.js SDK (@affix-io/sdk), secure QR, MCP connector
Company: AffixIO, Wales, UK. GB patent application pending.

The problem

Forged documents, manual checks, and systems that hoard personal data

High-trust workflows need a signed yes or no at the boundary, not another database of identity records.

Instant authenticity checks

Signed allow or deny on every request. Gate staff and downstream systems get a binary answer backed by cryptographic evidence.

Less manual review

Spent-proof logic for QR tickets stops copies and replays before they reach the turnstile. Policy runs once at issue, not at every gate.

Selective disclosure

Noir zero-knowledge circuits prove policy compliance without exposing underlying personal data to every verifier in the chain.

API and SDK integration

REST API, Node.js SDK, and MCP connector. Call once at the boundary. Core systems stay unchanged.

Platform

Verification primitives on one infrastructure layer

Issue credentials, verify at the edge, and retain tamper-evident proof trails on the same API surface.

Credential issuance

Bind policy, expiry, and event context at issue time. Outcomes carry verifiable metadata from the start.

QR verification

Proof embedded in the code. Scanners verify locally without live database access in the scan path.

Verification API

Public REST API on api.affix-io.com. Circuit verify, health, and Merkle audit endpoints. OpenAPI published.

Node.js SDK

Prove, verify, and witness prep on npm. Proof generation can run entirely on your infrastructure.

Merkle audit trail

Tamper-evident proof events anchored in a Merkle tree. Public inclusion proofs for regulators and internal audit.

Post-quantum architecture

ML-DSA-65 signatures aligned with NIST FIPS 204. Long-lived proofs that resist harvest-now-decrypt-later risk.

Read the documentation

How verification works

Issue, bind, present, verify

Four steps from policy to signed outcome. The same flow powers API calls, QR gates, and agent boundaries.

Issue

Your system defines eligibility rules and requests a credential or proof packet.

Procurement and compliance teams get a repeatable policy boundary instead of ad hoc checks.

POST /verify · circuit: yesno | kyc | health_age · Noir + Barretenberg
Bind

Policy, expiry, and context are bound cryptographically. The proof cannot be reused outside its scope.

Fraud teams can trace every outcome back to the rule set that produced it.

event_id · expiry · spent-proof flag · ML-DSA-65 signature
Present

The holder presents via QR scan, API call, or agent gate. No central lookup required at the edge.

Gate staff and field teams work offline when connectivity is poor.

surface: api | qr | agent | offline
Verify

Verifier receives allow or deny with signed evidence. Auditors can replay the proof without seeing raw PII.

Regulators and internal audit get tamper-evident records, not mutable logs.

outcome: ALLOW | DENY · sig + merkle ref

Solutions

Where signed outcomes matter

Sector workflows built on the same verification primitives: policy in, ML-DSA-65 signed allow or deny out, Merkle-ready proof for audit.

Government and public services

Public programmes need eligibility at the service point without assembling a citizen profile at every gate.

Challenge: Eligibility checks often pull more personal data than the decision needs. Shared databases create retention risk, and auditors still struggle to prove what was decided, when, and under which policy version.
Where it fits: Benefits and licensing gates, partner delivery checks, age-restricted public digital services, and any workflow where the operator needs a yes or no without holding the underlying identity record.
Workflow: Your system evaluates policy per request (or asks AffixIO to sign a prepared decision). The response is an ML-DSA-65 signed allow or deny with a Merkle-ready proof reference. Caseworkers and auditors verify the outcome without reopening the full case file.
Primitives: Stateless verification API, optional zero-knowledge predicates for age or eligibility attributes, proof-not-log audit trail, client-side proof generation via SDK where credential data must stay on your infrastructure.
Outcome: Defensible decisions for auditors and delivery partners. Less PII at the gate. A replayable proof that survives staff changeover and system swaps.

Government sector Government programmes Privacy-preserving age check Proof-not-log audit

Spirits and luxury goods authentication

Physical goods need authenticity checks that work in shops and warehouses without publishing the supply chain map.

Challenge: Counterfeit bottles, grey-market diversion, and reused labels undermine brand trust and duty revenue. Static barcodes and marketing QR codes are easy to copy. Field teams need a check that does not expose batch recipes, customer lists, or full logistics history.
Where it fits: Bottling or dispatch binding, retail spot-checks, warehouse intake, partner authenticity programmes, and brand verification flows where a phone scan should return a signed authenticity decision.
Workflow: Cryptographic binding at packaging or dispatch. The customer or inspector scans a QR. The verifier returns signed authenticity or refusal. Spent-proof flags stop the same proof being replayed as a fresh bottle later.
Primitives: Signed allow or deny, QR-bound proofs, anti-replay spent flags, offline-capable verify patterns where retail connectivity is weak.
Outcome: Field verification that is hard to forge and easy to audit. Brand teams keep supply detail private while still proving the bottle or item is genuine at the point of check.

Brand partnerships Collaboration programmes Offline gate verification

Workforce and training credentials

Site access should depend on current qualifications, not paper certificates that can be forged or left out of date.

Challenge: Forged cards, lapsed tickets, and photocopied certificates create safety and compliance risk at site entry. HR and LMS databases are the source of truth, but gate staff should not need full HR access to decide whether someone may enter a restricted zone.
Where it fits: Construction and industrial site turnstiles, contractor induction, training expiry gates, visitor badges with time-bound access, and partner sites that must accept credentials issued by another organisation.
Workflow: Issue training or clearance proofs with expiry and scope. Gate readers call verify and receive a signed allow or deny for the requested zone or role. No live join into the HR database at the turnstile.
Primitives: Time-bound proofs, policy-scoped allow or deny, Merkle audit for entry decisions, optional offline verify for remote sites.
Outcome: A clear entry decision at the boundary. Auditors can confirm who was allowed in and under which credential version, without exporting HR records to every gate device.

Access control sector Offline gate verification Proof-not-log audit

Events and ticketing

Gates need a yes or no that survives poor connectivity and resists screenshot reuse.

Challenge: Queues stall when the network drops. Static barcodes and screenshots bypass weak ticket checks. Resale and scalping abuse thrives when the same pass can be presented many times before the first successful entry is recorded.
Where it fits: Arenas, festivals, stadium turnstiles, multi-day passes, age-restricted entry, and ticketing platforms that need offline-capable verify with one-scan entry semantics.
Workflow: Proof is bound into the QR at issue. Gate devices verify locally when connectivity is weak, then sync spend state when online. A spent-proof flag enforces one successful entry per pass for that gate policy.
Primitives: Offline gate verification, spent-proof anti-replay, double-spend prevention patterns, signed entry outcomes for dispute handling.
Outcome: Faster entry under load, fewer fraudulent passes, and a signed record when a guest disputes a refused scan.

Offline tickets sector Anti-scalping tickets Offline gate verification Ticketing platforms

Regulated enterprise and agent workflows

Automations and AI agents need a signed permission boundary before consequential actions.

Challenge: API keys and shared service accounts prove identity of a caller, not that a specific action was authorised under current policy. Agents can call tools, move funds, or change customer records without a verifiable allow or deny at the boundary.
Where it fits: Agent tool calls (including MCP), delegated spend and agentic payments, high-risk workflow steps, shadow-AI controls, and any enterprise path that needs Know Your Agent style permission evidence.
Workflow: Before the action, request a signed allow or deny against policy version, agent identity, and tool scope. Store the proof reference with the business event. Downstream systems can verify the signature without trusting a free-text log line.
Primitives: Agent permissions and authorisation gates, REST and SDK integration, MCP verification connector, proof-not-log audit, post-quantum signatures on long-lived decisions.
Outcome: Explicit boundaries agents cannot override silently. Security and compliance teams get decision evidence that still holds when chat logs are incomplete or redacted.

AI agents sector Agent permissions Agent authorisation Agentic payments MCP connector

Telecommunications

Retail age gates, field engineer access, and partner APIs need eligibility without copying customer or staff records into every channel system.

Challenge: SIM activation, age-restricted services, contractor site access, and wholesale partner APIs often pull more identity than the decision needs. Channel systems become parallel copies of CRM and HR data.
Where it fits: Retail age assurance, handset finance eligibility, engineer site clearance, MVNO and partner API boundaries, and high-risk account changes that need a signed policy check.
Workflow: Evaluate policy at the channel boundary. Return ML-DSA-65 signed allow or deny with a Merkle-ready proof reference. Downstream systems verify the outcome without a live CRM join at every POS or field tablet.
Primitives: Stateless verification API, privacy-preserving age predicates, time-bound site clearance proofs, proof-not-log audit for dispute and regulator review.
Outcome: Faster channel decisions with less PII sprawl, and auditable evidence when a sale, activation, or site entry is challenged.

Telecommunications sector Privacy-preserving age check Access control Proof-not-log audit

Automotive

Dealership, plant, and parts workflows need signed eligibility at gates where forged credentials and grey-market components create safety and warranty risk.

Challenge: Contractor access to plant zones, technician certifications, warranty claims, and parts authenticity checks rely on paper or static barcodes that are easy to forge. OT and dealer systems should not hold full HR or supplier dossiers at every gate.
Where it fits: Plant and paint-shop entry, dealer workshop authorisation, certified technician proofs, parts intake authenticity, and connected-vehicle service actions that need a policy gate before privileged diagnostics.
Workflow: Issue time-bound clearance or authenticity proofs. Gate or service systems verify and receive signed allow or deny. Spent-proof and expiry stop reused passes and stale certifications.
Primitives: Access-control proofs, QR-bound authenticity, offline-capable verify for plant floors, Merkle audit for warranty and safety investigations.
Outcome: Clear decisions at plant and dealer boundaries, with evidence that holds when a warranty, recall, or incident review starts months later.

Manufacturing sector Transportation sector Access control Offline gate verification

Transport and mobility

Operators need fast, auditable eligibility at gates and depots, including when connectivity is weak.

Challenge: High-throughput entry points fail open or fail closed for the wrong reasons when the network drops. Screenshots and reused passes create fraud. Depot and crew access still needs a defensible yes or no.
Where it fits: Rail and bus gates, ferry and port embarkation, depot and crew access, concession entitlement checks, and mobility programmes that must prove entry decisions after the fact.
Workflow: Bind proof into the pass at issue. Verify at the gate with spent-proof anti-replay. Sync spend state when online. Keep a signed outcome for dispute handling.
Primitives: Offline gate verification, spent-proof anti-replay, double-spend prevention patterns, Merkle-ready entry evidence.
Outcome: Faster gates under load, fewer fraudulent entries, and auditable decisions for operators and regulators.

Transportation sector Offline gate verification Anti-scalping tickets Double-spend prevention

Finance and payments

Payment, programme, and partner boundaries need signed allow or deny that complements regulated KYC without re-copying documents into every downstream system.

Challenge: Once KYC is complete, many downstream systems still pull full identity packs for routine eligibility. Agent-initiated payments and delegated spend lack a verifiable permission check at the money movement boundary.
Where it fits: Programme eligibility after onboarding, partner and correspondent boundaries, step-up checks for high-risk payments, and agentic payment flows that need Know Your Agent style permission evidence.
Workflow: Before the action, request a signed allow or deny against policy version, party or agent identity, and transaction scope. Attach the proof reference to the payment or case event.
Primitives: Stateless verification API and SDK, agent permissions for delegated spend, proof-not-log audit, post-quantum signatures on long-lived payment decisions.
Outcome: Less document sprawl after KYC, clearer payment boundaries, and decision evidence that still holds when chat or ops logs are incomplete.

Finance sector Agentic payments Fintech and payments Agent permissions

Energy and critical infrastructure

Sites, substations, and contractor boundaries need defensible yes or no decisions without standing up another identity copy in every OT vendor system.

Challenge: Contractors, vendors, and rotating crews move across plants and field assets. Badge systems and OT vendors often hold overlapping copies of clearance data. Incident reviews need proof of who was allowed where, under which policy.
Where it fits: Plant and substation gates, field job permits, vendor zone access, safety training expiry, and partner boundaries into generation, transmission, or distribution assets.
Workflow: Issue clearance proofs with zone scope and expiry. Gate and permit systems verify and receive signed allow or deny. Audit teams replay Merkle-ready evidence after an incident or inspection.
Primitives: Access-control proofs, time-bound credentials, offline-capable verify for remote sites, proof-not-log audit for regulated operators.
Outcome: Clearer site boundaries, less PII in OT tools, and evidence that supports safety and regulatory review.

Energy sector Utilities sector Access control Proof-not-log audit

Aerospace and defence

Programmes need clear eligibility at facilities and partner boundaries, with post-quantum signatures suited to long-lived audit expectations.

Challenge: Facility access, export-control relevant workflows, and partner collaboration require decisions that remain verifiable for years. Shared identity copies across primes and suppliers expand exposure without improving proof quality.
Where it fits: Facility and secure-area gates, contractor clearance checks, partner data-room or tool access, and programme steps that need a signed policy decision before privileged work begins.
Workflow: Evaluate clearance or programme policy at the boundary. Return ML-DSA-65 signed allow or deny with a Merkle-ready proof reference retained with the programme event.
Primitives: Post-quantum attestation, access-control proofs, proof-not-log audit, client-side proof generation where credential data must stay on programme infrastructure.
Outcome: Defensible facility and partner decisions with long-lived cryptographic evidence, without growing another PII silo at every gate.

Aerospace and defence sector Access control PQC migration Proof-not-log audit

Manufacturing

Plants mix employees, contractors, and visitors across OT systems. Gates and line boundaries need signed allow or deny without another PII silo.

Challenge: Shift changes, contractors, and visitors create constant entry decisions. OT vendors and temporary badges often copy more personal data than the gate needs. Line and clean-room access still needs current training and clearance status.
Where it fits: Plant turnstiles, line and clean-room zones, contractor induction, visitor time-boxes, and supplier intake authenticity checks.
Workflow: Issue proofs with zone scope and expiry. Readers verify and receive signed allow or deny. Optional offline verify keeps gates moving when plant Wi-Fi is unreliable.
Primitives: Access-control proofs, offline gate verification, authenticity binding for parts where needed, Merkle audit for safety investigations.
Outcome: Safer plant boundaries with less identity sprawl in OT tools, and evidence that supports incident and compliance review.

Manufacturing sector Access control Offline gate verification Proof-not-log audit

Sports and venues

Stadiums, arenas, and multi-sport venues need signed entry and accreditation decisions that hold for every fixture type, from league matches to major tournaments.

Challenge: Football, rugby, cricket, tennis, motorsport, athletics, basketball, hockey, combat sports, and multi-sport events all share the same failure modes: queue collapse when connectivity drops, screenshot reuse, scalped passes, and staff or media accreditation that is hard to revoke in real time.
Where it fits: Matchday and race-day turnstiles, season tickets and memberships, cup and tournament passes, hospitality and lounge tiers, youth and age-restricted areas, media and photographer accreditation, athlete and team compound access, steward and contractor clearance, parking and park-and-ride, and secondary gates for training grounds or satellite venues.
Workflow: Bind proof into the ticket or accreditation at issue, including section, day, or zone scope. Gate devices verify with spent-proof anti-replay, including offline-capable lanes. Sync spend and audit state when connectivity returns. Age or membership predicates can return allow or deny without exposing full fan identity at the scanner.
Primitives: Offline gate verification, spent-proof anti-replay, anti-scalping ticket patterns, time and zone-bound accreditation, privacy-preserving age checks, Merkle-ready entry evidence for disputes and safety reviews.
Outcome: Faster entry across sports calendars, fewer fraudulent and duplicated passes, clearer staff and media boundaries, and signed evidence when a refused scan or incident review needs a defensible record.

Offline tickets sector Anti-scalping tickets Offline gate verification Ticketing platforms Age verification Access control

Security and architecture

Cryptographic integrity at the verification boundary

ML-DSA-65 signatures, Noir zero-knowledge proofs, in-memory-only API processing, client-side proof generation via SDK, and a tamper-evident Merkle audit trail.

ML-DSA-65 signatures

Post-quantum lattice signatures aligned with NIST FIPS 204. Every proof outcome carries a signature verifiers can check independently.

Zero-knowledge circuits

Noir circuits compiled with the open-source Barretenberg stack. Prove policy compliance without exposing underlying credential fields.

No data written to disk

API requests are processed in memory and discarded after signing. No PII is retained at the verifier by default.

Client-side proof generation

The Node.js SDK can generate proofs on your infrastructure. Credential data never has to reach AffixIO servers.

Merkle audit trail

Proof events anchored in a Merkle tree. Public inclusion proofs for replayable audit evidence.

Responsible disclosure

Security issues reported via security.txt. Documented architecture and trust materials published on the site.

Security architecture Technical architecture

Developers

REST API, SDK, sandbox, and docs

Start with the live sandbox or install the Node.js SDK. No framework lock-in.

REST API

OpenAPI 1.4.2 · spec · api.affix-io.com

Node.js SDK

@affix-io/sdk on npm. Prove and verify on your infrastructure.

Sandbox

Live endpoints without local setup.

Documentation

Quickstart · Noir circuits · Merkle audit

Read the docs

verify.js

import { verifyProof } from "@affix-io/sdk";

const { allowed, proof_id } = await verifyProof({
  apiKey: "YOUR_DEMO_KEY",
  proof: "YOUR_PROOF_HEX",
  circuit: "yesno",
  requestAttestation: true,
});

Demo keys via contact or use the sandbox without a key.

Wales, United Kingdom

Built in Wales for high-trust workflows

AffixIO is verification infrastructure built in Wales. The platform is live: public API, Node.js SDK, sandbox, and published field reports. GB patent application pending.

FAQ

Common questions

What does cryptographic verification mean?

Each allow or deny outcome is backed by a signed proof that can be checked later. Verifiers confirm the decision was issued correctly without re-running the full check or exposing underlying personal data.

How does QR verification work?

Proof is embedded in the QR code at issue time. Gate scanners verify locally, mark the code as spent, and do not need live database access or personal data in the scan path.

What data does AffixIO store?

None is retained at the verifier by default. AffixIO evaluates each request in memory, signs the outcome, and discards the input. Optional Merkle audit entries record proof metadata, not underlying credential fields.

What are post-quantum signatures?

AffixIO uses ML-DSA-65, a lattice-based signature scheme aligned with NIST FIPS 204. Proofs signed today remain verifiable if large-scale quantum computers break current public-key algorithms.

How do developers get started?

Use the live sandbox at affix-io.com/sandbox, read the quickstart at affix-io.com/docs/quickstart, or install the Node.js SDK @affix-io/sdk from npm. OpenAPI spec and Postman collection are published on the site.

Does verification work offline or with poor connectivity?

QR proofs verify on-device at the gate without connectivity. The same spent-proof flag prevents reuse when the device syncs later.

Can AffixIO integrate with existing systems?

AffixIO sits beneath your stack as a thin verification layer. Call it at the boundary via REST API, npm SDK, or MCP connector. Core systems stay unchanged.

Start with a conversation or the sandbox

Talk to us Try the sandbox