BoundProof
BoundProof answers one question for AffixIO: does this holder have a valid credential for this action on this page? The answer can be yes without sending who they are.
Most access checks ask for a profile: an email, an account id, sometimes a full credential dump. That works when the gate needs a name. It is wasteful when the gate only needs a yes.
BoundProof is built for the second case. The page or service asks AffixIO whether the holder is entitled to a specific action, for a specific audience string. On success, AffixIO returns a signed allow. It does not ask for, and does not receive, who the holder is.
Think of an old wax seal on a deed. The seal binds the document to a holder without copying their life into the archive. BoundProof aims at the same idea in software: bind a statement to a credential, skip the profile dump.
Three moves. You can run them on this page in under a minute.
The page asks api.affix-io.com for a one-time challenge. That challenge is locked to action zkuser-access and audience https://www.affix-io.com/boundproof. It expires after five minutes. A spent challenge cannot be used again.
This browser builds a proof that it holds a valid AffixIO test credential for that exact challenge. The work happens on your device. The request that goes to the API does not include a name, email, government identifier, or the credential contents.
The API checks the proof against published policy. If it passes, AffixIO spends the challenge, records a nullifier so the same proof cannot be replayed for the retention window, and returns a signed receipt. The page can check that signature against the published public key.
An allow on this page means only this: a holder showed possession of a valid AffixIO-issued test credential that permits zkuser-access for audience https://www.affix-io.com/boundproof, using a fresh single-use challenge. Identity attributes disclosed: none.
One click requests a challenge, builds a proof in this browser, submits it to api.affix-io.com, then checks the receipt signature with the published public key. No API key.
Ready. No personal data is requested.
Clear limits keep the demo honest.
| Topic | This BoundProof page | Not this page |
|---|---|---|
| Purpose | Show the prove and verify pattern for a test credential | KYC, age assurance, or government identity |
| Verifier | BoundProof test adapter on the live AffixIO API | Production UltraPLONK as the public demo path |
| Identity | Decision only; attributes disclosed: none | Name, email, or credential contents in the proof path |
| Access | No API key for this demonstrator | A substitute for Hub account security on its own |
AffixIO Hub can use the same pattern for hub-access. There the audience is the Hub origin, and an issued pass may be required. Email, when used, is for issuance only. The prove and verify steps still do not send email as identity.
This marketing page is narrower. It proves zkuser-access for audience https://www.affix-io.com/boundproof only. Same idea, different gate.
Values come from the live public policy endpoint. They can change; treat the API as source of truth.
Policy
Action zkuser-access. Audience must match exactly, with no trailing slash.
Timing
Challenge TTL 300s. Receipt TTL 300s. Nullifier retention 86400s.
Mode
development_mode and test_demonstrator are true on the public policy.
Keys
Receipt signer and verifier labels are published at GET /v1/zkuser/keys so the browser can check the allow locally.
The photograph is a fourteenth-century deed that still carries its wax seal. The point matches BoundProof: bind a statement to a holder without copying their life into someone else’s archive.
A way to prove a holder has a valid AffixIO credential for a named action and audience, without revealing who holds it. This page is the live test demonstrator.
Challenge from the API, proof built in the browser, verify on api.affix-io.com, single-use nullifier, signed receipt checked against published keys.
No. Public routes live at https://api.affix-io.com/v1/zkuser/.
How it Works. Claim Desk. PQC Gauge. Brief: boundproof/llms.txt.
BoundProof is AffixIO’s way to prove that a holder has a valid credential for a specific action and audience, without sending who they are or what is inside the credential. This public page is a live test demonstrator of that flow.
No. The demonstrator does not collect, accept, persist, log, return, or display names, emails, phone numbers, government identifiers, user IDs, wallet addresses, or credential contents.
Only that a holder possesses a valid AffixIO-issued test credential that permits zkuser-access for https://www.affix-io.com/boundproof, using a fresh single-use challenge.
A nullifier is a one-way marker the API stores after a successful verify. It stops the same proof from being accepted again during the retention window, without naming the holder.
No. This public page uses the BoundProof test adapter against the live API. Do not treat an allow as KYC or a real-person login.
No. Challenge, verify, keys and policy are public for this demonstrator.
Hub can use BoundProof for hub-access with an issued browser pass. Email on Hub is for issuance. Prove and verify still do not send email as identity. This page only proves zkuser-access for the BoundProof audience.
