We are glad to present the token economics of TE-FOOD’s second token: Calories (CAL).

This post is a follow up of the Token Economy of TE-FOOD post. In the previous post, we described the token economics of TFD, and introduced the planned two-token economy.

Introduction

This token economics is meant to be treated as a temporary one. As regulation of crypto tokens is more clear, the usage and structure can, and will be iterated accordingly. Some usage of crypto — which seems natural from technological or economic viewpoint — still not approved by authorities around the world. We think the next year will bring a lot of clarifications which are necessary to create a long lasting token economics.

We think that token economics based on token printing without revenue backing are pyramid schemes, which are both illegal, and unsustainable.

As TE-FOOD has more than 6000 business customers, we had to coordinate the token economics with ordinary financial processes: who gives and invoice, for what service, in what kind of currency.

We believe we found the best solution to build a token economy which is compliant to regulations, sustainable financially, and provide good opportunities for service providers.

Tokens in the ecosystem

TFD

TFD is a tokenized software licence. Users need to hold TFD tokens to be able to access the TE-FOOD ecosystem and perform the desired activities.

CAL

CAL is a stable token (pegged to USD), which acts a clearing unit for various services (and later — products) within the TE-FOOD ecosystem. CAL is automatically generated for the service provider when a service is fulfilled.

Why CAL is not a security

CAL doesn’t have any characteristics of securities:

it will not be traded on secondary exchanges, its price will not be volatile (as it’s a stable token), and it will be paid only for providing services (software licence rental, providing computation power, etc.).

Roles

Customers — food supply chain companies paying to use TE-FOOD’s traceability transaction ledger.

— food supply chain companies paying to use TE-FOOD’s traceability transaction ledger. Service Enablers — businesses which connect Customers with the TE-FOOD ecosystem (e.g. TE-FOOD Implementation Partners).

— businesses which connect Customers with the TE-FOOD ecosystem (e.g. TE-FOOD Implementation Partners). Service Providers — people or companies who provide a service (e.g. operating masternode to secure the network of TE-FOOD’s blockchain ledger) through the TE-FOOD ecosystem.

Services to settle in CAL

TFD token rental for food companies which don’t own TFD licence tokens

The licence model of TE-FOOD allows token holders to resell, or rent out their tokenized licences to any third party. The tokens remain in their wallets, but can cover the licence need of a different user.

The user which rents the token, pays a tiny extra fee for the licence rental, which generates CAL for the one which rented out the TFD.

Verifying and storing transactions on TE-FOOD’s blockchain

Those who maintain a masternode, thus provide computation power to secure the TE-FOOD blockchain network can earn CAL for their services. Those users who use the TE-FOOD blockchain pay for the transactions.

A part of the transaction fee goes to the masternode owners for validating the blocks.

Interface usage for transactions verified and stored on other blockchains

There will be Customers which use TE-FOOD’s client side apps and/or traceability interfaces to store their data in a third-party blockchain ledger (Vechain, WaltonChain, HyperLedger, etc.). In these cases, their transaction fees will be much lower, because they don’t use TE-FOOD’s blockchain ledger.

This service does not mean interoperable blockchains. In this case, the TE-FOOD client apps and traceability interfaces use different, third-party blockchains.

A part of the transaction fee goes to the masternode owners which run the TE-FOOD interface.

Subscription for value added services

As there will be a huge number of consumers and food companies using the TE-FOOD ecosystem, generating a lot of business data, it provides a compelling opportunity for third-party solution providers. They can access these users, and — upon permission from the user — access their data to provide services for them. Example: The deep data analysis module will provide subscription based access to tools which can increase the productivity.

The CAL ecosystem

The Calories ecosystem will provide an environment for food companies and service providers where they can build, manage, and settle successful businesses. There will be three main processes of the ecosystem:

1. Contract

Customers manually or automatically can contract with Service Providers to fulfill certain services, for a pre-set amount of payment and settlement period.

2. Service

Service Providers fulfill their contractual obligations.

3. Clearing

The system automatically manages the clearing of the payment for fulfilling the services. CAL acts as a settlement unit to show the amount the Customer owes to the Service Provider. The system will support both bilateral and multilateral clearing.

Token economics

