ReTix

The problem it solves

ReTix solves the problem of fraud and lack of trust in secondary ticket reselling.

In traditional ticket marketplaces: • Anyone can list a ticket, even if they don’t actually own it — leading to fake or duplicate listings. • Buyers have no cryptographic guarantee that the seller will deliver the ticket after payment. • Payments and delivery are not trustless — they rely on centralized platforms or reputation systems. • There’s no proof of delivery — sellers can claim they sent the ticket, but there’s no verifiable evidence.

ReTix addresses all of these issues by introducing cryptographic verification into the resale process: • Sellers must prove ticket ownership using Reclaim before they can list. • Buyers’ funds are held in a smart contract escrow — not controlled by any third party. • After sending the ticket via email, sellers submit a zkTLS proof (via Reclaim) that cryptographically confirms the ticket was sent to the buyer’s email address. • Only after this proof is verified on-chain are funds released to the seller.

In short, ReTix removes the need for trust, prevents fake listings, and makes delivery verifiable — all without intermediaries.

Challenges we ran into

While building ReTix, we encountered several key technical challenges: 1. Gmail Doesn’t Support zkTLS Gmail doesn’t expose the TLS handshake data required for generating native zkTLS proofs. To overcome this, we built a custom application called email-verifier that uses Google OAuth 2.0 to access the seller’s Gmail account (with consent). It reads the first email sent to the buyer and extracts the email content, recipient address, and timestamp. We use this data to construct a zkTLS proof. Then, we created a custom Reclaim provider (Id: 1def9b5a-dcb1-403a-bcb8-3f0360fa97fb) around this mechanism, allowing sellers to cryptographically prove that the email (containing the ticket) was sent — without relying on any centralized service. 2. Verifying the Correct Ticket Was Sent It’s not enough to prove that an email was sent — we also needed to verify that the correct ticket was delivered. When a seller lists a ticket, we extract the bookingId and transactionId from the BookMyShow URL and use them to generate an encrypted hash. This hash is stored as part of the ticket’s metadata on-chain. To enable this, we created a custom Reclaim provider (Id: c35f3209-0062-4dec-a173-955ba8e8f45d) that interacts with BookMyShow and verifies the seller’s ticket ownership at the time of listing. Later, when the seller emails the ticket to the buyer and submits a zkTLS proof (via email-verifier), we parse the email content to extract the URL again, derive the bookingId and transactionId, re-compute the encrypted hash, and compare it with the stored metadata. If the hashes match, we confirm that the correct ticket was sent — ensuring a fully verifiable, trustless transfer. 3. Escrow Lock Edge Cases If the seller never sends the ticket or doesn’t complete the proof, the buyer’s funds could remain locked in escrow. We implemented a cron-based timeout mechanism that automatically refunds buyers if the delivery isn’t confirmed within a specific time window.

Improvements Still Needed • Multi-Platform Support Right now, ReTix only supports BookMyShow tickets. We created a custom Reclaim provider specifically for verifying BookMyShow ownership during ticket listing. To scale, we need to build and integrate additional providers for other platforms like District, Paytm Insider, Ticketmaster, etc. • Preventing Duplicate Ticket Delivery Sellers could potentially email the same ticket to multiple buyers. One possible solution is to hold funds in escrow until after the event, allowing buyers to dispute invalid tickets. However, verifying whether a buyer was denied entry is still an open problem. • Native Ticket Transfers BookMyShow supports official ticket transfers for some events — generating a fresh QR code for the new user. Where available, we plan to integrate this feature to make ticket delivery fully trustless. Unfortunately, it’s not universally supported across events. • Offline/Physical Ticket Support We don’t yet support offline tickets such as wristbands or printed passes. We’re exploring how to add verifiable delivery via postal or courier services, or NFC tap-based proofs in person.