Attestation based ticketing system that is managed by Ethereum smart contracts and integrated with pretix. Re: RFP-1: Onchain Ticketing

Hi everyone,

It was really exciting for us at AlphaWallet to see that DEVCON 6 is looking to adopt Ethereum based tickets, as we have already implemented Ethereum based tickets for other events.

Our proposal for DEVCON 6 is to use an attestation based ticketing system that is managed by smart contracts and integrated with pretix.

  • Tickets would be distributed to the attendee’s email account, along with the purchase confirmation email. The ticket has a QR code and a link with the same content. The QR code/link contains a signed attestation from DEVCON that binds the ticket with the user’s email address.
  • Crypto users will be able to associate his or her Ethereum address with their ticket, using a DApp browser, in order to use blockchain for voting, receiving free or discounted crypto etc.
  • Non-crypto users can use the QR codes to access the venue and still have access to all the services provided through a traditional ticket

Attestation Based Ticketing
Attestation based ticketing ensures privacy, flexibility and cost efficiency for the blockchain implementation of ticketing. It involves two attestations:

  1. Attestation linking ticket with an email address (provided by ticketing system at the time of purchase of the ticket)
  2. [for crypto users] Attestation linking Ethereum address with email address (acquired by the user through a DApp browser)

Attestation #1 is the ticket. Attestation #2 is to be issued by

The process of acquiring attestation #2 would be a simple guided process for the users. It will be through visiting a website, where the user will have to verify their email to receive an attestation that will be saved in the Dapp browser as a cookie or in the user’s wallet if the wallet can recognise attestations.

When the user wishes to interact with a smart contract function, such as voting, the user will call the smart contract providing 1) the email address attestation; 2) the ticket attestation on that email address. Together they prove that the transaction sender’s Ethereum address is that of the valid attendee. Such an implementation would preserve the privacy of the user, as these attestations do not reveal the actual email address. Please check out the safe protocol for more details.

The advantage of such a design is:

  1. Ethereum address is optional for those who don’t want to use blockchain at all.
  2. For users who link a ticket to his or her Ethereum address, the process to bind that with the ticket is independent of the ticket issuing process. The buyer can get the needed email address attestation before or after purchasing Ethereum tickets.
  3. If the user loses his or her wallet, then the user can redo the process to get a new email address attestation of the original email.
  4. The ticket can be made tradable within rules specified by the smart contract.

Suitability for DEVCON 6 requirements

  1. Integration with pretix: the system is to be built through providing a module or customising Pretix, which is already a mature ticketing system. This will be done through a collaboration between pretix and AlphaWallet team.
  2. Payment with Crypto, Fiat and stable coins: Possible as the solution will be integrated with Pretix, which already supports these features.
  3. Build for all: The blockchain functionalities are opt-in. The ticket & the associated QR code/link distributed through email can behave as a traditional ticket.
  4. Support for different ticket types: The ticket can support any and all ticketing types, including but not limited to - general admission, discounted and free tickets.
  5. Limiting the ability to resell: The tickets’ resale-ability and tradeability can be restricted through the smart contract.
  6. Ability to purchase more than one ticket. Yes, attendees can purchase more than one ticket.
  7. Sybil Resistance Mechanism: Would be restricted through email
  8. Refunds and Automation: Can be automated for crypto users through smart contracts. Non-crypto users will have the same functionality as that offered by Pretix
  9. Ability for teams to grant special services: tickets can be used to claim special discounts and services. As the ticket can be easily verified by any services without going through any centralised trusted 3rd parties, tickets can be used as the integration point for any other services.
  10. Check-in process: The ticket usher app developed by AlphaWallet team for FIFA and UEFA supports the user to check-in without internet & can be integrated with Pretix
  11. Quality Experience: The AlphaWallet team’s experience in implementing VIP tickets for FIFA and UEFA on Ethereum, will ensure that the ticket experiences for attendees and organisers will be world-class
  12. DIP-0 requirements: Yes, will submit a DIP draft soon.
  13. Interoperability: The solution can be integrated into on-chain, off-chain or hybrid implementations. The exact approach can be designed after understanding the implementation of raffle and auction mechanisms.

Response to Outstanding Questions

  • Token Standard: Our preference is to use 721 compatible standards, as most of the infrastructures support 721
  • Sybil resistance mechanism: Email
  • ZKP and privacy of Ethereum addresses: The Ethereum address is associated with the email through attestation. The ticket is linked with Email in attestation(off-chain, no privacy issue), Email is linked with Ethereum address( off-chain, no privacy issue), Ethereum address can be linked with Ticket(Onchain), can be further improved by applying ZKP in attestation verification
  • Cheap transfers and interactions: Ticket sales do not require on-chain transactions unless the user wants to pay using crypto. Majority of ticket usage does not require on-chain transactions. Only when the user wants to transfer or resell the tickets, they or the buyer need to pay a transaction fee. The fees can be further reduced by using xDai or similar side chains, but it will break the Interoperability with other mainnet smart contracts, eg using Devcon tickets as collateral to borrow money.

