The GET Protocol makes certain information about tickets and event sales is publically available. The availability and access to the event and ticket data are made immutable by registering the data on the blockchain. By blockchain developer Kasper Keunen.

In this blog, we will explain how we achieve these goals using the structure and properties of ‘stating change receipts’.

A single state change defined

If a ticket is scanned or sold it changes state. This action effectively means that its new state the asset has different properties as before the state change.

The diagram below shows the process of an execution moving from the “Sold” place/state, to the “Resale” state via the “forSale” firing. Then the execution moves back to the “Sold” state via the “buy” firing. These 2 state changes would evidently produce 2 state change receipts.

In order to spread to the network that a certain change has occurred, receipts can be read by all actors. This is achieved with the help of receipt batches.

Receipt batches?

State change receipts are stored in Receipt Batches. The blog linked below provides details on what these are and how they are stored.

TLDR State change batches: All you need to know about the IPFS batches is that they are stored and sequenced in an immutable manner in a smart contract (here). A receipt contains 4 data points (on a single line in the batch). The code snippet shown below shows 6 state change receipts (second hash is shortened as to better fit the blog page).

zFsGM283o6E2SurYVLoZoVyDGKT78ausQGcyBZCWnzumr,zFsGM28F....,f,0

zFsGM28eNuoCzk7ouebPfBAzaH6XoMsJSYhMYMsGAiXtW,zFsGM28F.....,f,0

zFsGM26otRif88cVpUP5r72Me6Ze1JybrfSbiPhkJW6ks,zFsGM283.....,f,13

zFsGM262GY1aBnsEy7PpLyNRDkaUXSnYKuyjFTTjrqf3Y,zFsGM28e.....,f,13

zFsGM28HyJ6aT4zXkajepuWmsyZBgUfBScMK6VPUEyJwL,zFsGM262.....,f,2

zFsGM26TsUUzUkXxrKMp4bpGwiSAPxwx8G6eWF8A4D7Qf,zFsGM26o.....,f,2

Unpacking a state change receipt

A state change receipt contains 4 pieces of data. Let’s take for example the following receipt:

[zFsGM26zwhxGkTRhrVZsb24ySdofZh4snQyk4RcT4DLYg,zFsGM26LWQdSpmjzHdVdpJGVd54cLZYQ7xhYeQMz9uWCJ,f,2]

2 hashes, a string and an integer. How interesting. What do the variables of a state change do they encode? Here we go:

[zFsGM26zwhxGk...,zFsGM26LWQdSp...,f,2] -> written as [statehash, previous_statehash, type_of_statechange , id_of_firing]

Every state change receipt is structured in the exact same way (both for wirings as for firings!).

Definitions of receipt variables

A. statehash: This is a hash of a executions state change that of the receipt. Statehashes are unique identifiers of a certain execution in a wiring. Statehashes belong to

B. previous_statehash: This is the statehash of the state change of the execution in its previous state.

This means that a previous_statehash(B) was the statehash of the execution at t:n-1. So a verifier can find the preceding receipt of a certain execution by querying preceding IPFS batches to find this previous state change.

C. type_of_statechange: The type of state change that has taken place. There are two types of actions, wirings(indicated with a: ‘w’) and firings(indicated with a: ‘f’).

D. id_of_firing: Depending on the type of state change that occurred, this field points to the id of the firing that was executed in the state change. This data point can only be interpreting it alongside the wiring instructions of the event. Read more about wiring(instructions) in the 2 blogs linked below (both blog

Creating executions

[blog/ifno not yet public — awaiting the addition of enhanced authentication by Statebox]

Communicating with a wiring

[blog/ifno not yet public — awaiting the addition of enhanced authentication by Statebox]

Linking the receipts

Who is the first? Who is second? We need order. Receipts need to be sequenced for them to make any sense.

With only a single state change receipt no information can be inferred about a ticket or its execution.

A ticket explorer node needs to collect the full history of all the state changes of an execution. Only then anything can be concluded on a ticket's current state (and possible future states). This means a ticket explorer node needs to collect:

All state changes an execution has undergone (amount state changes unknown)

The wiring of the event in which the execution was created (1 state change)

Remember: Every state change receipt points to the previous stateHash as displayed in the diagram below.