Header Banner Showing our White-Label App next to a photo from Antoon's Event

large_MA - MA & Dashboard - Ad - 1920x1080(39).png

medium_MA - MA & Dashboard - Ad - 1920x1080(39).png

small_MA - MA & Dashboard - Ad - 1920x1080(39).png

thumbnail_MA - MA & Dashboard - Ad - 1920x1080(39).png

MA - MA & Dashboard - Ad - 1920x1080(39).png

On the 17th & 19th December, Antoon, the Netherland’s most listened to artist on Spotify in 2022, gave sold-out performances to crowds of excited fans at the Ziggo Dome venue in Amsterdam.

Following the success of a number of hit singles in 2022 and the award for best national artist in the QMusic top 40, Antoon was able to bring thousands of fans together for the two massive shows in December.

With high demand from Antoon’s young audience demographic, the choice was made to use GUTS Tickets, a white-label integrator of blockchain ticketing service provider GET Protocol. Through the use of innovative tech, GUTS Tickets offers event organizers all the necessary ticketing tools to control secondary market revenue, protect fans against scalping and facilitate easy entry for attendees with complete real-time ticketing statistics. 
All while collecting and retaining relevant fan data.

Let’s take a look at the data.

Retaining Secondary Market Ticket Revenue for the Ziggo Dome Events

When looking at ticket sales for these two sold out Ziggo Dome events, secondary market ticket activity formed a combined 12.5% of tickets resold.

Thanks to the built in secondary market, all of the secondary sale turnover from these secondary sales were kept out of the hands of scalpers and marketplaces and crucially fully retained by the event organizers.

