Home screen
Events page
Solana Transaction
Ticket purchase screen

About the Project

Inspiration

Event ticketing today is dominated by a few large players. Artists and venues have little say over resale; fans face unclear pricing, fees, and scalpers; and tickets are often just database rows that can be duplicated or faked, easily allowing ticket fraud to occur. We wanted to build ticketing where ownership is real (NFTs on-chain), artists set the rules (including their cut of resale), and scalping is structurally discouraged instead of encouraged. TicketChain was inspired by the idea that ticketing should put power back in the hands of artists and fans, and that Solana’s speed and low cost make on-chain tickets and resale not just possible, but practical.

What it does

TicketChain is a decentralized event ticketing platform on Solana. Organizers create events and set ticket supply, price, and an artist resale share (0–80%); the rest of resale is split between seller and platform (e.g. platform 20%, seller gets the remainder). Every ticket is minted as an NFT with Metaplex metadata (e.g. “Ticket for {Event Name} #1”), so ownership is verifiable and transferable. Fans can buy one or multiple tickets in a single transaction, view their tickets grouped by event, and list (or delist) tickets for resale in batches. When someone buys a resale ticket on-chain, the app records the new owner so the ticket shows up in the buyer’s account and disappears from the seller’s. A sync process keeps the backend in line with on-chain state so the UI stays accurate without constant manual refresh.

How we built it

We built TicketChain as a three-layer stack: an on-chain program, a backend API, and a React frontend.

On-chain (Solana): The core logic lives in an Anchor (Rust) program. It handles event creation, ticket minting (with Metaplex Token Metadata so each ticket has a name and symbol), primary purchases (including multi-buy in one transaction), and resale (list/buy/cancel). Resale payouts respect the event’s artist percentage, with the rest going to the seller and a platform fee. We use PDAs (Program Derived Address) for events, ticket mints, and listing state so everything is deterministic and auditable.
Backend (Node.js + Express): The API talks to the Solana program through the Anchor IDL and builds transactions (create event, buy tickets, list for resale, buy from resale, etc.). It uses Supabase (PostgreSQL) for off-chain data: event details, purchase records, and resale listings. When a user buys a resale ticket, the frontend sends the signed ticket and proof to the API, which calls a confirm resale endpoint and updates ownership in the DB so “My Tickets” and marketplace stay correct. A sync job periodically reconciles chain state (mints, listings) with the database to handle any drift.
Frontend (React + Vite + TypeScript): The app uses React Router, Phantom (and compatible wallets) for signing, and a small API client that mirrors the backend routes. Key flows: create event, purchase tickets (with a quantity selector and total display), view My Tickets grouped by event with “X owned · Y listed” and per-listing cancel, open a resale modal that shows the event’s actual artist/seller/platform split, list one or many tickets in a batch, and buy from the marketplace with an immediate ownership update after the on-chain tx.

Challenges we ran into

Chain vs app getting out of sync: On Solana, when someone buys a resale ticket the NFT moves to the buyer’s wallet right away, but our app’s database still showed the seller as owner, so “My Tickets” was wrong. We had to add a step where the app confirms the sale and updates who owns the ticket so the UI actually matches what’s on-chain.
Solana’s tight program limits: Solana programs have strict limits on how much memory an instruction can use. Our “buy ticket” flow (event + mint + buyer account + NFT metadata) blew past that limit and the program wouldn’t compile. We had to restructure the instruction so the heaviest data doesn’t sit on the stack, a Solana efficiency issue we didn’t see coming.
Showing the right resale split: We were showing a fixed 40/40/20 split in the resale modal, but every event can have a different artist share (0–80%). We had to wire the modal to the correct event so the UI shows the real breakdown instead of a placeholder.
Staying under RPC rate limits: Public Solana RPCs throttle you if you hit them too often. Our sync job was polling every few seconds, we started getting 429 errors, and the logs were unusable. We had to slow down the sync and trim logging so we could run on public devnet without getting cut off, a real efficiency and cost constraint when you’re not on a paid RPC.

Accomplishments that we're proud of

End-to-end NFT ticketing — Create event → buy ticket(s) → see NFT in the wallet, and resell with on-chain enforcement of artist share.
Artist-set resale economics — No hardcoded split; the event’s resale percentage is respected on-chain and reflected in the UI (landing, about, marketplace, resale modal).
Multi-buy and batch list — Purchase multiple tickets in one transaction; list up to 10 tickets for resale in one go, with a clear “X tickets” / “Y owned · Z listed” grouping per event.
Ownership that stays in sync — After a resale purchase, the backend updates ownership so the ticket shows in the buyer’s account and is removed from the seller’s.
A working stack under time pressure — Anchor program, Node API, Supabase, and React frontend all integrated with sync, confirm flows, and a consistent story from landing page to “My Tickets” and marketplace.

What we learned

We learned how much state a ticketing product has: on-chain (events, mints, listings) and off-chain (event metadata, purchase records, listing display). Keeping them aligned required a clear contract (what the program does) and a disciplined sync + confirm flow. We also learned the importance of account sizing in Solana programs (boxing to avoid stack overflow) and how sensitive public RPC endpoints are to polling frequency. On the product side, we learned that “artist-set resale share” is a strong differentiator and that showing the actual split everywhere makes the value proposition clear.

What's next for TicketChain

A big theme for us is giving artists more control. We want to explore tools so artists can decide who gets early access (like loyalty-gated drops), how their events and resale are presented, and what data they see. In specific: loyalty badges (on-chain or hybrid) that artists can use to gate early access or perks; organizer dashboards where artists see sales, attendees, and resale volume per event and can adjust strategy; richer NFT metadata (venue, date, tier) for better wallet and third-party display; and mainnet deployment with a production RPC and possibly a dedicated sync worker.