Technical update: Proudly presenting Stoolbox!

From blockchain developer Kasper Keunen.

Over the last months, we have been working on scaling the registration of our smart tickets on the blockchain. We are excited to announce that this project(called Stoolbox) is nearing production readiness in the upcoming weeks!

Stoolbox doesn’t only change the way we register tickets, its working also improve the value proposition of GET. To read more about what drove us to redesign our blockchain approach from the ground up please check out the blog below.

Smart ticket blockchain requirements

Before getting into how Stoolbox works, let’s start by listing the requirements for the blockchain approach we had when we started out. Note these feature requirements were formed in 1.5 years of selling blockchain registered tickets. This experience makes us certain that if implemented correctly, the features of Stoolbox will become a key driver in the protocols value proposition.

Scalable, reliable & cost-efficient processing of transactions

With the expected sales pipeline ahead of us, it is paramount that the blockchain registration part has to be able to process millions of tickets in a cost-efficient and reliable manner. A feat Ethereum surely didn’t provide out of the box as we learned the hard way.

2. Maximum transparency while respecting consumer & client privacy

Publishing datapoints to the blockchain only make sense if there is any meaning full information in the data that is made public. It should be possible to draw meaningful conclusions from the data, conclusions that expose certain public concerns.

However, the published data points should not compromise the identity of attendees(GDPR) nor the event marketing efforts of the event organizers themselves(implied scarcity can be a big marketing tool for event organizers. Exactly like it is for ICOs #hype #fomo).

3. Implementing the protocol should be non-invasive for any backend

To make it easy and cheap to integrate with the GET Protocol, we need our blockchain solution to easily integrated into the backend of integrating ticketing companies. To do this we have to assume that no ticketing system is built the same. Therefore Stoolbox needs to focus on generalizable concepts that will be compatible for a wide range of architectures.

For example, we want to make it possible for ticketing companies that still use static QR codes to slowly make their tickets a bit smarter/digital. Forcing companies to go full-digital at once is too big of an ask. By making implementation of ‘smartness’ gradual we aim to lower this friction. We have already seen this approach pay off!

4. An indispensable for GET

As the protocol scales and more unknown actors start using its features the economic fundamentals need to remain robust. We need to ensure the native asset won’t be forked out by an actor. Policing everybody doesn’t scale and can become technically hard as we open source. Hence if we want to ensure GET remains the unit of account within the protocol, the token must be made indispensable in its use case.

It might be hard to imagine this indispensibility angle so let’s use a metaphor. Let’s say you are monetizing a network of roads, you could do this with placement of toll-booths at all exits. As paying a toll fee doesn’t benefit drivers in their quest, they will choose not to pay this fee if there is a possibility to do so (like take an illigal route around a toll-booth). Hence you would need to invest in preventing this from happening. A different monetization approach would be to be the only company selling fuel to these cars(including an additional fee on top of the fuel fee). Drivers of cars cannot choose to not use fuel, hence no policing would be required as fuel is indispensible for a car to operate.

Whereas now GET is the only allowed currency to pay for protocol features, it will become the fuel required to get anything done in the GET Protocol. Like fuel, GET should be indispensable for a smart ticket to work in the GET Protocol(think Gas/ETH).