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.