It has been 3 months since the last buyback report, which means it is time for a new one! If you are interested in the mechanics and logic behind the buyback, I encourage you to read the blog linked below first.
2019 Q4 has been our most successfull quarter since the start of the protocol! Never before we have sold more tickets as we did in Q4 of 2019.
Updated buyback token economics: Introducing continuous buybacks
On March 27, GET Protocol conducted its largest buyback to date. In this blog, I will review how the Q1 ’19 buyback…
Summary Q4 the best quarter of the decade
In Q4 of 2019:
The GET Protocol processed a total of 350.332 state changes.
A record number of 62 215 tickets have been issued.
To fuel these state changes a total of 98 348 GET has been burned.
More details on the breakdown of this buy & burn back are provided in the body of this article.
Exchanges added to buyback mechanism
Instead of only using Liquid to acquire GET from the open market, the buyback mechanism is now active on the following markets:
This change will be effective from the buyback of Q1 2020 on forward. To track the progress of the buyback check out the status page.
The buybacks of the previous decade
The exact workings of the buyback evolve with our learnings, let’s take a look at the 6 buybacks conducted over the last 2 years. A brief overview linking the blogs, tickets sold and GET acquired is shown below.
Old economics (no burning):
No burning: Up until Q1'19 the GET bought back via buybacks would not be burned but partially reused by the event organizer for future events. This accumulation by the event organizer(EO) would lower the amount of GET needed in the future(effectively giving a future discount).
New economics (with burning):
Q2 2019 -> 44 468 tickets sold |20 839 GET burned (etherscan)
Q3 2019 -> 20 592 tickets sold | 12 293 GET burned (etherscan)
Q4 2019 ->62 215 tickets sold | 98 348 GET burned (etherscan)
Introducing scarcity: Starting from Q2'19 we added burning to the economics. In a nutshell, this meant that of the GET bought back a portion would be permanently destroyed. Creating scarcity in a immutable and transparent manner. This addition raised the effective cost-base for usage EOs, as no GET is accumulated. Partly because of this, discounting was introduced into the economics. This mechanism lowers costs for integrators by using internal GET inventory to subsidize usage. All GET issued as subsidy will be completely burned.
Read more about our growth trajectory in the blog linked below.
Looking ahead at 2020 - CEO Maarten Bloemers
This was originally posted as a part of the December ’19 update blog.
“With the currently signed deals for GUTS only, we’re growing by 182,9% next year. “ — Maarten Bloemers in Looking ahead 2020
Trivia question: 4 events ticketed in Q4 of 2019 were organized and hosted in a country that starts with a letter “K” and ends with on “orea”.
Changes to the buyback logic
We have decided to simplify the burn calculation logic. Instead of burning and discounting on a per-ticket basis as we did previously. We now use the more general burn per state change metric. This means that for every state change, a certain amount of GET needs to be burned.
In the previous 3 buybacks we burned a ratio of the bought back GET. As this allowed us to set the net price for acquired GET to €0.50 / GET. Moving forward we are simplifying this by burning all acquired GET if the open market price is below €0.50.
Buyback for what you burn
Event organizers pay for the total amount of state changes of their tickets. Of course, there are still differences in the complexity of a ticket. These are now reflected in the number of state changes needed to service the average ticket during an event cycle.
Besides being a far simpler mechanism to operate and secure from a technical perspective, we have found this model to also fit far better to business needs as ticket holder behavior. If a lot of people end up reselling tickets, something is hard to predict beforehand, this approach allows the protocol to account for that as it happens.
TLDR: Event organizers pay per state change. All GET used in a state change is burned. Meaning that all GET that is bought back is burned.
Input about Q4:
Total state changes: 350 332
Average discount rate per state change in Q4: 42%
Undiscounted rate per state change (averaged for Q4): €0.07
Total events: 220 (+159 more events as Q3'19)
Organizer accounts added: +17 new organizer accounts
Calculation burn exchange buyback
Average price state change = (€0.07 * 58%) = €0.041 per state change
Total funds for buyback Q4= (350 332 * €0.041) = €14 363
Amount GET bought from open market = 57 710 GET
Making the average buyback price of GET for Q4: +-€0.25 -> this result we will carry to the discount burn calculation in the paragraph below.
Calculation burn discount
Discounted per statechange: (€0.07 * 42%) = €0.029
Total funds for discount = (350 332 * €0.029) = €10 159
GET needed from internal pools = €10 159 / €0.25(carried) = 40 638 GET
Total allocated to buyback = €14 363 + €10 159 = €24 522
Total GET burned = 57 710 + 40 638 = 98 348 GET
This calculation might seem long but it is rather straight forward. In bullet points it comes down to the following:
- As long as GET traded below €0.50 on the open market, all GET bought back is burned for 100%.
- All GET that is provided as a discount, is priced at the average acquisition price of GET. This portion of GET is burned for 100%.
Dynamic tracking & burning
Currently, we are burning GET after the fact(hence this report still being important). This isn’t an ideal situation as this process is inherently centralized and opaque. We are working on making the usage of the token integral and necessary to register a transparent and honest ticket on the blockchain.
This means that just like with Ethereums Gas, that GET will eventually be burned in real-time as tickets are processed. If an event organizer(EO) does not present proof of burn-in GET, a proposed state change will not be picked up by the ticket explorer and thereby not be valid.
In short, combining the ticket explorer and GET burn-proof feature, it will be possible for the open market to check each state change (or the ticket history) and verify on the blockchain how much GET is burned.
The road to simplification
In the previous burn-back report we presented specification tables showing the exact breakdown of the tickets and the amount of GET needed per ticket. We have found that while these tables provide a meaningful context for a select few, the approach did a disservice to our eventual goal; building an open and transparent ticketing protocol.
The GET is a utility token there to fuel state changes of tickets and event services. In a similar manner as Ether is a means to interact with smart contracts. At the end of the day the focus should be on increasing the amount of state changes, as this is the eventual metric that will determine the success of the protocol and its native token in the open market.
Ticket complexity & state changes
In previous reports, we stated different amounts of GET per ticket (between theatre and concert for example). These came from the complexity of the ticket provided. However, as the number of organizers and venues we ticketed grew the price categories per event-type increasingly started to make less and less sense.
The amount of nuanced information I needed to press in a single figure resulted in numbers with very little actual meaning. Triggering confusion under people checking the math (understandably so). With international events on the short term horizon, this issue only seemed to scale to larger and larger proportions. Therefore we decided to shift to a 1-dimensional metric; state changes processed.
State change pricing
The net amount of GET per state determines the ‘FIAT’ price the integrator needs to pay to acquire GET from the open market. As for now, this required amount is set centrally by the GET Protocol Foundation (it averaged 0.28 GET/statechange in Q4). In the future, the dynamic burn ratio formula (as introduced in the blog linked below) will make this metric more transparent and decentrally determined. More information about this mechanism will be made public as soon as it is sufficiently developed.
More about GET Protocol
Any questions or want to know more about what we do? Join our active Telegram community for any questions you might have, read our whitepaper, visit the website, join the discussion on the GET Protocol Reddit. Or get yourself a smart event ticket in our sandbox environment. Download the GUTS Tickets app on iOS or Android.