Thanks Victor & team!

This looks awesome, I love all the detail! A few questions I personally have:

If an attendee loses control of their email, then they lose control of their ticket? If so, that’s no worse than our current exlcusively-email-based solution today, but how is it better?


In the check-in process, the attendee would need to show their QR code from their email or their attestation in their Ethereum wallet? Just one, both, or neither?


  1. So there is no way of linking the attendees Ethereum address or Devcon ticket with their email, right?
  2. But if you know an attendees Ethereum Address you can find their ticket and visa versa?
  3. Thus, if someone votes using their devcon ticket attestation, anyone would be able to link that vote with an Ethereum address, but no one (including the Devcon team) could link their vote to their email. Correct?


Is there a true need for the user to do two attestations? Would one email -> ticket attestation be good enough? It seems it would simplify the user’s workflow.

In the event of a refund of a ticket, how could we ensure that the old ticket is invalidated? Is that accounted for in this system?

All in all — awesome idea IMHO. Excited to hear your thoughts on the above, and more thoughts from others.

1 Like

If an attendee loses control of their email, they may lose the capacity to use smart contract functions like voting or trading. They can still attend the event as the event requires no more than the physical possession of the attestation. This was to stay compatible with a blockchain-less scenario.

If the attendee still wishes to access smart contract functions after losing control of email, there are two possibilities:

  1. They previously had an email address attestation that has not expired (say, 7 days). In that case, they can still transact, and they should do so immediately to transfer his attested ticket to their own Ethereum address. The smart contract revokes the attestation and grants a new NFT to the user.
  2. They can convince DEVCON to make a new ticket for their new email address, paying the cost of revoking the one to the deny-list in the smart contract.

The “Better” part in OP is that the attendee can associate his ticket with his Ethereum address and do transactions after purchase, wherein the previous solution you have to either issue an email ticket or a blockchain ticket. The flexible part means that he can acquire email address attestation before or after purchase, and if he loses that attestation he can always get another; if he loses his wallet (say he is a newbie) he can also restart from the ticket attestation and associate it with a different Ethereum address. The “cost” part means Devcon sends no transaction when issuing a ticket even if the user intend to use it on the blockchain later.

  1. If the attendee purchased the ticket from devcon, email + static QR code should do.
  2. If the attendee acquired the ticket from smart contract trade, he would not have the attestation, but an NFT instead. In this case, he use a dynamic QR code in mobile wallet to prove his knowledge of the key. The usher checks the ticket against a smart contract. The usher needs to be connected to the blockchain. The attendee doesn’t have to.

An observer (adversary) can link a Devcon Ticket to an Ethereum address but he cannot link email address or learn what is (any of the) email address. The zk is part of an attestation protocol to protect the identifier (email addr), not protect the ticket/address linkage like Tornado does to balance/address. This is because the zk part is baked into the lower level identifier attestation protocol but the ticket is a higher level protocol on top of it. Protecting email address is a bottom-line, but protecting higher level ticket - I would think it optional.

If the attendee used it on the blockchain (like voting), you can observe the blockchain and learn which ticket has voted, but not the identifier (email) that links the ticket to the Ethereum address.

if someone votes using their devcon ticket attestation, anyone would be able to link that vote with an Ethereum address, but no one except the Devcon team could link their vote to their email.

Devcon team can link their vote to the email because the ticket ID is not cryptographically hidden and devcon team has ticketID<->email data in the Pretix. We know we must protect email addresses, but further hiding ticket ID is a discussion of benefit vs complexity. The method to do so is well known in the secure voting cryptography, but whether it justifies the engineering effort…

Only users those who want to use smart contract need the 2nd attestation, otherwise, the smart contract can’t tell if the transaction sender is the email owner just by looking at email->ticket attestation, and any observer can front-run such a transaction by claiming they also have the emai->ticket attestation.

The smart contract has to maintain internal knowledge of invalidated ticket attestations anyway, since such a deny list is needed when someone trade his ticket with another (therefore invalidating the first person’s ticket attestation and creating a NFT for the second person).

I hope the info is useful from a technical prospective.

  • Weiwu Zhang (I’m not Victor - Victor Zhang is the CEO, I’m the CTO)
1 Like

DIP submitted


As the ticketing DIP RFP deadline approaches (tomorrow) I gave this DIP a deeper look.
First of all: I like this DIP and will support it (not the only one making this decision - but I will vote yes as I like the idea)
But we need to talk about some details. One thing that puzzles me a bit the DIP states:

On top of that, an email attestation service for uses needs to be built. We (AlphaWallet) can create one such service for attendees to claim attestation #2 (explained below) at,

This link currently leads me to a DEX - wonder what exactly the connection is. (and btw. we should do http->https here)

ideally to create a decentralised ecosystem of attestors for the benefit of enriching smart contract functions and reducing on-chain transactions. These attestations can be reused.

wondering about “reducing on-chain transactions” here. Can you elaborate how on-chain transactions are reduced?

Also would be great to get some use-cases for Attestation #2