Event ticketing

Tickets That Can't Be Duplicated, Scalped Blind, or Faked at the Door.

Issue tickets as single-use Script tokens, with one-scan redemption, resale caps, and instant validation, with the check-in API and app generated alongside the contract.

Start Building FreeTry it in the browser

A crowd facing an illuminated concert stage

The context

A ticket is a bearer instrument that must be spendable exactly once. Conventional ticketing solves that with a central database and a scanner that phones home, which is why duplicate-entry disputes end in an argument at the door.

Modelling the ticket as a single-use token makes redemption a state change rather than a lookup: once it's spent, it's spent, and anyone can verify that independently.

What you get

Ticket as a spendable token: Redemption is modelled as spending the token, so a ticket cannot be validly used twice.
Resale caps and royalties: Price ceilings and royalties on resale are enforced in the transfer rules.
Simulate issue, resell, redeem: Walk the whole lifecycle in simulation, including the resale paths you hope nobody finds.

The part that matters

Try to redeem the same ticket twice, here, not at the door.

The unlocking script is the turnstile: Redemption is spending the ticket. The Contract Arguments panel is where you supply the signature and prove that path behaves.
Run the attack yourself: Feed it a second redemption of an already-spent ticket and watch it fail. That is the guarantee you are actually selling.
Then the resale paths: Same loop for transfers above your price cap. Most ticketing surprises are in the resale rules, not the happy path.

The simulator with contract arguments for a ticket redemption path

Inside the IDE

Prompt tab: Smart Contract Architect. Describe the ticket rules once; the contract, check-in API and scanning app are drafted together.

Transactions and broadcast panel. The redemption transaction as it will be submitted, inspectable before it is sent.

Operational note

Door-side connectivity and offline validation are real deployment questions worth designing with your engineer. The contract logic doesn't solve venue Wi-Fi outages by itself.

Try it now

Run it in the browser before you sign up for anything.

Open the full editor in a new tab

Get the event ticketing starter kit

A prompt pack and worked example for this use case, so you start from something that already runs rather than a blank editor.

This form isn't connected yet.

Set NEXT_PUBLIC_FORM_STARTER_KIT to a Google Form share link and this section starts collecting submissions. No code change needed.

The starter kit content is still being authored per use case. Join and we'll send it the moment yours is ready, rather than mailing you a placeholder.

Frequently asked questions

If something you need to know isn't here, just ask. We'd rather answer directly than leave you guessing.

Try it in the browser

That's the honest constraint above, and it's a design question rather than a contract question. Offline validation with later reconciliation is a normal pattern, but it needs deciding deliberately with your engineer. The Script layer doesn't solve a dead uplink on its own.