[According to a study conducted in 2018](https://www.theguardian.com/tv-and-radio/2022/mar/14/john-oliver-ticketmaster-live-music-costs), scalping activity for a popular event of this kind would typically involve a 49% markup of primary sale price. When combined with the percentage of tickets re-sold for these events, our infrastructure was able to keep roughly €85K of profit out of the hands of scalpers.

An image showing stats for the Ziggo Dome events

large_MA - MA & Dashboard - Ad - 1920x1080(38)(1).png

medium_MA - MA & Dashboard - Ad - 1920x1080(38)(1).png

small_MA - MA & Dashboard - Ad - 1920x1080(38)(1).png

thumbnail_MA - MA & Dashboard - Ad - 1920x1080(38)(1).png

MA - MA & Dashboard - Ad - 1920x1080(38)(1).png

Curious how this tooling could impact your event revenue and data? [Get in touch for a demo here.](https://www.get-protocol.io/contact)

How does the GET Protocol White-Label control the secondary market & prevent scalping?

Our infrastructure utilizes a number of techniques to eliminate scalping and put secondary market activity back in the rightful hands of event organizers. 

This works through a number of important anti-scalping mechanisms:

- Every ticket’s QR code is locked until a short time before the event’s doors open
- Every QR code rotates periodically to make screenshots redundant
- Every ticket is tied to a mobile phone number to ensure legitimacy of the ticket buyer
- Every ticket cannot be exported out of the White-Label environment & only re-sold within application.

By applying these techniques together, we’re able to guarantee the eradication of ticket scalping & drive secondary sales directly through the secondary ticket market built into the mobile ticketing app & web shop.

An image showing the four main mechanisms for erradicating ticket scalping using the White-Label

large_MA - MA & Dashboard - Ad - 1920x1080(17)(1).png

medium_MA - MA & Dashboard - Ad - 1920x1080(17)(1).png

small_MA - MA & Dashboard - Ad - 1920x1080(17)(1).png

thumbnail_MA - MA & Dashboard - Ad - 1920x1080(17)(1).png

MA - MA & Dashboard - Ad - 1920x1080(17)(1).png

Putting Control Back in the Hands of Event Organizers

GET Protocol's White-Label infrastructure is designed with event organizers, creators, and attendees in mind. After all, it’s this fan relationship that fills stadiums and creates memorable experiences remembered for years to come.

In today's world of increasing fan connection, the ability to engage with attendees and understand who they truly are is becoming increasingly important & the secondary ticket market represents a significant portion of this event activity.

Without retaining control over this market, event organizers lose insight into their audience, miss out on a vast wealth of secondary market ticket revenue & have no control over attendee data. It’s the equivalent of 15% of attendee activity disappearing into the ether.

**In the case of the Ziggo Dome shows, this lead to thousands more data points of fans who purchased tickets, either from the primary or secondary market.**

By being able to retain control over secondary ticket markets you unlock:

- Secondary market ticket revenue
- Secondary market attendee data
- The ability to connect with all fans no matter primary or secondary market ticket buyers.

It’s therefore why GET Protocol’s White-Label infrastructure includes a built-in secondary ticket market, anti-ticket scalping systems, real-time ticket insights, check-in status & full customer data that can be exported into your own CRM.

Does this sound like music to your ears? [We’d love to give you a demo and show you around the system.](https://www.get-protocol.io/contact)

An image showing the suite of tools on offer with GET Protocol's White-Label

large_Tokenomics Banner - WL(6)(1).png

medium_Tokenomics Banner - WL(6)(1).png

small_Tokenomics Banner - WL(6)(1).png

thumbnail_Tokenomics Banner - WL(6)(1).png

Tokenomics Banner - WL(6)(1).png

Facilitating a Frictionless Attendee Experience

Naturally, whilst the control of revenue & data is critical, it’s also equally as imperative to have a user friendly ticketing experience that both attendees can navigate & event organizers can use to get all ticket holders through the door.

Our White-Label ticket scanning application can be loaded on any mobile phone & setup with ticket scanners at multiple doors. Each scanner can have their own scanning profile to ensure attendees enter the venue at the right places.

By using our scanning system, the event organizers effortlessly checked in all tickets at the doors at a rate of 230 ticket scans a minute. This efficiency is in part achieved by the ability for multi-ticket purchasers to form groups within the mobile ticketing app.

Ticket holders can invite their friends to form a group which then ties multiple tickets purchased to a single QR code, increasing scanning efficiency. As ticket purchasers for the Ziggo Dome events bought on average 3 tickets, ***that’s a 3x reduction in QR codes needed to scan at the doors & one of the reasons why our system can scan in attendees so effortlessly at the Ziggo Dome.***

When combined with real-time analytics, the event organizers could see exactly which attendees checked-in to the event, no matter if their ticket was purchased on the primary or secondary market.

An image showing the real-time analytics page in the event dashboard

large_Dashboard - Ad - Real-Time - 1920X1080(11)(1).png

medium_Dashboard - Ad - Real-Time - 1920X1080(11)(1).png

small_Dashboard - Ad - Real-Time - 1920X1080(11)(1).png

thumbnail_Dashboard - Ad - Real-Time - 1920X1080(11)(1).png

Dashboard - Ad - Real-Time - 1920X1080(11)(1).png

Seeing how the event organizers for Antoon's Ziggo Dome events interacted and succeeded with GET Protocol’s infrastructure is a testament to the importance for event organizers to have full control over their ticketing & we’re delighted at the results of these high octane events.

If the topics & outcomes discussed in this article resonate with you & your ticketing ambitions, then we’d love to hear from you. Our White-Label can robustly handle your events at scale whilst being customized with your branding & color scheme to fit your event brand.

Reach out today & be well on your way to seizing control of your tickets in less than a month of setup. Visit our [product page](https://www.get-protocol.io/white-label) or [inquire with us today on our contact page.](https://www.get-protocol.io/contact)

large_SPARK_20221219_215935_ANTOON_VB_6300-scaled.jpg

medium_SPARK_20221219_215935_ANTOON_VB_6300-scaled.jpg

small_SPARK_20221219_215935_ANTOON_VB_6300-scaled.jpg

thumbnail_SPARK_20221219_215935_ANTOON_VB_6300-scaled.jpg

SPARK_20221219_215935_ANTOON_VB_6300-scaled.jpg

White-Label

A usecase on capturing secondary market ticket revenue using GET Protocol's White-Label

large_40k+ Event - Banner.png

medium_40k+ Event - Banner.png

small_40k+ Event - Banner.png

thumbnail_40k+ Event - Banner.png

40k+ Event - Banner.png

You don’t have to work in the events industry to imagine that moving venues for a 40K+ attendance string of concerts is a -pardon our French- pain in the derrière. 

Changing the venue of 40K+ attendees with the click of a button

large_Changing venues  - Square Banner.png

medium_Changing venues  - Square Banner.png

small_Changing venues  - Square Banner.png

thumbnail_Changing venues  - Square Banner.png

Changing venues  - Square Banner.png

large_TheWhiteLabel - Banner.png

medium_TheWhiteLabel - Banner.png

small_TheWhiteLabel - Banner.png

thumbnail_TheWhiteLabel - Banner.png

TheWhiteLabel - Banner.png

The white-label is the perfect solution to go from no ticketing to scalable ticketing that puts you in full control of your tickets.

A breakdown of GET Protocol's White-Label

large_White-label  - Square Banner.png

medium_White-label  - Square Banner.png

small_White-label  - Square Banner.png

thumbnail_White-label  - Square Banner.png

White-label  - Square Banner.png

large_Screenshot 2022-12-16 at 12.47.39.png

medium_Screenshot 2022-12-16 at 12.47.39.png

small_Screenshot 2022-12-16 at 12.47.39.png

thumbnail_Screenshot 2022-12-16 at 12.47.39.png

Screenshot 2022-12-16 at 12.47.39.png

How to seize the opportunities of innovation

What independent artists need to know about Web3

Taking Back Control: Eliminate Ticket Scalping & Capture Secondary Market Revenue The Right Way

The ticketing industry has undergone a significant transformation in recent years with the rise of Non-Fungible Tokens (NFTs) quickly gaining popularity among event organizers as they offer a number of benefits over traditional ticketing systems such as enhanced security, increased scalability, and added value for attendees.

One of the key advantages of NFTs is their security. Built on blockchain technology, NFTs are virtually impossible to counterfeit, giving organizers the confidence that the tickets they sell are genuine and cannot be replicated by unscrupulous individuals. This is particularly important in the context of ticket scalping and fraud, which have long been major issues in the events industry. In fact, a recent survey found that over 70% of event organizers have been victims of ticket fraud at some point in their careers. With NFTs, organizers can be sure that only legitimate attendees will be able to access their event.

All the fans in this image have an NFT-backed ticket!

large_GET event stadium.jpeg

medium_GET event stadium.jpeg

small_GET event stadium.jpeg

thumbnail_GET event stadium.jpeg

GET event stadium.jpeg

In addition to security, NFTs also offer [increased scalability](https://www.get-protocol.io/content/v2). Because they are built on blockchain technology, NFTs can handle large volumes of transactions without slowing down or crashing. This makes them ideal for managing ticket sales for large-scale events, such as concerts, festivals, and conferences. For example, the popular music festival Coachella recently announced that they will be using NFTs for their 2022 event, which is expected to attract over 200,000 attendees. This increased scalability allows organizers to smoothly and efficiently manage ticket sales for their events, without worrying about technical issues or bottlenecks. 

And attendees love NFTs due to the added value they bring. Because they are unique and cannot be replicated, NFTs can be collected and traded like virtual collectibles. This means that attendees can potentially earn a return on their investment if they are able to resell their NFT tickets at a later date. In fact, some NFT tickets have already been resold for several times their original value. Additionally, NFTs can be used to offer special [perks and experiences](https://medium.com/get-protocol/lasting-connections-gucci-mane-lupe-fiasco-at-wild-acre-live-993722fa8d50) to attendees, such as access to VIP areas or exclusive meet-and-greet opportunities with performers. This added value provides attendees with a unique and valuable experience that they can potentially benefit from financially as well.

NFT tickets also unlock new revenue streams.

large_GET NFT Ticketing Benefits.jpeg

medium_GET NFT Ticketing Benefits.jpeg

small_GET NFT Ticketing Benefits.jpeg

thumbnail_GET NFT Ticketing Benefits.jpeg

GET NFT Ticketing Benefits.jpeg

GET Protocol is making it easy for organizers to create and manage NFT tickets for their events. With GET Protocol, organizers can easily [set up their own ticket shops](https://www.get-protocol.io/white-label) and issue NFT tickets to attendees. This allows them to take advantage of the benefits of NFTs without having to worry about the technical challenges of building and managing their own blockchain infrastructure. GET Protocol streamlines the process of creating and managing NFT tickets, making it accessible and straightforward for organizers of all sizes and backgrounds.

By offering enhanced security, increased scalability, and added value, NFTs can help organizers create a more seamless and enjoyable experience for attendees and with platforms like GET Protocol, it has never been easier for organizers to take advantage of the benefits of NFTs and create a truly unique and engaging event experience. As the events industry continues to evolve, the adoption of NFTs is likely to become increasingly widespread. Don’t wait: [Reach out now](https://www.get-protocol.io/contact) to get your events ticketed with the fastest growing NFT ticketing platform in the world today!

large_Ticket2.jpeg

medium_Ticket2.jpeg

small_Ticket2.jpeg

thumbnail_Ticket2.jpeg

Ticket2.jpeg

Ticketing 3.0 is available right now.

The benefits of switching to NFT tickets for your event

As frustrations build around traditional ticketing infrastructure and the cracks in the system become more and more apparent, independent artists are embracing Web3 technology and the power of decentralization to take control of their careers and share their work with the world. Gone are the days of being at the mercy of centralized platforms with restrictive policies and the potential for censorship, with all their inabilities to keep up with the pace of modern creative workflows. With decentralized platforms, artists can share their content directly with their audience and retain control over their own creations while still growing the reach and impact of their work. 

A recent survey found that over half of independent artists are currently using or considering using decentralized platforms to share their work. These platforms offer a number of benefits for artists, including the ability to build stronger connections with their fans and increase their revenue streams.

Decentralized platforms allow artists to share their work directly with their audience without fear of interference or censorship. This can provide independent artists with greater freedom and flexibility in how they share their work, and can help to foster stronger connections with their fans.

 In fact, a recent study found that artists who used decentralized platforms to share their work reported an average increase of 20% in engagement levels and a 15% increase in the loyalty of their fan base.

One platform that is gaining popularity among independent artists is [GET Protocol](https://www.get-protocol.io/). GET Protocol is a decentralized ticketing solution that allows artists to sell tickets directly to their fans without intermediaries. This not only gives artists more control over their ticket sales, but also allows them to retain a larger share of the revenue generated from their events. 

GET Protocol offers a number of benefits for independent artists. By using its tooling for ticket sales, artists can sell tickets directly to their fans without intermediaries, retaining a larger share of the revenue from their events. In addition, GET Protocol uses blockchain technology to provide a secure and transparent ticketing process, ensuring that tickets cannot be counterfeited or scalped. The product suite is designed from the ground up to facilitate NFT collectibles, fan engagement and incentive programs to keep audiences and fanbases engaged. And with a fully operational [event financing module](https://www.get-protocol.io/event-financing), GET Protocol is positioned to help independent artists flourish in breaking free from industry standards and carving their own path.

large_Screenshot 2022-12-16 at 12.13.21.png

medium_Screenshot 2022-12-16 at 12.13.21.png

small_Screenshot 2022-12-16 at 12.13.21.png

thumbnail_Screenshot 2022-12-16 at 12.13.21.png

Screenshot 2022-12-16 at 12.13.21.png

The use of decentralized platforms also has the potential to provide independent artists with more financial freedom. With traditional platforms, creators are often at the mercy of the platform's policies and may not have access to all of the revenue generated from their content. On a decentralized platform, artists can set their own terms for how their content is distributed and can potentially retain a larger share of the revenue generated from their work. The same survey mentioned above found that artists who used decentralized platforms reported an average increase of 30% in revenue compared to those using centralized platforms.

In short, the adoption of Web3 technology and the use of decentralized platforms is a game-changer for independent artists. An easy way to get started is in NFT ticketing with GET Protocol, offering a [secure and transparent solution](https://www.get-protocol.io/white-label), allowing artists of any size to retain a larger share of the revenue from their events. These platforms provide a new avenue for artists to share their work and build their careers without fear of censorship or interference. So why not join the decentralized revolution and take control? [Feel free to reach out](https://www.get-protocol.io/contact) for more information about the solution and to find out how the platform has helped other artists expand their reach!

large_TheDigitalTwin - Banner.png

medium_TheDigitalTwin - Banner.png

small_TheDigitalTwin - Banner.png

thumbnail_TheDigitalTwin - Banner.png

TheDigitalTwin - Banner.png

Digital Twin

An easy avenue for tapping into the benefits of blockchain and NFT ticketing, with zero risk to current business operations

A breakdown of GET Protocol's Digital Twin

large_Digital Twin - Square Banner.png

medium_Digital Twin - Square Banner.png

small_Digital Twin - Square Banner.png

thumbnail_Digital Twin - Square Banner.png

Digital Twin - Square Banner.png

Meet your new protocol, same as the old protocol.

Well, if that was strictly true then there wouldn’t be anything to write about but you may need to squint to notice that something has changed with this release, while the irony is that almost everything has. As a protocol that operates at the infrastructure layer allowing other ticketing companies to build on top of our tech we take stability and continuity seriously and part of that obligation is making sure everything works just as it should, no matter when, where, or who created tickets with us.

For those new to GET Protocol we offer a number of solutions depending on your needs as an Event Organiser, Partner Integrator, or Ticketing Company and they all work together to help you manage your event through the complete lifecycle and to mint NFT tickets for your attendees. Here we’re releasing a big update to our Digital Twin product; the foundation layer responsible for creating all of our NFTs on the blockchain.

At the start of the year we set out to build the only NFT ticketing platform ready for global scale and we’re now launching the next iteration of the Digital Twin that is ready to take on that challenge, and because all NFTs on GET Protocol are minted with Digital Twin APIs these benefits will be available in our white-label product too. In the world of blockchains and real scalability nothing can be taken for granted, so for the last 6 months we’ve left no stone unturned in pushing towards that goal. 

As a blockchain protocol we operate on a number of principles:

- We believe in open, public, and permissionless networks. Our mission is to become the data standard for ticketing worldwide and this cannot be possible cutting corners with ultra-high-speed, ultra-non-transparent “private blockchains”.
- We believe in utility and experience. Minting a million NFTs on a ghost chain with subsidised fees would be simple but what is scalability without utility? We expect our NFTs to have integrations with top-tier marketplaces, social media platforms, and wallets.
- We believe in affordability. Thanks to the wonders of transaction fee markets and mempool priority we have one unsustainable option to scale up; pay for it. A data standard will only become the standard if it’s affordable to everyone.
- We believe in on-boarding global volume to Web3. 20 NFT tickets a day won’t move the needle towards global adoption and if we want to be serious about this then we need to be ready to scale with the industry.

So where does that leave us? We need to be able to mint massive amounts of NFT tickets onto well integrated and well established public blockchain networks cheaply, and for the last 6 months this is what we’ve been working towards. Easy peasy.

This article will be going to be into depth about the development, decision-making and improvements made for our V2 release as well as flaunt the amazing work that has led us to this point. For those that are just here for the headlines, here’s what has happened:

- Our new V2 Ticket Engine API will be rolling out giving us a 316x boost in peak throughput and 11.8x improvement in minting costs.
- We’ve rolled up a number of product improvements to our blockchain structure to give event organisers more control over their events with each event being its own smart contract.
- We’re releasing our new Integrator Dashboard to put integrators further in control of managing their account and topping up their balance.
- A number of small but important improvements have taken place; further decentralisation of the ticket explorer and a clearer path forward to a multi-chain GET Protocol.
- In V2 all ticket revenue is on-chain and settled in GET.

To define success you need to set a line in the sand. Around the time we started to take the scale up attempt seriously GET Protocol hadn’t long passed its [millionth ticket](https://cointelegraph.com/press-releases/a-one-in-a-million-nft-milestone-get-protocol-issues-its-millionth-on-chain-event-ticket) and as conversations about the design and architecture of the new system started to unfold that number was fresh in our mind. How about if we could do that in a week? 52 million a year sounds like a target to hit! Without knowing what we were getting into, that became the goal.

The throughput of V1 can be quite easily found as `yearlyThroughput = maxTicketsPerDay * daysInYear` and based on organic usage it was understood that the existing blockchain relayers were able to process around 20,000-30,000 transactions per-day. Per-year that works out to be 7.3M-10.95M tickets and is already falling short of our hopeful target by some margin. When benchmarking it is always safer to take the lower-bound so we felt confident that we could produce *up to* 7.3M tickets per-year under the live system, high enough to handle current demand but low enough to show some slight lag during heavy volume days of concurrent stadium events. 52M/year would represent a 7.1x increase in throughput, an ambitious target but it’s better to aim high.

The power of an NFT lies in its interoperability and its ability to plug and play easily into tooling and products already existing within the wider crypto ecosystem. Straying away from the standards allow us more flexibility to mint tickets more efficiently but reduce our integration potential with marketplaces and social networks, something worth keeping in mind at all times when choosing a standard to work with. Our initial discovery led us towards [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155), a less common but more efficient NFT standard with OpenSea support and an increasing level of popularity among developers. Although promising, after some experimentation we decided that the support of third-party applications wasn’t quite at the level needed and would risk leaving the ticket buyers an NFT with compromised utility and fewer guarantees of support on their favourite marketplaces, NFT galleries, and wallets.

Keeping our NFTs within the ERC-721 standard was the direction to take for maximum utility and that meant finding a way to mint 721s as efficiently as possible by working on the other two main inefficiencies; storing more data than necessary and processing only a single ticket per-transaction. If these could be improved then there was a good chance of finding a viable path forward with ERC-721.

V1 of the protocol was designed for flexibility and ensuring that all data could be recorded about a ticket in the most granular and accurate way possible, which is often the right way to approach all software. In the early phases of a product it is not yet obvious how it will be used, the features that will be needed, and those that won’t stand the test of time so it’s common to ensure you’ve covered all bases and that worked well for us. But the earlier you are in a product’s lifecycle the less information you have; you should refine as you go. While accounting for all future use-cases gives the most flexibility it also increased bloat and offers us opportunity to optimise now that we’ve gained experience. So that’s what we did.

Approaching an optimisation task is often like plugging holes in the bottom of a sinking boat, you’ve got to start with the biggest and baddest ones first and in Solidity this would be the amount of data you store on-chain.  Because each NFT is its own boat, multiply that leakage by the number of tickets created and it quickly becomes important to reduce our on-chain storage before attacking other issues.

Solidity and the EVM meters gas usage for storage in the number of ‘slots’ that are used, where each slot represents a 256-bit number and each bit is a separate 1 and 0. This means that you have 256 individual ‘bits’ to use and each of those can be set to a 1 or a 0 and that’s it. Go a single bit over this 256 and you’ll get charged for another whole 256, no ifs and no buts. Each slot costs 20,000 gas and looking at one of our V1 tickets we can see that [we’re currently using around 365,000 gas per NFT](https://fravoll.github.io/solidity-patterns/tight_variable_packing.html).

What is all that gas going towards? Let’s account for some of the main offenders:

```
struct TicketData {
  address eventAddress;
  bytes32[] ticketMetadata;
  uint32[2] salePrices;
  TicketStates state;
}
```

The `TicketData` structure is stored for each NFT. An *address* is 160-bits which is used to link a ticket to a particular event, a *bytes32* is 256-bits each and one is used to store the price in the currency of the event, two *uint32*s add another 64-bits to the tally, and the *TicketStates* add 8bits. Due to the way Solidity [packs](https://fravoll.github.io/solidity-patterns/tight_variable_packing.html) these into storage this means this is using a slot for the eventAddress, a minimum of one for the metadata, and one for the rest for a total of three slots for our custom TicketData.

**Take-away**: Huge improvements in storage requirements were made by rethinking and redesigning the way we represent ticket and event information.

But wait, there’s more… The ERC-721 standard itself needs to store some data to track the ownership of the NFT and the unique ID. In V1 this is using [OpenZeppelin’s ERC721Enumerable](https://docs.openzeppelin.com/contracts/4.x/api/token/erc721#IERC721Enumerable) contracts to handle the ERC-721 standards and this stores data in a way that it makes reading certain information of an NFT slightly easier at the expense of making production of an NFT a lot more expensive. [Others’](https://www.alchemy.com/blog/erc721-vs-erc721a-batch-minting-nfts) have written [at length](https://medium.com/coinmonks/comparison-of-the-most-popular-erc721-templates-b3614353e31e) about ERC721Enumerable’s inefficiencies but all you need to know here is that it adds a lot of additional overhead that we can do without, estimated at an additional six or seven storage slots on top of our three. And let’s not forget our on-chain economics as each ticket has its own fuel tank that stores the amount of fuel it has for the rest of its lifecycle. Removing from the integrators account balance and adding it to the ticket balance accounts for another two slots worth of storage. All said and done this storage accounts for 11-12 slots in the region of 220,000-240,000 gas per NFT.

V2 reduces this down to a single slot with 20,000 usage, with some bits to spare:

```
struct TokenData {
    address owner;
    uint40 basePrice;
    uint8 booleanFlags;
}
```

The owner address cannot be avoided as each NFT must have an owner, giving us the first 160bits of storage. We assign the next 40 towards storing only the basePrice, which is the USD denominated value of the ticket at the time of sale. Then some [clever tricks](https://blog.polymath.network/solidity-tips-and-tricks-to-save-gas-and-reduce-bytecode-size-c44580b218e6) are used to represent 8 different states as part of a single 8-bit integer that can store whether a ticket has been scanned, checked-in, invalidated, or claimed. Because each event is its own smart contract we no longer need to store the event address with each ticket and this leaves us with a positively healthy 48-bits to spare for future upgrades. But what about the on-chain economics? The fuel tank? The rest of the NFT standard?

The final big target in our sights for efficiency was our handling of 1 transaction = 1 mint and when you consider all the overheads of merely confirming each transaction you’re better off batching these into chunks. Soon after the release of Ticket Engine V1 we quickly realised that the maximum number of transactions you can have queued for a single address (while still making sure the network will confirm them) was 16 per address due to a limit enforced by peer nodes within the network and since each integrator can have its own relayer address this allowed for 16 transactions to be queued per-integrator at any given time. As these were confirmed more could be sent for confirmation.

By batching the ticket actions the V2 contracts are able to push minting costs down drastically.

large_v2-batching.jpg

medium_v2-batching.jpg

small_v2-batching.jpg

thumbnail_v2-batching.jpg

v2-batching.jpg

Building V1 without batching forced us to make every transaction count and pushed development towards building a system that was very good at confirming transactions at scale. Despite some challenges at the start our development team pushed onwards and Ticket Engine got very (very!) good at confirming transactions in all weather conditions of the Polygon network. Despite this we didn’t at all maximise the value of each transaction confirmation, leaving a lot of growth potential on the table. Or in other words, these transactions were getting confirmed amazingly well no matter the gas price or the competition, but we were then using them to do a single NFT mint losing all that advantage we’d built in the infrastructure layer.

So to increase our volume you can use another simple equation of `maxTicketsPerDay = maxTransactionsPerDay * ticketsPerTransaction` and it was this tickets-per-transaction that we began to focus in on. If only 10 tickets could be packed into each transaction then our goal of 52M/year would be achieved and everyone would be happy. The first design of the new smart contracts batched a single action-type but this felt clunky and inflexible so after a number of breakthroughs batching all ticket interaction types is now possible with V2. We’re happy to say that this has now been tested successfully to 250 NFT tickets per-transaction, far more than the 10 we were hoping for.

**Take-away**: NFT minting is now batched so that multiple can happen in a single transaction and these can be updated as part of the batch rather than individually. Hoorah!

Batching ticket interactions in this way helps from all angles: our API has to confirm fewer transactions for the same number of tickets, and only needs to update the certain parts of the on-chain data per-batch rather than everything per-ticket. Calculating the GET fuel usage here is the perfect example of this as it requires writing the same two pieces of data to the chain; the reserved fuel needs to increase and the integrator’s available balance needs to decrease. When batching we no longer need to update these per-ticket and can be updated once per-batch. This same approach is taken for updating the NFT token balances and ownership data resulting in heavy savings when these costs are spread across the batch. Where two storage slot updates would previously cost a full 40,000 gas per-ticket, doing that same operation once for a batch of 250 socialises the cost to a featherweight 160 gas per-ticket.

To make this easier to follow we’ve charted out the impact of the number of tickets in each batch along with its total gas usage and the per-ticket gas usage. Even batch sizes as low as 10 can have a huge impact on the overall efficiency of each transaction.

Scaling our blockchain contracts only tells one chapter of the story. A big part of our value proposition as an infrastructure provider for digital ticketing is that enterprises no longer need to hire a blockchain team just to experiment with NFTs. To bridge the Web2 and Web3 worlds we offer our Ticket Engine API for minting Digital Twin tickets of existing ticket inventory and to handle this demand we’ve completely rearchitected our services from the ground up to be [event-driven](https://aws.amazon.com/event-driven-architecture/) and asynchronous.

In non-technical speak this means is that the API application code has been broken down into smaller modules that are highly performant at a single task and these modules are only activated when they are instructed to do. When the API receives a request to mint an NFT it is placed into a queue and instructs a module to perform a specific function on that request before passing to another queue. We’ve separated out the data validation, the processing, the batching, and the broadcasting of each transaction into separate pieces of code that can be built and executed independently of one another. This modular architecture not only gives us more technical scale but gives us a simpler development environment for future data handling.

Moving much of the initial request processing to later modules allows the API to respond to requests far faster than possible in V1, producing a confirmation response within **~5 milliseconds per action** requested.

Developing applications that use the Ticket Engine API has been simplified in V2 and instead of having to separate our individual actions into batches of 100, we now offer a singular endpoint accepting a maximum of 5000 actions, a **50 fold increase**. Previously, registering sold and scanned tickets would need to be separate API requests, but these can now be sent together and the API will now process them in the order received, no need for separation.

When you bring it all together you end up with something quite powerful, which was confirmed on the initial production environment benchmark tests that resulted in 57,500 NFTs minted in 13 minutes and 6 seconds. What would have taken almost three days in V1 can now be handled in less time than a coffee break. The API and back-end services have been found to be highly performant at confirming transactions on Polygon mainnet and the stress-test proves it, showing a peak **316x efficiency improvement in throughput.**

As for cost of minting NFTs, where a single Ticket under V1 would previously cost 365,000 gas, this has been compressed all the way down to 30,950 for batches of 250, an **91.5% cost reduction.**

This update is not all scale and throughput. We’re also releasing a number of key product upgrades and features that drive the next theme of our roadmap… desirability.

The number one challenge we faced with the composability of V1 NFTs was that they were minted on a single smart contract that contained all tickets from all events from all integrators and as the wider ecosystem of NFT tooling has evolved it has became more and more challenging to operate with this foundation. NFT marketplaces create collections based on the smart contract that created the NFTs, and DAO governance tooling can collect votes based on if you own an NFT from a particular collection (again, relying on the contract address.) The list of these examples goes on but it became clear that the right move would be to give each event its own smart contract to then allow creators and artists the ability to use these NFTs within their communities and platforms more effectively without developer assistance.

In V2 the tickets of every event will be minted by a unique minting contract specifically deployed for the event at hand.

large_v2-event-contracts.jpg

medium_v2-event-contracts.jpg

small_v2-event-contracts.jpg

thumbnail_v2-event-contracts.jpg

v2-event-contracts.jpg

This instantly opens up a number of possibilities to the utility of a ticket NFT:

- It becomes easy to check whether an event attendee owns an NFT for a specific event.
- Voting and DAO rights can be offered to these attendees using standard available tooling.
- Community NFT-gated access is easy to use by allowing owners of a ticket the right to access certain Discord and Telegram groups.

One that isn’t quite ready yet for release is collecting NFT trading royalties to an address on a per-event basis, incentivising creators to produce valuable and tradable NFTs. This update allows that and sets the stage for future feature upgrades.

This is more than just a technical feat... all popular NFT collections are minted on their own dedicated smart contract and due to V1 minting all NFTs onto a single contract this reduced their desirability because of the lack of curation and personalised collection details.

**Take-away**: Every created event will deploy a new NFT minting contract. This will give every event its own OpenSea collection, improving uniqueness, scarcity, and personality.

It remains to be the case that picking a winning blockchain is an exercise in betting and guesswork. Will there even be a winner? Will the future be multi-chain? Or will it be cross-rollup? Or neither? Truly, no one really knows.

V2 architecture allows deployments on multiple L1s (or L2s) at the same time.

large_v2-multi-chain.jpg

medium_v2-multi-chain.jpg

small_v2-multi-chain.jpg

thumbnail_v2-multi-chain.jpg

v2-multi-chain.jpg

The best way to hedge our bets is to build on the most common and compatible standards available to us while also ensuring we have the ability to quickly launch on new chains depending on integrator preferences and demands. It’s never been our approach to launch everywhere and spread ourselves thin and that remains the case but V2 is designed to allow for quick deployment to other EVM compatible chains if there is demand from integrators to do so. The keen-eyed may have already seen hints of this on the latest release of the ticket explorer:

The full ID of a ticket now includes its blockchain and the event ID to allow any ticket on the protocol to be found.

large_v2-ticket-explorer.png

medium_v2-ticket-explorer.png

small_v2-ticket-explorer.png

thumbnail_v2-ticket-explorer.png

v2-ticket-explorer.png

The [Ticket Explorer](https://explorer.get-protocol.io/) has taken steps towards greater decentralization and now fetches almost all of its data using only [TheGraph](https://thegraph.com/hosted-service/subgraph/getprotocol/get-protocol-subgraph). While it may seem like a small back-end change, and to many users of the ticket explorer it will be, it represents a crucial architecture shift in how we build our applications. While private data was never used within the Ticket Explorer, it is now much easier to confirm that is the case since the site is now generated using the subgraph data. The Ticket Explorer will continue to be developed as the primary place to view NFT ticket information and this new foundation helps us only operate on public blockchain driven data. A small win for the architecture but a big win for the ethos of an open protocol.

Builders and integrators wishing to use this data to create applications or user experiences can now do so and [the code is publicly available on our Github](https://github.com/GETProtocol/subgraph#readme).

Saving one of the most exciting updates til the end, we’re now in the process of rolling out our Integrator Dashboard to existing integrators & partners. This provides a convenient way for integrators to top-up their GET fuel balance and providing necessary account management features such as balance alerts and usage statistics.

Integrators will now have a way to top up their account balance directly using GET within their wallet.

large_v2-integrator-dashboard.png

medium_v2-integrator-dashboard.png

small_v2-integrator-dashboard.png

thumbnail_v2-integrator-dashboard.png

v2-integrator-dashboard.png

Partners that wish to have a deeper look into their usage statistics and blockchain data will be able to see the exact blockchain usage as well as the events that they have recently created along with their smart contract addresses. Guides and support documentation will be provided to partners as part of the rollout and will be available publicly from the dashboard.

As our partners are business entities we’ve taken extra care to build it to be business ready from launch, offering top-up transactions verifiable on-chain as well as top-up receipts in PDF form for accounting purposes. For those that prefer a simpler top-up experience we’re working hard to implement direct top-ups using bank transfer and we’ll release more information when this becomes available.

Depot? Silo? Fuel tanks? RIP we hardly knew ye.

We’ve moved away from a metaphor tied to fuel refinement and towards something that more accurately describes the accounting flow both within the code and documentation. For the economics to be widely understood it needs to be simple.

The accounting workflow is largely the same as in V1, however the three different states the GET fuel can be in have been renamed:

- *Available Fuel* represents an integrators’ balance on their account. Already topped-up and available to pay for NFT mints.
- *Reserved Fuel* is accrued from *Available Fuel* at the time of minting and is held within the system for the ticket’s lifecycle until it is checked-in or invalidated.
- *Spent Fuel* is accrued from *Reserved Fuel* upon check-in and invalidation and is ready to be collected from the protocol to the destination addresses.

All simplification no matter how minor can only be a good thing, right?

As a ticket moves through the event cycle GET moves within the Economics.sol contract from Available Fuel, to Reserved Fuel and eventually will end up in the Spent Fuel balance.

large_v2-fuel-terminology.jpg

medium_v2-fuel-terminology.jpg

small_v2-fuel-terminology.jpg

thumbnail_v2-fuel-terminology.jpg

v2-fuel-terminology.jpg

In V2 all ticket revenue is on-chain and settled in GET

In V2 all ticket revenue is on-chain and settled in GET.

small_v2-simpsons.png

thumbnail_v2-simpsons.png

v2-simpsons.png

Before you go, there is one final thing…

**In V2 all ticket revenue is on-chain and settled in GET.**

All ticket revenue, service fees and sales taxes will be settled in GET via the Integrator Dashboard. 

*But I thought that was already the case?*

Might be top of mind, and while it is almost true but there’s a little bit of history wrapped up in this question. The V1 economics live right now was based mostly on the token revenue numbers of the system that preceded it and inherited the status-quo when it came to the amount of GET needed to service a ticket. The on-chain real-time economics of V1 that you’ve seen live for the previous year was no doubt a lightyear ahead of the quarterly reports prior, but the usage numbers, pricing, and accounting processes within the company remained mostly unchanged. You can’t pivot on a dime and representing the GET requirement for NFT ticket mints was already upgrading a large chunk of functionality so much of the development of a fully on-chain accounting system was deferred until a later release; this one.

*So what’s the difference?*

For starters, the amount of GET needed to create a ticket on the protocol was disconnected from the incoming revenue streams from the White-Label product and the calculation of these figures was arbitrary and carried-over from legacy decisions. It also meant that because of existing accounting practices within the company that the token revenue was ultimately treated as a cost at the end of an accounting cycle rather than the foundation on which the accounting system is built. For that we needed the integrator dashboard.

*In plain English?*

For the White-Label SaaS application **3% of the primary and secondary market order value** of each NFT minted on the protocol will be required as fuel and for the Digital Twin this will be a **fixed fee of $0.02 per-NFT**.

You can now consider (as-in the ‘enforced by smart contracts’ sense) the Digital Twin service fees to be a subset of the White-Label fees and these will be accounted for separately to the full service fee that would be charged for the White-Label, all in GET. This gives us the opportunity to align and set the future long-term direction of product separation and responsibilities between the entities that exist today, GET Protocol Foundation and the DAO. Each entity has different roles to play in the success of the protocol and has different strengths and weaknesses and although still being worked on, we’re starting to build a migration path to allow development work on the decentralised technologies within the protocol under the umbrella of the DAO. More to follow.

Each interaction will split fuel based on core Digital Twin costs and white-label revenue. Both the DAO and GET Protocol Foundation will receive revenue from this split.

large_v2-fuel-split.jpg

medium_v2-fuel-split.jpg

small_v2-fuel-split.jpg

thumbnail_v2-fuel-split.jpg

v2-fuel-split.jpg

*What happens to the GET fuel?*

Well, for starters, more fuel will be used. A lot more. And we need to have a strategy on how to capture value as efficiently as possible. For those that are familiar with us already you’ll know that we’re aiming to build a long-term vision for the future of ticketing and as a result we need a sustainable business to do that. This means some of this GET will need to be sold, and this should naturally be the case and expected - there are operational expenses to cover, staff costs, future hiring, and growth, and these things won’t happen if the fuel just piles up month after month. Nor is it the Protocol’s mission to only collect fuel, it will be reinvested, allocated, and spent for sustainability. The DAO would fall under the same realities and not all of the goals can be achieved by collecting and holding GET ad-infinitum.

The true elegance of this system however is that it gives us a lot of flexibility on the terms in which the fuel is sold and we’re exploring a system that will work in lockstep with future staking mechanisms, offering this collected GET fuel directly to committed stakers so we ensure that this GET remains in the hands of those that also share this long-term vision of the protocol. We may only be at the start of working out the finer details of these mechanisms but the idea is solid; we increase the demand for GET through its fuel usage, and we retain this value by ensuring we offer it to those that are in it with us for the long haul.

Stories published by GET Protocol

Featured Stories

Latest Stories