Problem

• Ticketing is an essential process of access control in events.
• The current ticket emission and trading process is not very sophisticated at all. It’s quite usual to come across issues such as such as counterfeiting and ambiguities in ticket allocation, ownership, and tradability arise.
• The main problems are:
  • Ownership verification: Usually tickets are linked uniquely to one ID, and there’s no way to officially change it.
  • Transparency: Clients don’t know what they can or cannot do with their ticket in a satisfactory way. Besides, the allocation is not transparent, which is something desirable.
  • Tradability: Usually tickets cannot be officially traded. However, this is a highly desirable feature, and not supporting it makes it happen in a peer-to-peer fashion, which is not secure at all.
  • Flexibility: Integrating tickets and making the ticket selling process any different from the usual is really hard. Flexibility would make marketing a lot more interesting and would increase the visibility of the event.
  • Fees: Fees for ticketing management are really high. Obviously, a ticketing system leads to considerable costs, but a ~20% fee is really high and not really on par with the features offered by the emitter.
• Also, even though digital tickets are already well-established for quite some time, there are not that many changes from a physical ticket.
• We want to make something that addresses all of the above points, especially in terms of tradability, in which the ticket emission and event access is still a smooth experience.

Overall Solution (TL;DR)

• We are building a full ticketing and access control system based on the tokenization of tickets as non-fungible tokens (NFTs) in a smart contract-enabled blockchain and a signature-based authentication process. The representation of a ticket as tokens in a blockchain basically already solves all of the expected problems - the ownership can be verified through the signature of a message from the ticket owner address, all the transactions and logic are transparent and verifiable in the blockchain itself, which makes it transparent, the ERC-721 standard already supports transfers and there are multiple battle-tested trading dApps that support any ERC-721 token, it should be quite easy to customize each ticket’s implementation, which makes it flexible, and now as there will be almost no specific back-end for ticketing, one more reason to decrease fees. Additionally, we’ll be including fallbacks for internet and power outages, which involves a privacy-preserving identity system.
• The tickets will be emitted in a blockchain, based on a smart contract infrastructure and through a web app. With an account in the blockchain in question, the user would be able to connect their wallet in the web app and emit a ticket in one of the available categories by paying a pre-configured amount in the set tokens. This ticket will be simply transferrable in the app, and the user would be able to generate a QR code with an ownership proving message for each of their available tokens. This is the QR code that must be shown in the entry process.
• A user may also want to create an identity in the identity system to allow offline authentication. In order to do that, they should move to an identification agency in which their fingerprint would be collected and ‘hashed’, and an entry would be created linking this fingerprint to any of his data in a cloud-based database and API. One of the possible fields is their blockchain address, which would also make it so a registry smart contract attests to an identity registration on that address.
• There will be a local module for physical access. It will include:
  • A central module, which should be able to control multiple tripod turnstiles (obs.: in the prototype, there will be one full turnstile and a ‘mock’ turnstile).
  • Tripod turnstiles, to allow people to access the event, with not only the turnstile mechanism but also authentication capabilities, i.e. signature detection through QR codes and ID number input + fingerprint verification capabilities.
• This local module would be installed in the venue itself, and would then be configurable through a management web app. There, the ticket contract address would be configured, and the event personnel would also be able to view the access events and manually open the turnstiles.
• The main flow would be the following:
  • The user gets a ticket to the event (either by emitting it or through a transfer).
  • The user generates a QR code that works as an attestation from their address that the ticket is owned by him, and shows it to the turnstile webcam.
  • The turnstile verifies the ticket ownership in the blockchain and marks the ticket as used (both locally and in the blockchain) and opens the turnstile.
    • If there’s no internet connection, the turnstile asks for either (1) the user to input their identity system ID and fingerprint or (2) the event personnel to input the users’ actual ID and use their fingerprint to attest to it.
    • The QR code will have its verification delayed, but this additional personal data will make it so any fraud is automatically imputable to someone.
  • If anything strange happens during this process, an alarm will be triggered to draw the event personnel’s attention.
• There are also some additional features, such as the power management system, to keep the system working for some time in power instabilities.

Details