Ticket interoperability 2020

At the heart of the GET Protocol, it’s the ability to make tickets truly digital. Having a fast and transparent data layer to store the relevant ticket states is a key requirement for the platform to truly scale. Why is that? Because without a clear way of checking, registering and propagating ticket changes of a ticket there will be no consensus about the current state of all tickets. Without a standard, it is not possible to track tickets distributed by different sales funnels. This fragmentation creates huge inefficiencies for both issuers and buyers.

More funnels, more $ale$

Digitization of tickets brings along a wide array of benefits; less scalping, fraud and better fan data. However, the client making the buy decision will always prefer the system that boosts their ability to sell more tickets. Artists might tweet with their hart, but mo$t of them $ign ticketing contract$ with their wallet.

Issuance of tickets on different platforms (and by different ticketing companies even) is very common in the industry. Something we have witnessed ourselves during ADE.

For the protocol to have mass-market appeal, being able to process, track and monetize tickets from different funnels is crucial. Including tickets that we would classify as ‘dumb’. This does not mean we are compromising on ticket security, we are merely allowing less secure tickets to be tracked alongside smarter tickets.

Luckily there is a big downside for ticket issuers when using multiple funnels with ‘dumb tickets’. After the QR codes are issued to a funnel, they cannot easily be revoked, changed or interacted with. It is like exposing your private key in public, even if you manage to delete the key quickly. You can never be sure it wasn’t stored, until its too late.. Take for example this instance:

There is no way of knowing who is right or wrong in this Ticketmaster case(although I would dare to take a bet). Due to their reputation, everything they say that requires the public to trust will not be believed. What if they were telling the truth all along?? THE INJUSTICE!!! probably not though lol.

No party can make any meaningful claim in this case. The ‘dumb QR codes’ cannot be tracked as they are essentially naked private keys. We cannot figure out who sold the ticket and from whom this ticket originated. This situation favors those that like the shadows and doubt. It draws out bad immoral actors. Let me introduce you to; the ticketing industry.

Hi it’s me. Benjamin. Remember kids: The sound of the cash register has always drowned out the sound of angry tweet notifications.

Back to reality, ‘disagreeing with capitalism’-as a service never really took hold with the mainstream. So we Duch socialists better not finger-wag too long to the big bad wolf called ‘driving shareholder value’. If we want to improve the way tickets are issued we better $peak Benjamin$.

Let me try.

More transparency, more sales

The key idea of the GET Protocol is to standardize the way we register a ticket changing state. Regardless of the back-end of the ticketing company. With such standardization in place tickets of a single event can be propagated to funnels, without losing control. Tickets of an event could be issued on multiple funnels, with only the necessary state changes about the fundamental state of the ticket being propagated (so no sensitive information companies do not want to share for competitive reasons).

Finally; the sound of the cash register

The GET Protocol ticket transparency add-on will allow ticket issuers to track tickets of an event across several funnels. Allowing them to optimize funnels as they go. In addition, they are able to effectively interact with the current owners of a ticket.

Each statehash points to the previous statehash and so on. All the way to the root of the tree. Due to the way state changes are hashes and calculated and because of Statebox properties we can infer current and previous states without exposing any identifying data.

Every hour Stoolbox registers a batch of ticket statechanges to the blockchain.

What the hash is going on here?

There is no information to be extracted from only analyzing a single ticket mutation in such an IPFS batch. Only when the complete history of the graph tree is downloaded and analyzed is it possible to determine to draw conclusions. This iterative process of crawling the IPFS batches and building a state-tree is conducted by the ticket explorer.

Sneakpeak image from the documentation on how to interpret the mutation receipts stored to IPFS by the GET Protocol.