05 / 06 — Ticketing platform · Pre-launch
Admit
Ticketing for nightclubs, fight nights, grassroots sport and every independent in between, with the same class of protection as Ticketmaster’s SafeTix. A ticket is never an image: the fan’s phone signs a fresh code every ten seconds, and one scan lets one person in.
Try the door
PresentedADM1.7K2QM9XRP4TD.1.k3Nq8Q2a.step.signature
- Reads as an exact ADM1 code
- A ticket for this event
- Not cancelled or listed for resale
- The ticket’s current version
- Signed by the phone it’s bound to
- The signature verifies
- Its time step is within one of now
- First scan wins: one atomic write
ReadyHold something up to the door.
- 1 The phoneThe fan’s phone, live: a code it signed during this ten-second step. Every check passes and the ticket is used.
- 2 A screenshotThe same ticket, captured thirty seconds ago. The code is genuine, so it passes until the clock: it’s three steps old.
- 3 A copy, sharedA screenshot sent to a friend and scanned seconds after the phone got in. It’s fresh, so only the last check stops it: the single write that admits a ticket has already happened.
- 4 After a transferThe seller’s own copy, taken just before they sent the ticket on. The transfer re-keyed it to the buyer’s phone and bumped its version, so the old code is dead.
- 5 An edited copyThe thirty-second-old screenshot with its time step changed to now. Any change breaks the signature, and no one without the phone’s key can make a new one.
| Time | Presented | Result |
|---|---|---|
| 21:04:07 | The phone | ✓ Admitted |
| 21:04:15 | A screenshot, 30 s old | × Code expired, at check 7 |
| 21:04:22 | A copy, shared | × Already scanned, at check 8 |
| 21:04:30 | After a transfer | × Old ticket code, at check 4 |
| 21:04:38 | An edited copy | × Not a valid ticket, at check 6 |
The event and ticket are invented; the log shows one run of the five attempts.
What it stops
- Screenshots and photocopies
- Codes expire within about twenty seconds, and the moving strip and live clock give a still image away at a glance.
- Codes worked out in advance
- Anything more than one step ahead is refused.
- Forged or edited codes
- Signing needs the phone’s private key, made on that phone as non-extractable: JavaScript, ours included, can ask it to sign but can never read it out.
- One ticket, two doors
- A single conditional database write admits a ticket. Two doors scanning at the same instant can’t both win; it’s tested against real Postgres.
- Reselling after a transfer
- A transfer re-keys the ticket, so the seller’s codes die the moment the buyer accepts.
- A lost phone
- Removing it from the account stops its codes at every door at once.
- A stolen scanner
- Doors hold public keys only. A scanner can check tickets but never mint one.
Where it stops. A door working offline from its downloaded list can still hold a seller’s old key after a transfer, and admit them once; the sync flags any second entry. So on events that use offline doors, transfers close before doors open.
About
Organisers run everything from Studio: events, price brackets and sections, rules, door setup and live check-ins, guest lists and a box office, discount and presale codes, refunds, payouts, waitlists and face-value resale. Fans buy at all-in prices on an event page that embeds in any website, and keep their tickets in a wallet that installs from the browser.
Any phone, or a handheld USB or Bluetooth scanner, becomes a door with a six-character pairing code, and shows green or red with the guest’s seat. The rules are the organiser’s: transfers on or off, a transfer cut-off, tickets per person, an age limit, re-entry. Pro adds phone lock, offline doors and staged code release.
The whole product runs on a laptop with no accounts, against stand-ins for payments and email. What stands between the build and selling real tickets is the business side: a payments account, a domain, a solicitor’s review and an independent penetration test. Admit is a working name.
Facts
- Type
- Ticketing platform: marketing site, organiser Studio, event pages, wallet, door scanner, admin console
- Ticket code
- ADM1: ECDSA P-256 over the ticket, its version, the phone and the ten-second step
- Lifetime
- About twenty seconds: one step of grace either side
- Entry
- One conditional write per scan; the first scan wins
- Stack
- Hono API on Node, Postgres (embedded PGlite locally), React and Vite
- Tests
- 412 end-to-end security tests that attack the real API; Playwright layout, accessibility and flow suites
- Load
- Twenty doors at five scans a second each: p95 6 ms on one desktop, no double admission
- Status
- Pre-launch: built and running end to end; launch waits on the business’s accounts and legal sign-off