Concert and festival gates
High-volume scan lanes with local spent-proof enforcement.
gate · offlineVenues and events
Offline ticket verification
QR tickets with embedded proofs verify at the gate without live database access. Spent-proof logic stops double entry, screenshots, and scalping. Same ML-DSA-65 signature stack as API verification. Gate devices reconcile with Merkle audit when back online.
OFFLINE QRSPENT PROOFGATE SCANANTI-REPLAYML-DSA-65VENUES
At a glance
- Product
- Offline-capable QR ticket verification with spent-proof
- Scope
- Concerts, sport, transport, festivals, conferences
- Anti-replay
- One scan, one entry. Credential marked spent locally.
- Offline
- Verify without live connectivity to central server
- Signatures
- ML-DSA-65 post-quantum
- Reconciliation
- Merkle audit when devices reconnect
Offline ticket verification embeds a cryptographic proof in the ticket at issue time. Gate scanners verify the signature locally, enforce spent-proof rules, and return allow or deny without pulling attendee data into the venue system.
The challenge
Why venues need offline verification
Venues lose revenue and trust when tickets are copied, scalped, or validated against fragile central servers that fail when connectivity drops.
Screenshot replay
Static QR codes from screenshots pass naive scanners until the database catches up.
Connectivity failure
Stadium basements and rural festivals cannot depend on live API calls per scan.
Scalping
Resold tickets bypass issuer controls when verification is decoupled from proof.
Data hoarding
Traditional systems copy purchaser PII into every gate vendor database.
Use cases
Ticket verification scenarios
Any high-throughput entry point where offline verification and anti-replay matter.
Sport stadiums
Season pass and single-event tickets with section binding.
seat bindTransport passes
Metro and rail gates verify without network per tap.
transit QRConference badges
Multi-day credentials with day-bound proofs.
event bindVIP and backstage
Tiered access without exposing attendee identity at scanner.
tier ZKParking and ancillary
Linked credentials for parking, merch, and lounge access.
bundleProof pipeline
How verification works
- 01
Issue
Policy authority defines a Noir circuit for the rule set. Witness inputs come from systems that already own the records.
- 02
Bind
Proof is bound to event context: programme ID, expiry, geography, and anti-replay nonce. ML-DSA-65 signature applied at issue.
- 03
Present
User, agent, or device presents the credential via API call or secure QR at the service boundary.
- 04
Verify
Verifier receives allow or deny plus Merkle reference. No personal data retained at the verifier by default.
Stack
Technical foundation
OfflineGate verify
1 scan1 entry
ML-DSA-65Signatures
SpentAnti-replay
MerkleReconcile
SDKIssue path
Mint and verify tickets in the sandbox. See anti-scalping tickets for venue patterns.
FAQ
Frequently asked questions
How does offline verification work?
Proof is embedded at issue. Scanners verify the signature locally and mark the credential spent without a live database call.
What stops screenshot replay?
Spent-proof logic binds each credential to a single successful scan. Replays fail at the gate.
Do gates need internet eventually?
Initial verify is offline. Devices reconcile spent state and Merkle references when connectivity returns.
Can tickets be bound to seating?
Yes. Witness inputs can include section, row, and seat at issue time.
Is attendee PII stored at the gate?
No. Scanners receive allow or deny. No standing profile at the verifier.
How do we evaluate for a venue pilot?
Use the sandbox ticket mint flow and the live ticket verification sandbox whitepaper.
Get started
Validate offline ticket verification on the live sandbox, then scope a pilot with engineering.