TixChain

Context

TixChain explored ticket authenticity, resale pricing, and event funding in a hackathon setting. The idea was to combine familiar event browsing, purchasing, and QR check-in with blockchain ownership records for resale.

The project progressed from an earlier Streamlit proof of concept to a broader web application. This archive records the implementation scope and the engineering questions it raised.

My contribution

I worked across event and ticket APIs, MongoDB models, QR-ticket generation and validation, frontend integration, and blockchain interaction helpers. Our three-person team also covered frontend/UI and business analysis responsibilities.

Approach

The Next.js frontend calls Express APIs, with MongoDB storing event information, ticket records, and ownership history. Backend helpers attempt blockchain transactions and link application ticket IDs to minted token IDs.

The hybrid design deferred minting until a ticket entered the resale flow. That introduced an important coordination problem: a successful database update and a successful blockchain transaction are separate events.

The resale controller checks listing prices against the ticket’s current stored price and calculates an organizer royalty. QR generation and check-in validation cover the conventional application side of the ticket lifecycle.

Results

The prototype contains event browsing, purchase, owned-ticket, resale, and organizer-management flows. Its resale rule rejects listings above 1.2 times the current stored ticket price, and its royalty calculation uses 5% of the resale price.

These values describe configured application behavior. Because a resale can update the stored price, the ceiling does not establish a permanent limit relative to the first purchase price. Successful financial settlement was not established.

Limitations and lessons

Authentication, payment processing, escrow wiring, and monetary refunds need further implementation. Matching contract sources and project-specific automated tests also need to be brought into a coherent, verifiable state.

The main lesson was the cost of coordinating two sources of state. A production version would need explicit transaction states, recovery paths for failures, and reliable reconciliation between database records and on-chain ownership.