RFP-1 On-chain Ticketing
Tl;dr The Devcon team is exploring the possibility of implementing a ticketing system that leverages Ethereum at Devcon 6. We want to hear your ideas!
RFP Description
For many Devcons now, we have allowed ticket purchases using cryptocurrencies, but advancements of Ethereum and its capabilities to-date now allow us to do so much more! Imagine receiving a Devcon Attendee Non-Fungible Token (NFT) as your ticket. This allows a few cool things like anyone holding this Devcon Attendee NFT is granted the right to vote on future Devcon decisions, or perhaps a team completely separate from the Devcon team would like to extend discounts to all attendees of previous Devcons — they can do so thanks to the inherent interoperability of NFTs!
And that’s just the start! Once we start unwinding that ball of (Ethereum-based) yarn, the possibilities are endless! Maybe we want to experiment with a new ticketing distribution mechanism where a small portion of the tickets are auctioned off and a larger portion of the tickets are raffled off — balancing efficiency with fairness — in some sort of open, permissionless system where our team (or any other central authority) has no influence and all outcomes are publicly verifiable by anyone . That would all become possible with built-on-ethereum ticketing!
On-chain ticketing allows for some cool possibilities. It’s also fairly novel and understandably challenging. The Devcon team wants to implement it, but with Devcon being a large conference serving several thousand attendees who all have rightfully high expectations, we need any ticketing system to be seamless, intuitive, feature-rich, and well-tested.
Requirements
-
Integration with Pretix, or something equally as feature-rich, open-source, and battle-tested. At Devcon 5 we used Pretix — a free-and-open-source, extensible, well-tested, feature-rich ticketing platform. While we did have some ticketing hiccups for Devcon 5 (largely due to user error on our part and lack of QA), Pretix served us well in distributing thousands of tickets of varying types (sponsor vouchers, scholar vouchers, general admission tickets, etc), on different timelines (wave 1, wave 2, wave 3, etc), with different payment methods (fiat and crypto accepted), through an intuitive UX (customizable event-ticketing-specific interface), and with an efficient mobile app for speedily checking-in all 3,000+ tickets. For these reasons, we believe it is better to integrate rather than re-invent. We’ll leave it up to you to show us how you can integrate, or prove to us that your solution is just as good or better than Pretix. If you would like to take a peak at what our current Pretix system looks like, we would be happy to provide access; please email us at dip@devcon.org.
-
Payments via cryptocurrencies, fiat, & stablecoins must be supported.
-
The system should be built for all attendees , whether they have Ethereum knowledge and an Ethereum wallet, or not.
-
The system should account for at least the following ticket types :
- General Admission — publicly available for purchase
- Discount tickets — privately available based on application for discounted purchase (builder, academic, etc)
- Free tickets — privately available based on application for free (volunteer, sponsor, etc)
-
We should be able to limit the ability for attendees to resell their tickets on an open on-chain market. We may offer no-question-refunds for all ticket purchases, and if that is the case, allowing ticket resales will just invite scalpers.
-
Attendees should be allowed to purchase more than one ticket .
-
A sybil resistance mechanism should be proposed to limit the number of tickets sold per person below a certain threshold (i.e, 2 tickets max per person). In the past we have used email addresses, and though we recognize the shortcomings of this approach, we would be open to this solution — though we would prefer a more resistant, decentralized method.
-
Refunds must be possible and as automated as possible . Once we approve a refund, the purchaser should forfeit their Devcon Ticket (and any associated Devcon Attendee tokens) and then (and only then) they should be (effortlessly) refunded their payment.
-
The proposed solution should allow the Devcon team and other outside teams to grant special discounts, abilities, or other special interactions to all Devcon attendees by interacting with an on-chain representation of their ticket (i.e, an NFT or other token representation that other projects can interact with, without expiration).
-
Check-in process should be accounted for in this proposal and any check-in process should be able to function without internet or if their phone is dead. One option is to integrate with Pretix and use their built-in check-in system.
-
All in all, we’re looking for a solution that provides a quality experience for attendees (painless buying process, simple check-in) and organizers (as much automation as possible)
-
All proposed solutions should also adhere to all requirements listed in DIP-0.
-
In particular, the interoperability requirement is important as we may plan to extend this implementation with an on-chain hybrid raffle/auction mechanism for which we would need to hook into whatever implementation you propose.
Outstanding Questions
-
ERC-721 NFT’s are often the first suggestion tossed out when discussing an on-chain ticketing platform, but it is the right one? Tickets of different classes (i.e., General Admission vs Builder) are indeed non-fungible, but are two general admission tickets non-fungible? Perhaps ERC1155 would best represent Devcon tickets? Or another standard?
-
We’ve used emails in past years as our sybil resistance mechanism, but it’s certainly a flawed one. Have a better idea that can accommodate attendees of all blockchain experience levels? Suggest it!
-
In an ideal, privacy-conscious world, a user could purchase their ticket on-chain, provide us with their email, but not have their specific Ethereum address associated with their email. Perhaps ZKPs could be utilized to achieve this outcome?
-
Transfers and interactions should be as cheap and as fast as possible, perhaps utilizing some layer 2 solution would achieve these results?
Ideate!
Comment below for questions, clarifications, or simple ideas. If you have a proposed solution, start a new topic that details it specifically, and welcome comments, feedback, and discussion! The idea should address all points made here, as well as all requirements laid out in DIP-0. After evaluation of your idea, we may ask for a more in-depth demo.
Deadline to Submit your DIP
All DIPs responding to this RFP must be submitted by October 15th.
