AFFIXIO
One credential, one use
A valid proof should not work twice. AffixIO marks credentials as spent at the verifier and returns DENY on replay, whether the scan is at a gate, a payment terminal, or an API boundary. Test ticket edge consume in the sandbox or verify spent digests with the Merkle verifier.
At a glance
- Product
- Spent-proof anti-replay for credentials
- Scope
- Tickets, payments, access tokens
- Mechanism
- Digest marked spent on first consume
- Offline
- Local spent lists on edge gate devices
- Audit
- Merkle inclusion for every consume event
- Retention
- No personal data at verifier
The gap
Replay attacks look like legitimate scans
Screenshot sharing, cloned QR codes, and replayed payment authorisations cost venues and issuers millions each season. Traditional systems detect fraud after the fact through log analysis.
By then the fan is inside, the payment has cleared, or the agent has already exported the file.
Spent proofs flip the model: the second presentation fails at the boundary, with cryptographic evidence of why.
Architecture
Database dedup vs spent proofs
- ✕ Race conditions on concurrent scans
- ✕ Offline gates cannot check central DB
- ✕ Audit is log grep, not verifiable proof
- ✕ Replay detected hours later in reports
- ✕ No standard reason code at deny time
- ✓ Proof digest marked spent at verify
- ✓ Local spent lists on edge devices
- ✓ Merkle inclusion on every consume
- ✓ Instant DENY on second presentation
- ✓ Works for tickets, payments, and tokens
First scan
Proof verified. Digest added to spent registry. Gate opens.
60 seconds later
Second scan
Spent digest match. Entry refused with signed reason code.
Capabilities
How spent enforcement works
Proof fingerprint
Each credential hashes to a unique digest at verify time. That digest is the spent key.
Spent list
Central and edge registries hold consumed digests. Lookup is O(1) at scan time.
Edge sync
Gate devices merge spent partitions on reconnect. No duplicate admission across gates.
Multi-use proofs
Circuits can allow N uses with a decrementing counter instead of single spend.
Pre-spend block
Refunded or cancelled credentials blocked before first scan via revocation deltas.
Merkle trail
Consume events append to tamper-evident tree. Verify with the Merkle tool.
Integration
Four steps to spent enforcement
Issue credential
Mint ticket, token, or payment proof with spent semantics in the circuit definition.
Verify at boundary
Gate or API checks proof validity and queries spent registry before admitting.
Mark spent
On PASS, digest written to local and central spent lists via edge consume.
Audit reconcile
Upload Merkle events. Cross-check admission counts against box office records.
Where it applies
Double-spend scenarios
Event tickets
Stop screenshot sharing at turnstiles. One QR, one entry, one Merkle event.
Agentic payments
Single-use authorisation for autonomous transfers. Replay returns DENY.
Access tokens
One-time building entry codes that cannot be forwarded after first use.
Voucher redemption
Retail offers consumed once with spent proof at point of sale.
Clinical consents
One-time consent proofs for procedures. No reuse after signing.
Government permits
Licence checks where a permit must not validate at two locations simultaneously.
Spent proofs and replay resistance
Double-spend is not only a cryptocurrency problem. Any transferable digital right can be copied: event tickets, voucher codes, access passes, and one-time settlement authorisations. Database unique constraints help online but fail across disconnected verifiers or delayed sync windows.
AffixIO treats consumption as a first-class state transition. A proof presented twice yields DENY on the second attempt. The spent marker is cryptographic, not a best-effort cache flag.
Where teams deploy spent semantics
- Multi-lane venue entry with offline-first scanners
- Agentic payment authorisations that must not replay
- Government programme vouchers with finite redemption counts
- Time-bound access credentials for contractors and visitors
Evidence for fraud investigations
Each verify appends a digest to the Merkle audit tree. Investigators confirm inclusion with the public Merkle verifier without trusting vendor-exported CSV logs. Pair with proof-not-log audit when regulators ask for tamper-evident records instead of SIEM narratives.
Compare approaches: offline QR vs dynamic barcode. Reviewed 12 July 2026.
Frequently asked questions
What is a spent proof?
A credential that has already been consumed at a verifier. AffixIO records the proof digest in a spent registry. Any subsequent presentation returns DENY.
Does spent enforcement work offline?
Yes. Edge gate devices maintain local spent lists. Partitions merge when devices reconnect.
Can I audit spent events?
Every consume event appends to a Merkle audit tree. Verify inclusion with the Merkle verifier.
Which credential types support spent rules?
Tickets, payment authorisations, access tokens, and agent action proofs. The circuit defines single-use or multi-use with a counter.
Test spent enforcement
Mint a ticket, run edge consume twice, and watch the second scan return DENY. Verify the Merkle trail in the sandbox.