Customer (directly, or through Service Enabler) requests a service. As the service is fulfilled by the Service Provider, the fulfillment automatically generates Calories in the Service Provider’s wallet, accourding to the value of the service. The Customer (directly, or through Service Enabler) buys the Calories from the Service Provider in ETH or USD. The payment can be immediate, or bound to specific, or regular settlement dates. Calories bought by the Service Customer are burned automatically.

Token economics example of masternode operation:

Node tiers

1. Iridium node

Virtual node to rent out TFD as a licence rental. An automatic script will rent out the TFD (as software licence) to Customers which want to use TE-FOOD but don’t hold TFD. Iridium node operators won’t maintain a masternode, thus providing computation power.

A part of the Customers’ transaction cost goes to the node owner as software licence rental fee.

2. Steel node

Masternode, providing low capacity computation power. The computation power is used to run TE-FOOD’s interface to send/request traceability data to/from TE-FOOD’s own blockchain, or a third-party blockchain.

A part of the Customers’ interface transaction cost goes to the masternode owner for running the service.

3. Platinum node

Masternode, providing medium capacity computation power. The computation power is used to verify and store transactions on TE-FOOD’s blockchain, and to run TE-FOOD’s interface to send/request traceability data to/from TE-FOOD’s own blockchain, or a third-party blockchain.

A part of the Customers’ traceability transaction and interface transaction cost goes to the masternode owner for running the service.

4. Titanium node

Masternode, providing high capacity computation power. The computation power is used to run complementary services of the ecosystem used by Customers, verify and store transactions on TE-FOOD’s blockchain, and to run TE-FOOD’s interface to send/request traceability data to/from TE-FOOD’s own blockchain, or a third-party blockchain.

A part of the Customers’ traceability transaction and interface transaction cost goes to the masternode owner for running the service.

To run a node, operators are required to possess a certain amount of TFD as software licence:

Iridium — 20 000 TFD

Steel — 60 000 TFD

Platinum — 120 000 TFD

Titanium — 350 000 TFD

The configuration requirements of the tiers will be defined later, but they will be aligned to the common tier offerings of VPS providers.

Reputation

As masternodes provide continuous high level service to secure the network, their reputation score will be increased.

After each year of high level uptime, their software licence need for running the node decreases by maximum 25% each year for 5 years.

Distribution of transactions

These proportions might be iterated as we see how many applications we receive for the different masternode types, and how we can make each tiers more compelling. We think that same levels of revenue will be achieveable as other utility token masternodes, while providing a unique feature by the decrease of TFD licences through Reputation. More details will be coming during the next months.

Sharing of interface transactions amongst masternodes:

Steel — 70%

Platinum — 20%

Titanium — 10%

Sharing of traceability transactions amongst masternodes:

Platinum — 50%

Titanium — 50%

Please note that there will be much less Titanium masternodes than Steel or Platinum.

As the token economics is planned for mass adoption, the service revenues follow the typical S-curve:

The growth range of the curve will depend on a lot of factors:

TE-FOOD adoption rate

Number of nodes

Added value / food types (transaction cost can be higher in specific food types)

Relative estimation of service revenue proportions

Operational and Sleeping Masternodes

To make masternode maintenance a compelling service, the number of operational nodes (nodes which will verify and store transactions) will be limited. Having a large amount of masternodes at the start would result in bad revenue outlook which would make masternode operation unprofitable. As the expansion of TE-FOOD progresses, and the number of transactions grow, the number of masternodes will be increased.

The initial number of Operational Masternodes will be determined before the launch of the TE-FOOD blockchain according to the estimated daily transaction number during the first year of operation.

In case we receive more masternode registrations than the initially planned Operational Masternodes, a selection method will be applied. The selection method will be published soon.

However, those who plan to operate masternode, but doesn’t fit in the starting masternode limit, still can operate a Sleeping Masternode, and enjoy the Reputation growth. They can switch to an Operational Masternode when the number of transactions justifies more nodes are needed. To achieve this, they need to register for a masternode, and hold the tokens necessary for the selected masternode level.

Node eligibility time

To be deemed eligible for running a node, Service Providers will need to registrate, and keep the tokens in their wallets for a specific time period prior to start the node’s service.