Accounting

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 DAO, 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️⃣ relayerAddress with GET.
  2. For simpler use on-chain this is refined into the 2️⃣ Relayer Silo, making it ready for consumption from within the smart contracts.
  3. Upon minting a ticket GET is moved from the Relayer Silo to the 3️⃣ NFT Fuel Tank as determined by the mintRate.
  4. When a ticket is checked-in this GET is moved to the 4️⃣ Depot balance ready for transfer to the DAO.
  5. The swipeDepotBalance can be called to issue a GET token transfer from the Depot to the 5️⃣ DAO fee collector address.

Sources of Funding

Each of the two main interaction types (Basic & Upsell) source their fuel from different balances. Basic interactions are always sourced from the backpack as a percentage of the remaining balance, and upsell interactions are paid for by the Relayer Silo balance.

When NFT tickets are first minted they are allocated a separate GET balance at the point of mint from the Relayer Silo to be used for basic interactions. For upsell interactions this fuel is paid for directly from the Relayer Silo.

Let's break it down.

  • The GET token acts as the programmable fuel for platform, all interactions are priced in GET.
  • Each integrator has their own relayer address, which can be topped up with GET.
  • When an NFT is minted, GET is assigned to that NFT from the Relayer Silo to cover the basic ticket lifecycle. This is known as the NFT 'fuel tank' and will fund all interactions within the basic end-to-end.
  • Upsell interactions would be funded from the relayer address balance atomically.

These two balances to fund interactions will be referred to as the NFT Backpack and the Relayer Silo.

Cost of Mint

In a standard basic lifecycle of a ticket, the most important variable used is the mintRate which defines the cost of minting an NFT as a percentage of the ticket's basePrice.

All of these variables are available on-chain. The basePrice is required to process and NFT mint and the relayer handling the mint is aware of its own mintRate. We can then take this mintValue for the NFT and use the price of GET from an oracle to determine the amount of GET needed to subtract from the Relayer Silo and assign into the NFT fuel tank.

Calculating this balance on-chain allows the mintBalance to be assigned to the fuel tank atomically, else the transaction will fail. If the Relayer Silo does not have enough GET fill the tank then the transaction will fail and the NFT will not be minted. Once GET has been added to the fuel tank, other basic interactions will draw down this balance perpetually.

Because of this, the protocol can be thought of as being paid for on debit. In order to continue to mint tickets a positive Relayer Silo balance must be maintained.

About the future taxRate

Once the NFT fuel tank has been filled with GET all basic interactions will continue to be funded from this GET balance to complete the basic lifecycle of a ticket. Each interaction that a ticket receieves will reduce the amount of fuel left in the tank by the percentage set as the taxRate, at which point it will be collectable by the DAO. By using a rate system like this we ensure that the balance of the fuel tank can never be 0 because the remaining fuel will be reduced by a percentage of the total.

A simple example would be to consider a taxRate of 30% and a fuel tank balance of 1 GET. The first interaction will charge 30% of 1 GET (0.3 GET), and the following interaction will charge 30% of the remaining 0.7 GET (0.21 GET). The remaining fuel in the tank after the first two interactions would be 0.49 GET.

Note that the first interaction happens at the time of mint within the same transaction. This means that minting an NFT is composed of two steps:

  1. The fuel tank balance is allocated from the Relayer Silo.
  2. The first fuel tank tax is collected.

In the example above, the tank would be left with 0.7 GET remaining directly after minting and 0.3 GET would be collectable by the DAO.

📘

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

  • If an event is cancelled or rescheduled, the remaining balance will not be lost. This is fuel that can be re-used by the NFT or integrator for these edge cases.
  • The NFT has not completed its lifecycle. It's important that DAO participants are incentivised to encourage proper use of the protocol, rather than focusing only on the initial mint.

Crediting the DAO

A check-in event is a one-way operation and will finalise the state of the ticket, making it claimable as an NFT collectible. Upon scan the remainder of the fuel tank will credited to the depot and then be collectable by the DAO fee collector, emptying the fuel tank of the NFT. In other words, checking-in a ticket ends its basic interaction lifecycle. Claims and further interactions with this ticket will be funded by the Relayer Silo as upsell interactions.

It's not economical to move GET on-chain for every ticket check-in and as such after checking-in a ticket the GET is collected to the Depot balance prior to moving to the DAO fee collector address. The depot can be collected to the DAO address at any time using the swipeDepotBalance function.

Lifecycle Example

🚧

Current Release

Please note that the current system is simpler than the table laid out below. During the testing and initial release of the DAO economics only the mintRate is in effect. This means that:

  1. GET will be debited from the Relayer Silo upon each mint.
  2. GET will be credited to the depot on each check-in.
  3. GET will be moved to the fee collector (DAO) address when the swipeDepotBalance function is called.

The additional rates below show the flexibility of the economics and the ability to provide more complex billing functionality, but to begin only the mintRate will be active.

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

🚧 = Separate rate not yet in use, currently funded via mintRate.

Step

Interaction

Cost

From Account

Sent To

1-1
(PrimarySaleMint)

mintRate
(basic)

(mintRate x basePrice)/getPrice
(2% x $50)/$1 = 1 GET

Relayer Silo
-1 GET

Fuel Tank
+1 GET

1-2
(PrimarySaleMint)

🚧 taxRate
(basic)

1 GET x 0.3 = 0.3 GET

Fuel Tank
-0.3 GET

Depot
+0.3 GET

2

🚧 editMeta
(basic)

0.7 GET x 0.3 = 0.21 GET

Fuel Tank
]-0.21 GET

Depot
+0.21 GET

3

🚧 resold
(upsell)

(resellRate x basePrice)/getPrice
(0.5% x $50)/$1 = 0.25 GET

Relayer Silo
-0.25 GET

Depot
+0.25 GET

4

checkIn
(basic)

Remaining 0.49 GET

Fuel Tank
-0.49 GET

Depot
+0.49 GET

5

🚧 claim
(upsell)

(claimRate x basePrice)/getPrice
(0.5% x $50)/$1 = 0.25 GET

Relayer Silo
-0.25 GET

Depot
+0.25 GET

6

swipeDepotBalance

Depot
-1.5 GET

DAO (Fee Collector)
+1.5 GET

TOTALS

DAO (Fee Collector)
+1.5 GET

👍

Recap

  • There are three balances of GET within the system; the Relayer Silo, NFT Fuel Tank, and the Depot.
  • When minting a ticket, the Fuel Tank is filled up using GET from the Relayer Silo.
  • The fuel tank funds a complete basic lifecycle. Upsell interactions are funded by the Relayer Silo.
  • When a ticket is scanned the remaining fuel will be sent to the Depot.
  • The depot balance can be collected to the DAO using the swipeDepotBalance function.