2.1 Principle 1

Principle 1. You can’t have your cake and eat it too.

All modern ticketing services provide the buyer with either a QR code or a barcode (“Code”) containing the necessary data to determine a ticket’s validity. The problems in the secondary market arise because these Codes are static. This is because the Code printed on the ticket has no inherent connection to the ticket’s owner. With the GET Protocol, the Code will be linked to the owner rather than the ticket, allowing the GET Protocol to control and regulate the secondary ticket market.

Furthermore, the GET Protocol utilizes a dynamic Code that is only revealed right before an event starts. This way, scalpers cannot sell a fake ticket because they don’t have a Code to sell in the first place. The screenshot below from the GUTS application show how these(figure 1) features work, viewed from an user’s smartphone.

Figure 1: The Code on the smart ticket (at left) remains hidden during the days/weeks leading up to the event, therefore trading tickets outside of the GET Protocol is impossible by default(there is no data to sell). The user-specific Code (middle) appears just before the event starts. Once scanned at the entrance the user-specific Code disappears (right), preventing last minute reselling of the ticket. The Code itself changes as a function of time, thus taking a screen-shots of the ticket before the scan is of no practical use; any screen-capped Code becomes invalid just minutes after it has been captured.

Implementations of this principle

  • The ticket’s Code is dynamic, not static, meaning it changes as a function of time, and when it is transferred to a different user.

  • The event organizer chooses and sets the time that they want user-specific Codes to become visible.

  • Codes are linked to users through their phone number1 ; only the ticket owner will receive his or her ticket, and on the verified phone only.