A provably fair competition platform built on cryptographic trust.

Trust was the central design constraint, so we started with the draw engine.

The winner selection system is built directly into the database layer using PostgreSQL's pgcrypto extension — the same cryptographic library used to generate SSL/TLS certificates. The draw logic never touches application code, eliminating any possibility of manipulation at the API layer.

When an admin triggers a draw, four things happen in sequence:

1. A 256-bit cryptographic seed is generated using hardware-backed random number generation sourced from the server's entropy pool.
2. The seed is combined with the competition ID and a precise timestamp, then hashed using SHA-256 — the algorithm that underpins the Bitcoin network.
3. The hash is converted to an index that maps to a specific ticket in the pool. The winning ticket is selected.
4. The complete cryptographic proof — public seed, SHA-256 hash, verification hash, winning index, and algorithm identifier — is stored permanently alongside the result.

A public verification endpoint allows anyone to independently recalculate and confirm the result. No login required. Enter the competition ID, and the system re-derives the hash from the stored seed and metadata, confirms it matches the original, and proves the winner was selected correctly.

Popular competitions can see hundreds of users purchasing tickets simultaneously. A single duplicate ticket number or a failed allocation under load would undermine the fairness the draw system is designed to protect.

The platform pre-generates a complete ticket pool for each competition at creation time. When a user purchases tickets, the system uses PostgreSQL's row-level locking to atomically claim available tickets from the pool. Each allocation is isolated — concurrent transactions skip locked rows and claim the next available tickets, guaranteeing uniqueness even under heavy load.

If any part of a transaction fails, the entire allocation rolls back cleanly. No duplicate ticket numbers. No gaps in the pool. No race conditions.

The checkout flow was designed around a single principle: no user should ever be left in an ambiguous state. A failed payment should never result in allocated tickets lingering in limbo, and a successful payment should never leave a user without their ticket numbers.

The system achieves this through a staged transaction model:

1. Pre-allocation: Tickets are reserved from the pool and an order is created in a pending state before the user enters payment details.
2. Payment processing: Stripe handles the transaction with full PCI compliance.
3. Confirmation: On successful payment, the order is marked complete, tickets are activated, and a confirmation email is dispatched.
4. Rollback: On failure, the pending order is cancelled and tickets are released back into the available pool automatically.

This guarantees the ticket pool remains consistent at all times, regardless of what happens during checkout.

UK Gambling Commission regulations require prize competitions to include a skill element to distinguish them from lotteries. This isn't optional — it's a legal requirement.

The platform enforces this at the API level. Each competition can be configured with a skill-based question that participants must answer correctly before they can proceed to checkout. The validation happens server-side — a user cannot create a payment intent without a verified answer on record.

All answers are stored and auditable, giving the operator a clear compliance trail without adding noticeable friction to the purchase flow.

Customer communication spans the full competition lifecycle, handled by six email templates built as React components and rendered server-side:

• Ticket confirmations — sent immediately after purchase
• Draw reminders — triggered 24–48 hours before a draw date
• Winner announcements — sent to the winner with next-step details
• Welcome emails — on account creation
• Postal entry confirmations — for free postal entries (UK regulatory requirement)
• Non-winner notifications — sent to all entrants after a draw, closing the loop and encouraging re-entry

The draw reminder system runs as a Deno-based edge function on a cron schedule, identifying upcoming competitions, grouping ticket holders by user, and dispatching personalised emails.