Fuel

So far we've covered the main interaction types and how they are priced, but where are the balances stored? And how are they accounted for?

Flow Summary

This section will go into depth on the different addresses and balance in use within the system so may be overwhelming to casual readers. Treat this as reference documentation for the on-chain ecominics, but not all of this info needs to be absorbed in detail.

The GET flow through the system can be summarised as follows:

1. An integrator tops up their 1️⃣ Available Fuel using the Integrator Dashboard.
2. Upon minting a ticket OPN is reserved from the Available Fuel into the 2️⃣ Reserved Fuel as determined by the primaryRate.
3. When a ticket is checked-in this OPN is moved to the 3️⃣ Spent Fuel balance ready for collection.
4. The FuelDistributor contract can be used to issue a OPN token transfer from the Spent Fuel to the 4️⃣ Fuel Destination addresses.

Sources of Funding

Each of the two main interaction types (Basic & Premium) source their fuel from different balances. Basic interactions are always sourced from the Reserved Fuel as a percentage of the reserved fuel per-active-ticket, and premium interactions are paid for by the integrator's Available Fuel balance.

When NFT tickets are first minted they allocate a certain balance of OPN into the Reserved Fuel and is no longer usable for further minting, only for future basic interactions. This OPN 'lives within the system' until the ticket lifecycle is completed. Premium interactions are funded directly from the Available Fuel.

Let's break it down.

• The OPN token acts as the programmable fuel for platform.
• Each interaction is priced as a rate of the ticket's price or as a fixed USD fee.
• Each integrator has their own available account balance, which can be topped-up using the dashboard.
• Top-ups are valued and fixed in USD to protect against OPN token volatility.
• When an NFT is minted, OPN is deducted from the integrator's Available Fuel into the Reserved Fuel to cover the basic ticket lifecycle.
• Further premium interactions would be funded from the integrator's Available Fuel.

Only when the ticket has completed it's lifecycle (either invalidated or checked-In) will the fuel be 'spent' and ready to be collected.

Pricing an Interaction

📘

Implementation Detail

Integrators do not need to be aware of the following implementation detail as this is abstracted away from usage. Each integrator's account contains an internal 'OPN price' that is used to calculate the amount of OPN needed on each interaction. This section acts as a reference on how this is calculated from first principles.

In a standard basic lifecycle of a ticket, the most important variable used is the primaryRate which defines the cost of minting an NFT as a percentage of the ticket's basePrice. We can use both the rate and price to calculate the expected USD cost of minting an NFT.

The basePrice is provided at the time of mint and the primaryRate is set at the time of creating an integrator so this can all be processed on-chain.

As this cost is denominated in USD, we also need to have a price of OPN available to compute the amount of OPN needed for the interaction. This already held per-integrator and determined by the price at the time of top-up.

With this OPN amount calculated it is then possible to check the Available Fuel balance to ensure that is is greater than the amount to be deducted. If yes then this will be deducted from the Available Fuel and added to the Reserved Fuel.

Because of this real-time deduction the protocol can be thought of as being paid for on debit.

Spent Fuel

Check-in and invalidate interactions are one-way operations and will finalise the state of the ticket, making it claimable as an NFT collectible, ending its basic interaction lifecycle. If billed, claims and further interactions with this ticket will be funded by the integrator as premium interactions.

Due to gas constraints it is not economical to transfer OPN on-chain for every ticket check-in and as such after checking-in a ticket the OPN is added to the Spent Fuel balance prior to being collected. As soon as the Spent Fuel balance is allocated this can be collected using the public FuelDistributor.collect() function that will initiate a transfer to the desintation addresses as defined by their percentages.

Protocol Fuel

To allow the on-chain economics to independently meter revenue between the base protocol costs and value-adding product fees the spent and reserved fuel balances have been split into two; total fuel, and protocol fuel. To use spent fuel as an example:

• spentFuel is the complete amount of OPN fuel used and awaiting collection.
• spentFuelProtocol is the amount of fuel charged only for basic protocol fees, in this case Digitial Twin.

The white-label product is a superset of the digital twin and includes many value-adding event management features not present in the digital twin product. But each white-label ticket still requires an NFT and to properly allocated revenue between these products the 'protocol fuel' is tracked alongside the total fuel usage.

Digital twin usage is set as a fixed-fee per-NFT charge and is deducted before any other white-label revenue costs meaning the protocol takes the first slice of the overall fuel usage per-transaction.

Destination Split

Both the OPN Ticketing Ecosystem and GET Protocol Foundation require independent revenue streams, fee collection, and treasury management as each have different strength and weaknesses. At present, all product development is funded by GET Protocol Foundation and as a result requires fuel revenue to sustainably continue operations. The DAO will continue to scale up over time and onboard operational costs and expenses and as a result the fuel revenue allocation to the DAO will also grow.

There is a simple product-organisation relationship available:

• Revenue from API issuances will be accrued as protocol fuel and sent to the Ticketing Revolution DAO.
• Revenue from the full suite will be accrued as the remaining fuel and sent to GET Protocol Foundation.

This matches the ethos of each product; decentralised blockchain products will be the responsibility of the DAO, centralised ticketing-system products will be the responsibility of the Foundation.

Although the DAO does not yet fund operational costs and product development of the Digital Twin, this opens up a migration path to increase this responsibility when the has DAO reached maturity. Until this point the DAO will capture Digital Twin revenue with the expectation that it will eventually manage product development costs.

The destination addresses (recipients) of the spent fuel are defineded depening on the source of the spent fuel; protocol or remainder. This gives flexibility and autonomy to each organisation in how they wish the fuel revenue to be split. Any number of addresses can be defined along with the percentage of the spend fuel portion that will be sent to that recipient.

For example, if the protocol spent fuel amount is 1000 OPN and the DAO main address is set to collect 80% of this fuel and the bounty program is allocated 20%, then the DAO main address will receive 800 OPN and 200 OPN will be sent to the bounty program address.

The subgraph can be used to list the current recipients:

{
  spentFuelRecipients {
    id
    source
    label
    percentage
  }
}

📘

If it all goes to the destinations eventually, why not send it there immediately?

• Safety. As soon as fuel is allocated to the spent fuel balance it would be collectable to the destination addresses making it unrecoverable by the economics contract. Keeping this as a reserved balance protects against edge-cases that might require recovery of this fuel.
• The ticket has not completed its lifecycle. It's important that stakeholders are incentivised to encourage proper use of the protocol, rather than focusing only on the initial mint.

Basic Tax Rate

To ensure that there is a constant flow of funds from Reserved Fuel to Spent Fuel, basic actions will be taxed a percentage of what was reserved on primary sale and this is set to 20%. If a ticket required 1.5 OPN to be used as fuel on primary mint and then this is scanned, 0.3 OPN will be deducted from the reserved fuel balance and added to the spent fuel balance.

Doing this prevents tickets with a longer lifecycle or multiple scan interactions from becoming stale and provides a steady stream of spent fuel prior to being checked-in.

Lifecycle Example

Bear in mind that the examples here are just that, examples. The primaryRate used will depend on the products used by the integrator and the fee that can be charged as a result. See the Integrator Accounts section for more.

👍

Recap

• There are three balances of OPN within the system; Available Fuel, Reserved Fuel, and Spent Fuel.
• When minting a ticket, the cost is moved from Available Fuel to Reserved Fuel.
• This Reserved Fuel funds the basic lifecycle. Premium interactions are funded by the Available Fuel.
• When a ticket is finalised the remaining Reserved Fuel will be moved to Spent Fuel.
• The Spent Fuel can be sent to the destinations using the public collect() function.