Integrator Accounts

All integrators issuing tickets on GET Protocol interact with the same contracts, but aren't equal in terms of resource usage and value. Despite all tickets being issued as NFTs on-chain, the path to get there can be different depending on how much of the protocol is required.

We have two main products available for use:

• White-Label; a full-stack ticketing solution, offering mobile apps, seating and crowd management, payouts, and resale markets.
• Digital Twin; NFT ticket distribution for existing ticketing platforms. See Ticket Engine for usage.

Revenue for all product tiers is represented on-chain, but the rates charged depending on the product used as these have different pricing due to their complexity. The Digital Twin product, for example, is a infrastructure layer to allow existing ticketing systems to produce digital NFTs of their current inventory and as such is priced at a lower rate than users of the white-label product that offers this functionality by default.

Integrator Billing

While it makes sense to treat integrators of each product separately when it comes to pricing based on resource usage, in the eyes of the smart contracts all users are the same (only with different parameters and rate configurations). For that reason we identify all integrators on the protocol by their relayerAddress or integratorIndex. This allows us to rely on the on-chain identity using the public address of each relayer representing an integrator, regardless of their type or pricing model.

The following rates can be set:

struct DynamicRates {
    uint24 minFeePrimary;
    uint24 maxFeePrimary;
    uint24 primaryRate;
    uint24 minFeeSecondary;
    uint24 maxFeeSecondary;
    uint24 secondaryRate;
    uint24 salesTaxRate;
}

Here, it is useful to consider integrators as their data model on-chain as it makes it clear we are discussing smart contracts rather than invoicing or spreadsheet accounting to a business entity.

Usage metering and charging happens in real-time and the account to be charged is determined by the relayer address that is calling the contract and with a blockchain we cannot send an invoice after-the-fact.

Top-Ups

Each ticket created on the protocol requires GET to be paid as fuel in order for the NFT to be minted and without this GET fuel the NFT minting process will fail. Because of that integrators are required to top-up their balances in advance. This top-up process is managed using the Integrator Dashboard and allows for top-up of the account balance directly using GET held within a cryptocurrency wallet or using bank transfer.

The GET token itself is volatile and it would be an issue if a top-up would be made that would then reduce in value because of market volatility, so for that reason the value of a top-up is fixed in USD at the time of top up. If a top-up is worth $1,000 at the moment this top-up occurs then the value on-account added to the integrator will be fixed at $1,000 regardless of the price of GET.

Sales Tax

Stichting GET Protocol Foundation is registered and regulated in the Netherlands and we are required to charge a 21% sales tax (VAT) rate for customers also within the Netherlands. Deductions will be listed on all invoices.

Rate Configuration

Each integrator has an independent configuration of variables that define the usage costs of the protocol. GET is used as the medium of exchange and payment for all interactions on the protocol, but USD is used as the base currency for determining the amount of GET required.

A list and description of the rates used in each DynamicRates configuration can be found in System Variables.

📘

Remember

Although all NFTs are created with the same code, the rate configuration set for each integrator will depend on the product package used.