Instant authenticity checks
Signed allow or deny on every request. Gate staff and downstream systems get a binary answer backed by cryptographic evidence.
AffixIO · PQC verification · SDK 2.3.0
Eligibility proofs for a post-quantum computing world, without holding personal data
AffixIO returns a signed allow or deny for age, KYC outcomes, tickets, site access, and agent permissions. Built for post-quantum computing (PQC) with Noir zero-knowledge circuits and ML-DSA-65 (FIPS 204) attestation. Run prove and verify from @affix-io/sdk on your host, or call the REST API. Merkle audit when you need replayable evidence.
- PQC attestation with ML-DSA-65
- Prove and verify on your infrastructure
- Zero PII retention at the verifier
- Merkle audit and offline prove queue
At a glance
What AffixIO provides
Verification infrastructure for signed yes or no outcomes, plus a Node.js SDK that runs prove, verify, witness prep, gates, and audit from your own services.
Platform
- Stateless eligibility verification Allow or deny with cryptographic proof for age, KYC outcomes, residency, tickets, and policy gates.
- Post-quantum computing (PQC) signatures ML-DSA-65 attestation aligned with NIST FIPS 204, so long-lived decisions stay verifiable as post-quantum computing advances.
- Zero-knowledge circuits Noir circuits on the Barretenberg stack. Prove a predicate without exposing raw credential fields to every verifier.
- REST API and OpenAPI contract Public endpoints on api.affix-io.com for health, prove, verify, witness prepare, and Merkle audit.
- QR and edge presentment Bind proofs into QR and related carriers for gates that need offline-capable checks and spent-proof anti-replay.
- Merkle audit trail Tamper-evident inclusion proofs for regulators, partners, and internal replay without a mutable log-only record.
Node.js SDK
npm i @affix-io/sdk · v2.3.0 · Node 18+
- prove / verify / proveAndVerify Generate and check zero-knowledge proofs from Express, Fastify, Next.js routes, workers, or agent tools.
- Witness preparation buildWitness and prepareWitness normalise credentials to circuit inputs before prove, including local field mapping for supported templates.
- Bundled yes/no circuits Ships production yesno and simple_yesno Noir sources plus compiled artefacts matching the API bytecode.
- Offline prove queue Failed prove jobs queue under .affix/; flushOfflineQueue replays when connectivity returns. Recent proofs store in proofs.json.
- Gates, factors, and delegation Gate check and consume, multi-factor and quorum decisions, device registry, delegation, and revocation packs from the same client.
- CLI and presentment helpers npx affix-sdk for health, prove, verify, circuits, and flush. Helpers for tokens, deep links, NFC, wallet, JWT/OIDC, mDL sessions, OTP, and related carriers.
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.
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 computing (PQC)
ML-DSA-65 signatures aligned with NIST FIPS 204. Built for post-quantum computing so long-lived proofs resist harvest-now-decrypt-later risk.
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.
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
import { verifyProof } from "@affix-io/sdk";
const { allowed, proof_id } = await verifyProof({
apiKey: "YOUR_DEMO_KEY",
proof: "YOUR_PROOF_HEX",
circuit: "yesno",
requestAttestation: true,
});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
Straight answers for buyers and builders. AffixIO returns signed allow or deny. The Node.js SDK runs on your host. Personal data stays in your systems.
Everyone
Business, privacy, and pilots
No jargon required. What AffixIO is, what it is not, and who holds the data.
What does AffixIO do, in plain terms?
AffixIO answers a yes or no eligibility question with a signed proof. That might be age, a KYC outcome, a ticket, site access, or an agent permission. Your other systems keep the personal details. AffixIO returns allow or deny plus evidence you can check later.
Is AffixIO a database of my customers?
No. AffixIO is verification infrastructure. Your CRM, banking core, clinic system, or ticket platform stays the system of record. AffixIO returns a signed decision at the boundary.
Does the AffixIO website run my production checks?
No. Sandbox and demo pages are for trying the idea. Production installs the Node.js package @affix-io/sdk on your own server, laptop, clinic host, or worker. Your systems call prove and verify from there.
Who keeps the personal data?
You do. Credentials and hashing stay on your host. AffixIO handles the prove and verify call, then discards inputs at the verifier by default. Optional Merkle audit stores proof metadata, not identity dossiers.
What does allow or deny mean for my business?
It is a clear gate decision you can act on and show later: let the payment through, open the door, accept the ticket, or refuse the agent action. The signature is the evidence that the decision was issued under your policy.
Can auditors check what happened later?
Yes. Each outcome can carry a cryptographic signature. Optional Merkle audit lets you replay that a decision existed without opening the underlying personal fields.
Does AffixIO replace KYC or login?
No. Identity providers and KYC vendors still establish who someone is. AffixIO checks a policy question at the moment of action and returns signed allow or deny.
What are post-quantum computing (PQC) signatures?
Post-quantum computing (PQC) threatens classical public-key algorithms. AffixIO uses ML-DSA-65 aligned with NIST FIPS 204 so proofs signed today remain verifiable if ECDSA, EdDSA, or RSA break.
How do we evaluate or start a pilot?
Use the sandbox, read the evaluation guide, or contact AffixIO for a scoped pilot. Procurement materials sit on the Trust and procurement paths.
Developers
SDK, API, and local host
Where prove and verify run, what stays on disk, and how to wire AffixIO into your stack.
What stays on my machine when I use the SDK?
You install @affix-io/sdk where your app already runs. Credentials, hashing, and optional files under .affix/ (queued jobs and recent proofs) stay on that host. The SDK talks to the AffixIO API for prove and verify. AffixIO does not become your customer database.
How do prove and verify work with the local SDK?
From your host you call sdk.prove, sdk.verify, or sdk.proveAndVerify. The SDK prepares the request on your side, then uses the AffixIO API to generate or check the proof. You can also verify a stored proof string from .affix/ without re-sending the original credentials.
Does the SDK run in the browser?
No. @affix-io/sdk targets Node.js 18+ ESM. Keep API keys and prove calls in a server process, background worker, or CLI. Do not ship keys in client-side JavaScript or mobile binaries.
What is the difference between the REST API and the SDK?
The REST API is the AffixIO service surface (health, prove, verify, Merkle). The SDK is the Node.js client on your infrastructure: those calls plus witness helpers, offline queue, local proof store, CLI, and gate helpers.
Does verification work offline or with poor connectivity?
QR proofs can verify on a gate device without a live database. On the SDK host, failed prove jobs can queue under .affix/ and flushOfflineQueue replays them when the network returns. Stored proofs can be checked later without sending credentials again.
What lives in the .affix/ folder?
Optional local state on the host running the SDK: offline-queue.json for failed prove jobs, and proofs.json for recent proof strings you may want to re-verify later.
Which languages and runtimes are supported?
The published SDK is Node.js 18+ ESM (@affix-io/sdk on npm). Any stack that can call HTTPS can use the REST API and OpenAPI contract directly.
How do circuits fit into prove?
Each eligibility check maps to a circuit (for example yes/no claim, age, ticket). You pass credential, witness, or field inputs for that circuit. The SDK docs list the catalogue and input shapes.
How do developers get started?
Try the sandbox, install @affix-io/sdk from npm, and follow the SDK docs. OpenAPI is at /openapi.json; a Postman collection is published on the site.