# TPRO Network Documentation
## Description
This repository contains official documentation for TPRO project. We recommend you to read this pages on [official website](https://tpro.pro/docs). If you see any problems or misleading parts of this document, tell use about it in [Github Issues](https://github.com/tpro-network/docs/issues) or consider making contributions yourself.
## Table of Contents
* [Abstract](/abstract)
* [Introduction](/introduction)
* [Objectives and Design Considerations](/objectives-and-design-considerations)
* [Design Considerations](/objectives-and-design-considerations#design-considerations)
* [Delegation of Processing Power](/objectives-and-design-considerations#delegation-of-processing-power)
* [Delegation of storage](/objectives-and-design-considerations#delegation-of-storage)
* [Data providers vs resource providers domain gap](/objectives-and-design-considerations#data-providers-vs-resource-providers)
* [TPRO at the center](/objectives-and-design-considerations#tpro-at-the-center)
* [File sizes](/objectives-and-design-considerations#file-sizes)
* [Replication](/objectives-and-design-considerations#replication)
* [On-chain reporting](/objectives-and-design-considerations#on-chain-reporting)
* [Design Overview](/objectives-and-design-considerations#design-overviewdesign-overview)
* [TPRO network overview](/objectives-and-design-considerations#tpro-network-overview)
* [Design Objectives](/objectives-and-design-considerations#design-objectives)
* [Proposed Solutions](/proposed-solutions)
* [Models](/proposed-solutions#models)
* [Publishing model scheme](/proposed-solutions#models-schemes-publishing)
* [Retrieving model scheme](/proposed-solutions#models-schemes-retrieving)
* [Publishing model instance](/proposed-solutions#models-publishing)
* [Storing model instance](/proposed-solutions#models-storing)
* [Previewing model instance](/proposed-solutions#models-previewing)
* [Purchasing model instance](/proposed-solutions#models-purchasing)
* [Tokenomics](/proposed-solutions#tokenomics)
* [Publishing tokenomics scheme](/proposed-solutions#tokenomics-schemes-publishing)
* [Retrieving tokenomics schehme](/proposed-solutions#tokenomics-schemes-retrieving)
* [Publishing tokenomics instance](/proposed-solutions#tokenomics-publishing)
* [Storing tokenomics instance](/proposed-solutions#tokenomics-storing)
* [Previewing tokenomics instance](/proposed-solutions#tokenomics-previewing)
* [Simulations](/proposed-solutions#simulations)
* [Performing simulation](/proposed-solutions#simulations-performing)
* [Publishing simulation results](/proposed-solutions#simulations-publishing)
* [Storing simulation results](/proposed-solutions#simulations-storing)
* [Previewing simulation results](/proposed-solutions#simulations-previewing)
* [Purchasing simulation results](/proposed-solutions#simulations-purchasing)
* [Analysis Reports](/proposed-solutions#analysis-reports)
* [Lifetime Events](/proposed-solutions#lifetime-events)
* [Rewarding](/proposed-solutions#rewarding)
* [Rewarding model providers](/proposed-solutions#rewarding-model-providers)
* [Rewarding tokenomics providers](/proposed-solutions#rewarding-tokenomics-providers)
* [Rewarding simulation operators](/proposed-solutions#rewarding-simulation-operators)
* [Rewarding analysts](/proposed-solutions#rewarding-analysts)
* [Rewarding storage providers](/proposed-solutions#rewarding-storage-providers)
* [Rewarding processing providers](/proposed-solutions#rewarding-processing-providers)
* [Rewarding TPRO](/proposed-solutions#rewarding-tpro)
* [Further incentivization](/proposed-solutions#further-incentivization)
* [Proofs](/proposed-solutions#proofs)
* [Proof of Offer (PoO)](/proposed-solutions#proofs-poo)
* [Proof of Storage (PoS)](/proposed-solutions#proofs-pos)
* [Proof of Purchase (PoP)](/proposed-solutions#proofs-pop)
* [Proof of Simulation (PoSIM)](/proposed-solutions#proofs-posim)
* [Managing Risks](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md)
* [Lack of adoption](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#lack-of-adoption)
* [Unfair rewarding](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#unfair-rewarding)
* [Unfair randomness](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#unfair-randomness)
* [Lack of permament storage](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#lack-of-permament-storage)
* [Repackaging instances](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#repackaging-instances)
* [Pirating instances](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#pirating-instances)
* [Defective uptime](https://github.com/TPRO-Network/docs/blob/master/manging-risks.md#defective-uptime)
* [Economic Simulations](/economic-simulations)
* [Form](/economic-simulations#form)
* [Project Selection](/economic-simulations#1_project_selection)
* [Liquidity Configuration](/economic-simulations#2_liquidity_configuration)
* [Allocation Rounds and Vesting](/economic-simulations#3_allocation_rounds_and_vesting)
* [Supply Strategy Configuration](/economic-simulations#4_supply_strategy_configuration)
* [Secondary Market Configuration](/economic-simulations#5_secondary_market_configuration)
* [Simulations](/economic-simulations#simulations)
* [Simulation Step](/economic-simulations#simulation_step)
* [Randomness Within the Scenario](/economic-simulations#randomness_within_the_scenario)
* [DEX](/economic-simulations#dex)
* [CEX](/economic-simulations#cex)
* [Vesting](/economic-simulations#vesting)
* [Primary Market Strategies](/economic-simulations#primary_market_strategies)
* [Random Sale](/economic-simulations#random_sale)
* [Aggressive Random Sale](/economic-simulations#aggressive_random_sale)
* [Incremental Doubling Sales](/economic-simulations#incremental_doubling_sales)
* [Extended Profit Multiplier](/economic-simulations#extended_profit_multiplier)
* [Incremental Profit Doubling](/economic-simulations#incremental_profit_doubling)
* [Secondary Market Agents](/economic-simulations#secondary_market_agents)
* [Base Agent](/economic-simulations#base_agent)
* [Low Advanced](/economic-simulations#low_advanced)
* [Moderately Advanced](/economic-simulations#moderately_advanced)
* [Very Advanced](/economic-simulations#very_advanced)
* [Speculator](/economic-simulations#speculator)
* [Scoring Engine](/economic-simulations#scoring_engine)
* [Allocations](/economic-simulations#allocations)
* [Demand](/economic-simulations#demand)
* [Availability](/economic-simulations#availability)
* [Short-term Price](/economic-simulations#short_term_price)
* [Long-term Price](/economic-simulations#long_term_price)
* [Additional Metrics](/economic-simulations#additional_metrics)
* [Detailed Results of the Simulation](/economic-simulations#detailed_results_of_the_simulation)
* [$TPRO Pool](/pool)
* [Liquidity Pool](/pool#balancer_pool)
* [Dynamic Fee](/pool#dynamic_fee)
* [Mechanism Parameters](/pool#mechanism_parameters_dynamic_fee)
* [Mechanisms Mathematical Specification](/pool#mechanism_mathematical_specification_dynamic_fee)
* [Impermanent Loss Protection Mechanism](/pool#impermanent_loss_protection)
* [Mechanism Parameters](/pool#impermanent_loss_protection_machnism_parameters)
* [Mechanisms Mathematical Specification](/pool#impermanent_loss_protection_mathematical_specification)
## Contributing
For contributions submitting documentation for the **current stable release**, submit it to the corresponding branch. For example, documentation for `TPRO 0.3` should be submitted to the `0.3` branch. Documentation intended for the upcoming release should be submitted to the master branch.
# Abstract
The cryptocurrency space has long been plagued by a lack of transparency in tokenomics, leading to fundamental flaws that compromise the integrity and sustainability of projects. Without clear and transparent tokenomics, investors and users are left in the dark regarding how tokens are distributed, their supply dynamics, and their utilization within the ecosystem. This opacity breeds mistrust and uncertainty, hindering widespread adoption and potentially resulting in overvaluation or undervaluation of tokens. Moreover, hidden tokenomics can facilitate market manipulation and insider trading, further damaging the reputation of projects and eroding trust within the community. Recognizing these critical issues, TPRO Network emerges as a beacon of hope, aiming to revolutionize the landscape by providing transparency and data-driven decision-making tools.
TPRO Network addresses the critical issues of financial losses exceeding $600 million in the blockchain sector due to inadequate system designs by implementing robust, thoroughly tested, and community-validated economic models. By bridging the knowledge gap in blockchain economies, TPRO enables community members with varying levels of technical expertise to actively participate and make informed decisions. This initiative not only empowers communities, founders, and venture capitalists but also sets a new standard for transparency and reliability in tokenomics.
TPRO offers a comprehensive stack that allows communities, founders, and VCs to create and utilize bulletproof economic systems, enabling them to make data-driven decisions. This approach not only increases security in the market but also provides more data for potential investors, fostering a healthier landscape for cryptocurrency projects. Additionally, TPRO Network adds value for developers by allowing them to build economic dApps on top of the network, while Key Opinion Leaders (KOLs) can develop and audit tokenomic models of projects they discuss, enhancing transparency and accountability.
For the first time in history, community members can gain an unfair advantage by making their due diligence process through data-driven decisions. This enables investors to navigate the cryptocurrency space with confidence, knowing that they have access to transparent and reliable information. Furthermore, TPRO Network adds value for founders by providing them with tools to double-check tokenomic models, mitigating the risk of project failure during launch and ensuring a solid foundation for success. \_\_
# Introduction
TPRO network is a blockchain-based ecosystem that enables modeling, simulating, reporting and verifying of tokenomics models. TPRO Network stands as a transformative force in the cryptocurrency space, revolutionizing transparency in tokenomics and paving the way for more sustainable projects. Currently, TPRO Network operates on centralized solutions based on cloud infrastructure, providing applications and tools to its users. While this centralized approach offers convenience and scalability, it comes with several drawbacks, particularly in terms of operational efficiency and uptime reliability.
Proposed Architecture
One of the primary issues with hosting ecosystems in a centralized manner is the operational burden it imposes. Centralized servers and storage databases require constant maintenance and supervision, leading to increased operational costs and resource allocation. Moreover, relying on centralized solutions leaves the network vulnerable to downtime and outages, disrupting service availability and user experience. The cost of running a centralized hosting can quickly escalate, especially as the network grows and demand increases. This not only strains the financial resources of operators but also limits scalability and expansion opportunities.
Transitioning to a decentralized architecture offers a viable solution to address these challenges. Decentralization distributes the hosting responsibilities across a network of providers, eliminating the reliance on a single point of failure and reducing the risk of downtime. Additionally, by embracing decentralization, TPRO Network operators can benefit from improved operational efficiency, reduced hosting costs, and enhanced reliability. Decentralization empowers operators to leverage existing resources more effectively and ensures uninterrupted service delivery to end-users.
For end-users, decentralization brings a host of benefits, including increased transparency, fairness, and security. With decentralized solutions, users can trust that their data is stored securely and accessed only by authorized parties. Furthermore, decentralization promotes inclusivity and accessibility, allowing users to participate in the network without discrimination or censorship. Transitioning from centralized to decentralized architecture holds immense promise for enhancing the reliability and transparency of TPRO Network. In the following sections, we will delve into the proposed architecture for TPRO Network's decentralization, outlining the specific solutions and benefits it offers to both network operators and end-users.
# Managing Risks
* [Lack of adoption](#lack-of-adoption)
* [Unfair rewarding](#unfair-rewarding)
* [Unfair randomness](#unfair-randomness)
* [Lack of permament storage](#lack-of-permament-storage)
* [Repackaging instances](#repackaging-instances)
* [Pirating instances](#pirating-instances)
* [Defective uptime](#defective-uptime)
## Introduction
Managing risks stands as a mandatory pillar for ensuring the successful delivery of complex systems and solutions. As project’s design and architecture evolves rapidly and uncertainties emerge, the need to proactively identify, analyze, and mitigate potential threats is crucial. This section of the documentation is dedicated to outlining our comprehensive approach to risk management, highlighting key strategies, methodologies, and tools employed to safeguard our project's objectives and deliverables from different threats. By effectively managing risks, we not only enhance the likelihood of project success but also bolster its resilience.
## Lack of Adoption
The lack of adoption risk refers to the potential challenge of achieving widespread acceptance and usage of the technology within the targeted user base. Despite the numerous benefits and innovations that TPRO technology offers, such as transparency, security, and decentralization, the network will suffer from the lack of adoption at early stages. In order to mitigate that risk TPRO will be required to provide its own storage providers and processing power providers at start, before independent ones join the network. Mitigation of this risk does not create any requirement on the technology side of the project, but it needs to be understood that at start TPRO will still have to cover its own computation/storage, and slowly reduce the amount of proprietary providers as the new, independent ones join the network. Eventually all storing/processing provision will be possible to be delegated outside TPRO, but not at start.
## Unfair Rewarding
Due to the extensive pool of providers offering access to specific data and/or computational resources, coupled with the dynamic nature of the system, evenly distributing rewards becomes challenging. The sheer scale of addresses within the network presents an obstacle to efficiently distributing rewards. In order to deal with this challenge the solution proposed random selection of providers within each access. However, while theoretically this would ensure even distribution of the rewards, in practice the reward distribution may be skewed especially in early and late phases of the network.
In the early phase the potentially even reward distribution may be skewed purely to low size of providers sample, meaning some of the providers may look as if they are being favored by TPRO leading to community discontent. On the other hand, in leat phase because of the large amount of providers enabled within the network, there may be too low chance for being picked at all, leading to lack of continuity in reward scheme in which providers are either losing money (not being selected at all) or winning a jackpot (if there are selected). Similar situation exists in Bitcoin mining, however it is solved by merging into pools. Because of technical limitations such a solution would not be possible for TPRO network (at least not currently). Instead a slightly modified VRF function is proposed which would track already selected providers and favor the participants that were not selected yet ensuring even distribution, regardless of sample size.
## Unfair Randomness
The issue of unfair randomness due to the random nature of the selection algorithm can be effectively addressed by implementing a verifiable random function (VRF). VRF is a cryptographic function that generates a random output while also providing a proof that the output was generated correctly. By incorporating VRF into the selection algorithm, the TPRO network ensures an even distribution of providers picked for data access or computation, thereby eliminating the potential for unfair randomness.
## Lack of Permament Storage
Delegation of storage to multiple providers may increase the system uptime and reliability, but it is not able to ensure permanent storage of the data within it. Even though multiple providers may replicate the same set of data, there is never guarantee that data will prevail long term, especially considering diminishing interest in older data, which may be outdated. In such scenarios the providers are incentivized to remove information that nobody wants, which by definition strikes out this solution as permanent storage. TPRO network may need some kind of archive to deal with this problem, but in the current iteration of the system it is unclear how to deal with this problem yet. What may be considered is a new type of provider called archive which would be paid by modelers directly for storing data outside the network, not for providing it within the network as current storage providers are meant to do.
## Repackaging Instances
Due to the monetized nature of the data available within the TPRO network, there is a threat in which consumers would purchase specified data, then repackage it under different name and/or ID and republish on the network hoping it would be able to steal purchases from the original owner. This threat can be prevented by deterministic generation of hashes of each data packet, meaning that the same information being used twice would generate the same hash. That would disqualify the same information being repackaged as it would raise double-spend error when trying to be published a second time by another owner.
## Pirating Instances
Due to the monetized nature of the data available within the TPRO network, there is a threat of piracy of the data. Consumers may purchase information from the network then publish it for free outside the network and advertise it to network users in order to direct the traffic from the network to their own repositories. This issue can be prevented by two security measures. The first security measure is deterministic hash generation mentioned in 4.5 Repackaging Instance, meaning the pirated information cannot be injected into the TPRO network from outside the second time. The second security measure is that the system would need to provide options for monetizing data while being used in simulation each time, rather than focus on purchases. Since pirated data would not be able to be put into the system a second time, and simulation would require use of existing data on the network to be paid for, there is no method of using the pirated information within simulation, majorly limiting its use. Additionally, because simulation tools are proprietary and not public in terms of source code, the pirating parties would not be able to replicate those tools out of the system.
## Defective Uptime
Due to lack of possibility to granularly check the uptime of storage providers, they cannot be rewarded for storing the data, but rather for providing the access to that data. However, while this model reduces economical risk of paying for malfunctioning providers, it cannot eliminate such providers from being part of the network. There is a possibility to monitor the uptime of the providers due to the huge size of data they will be providing within each resource. The only way to deal with this threat is to penalize the providers which did not provide resource access when requested, when chosen by VRF function. This would reduce the amount of malfunctioning providers, theoretically enabling the solution to remove malfunctioning ones from being registered on the network. Unfortunately, this solution would not limit such providers to zero. It is currently unclear how to completely deal with the problem.
# Objectives and Design Considerations
* [Design Considerations](#design-considerations)
* [Delegation of Processing Power](#delegation-of-processing-power)
* [Delegation of storage](#delegation-of-storage)
* [Data providers vs resource providers domain gap](#data-providers-vs-resource-providers)
* [TPRO at the center](#tpro-at-the-center)
* [File sizes](#file-sizes)
* [Replication](#replication)
* [On-chain reporting](#on-chain-reporting)
* [Design Overview](#design-overviewdesign-overview)
* [TPRO network overview](#tpro-network-overview)
* [Design Objectives](#design-objectives)
## Introduction
The objectives and design considerations serve as the foundational pillars guiding the development and evolution of the TPRO Network. This section tries to stay as high-level focused as possible, so it will not go into details on how to achieve mentioned characteristics and/or what kind of tech use, but rather how it should be constructed and how the solution should behave. This section is further divided into sub-sections, each one dedicated to each topic.
## Design Considerations
Design considerations serve as the guiding principles for every aspect of the project’s architecture, ensuring that each component contributes to the overall objectives and goals. By addressing key design considerations, TPRO Network aims to create a robust infrastructure that maximizes the utility of its native token while offering a seamless and secure environment for users to engage with the platform.
### Delegation of Processing Power
One crucial design consideration for the project is the strategic shift towards delegating processing power, particularly computation resources, from centralized providers to decentralized ones. By decentralizing the distribution of operational costs associated with running the network, the burden is spread across multiple providers instead of relying solely on a single entity. This approach not only promotes a more equitable distribution of resources but also incentivizes providers to offer their services directly to end-users in exchange for tokens, thereby fostering a sustainable and self-sustaining ecosystem within the network.
### Delegation of Storage
Another important design consideration for the project involves the delegation of storage space from centralized providers to decentralized ones, with the aim of spreading operational costs across multiple providers rather than relying solely on a single entity. In addition to this decentralization, ensuring data replication is crucial to the project's success. Replicating data across multiple providers simultaneously extends the artifact's lifetime and enhances network resilience by enabling fallback options. This approach not only distributes operational costs more evenly but also enhances data durability and availability, thereby bolstering the reliability and sustainability of the network as a whole.
### Data providers vs resource providers domain gap
The project actors can be categorized into two distinct groups: those who provide models for computation/storage (consumer-type) and those who offer resources for computation/storage (provider-type). However, this division creates a domain gap between them, as the consumer-type actors lack a space to temporarily store their data before presenting it to the provider-type actors for replication. Essentially, there is a missing mediation layer between these two groups. This mediation layer must be introduced to facilitate seamless interaction between actors, ensuring that consumer-type actors can easily present their data to provider-type actors without additional costs or complexity. Importantly, this mediation layer should not replace computation/storage providers but rather act as a facilitator to streamline the exchange process and enhance overall network efficiency.
### TPRO at the center
While the TPRO network aspires to be decentralized, it must evolve in a manner that ensures the longevity and relevance of the TPRO entity without rendering it obsolete. It is essential to strike a balance where decentralization enhances the network's resilience and transparency while maintaining the core value proposition of TPRO. Additionally, careful consideration must be given to prevent creating new leverage for competitors to replicate the TPRO network from scratch and potentially replace it. This necessitates ongoing innovation and adaptation to emerging technologies and market dynamics, ensuring that TPRO remains a leader in the field while embracing decentralization as a foundational principle.
### File sizes
A critical aspect of the platform as a whole is the size of the data being exchanged between its components, which can reach gigabytes in scale. This substantial file size imposes significant restrictions on how such data can be stored and shared efficiently. During the development of the system, it is paramount to keep this constraint in mind and ensure that proposed solutions are viable for handling files of such sizes. By addressing this challenge effectively, the platform can facilitate seamless data exchange and processing, unlocking its full potential for users while maintaining optimal performance and scalability.
### Replication
The replication of data within storage providers in the project is of major importance to ensure the uptime and reliability of the system. It is not sufficient merely to store artifacts produced by the TPRO network within a single service provider; rather, data replication is crucial to safeguard against potential disruptions. By replicating data across multiple storage providers, the system can mitigate the risk of downtime in the event that one or more providers become unavailable for any reason, such as maintenance, technical issues, or even natural disasters. This redundancy ensures continuous access to critical data and services, maintaining the uptime of the system and enhancing its resilience in the face of unforeseen challenges.
### On-chain reporting
TPRO Network stands as a project deeply committed to incentivizing the utility of its native token, emphasizing the need for proposed solutions to reflect this imperative. As such, delegating some components directly to the blockchain (on-chain) becomes a strategic necessity. These blockchain-based components must prioritize transparency and be payable using the TPRO token, aligning with the network's overarching vision. However, it is equally crucial to ensure a sensible division between on-chain and off-chain elements. This approach ensures that the incorporation of on-chain elements does not hinder the performance or scalability of the network and does not impose artificial costs on consumers or providers. By striking this balance, TPRO Network can optimize its operations while enhancing the value proposition of its native token.
## Design Overview
The design overview of the TPRO Network provides a comprehensive overview of the platform's architecture, highlighting key components and their interconnections in relation to business requirements. This overview serves as a roadmap for understanding how a system is supposed to be shaped.
### TPRO Network Overview
TPRO network offers following products:
* Modeling Suite which enables definitions of models and tokenomics
* Simulation Suite (“Simulate”) which provides the execution of economics (tokenomics) on top of multiple demand, supply, and market scenarios (models)
* Analysis Suite (“Analyze”) which enables extending simulation results with human-made interpretation of the results by analysts
* Insights Exchange (“Exchange”) which enables marketplace for existing models, tokenomics, simulations and analysis
TPRO network offers following services:
* Portal (which consists of multiple TPRO products)
* Fullnode which is implementation of a single node; multiple of which are required for running the network
* Off-chain Worker which is implementation of a bridge between on-chain and off-chain data and uses throughout multiple services to allow them to serve its purpose
* Wallet which is end-user application which can be used for interacting with TPRO network, holding tokens, making payments, calling offchain services, signing and authorizing services etc
* SDK which is implementation of TPRO protocol and enables instantiation and transporting of each one of TPRO network structures and primitives
* Contract Spec which is specification of contracts running on TPRO network
* Protocol Spec which is specification of protocol used between TPRO network products and services
TPRO network is built around following architectural characteristics:
* Account-based L1 settlement system (EVM)
* Oracle-based L2 supplementary layer (EVM)
* Blockchain as knowledge repository for deployment
* Blockchain as token distribution repository
* Low-finalization transfers with high throughput
* Low-transaction cost and eco friendly algorithms
* Programmability through EVM contracts
* Delegated proof of stake consensus
* Tiered architecture based on Aurora
* DAO Governance
* Highly configurable & easy for maintenance
TPRO network consists of five types of entities which are used to represent data. Those are models, tokenomics, analysis, simulations and Lifetime events.
* Models are used to represent supply and demand of different tokens and the contextual state of the world (bull market, bear market, accumulation, distribution etc).
* Tokenomics are used to represent the distribution and allocation of tokens.
* Lifetime events are used as information about past events that impacts the model or tokenomics such as transfers between users or unlocks that already happened (which is required in case of modeling tokenomics of existing platform that is already available and is being actively used by their users)
* Simulations are used to model information about the future of tokenomics, which is useful in order to predict impact of different models on the overall state of the ecosystem, including price prediction. Simulations rely on three inputs - models, tokenomics and (optionally) Lifetime events.
* Analysis are used to interpret simulation results. They represent additional human-input on top of machine-based simulation.
TPRO network provides multiple tools to define, create, use and interpret data. Those tools are used by different type of users including:
* Consumers which are type of users that can read (consume) data
* Modelers which are a type of users that can use schemes for models, fill them with contents and create model instances
* Tokenomics Provider which are a type of users that can use schemes for tokenomics, fill them with contents and create tokenomics instances
* Simulation Operators which are a type of users which can take existing models, tokenomics and/or lifetime events and run simulations in order to receive the results on how given system should behave
* Analysts which are type of users that can the results of performed simulations and add their own understanding/interpretation of the results
* Lifetime Providers are type of users that can track major events on existing platforms, filter ones which are important in case of tokenomics and provide them for the purpose of simulating on real-data
* Storage Providers are type of users which provide storage for storing model instances, tokenomics instances, lifetime events, simulation results and analysis results
* Processing Providers are type of users which provide processing/computation power for performing simulations
* TPRO is special type of use that represents TPRO as an entity within TPRO network architecture
* Validators are type of users which are running validator nodes
* Maintainers are type of users which are running non-validating nodes (inc. lite nodes and archive nodes)
* Oracle Operators are type of users which are running any type of oracles, including bridges, off-chain services, ingest controllers or any other peripheral services required for proper functioning of other services
## Design Objectives
TPRO network objectives are as follows:
* Decentralize the network further, increasing efficiency, resiliency and accessibility of the system
* Delegate processing and storage from TPRO entity to willing providers; reduce operational costs for TPRO while enabling providers to receives rewards for the services they are providing
* Delegate model instances storage to storage providers
* Delegate tokenomics instances storage to storage providers
* Delegate lifetime events storage to storage providers
* Delegate simulation results storage to storage providers
* Delegate analysis results storage to storage providers
* Delegate simulation computation to processing providers
* Standardize TPRO protocol and ensure its a go-to solution for providing trust in tokenomics
* Incentivize TPRO token usage, therefore increasing its demand in the market
* Enable “pay per data” model for models
* Enable “pay per data” model for tokenomics
* Enable “pay per data” model for lifetime events
* Enable “pay per data” model for simulations
* Enable “pay per data” model for analysis
# Proposed Solutions
* [Models](#models)
* [Publishing model scheme](#models-schemes-publishing)
* [Retrieving model scehme](#models-schemes-retrieving)
* [Publishing model instance](#models-publishing)
* [Storing model instance](#models-storing)
* [Previewing model instance](#models-previewing)
* [Purchasing model instance](#models-purchasing)
* [Tokenomics](#tokenomics)
* [Publishing tokenomics scheme](#tokenomics-schemes-publishing)
* [Retrieving tokenomics scehme](#tokenomics-schemes-retrieving)
* [Publishing tokenomics instance](#tokenomics-publishing)
* [Storing tokenomics instance](#tokenomics-storing)
* [Previewing tokenomics instance](#tokenomics-previewing)
* [Simulations](#simulations)
* [Performing simulation](#simulations-performing)
* [Publishing simulation results](#simulations-publishing)
* [Storing simulation results](#simulations-storing)
* [Previewing simulation results](#simulations-previewing)
* [Purchasing simulation results](#simulations-purchasing)
* [Analysis Reports](#analysis-reports)
* [Lifetime Events](#lifetime-events)
* [Rewarding](#rewarding)
* [Rewarding model providers](#rewarding-model-providers)
* [Rewarding tokenomics providers](#rewarding-tokenomics-providers)
* [Rewarding simulation operators](#rewarding-simulation-operators)
* [Rewarding analysts](#rewarding-analysts)
* [Rewarding storage providers](#rewarding-storage-providers)
* [Rewarding processing providers](#rewarding-processing-providers)
* [Rewarding TPRO](#rewarding-tpro)
* [Further incentivization](#further-incentivization)
* [Proofs](#proofs)
* [Proof of Offer (PoO)](#proofs-poo)
* [Proof of Storage (PoS)](#proofs-pos)
* [Proof of Purchase (PoP)](#proofs-pop)
* [Proof of Simulation (PoSIM)](#proofs-posim)
## Introduction
This section outlines proposed solutions for implementing the business requirements of the TPRO network. This section, similarly to design considerations, tries to stay as high-level as possible, so it will not go into details on how to achieve mentioned solutions and/or what kind of tech to use, but rather how it should work on a functional level and how it should behave. This section is further divided into sub-sections, each dedicated to its own topic.
## Models
Models are structures used for modeling token ecoconomic’s supply, demand and environment. Models need to be divided into two substructures: Model schemes (MS) and Model instances (MI). Schemes are structures that define the format of the model compatible with TPRO network, while Instances are schemes filled with actual data.
Model schemes are administered only by the TPRO network itself in order to establish protocol rules and it may be possible for more than one scheme to exist at time. Model schemes are also not monetized as it is part of the protocol, meaning the access to it should be public and unencrypted. Since there is no monetization involved with schemes, the solution will require TPRO network to run a service that enables querying of the model schemes directly from TPRO network, not storage providers.
Model instances can be created by modelers, which are types of end-users. Model instances can be created in online and offline modes using TPRO application (or TPRO marketplace). Model instances contain specific data provided by the modeler, therefore in contrast to schemes, they need to be monetized. Monetization of models comes in two ways. Purchasing model directly from storage provider for local storage / other needs and purchasing model for use in simulation. Purchasing models directly from storage providers would happen between consumer and storage provider through dedicated proof. Purchasing models for simulation needs would be made indirectly through (TPRO simulation suite) in such a way simulation operator pays for simulation to TPRO, then TPRO delegates part of the payment to storage provider in order to access the model.
Due to the monetized nature of model instances, they need to be fully encrypted while stored within a storage provider, so storage provider does not have free access to the contents of the data (it is not able to workaround TPRO payments). Decryption of the data should be possible only by the original owner (modeler) or TPRO marketplace itself (while providing proof of purchase). Additionally, there needs to exist some kind of preview of models, that would contain unecrypted part of the original model in order to enable consumers to view it and use that viewing as decision maker whether to make or not make purchase (similar to how parts of PDF books are provided for free to incentivize potential buyer).
In relation to models, there needs to exist a ways for:
* TPRO (T) to publish model scheme
* User (USR) to retrieve model scheme
* User (USR) to publish model instance
* Storage Provider (SP) to store model instance
* User (USR) to preview model instance
* User (USR) to purchase model instance
### Publishing Model Scheme
Publishing model scheme is a process defined as follows:
* TPRO (T) defines a new model scheme (MS)
* TPRO (T) activates a new model scheme (MS), computes its hash and publishes its contents in Ref. Data Repository (RDR)
* Ref. Data Repository (RDR) publishes model scheme under unique API link, consisting of model scheme (MS) hash, which returns model scheme (MS) definition
* TPRO (T) registers hash of newly defined model scheme (MS) within Model Scheme Registry (MSRC) contract available on TPRO network
* Model Scheme Registry (MSRC) contract emits event indicating registration of model scheme (MS)
* Event is publicly visible and can be used by User (USR) to notice new model scheme and get its routing information
### Retrieving Model Scheme
Retrieving model scheme is a process defined as follows:
* User (USR) wants to retrieve a model scheme (MS)
* User (USR) uses their wallet to query model scheme routing information from Model Scheme Registry (MSRC)
* User (USR) uses their wallet and receives routing information to query model scheme (MS) from Ref. Data Repository (RDR)
* User (USR) receives model scheme (MS)
### Publishing Model Instance
Publishing model instance is a process defined as follows:
* User (USR) retrieves model scheme according to flow 3.1.2
* User (USR) uses TPRO app (TAPP) in online or offline mode to fill model scheme (MS) therefore creating a new model instance (MI)
* User (USR) encrypts model instance (MI) and creates a preview using TPRO app (TAPP)
* User (USR) publishes model instance (MI) through TPRO marketplace (TMAR)
* User (USR) uses their wallet to provide Proof of Publishing (PoP) to TPRO marketplace (TMAR) that contains:
* information identifying created model instance (MI)
* publishing context including time-to-live for the offer (that has to match CR TTL)
* purchase price
* simulation royalties
* listing fee (if applicable)
* other relevant information
* Model instance and preview is uploaded to Cache Repository (CR) and will be available there until specified time-to-live amount of time passes
* Cache Repository (CR) provides endpoint to query model instance (MI) in encrypted form: ex: GET
* Cache Repository (CR) provides endpoint to query model instance (MI) preview in raw form, that contains part of the model instance (MI): ex: GET
* Proof of Offer (PoO) is uploaded to Offer Repository (OR) and will be available there until specified time-to-live amount of time passes
* (Optionally) TPRO marketplace (MAR) periodically publishes merkle tree root of active offers on-chain to indicate changes in offer list
* (Eventually) After TTL of the model instance (MI) publishing offer passes it is removed permanently from Cache Repository (CR) and Offer Repository (OR)
* (Optionally) User (USR) can renew offer restarting process 3.1.3
* (Optionally) Model Instance (MI) can be queried from Storage Providers
### Storing Model Instance
Storing model instance is a process defined as follows:
* Storage provider (SP) queries information about active offers from Offer Repository (OR)
* Storage provider (SP) selects interesting offers and for each:
* Storage provider (SP) download encrypted model instance (MI) and its preview from Cache Repository (CR)
* Storage provider (SP) provides endpoint to query model instance (MI) in encrypted form from its own storage: ex: GET
* Storage provider (SP) provides endpoint to query model instance (MI) preview in raw form, that contains part of the model instance (MI): ex: GET
* Storage provider (SP) registers hash of newly stored model instance (MI) within Model Instance Registry (MIRC) contract available on TPRO network together with Proof of Offer (PoO).
* Model Instance Registry (MIRC) registers model instance (MI) and its Proof of Offer (PoO)
* Model Instance Registry (MIRC) contract emits event indicating registration of model instance (MI)
* Event is publicly visible and can be used by User (USR) to notice new model instance and get its routing information
* (Optionally) TPRO Marketplace (TMAR) observes new storage registration, checks its authenticity and approves by triggering corresponding proofs (PoO) on Model Instance Registry (MIRC)
### Previewing Model Instance
Previewing model instance is a process defined as follows:
* User (USR) wants to preview a model instance (MI)
* User (USR) uses their wallet to query model instance routing information from Model Instance Registry (MIRC)
* User (USR) selects preferred Storage Provider (SP)
* User (USR) queries model instance preview from its storage using routing information received from Model Instance Registry (MIRC) - ex:
### Purchasing Model Instance
Purchasing model instance is a process defined as follows:
* User (USR) preview model instance following steps defined in process 3.1.5
* User (USR) decides to purchase a model instance (MI)
* User (USR) uses their wallet to create Proof of Purchase, which is an atomic structure allowing making off-chain payment in exchange for model instance (MI)
* Storage Provider (SP) triggers Proof of Purchase (PoP) on-chain using Proof Registry (PR)
* Payment is automatically executed from User (USR) to Storage Provider (SP)
* User (USR) queries model instance from its storage using routing information received from Model Instance Registry (MIRC) - ex:
* User (USR) can decrypt queried model instance using TPRO App (TAPP) by providing the same Proof of Purchase (PoP)
* (Optionally) TPRO App (TAPP) verifies Proof of Purchase
## Tokenomics
Tokenomics are structures used for modeling token distribution. Tokenomics need to be divided into two substructures: Tokenomics schemes (TS) and Tokenomics instances (TI). Schemes are structures that define the format of the tokenomics compatible with TPRO network, while Instances are schemes filled with actual data.
Tokenomics schemes are administered only by the TPRO network itself in order to establish protocol rules and it may be possible for more than one scheme to exist at time. Tokenomics schemes are also not monetized as it is part of the protocol, meaning the access to it should be public and unencrypted. Since there is no monetization involved with schemes, the solution will require TPRO network to run a service that enables querying of the model schemes directly from TPRO network, not storage providers.
Tokenomics instances can be created by tokenomics providers, which are types of end-users. Tokenomics instances can be created in online and offline modes using TPRO application (or TPRO marketplace).
In relation to tokenomics, there needs to exist a ways for:
* TPRO (T) to publish tokenomics scheme
* User (USR) to retrieve tokenomics scheme
* User (USR) to publish tokenomics instance
* Storage Provider (SP) to store tokenomics instance
* User (USR) to preview tokenomics instance
### Publishing Tokenomics Scheme
Publishing tokenomics scheme is a process defined as follows:
* TPRO (T) defines a new tokenomics scheme (TS)
* TPRO (T) activates a new tokenomics scheme (TS), computes its hash and publishes its contents in Ref. Data Repository (RDR)
* Ref. Data Repository (RDR) publishes tokenomics scheme under unique API link, consisting of tokenomics scheme (TS) hash, which returns tokenomics scheme (TS) definition
* TPRO (T) registers hash of newly defined tokenomics scheme (TS) within Tokenomics Scheme Registry (TSRC) contract available on TPRO network
* Tokenomics Scheme Registry (TSRC) contract emits event indicating registration of tokenomics scheme (TS)
* Event is publicly visible and can be used by User (USR) to notice new tokenomics scheme and get its routing information
### Retrieving Tokenomics Scheme
Retrieving tokenomics scheme is a process defined as follows:
* User (USR) wants to retrieve a tokenomics scheme (TS)
* User (USR) uses their wallet to query tokenomics scheme routing information from Tokenomics Scheme Registry (TSRC)
* User (USR) uses their wallet and receives routing information to query tokenomics scheme (TS) from Ref. Data Repository (RDR)
* User (USR) receives tokenomics scheme (TS)
### Publishing Tokenomics Instance
Publishing tokenomics instance is a process defined as follows:
* User (USR) retrieves tokenomics scheme according to flow 3.2.2
* User (USR) uses TPRO app (TAPP) in online or offline mode to fill tokenomics scheme (TS) therefore creating a new tokenomics instance (TI)
* User (USR) encrypts tokenomics instance (TI) and creates a preview using TPRO app (TAPP)
* User (USR) publishes tokenomics instance (MI) through TPRO marketplace (TMAR)
* User (USR) uses their wallet to provide Proof of Publishing (PoP) to TPRO marketplace (TMAR) that contains:
* information identifying created tokenomics instance (MI)
* publishing context including time-to-live for the offer (that has to match CR TTL)
* purchase price
* simulation royalties
* listing fee (if applicable)
* other relevant information
* Tokenomics instance and preview is uploaded to Cache Repository (CR) and will be available there until specified time-to-live amount of time passes
* Cache Repository (CR) provides endpoint to query tokenomics instance (TI) in encrypted form: ex: GET
* Cache Repository (CR) provides endpoint to query tokenomics instance (TI) preview in raw form, that contains part of the tokenomics instance (TI): ex: GET
* Proof of Offer (PoO) is uploaded to Offer Repository (OR) and will be available there until specified time-to-live amount of time passes
* (Optionally) TPRO marketplace (TMAR) periodically publishes merkle tree root of active offers on-chain to indicate changes in offer list
* (Eventually) After TTL of the tokenomics instance (TI) publishing offer passes it is removed permanently from Cache Repository (CR) and Offer Repository (OR)
* (Optionally) User (USR) can renew offer restarting process 3.2.3
* (Optionally) Tokenomics Instance (TI) can be queried from Storage Providers
### Storing Tokenomics Instance
Storing tokenomics instance is a process defined as follows:
* Storage provider (SP) queries information about active offers from Offer Repository (OR)
* Storage provider (SP) selects interesting offers and for each:
* Storage provider (SP) download encrypted tokenomics instance (TI) and its preview from Cache Repository (CR)
* Storage provider (SP) provides endpoint to query tokenomics instance (TI) in encrypted form from its own storage: ex: GET
* Storage provider (SP) provides endpoint to query tokenomics instance (TI) preview in raw form, that contains part of the tokenomics instance (TI): ex: GET
* Storage provider (SP) registers hash of newly stored tokenomics instance (TI) within Tokenomics Instance Registry (TIRC) contract available on TPRO network together with Proof of Offer (PoO).
* Tokenomics Instance Registry (TIRC) registers tokenomics instance (TI) and its Proof of Offer (PoO)
* Tokenomics Instance Registry (TIRC) contract emits event indicating registration of tokenomics instance (TI)
* Event is publicly visible and can be used by User (USR) to notice new tokenomics instance and get its routing information
* (Optionally) TPRO Marketplace (TMAR) observes new storage registration, checks its authenticity and approves by triggering corresponding proofs (PoO) on Tokenomics Instance Registry (TIRC)
### Previewing Tokenomics Instance
Previewing tokenomics instance is a process defined as follows:
* User (USR) wants to preview a tokenomics instance (TI)
* User (USR) uses their wallet to query tokenomics instance routing information from Tokenomics Instance Registry (TIRC)
* User (USR) selects preferred Storage Provider (SP)
* User (USR) queries tokenomics instance preview from its storage using routing information received from Tokenomics Instance Registry (TIRC) - ex: /{hash}/preview
## Simulations
Simulations are processes used by simulation operators to simulate the future behavior of token system, including token flows, allocations, performance, pricing and others. Simulations are by design performed by simulation operators that take input in the form of tokenomics instances, model instances and lifetime events. The output of simulations are the results that describe previously mentioned expectations.
Simulations can be performed by simulation operators, which are types of end-users. Simulation can be performed only in online modes using TPRO application (or TPRO marketplace). Simulations take data input from specific instances of data requested (chosen) by simulation operators, which needs to be paid far.
Covering costs of simulations comes in two ways. First, when making a simulation the TPRO application (or TPRO marketplace) has to query requested data from storage providers, which needs to be paid from overall simulation fee. This is to ensure a constant revenue stream for modelers, tokenomics providers and Lifetime event providers, while reducing threats of potential piracy or repackaging (more on this in managing risks section). In contrast to simple purchases of instances, the purchases done through simulation are distributed by TPRO application (or TPRO marketplace) through Proof of Simulation. Proof of Simulation is intended to be a simple proof that wraps around multiple Proof of Offers and Proof of Purchases that needs to be distributed between multiple providers. The purpose for this proof is to enclose everything into one, atomic structure, ensuring that simulation either pays everyone, or it fails (if the fee specified by the simulation operator is not enough to cover all costs).
Aside from querying instances which are used for simulation, there is also the matter of processing resources, as simulation tends to be expensive in terms of processing power. Payment for processing power has yet another cost that is intended to be part of the fee, which similar to other fees will be enclosed within Proof of Simulation and paid to the processing provider. Since it is not possible to provide precise estimation on how much cost will be associated with the simulation before performing ones, the proposed fee model has to enable dynamic pricing and constraining. The proposed approach is to copy the solution blockchain platforms are using for processing contracts, meaning that the fee for processing power will consist of unit price which can be used for prioritization and limit on how many processing units can be spent in order to finish simulation. The maximum processing costs for simulation would then be equal to unitPrice\*unitLimit. If simulation is performed before that limit is reached it finishes successfully. The chargeback for the unused fee should then be transferred back to the simulation operator. If simulation is not performed before the limit is reached, the TPRO application (or TPRO marketplace) should immediately drop its processing while providing appropriate error message and error code to the simulation operator. Storage fees for failed simulation should still be distributed to the storage providers, as they performed their service correctly.
To sum up, the cost of running a simulation should be covered by Proof of Simulation that will be provided by the simulation operator. Proof of Simulation should consist of, but not be limited to, choice of data instances to use and a fee for storage/processing. The overall cost of running simulation may be represented in following formula: cost = storagePriceForAllModels + processingUnitPrice\*processingUnitLimit
Monetization of simulation, in contracts to data instances, would be provided in one way only. Purchasing simulation results directly from storage providers for local storage / other needs. Purchasing simulation results directly from storage providers would happen between consumer and storage provider through dedicated proof.
Due to the monetized nature of simulation results, they need to be fully encrypted while stored within a storage provider, so storage provider does not have free access to the contents of the data (it is not able to workaround TPRO payments). Decryption of the data should be possible only by the original owner (simulation operator) or TPRO marketplace itself (while providing proof of purchase). Additionally, there needs to exist some kind of preview of simulation results, that would contain unecrypted part of the original simulation in order to enable consumers to view it and use that viewing as decision maker whether to make or not make purchase (similar to how parts of PDF books are provided for free to incentivize potential buyer).
In relation to simulations, there needs to exist a ways for:
* User (USR) to perform simulation
* User (USR) to publish simulation results
* Storage Provider (SP) to store simulation results
* User (USR) to preview simulation results
* User (USR) to purchase simulation results
### Performing Simulation
Performing simulation is a process defined as follows:
* User (USR) uses TPRO app (TAPP) in online mode to initiate simulation
* User (USR) configures simulation environment
* User (USR) selects model instances to use
* User (USR) selects tokenomics instance to use
* (Optionally) User (USR) selects lifetime events to use
* User (USR) provides additional input if necessary
* User (USR) provides simulation settings
* User (USR) configures simulation fees
* User (USR) configures base fee (cumulative storage fee)
* User (USR) configures processing unit price
* User (USR) configures processing unit size limit
* User (USR) configures other settings if applicable
* User (USR) runs simulation
* User (USR) uses their wallet to provide Proof of Simulation (PoS) to TPRO application (TAPP) that contains:
* Selected model instances including their hashes and storage providers identifications
* Selected tokenomics instances including their hashes and storage providers identifications
* (Optionally) selected lifetime events including their hashes and storage providers identifications
* (Optionally) other simulation input
* Proof of Purchase for each model
* Proof of Purchase for each tokenomics
* Proof of Purchase for each lifetime events
* Processing unit price
* Processing unit size limit
* Processing provider identification
* Proof of Offer reference (not actual PoO, but identification which proof it relates to)
* TPRO application (TAPP) finishes simulation
* User (USR) receives results
* Proof of Simulation is send to blockchain
* Simulation results and preview is uploaded to Cache Repository (CR) and will be available there until specified time-to-live amount of time passes
* Cache Repository (CR) provides endpoint to query simulation results (SRI) in encrypted form: ex: GET
* Cache Repository (CR) provides endpoint to query simulation results (SRI) preview in raw form, that contains part of the simulation results (SRI): ex: GET
* Proof of Offer (PoO) is uploaded to Offer Repository (OR) and will be available there until specified time-to-live amount of time passes
* (Optionally) TPRO marketplace (TMAR) periodically publishes merkle tree root of active offers on-chain to indicate changes in offer list
* (Eventually) After TTL of the simulation results (SRI) publishing offer passes it is removed permanently from Cache Repository (CR) and Offer Repository (OR)
* (Optionally) User (USR) can renew offer restarting process
* (Optionally) Simulation results (SRI) can be queried from Storage Providers
### Publishing Simulation Instance
Publishing simulations results instance is a process defined as follows:
* TPRO application (TAPP) finishes simulation
* User (USR) receives results
* Proof of Simulation is send to blockchain
* Simulation results and preview is uploaded to Cache Repository (CR) and will be available there until specified time-to-live amount of time passes
* Cache Repository (CR) provides endpoint to query simulation results (SRI) in encrypted form: ex: GET
* Cache Repository (CR) provides endpoint to query simulation results (SRI) preview in raw form, that contains part of the simulation results (SRI): ex: GET
* Proof of Offer (PoO) is uploaded to Offer Repository (OR) and will be available there until specified time-to-live amount of time passes
* (Optionally) TPRO marketplace (TMAR) periodically publishes merkle tree root of active offers on-chain to indicate changes in offer list
* (Eventually) After TTL of the simulation results (SRI) publishing offer passes it is removed permanently from Cache Repository (CR) and Offer Repository (OR)
* (Optionally) User (USR) can renew offer restarting process
* (Optionally) Simulation results (SRI) can be queried from Storage Providers
### Storing Simulation Instance
Storing simulation results instance is a process defined as follows:
* Storage provider (SP) queries information about active offers from Offer Repository (OR)
* Storage provider (SP) selects interesting offers and for each:
* Storage provider (SP) download encrypted simulation results instance (SRI) and its preview from Cache Repository (CR)
* Storage provider (SP) provides endpoint to query simulation results instance (SRI) in encrypted form from its own storage: ex: GET
* Storage provider (SP) provides endpoint to query simulation results instance (SRI) preview in raw form, that contains part of the simulation results instance (SRI): ex: GET
* Storage provider (SP) registers hash of newly stored simulation results instance (SRI) within Simulation Results Instance Registry (SRIRC) contract available on TPRO network together with Proof of Offer (PoO).
* Simulation Results Instance Registry (SRIRC) registers simulation results instance (SRI) and its Proof of Offer (PoO)
* Simulation Results Instance Registry (SRIRC) contract emits event indicating registration of simulation results instance (SRI)
* Event is publicly visible and can be used by User (USR) to notice new simulation results instance and get its routing information
* (Optionally) TPRO Marketplace (TMAR) observes new storage registration, checks its authenticity and approves by triggering corresponding proofs (PoO) on Simulation Results Instance Registry (SRIRC)
### Previewing Simulation Instance
Previewing simulation results instance is a process defined as follows:
* User (USR) wants to preview a simulation results (SRI)
* User (USR) uses their wallet to query simulation results routing information from Simulation Results Instance Registry (SRIRC)
* User (USR) selects preferred Storage Provider (SP)
* User (USR) queries simulation results instance preview from its storage using routing information received from Simulation Results Instance Registry (SRIRC) - ex:
### Purchasing Simulation Instance
Purchasing simulation results instance is a process defined as follows:
* User (USR) preview simulation results following steps defined in process 3.3.4
* User (USR) decides to purchase a simulation results instance (SRI)
* User (USR) uses their wallet to create Proof of Purchase, which is an atomic structure allowing making off-chain payment in exchange for simulation results instance (SRI)
* Storage Provider (SP) triggers Proof of Purchase (PoP) on-chain using Payment Registry (PR)
* Payment is automatically executed from User (USR) to Storage Provider (SP)
* User (USR) queries simulation results instance from its storage using routing information received from Simulation Results Instance Registry (SRIRC) - ex:
* User (USR) can decrypt queried simulation results instance using TPRO App (TAPP) by providing the same Proof of Purchase (PoP)
* (Optionally) TPRO App (TAPP) verifies Proof of Purchase
## Analysis Reports
Analysis reports are structures used for providing extra interpretation on top of simulation results. Analysis reports are performed by analysts that can query simulation results contents using TPRO application (or TPRO marketplace) and then use that information to create additional insights and reviews which can be consumed then by other users (similar to TradingView ideas).
Analysis reports can be created by analysts, which are types of end-users. Analysis reports can be created in online and offline modes using TPRO application (or TPRO marketplace). Analysis reports contain specific data provided by the analysts and they need to be monetized. Monetization of analysis reports comes in one way. Purchasing analysis reports directly from storage providers for local storage / other needs. Purchasing analysis reports directly from storage providers would happen between consumer and storage provider through dedicated proof.
Due to the monetized nature of analysis reports, they need to be fully encrypted while stored within a storage provider, so a storage provider does not have free access to the contents of the data (it is not able to workaround TPRO payments). Decryption of the data should be possible only by the original owner (analyst) or TPRO marketplace itself (while providing proof of purchase). Additionally, there needs to exist some kind of preview of analysis reports, that would contain unencrypted part of the original report in order to enable consumers to view it and use that viewing as decision maker whether to make or not make purchase (similar to how parts of PDF books are provided for free to incentivize potential buyer).
In relation to tokenomics, there needs to exist a ways for:
* User (USR) to publish analysis reports
* Storage Provider (SP) to store analysis reports
* User (USR) to preview analysis reports
* User (USR) to purchase analysis reports
## Lifetime Events
Lifetime events are structures used to model information about the past of a particular blockchain. Lifetime events purpose is to provide historical information about active projects which can be used to enhance simulation quality and improve results.
Lifetime events can be created by lifetime providers, which are types of end-users. Lifetime events can be provided online using the TPRO application (or TPRO marketplace). Lifetime events instances contain actual data about external networks provided by the lifetime provider.
## Rewarding
In order to provide incentivization to use TPRO tokens throughout the network, the rewarding of different participants have to be represented in TPRO tokens. This section focuses on different revenue streams for each actor, to help the readers to better understand economic incentives.
### Rewarding Model Providers
Model providers provide TPRO networks with model instances which can be used for simulations and analysis. In order to define model instances, model providers require model schemes and access to TPRO applications, both of which are available to them for free.
Model providers pay for:
* listing fees which are used to cover on-chain interactions for TPRO marketplace and storage providers
Model providers are being paid for:
* Model instances purchases
* Model instances uses in simulations
### Rewarding Tokenomics Providers
Tokenomics providers provide TPRO networks with tokenomics instances which can be used for simulations and analysis. In order to define tokenomics instances, tokenomics providers require tokenomics schemes and access to TPRO applications, both of which are available to them for free.
Tokenomics providers pay for:
* listing fees which are used to cover on-chain interactions for TPRO marketplace and storage providers
Tokenomics providers are being paid for:
* Tokenomics instances purchases
* Tokenomics instances uses in simulations
### Rewarding Simulation Operators
Simulation operators provide the TPRO network with results of simulations that they schedule. In order to perform simulation simulation, the operator needs to select the models, tokenomics and lifetime events to be used within simulation which, depending on selection, may be paid or free, but most likely paid. In order to perform simulation, the operator needs access to TPRO applications, which are available to them for free.
Simulation operators pay for:
* Model instances purchases which covers modeler that created model and storage provider that enabled access to it
* Tokenomics instances purchases which covers tokenomics provider that created tokenomics and storage provider that enabled access to it
* Lifetime events purchases which covers Lifetime providers that provided events and storage provider that enabled access to it
* Processing power provided by processing provider
Simulation operators are paid for:
* Simulation results purchases
### Rewarding Analysts
Analysts provide the TPRO network with analysis, which are interpretations of simulation results provided by simulation operators. In order to perform analysis, analysts have to purchase simulation results which are paid. Analysts also require TPRO applications, which are available to them for free.
Analysts pay for:
* Simulation results which covers simulation operator that created simulation and storage provider that enables access to it
Analysts are paid for:
* Analysis results purchases
### Rewarding Storage Providers
Storage providers provide the TPRO network with storage space to store models, tokenomics, Lifetime events, simulation results and analysis results. Additionally the provide replication when multiple providers store the same data.
Storage providers pay for:
* None
Store providers are paid for:
* Model instances purchases
* Model instances uses in simulations
* Tokenomics instances purchases
* Tokenomics instances uses in simulations
* Simulation results purchases
* Analysis results purchases
### Rewarding Processing Providers
Processing providers provide the TPRO network with processing power to perform (compute) simulations.
Processing providers pay for:
* None
Processing providers are paid for:
* Simulations computations
### Rewarding TPRO
TPRO provides applications and tools required for making models, tokenomics, aggregating Lifetime events and performing simulations and analysis. As TPRO protocol provider, TPRO is rewarded for each purchase or computation (a marginal fee on top of what providers make)
TPRO pays for:
* Application and tools development, maintenance and hosting that are not part of TPRO network blockchain monetization infrastructure
TPRO is paid for:
* Marginal fee on top of each purchase and computation
### Further Incentivization
In order to further incentivize network participants and strengthen the overall adoption of the network, TPRO may consider airdrops of tokens and/or competitions , both of which may divide amount of rewarded tokens based on participant activity on the network (judged by on-chain metrics available within TPRO network).
## Proofs
In order to properly implement the TPRO network, it will be required to implement a few types of proofs. Those proofs will be used in order to ensure monetization of the platform, efficient exchange of tokens in exchange for data, proof network metrics related to distribution and quality and, last but not least, incentive distribution of the network. All of the proofs will be provided within payment channels established between participants of the TPRO network.
### Proof of Offer (PoO)
Proof of Offer is a special type of proof exchanged between users that created any data instance that they wish to store on the TPRO network, including models, tokenomics, events, simulations, analysis reports etc. Proof of Offer main purpose is to broadcast to storage providers information that a new data instance has been produced that needs storage space, and provide them information on royalties that data instance author wishes to receive for use of the data.
Proof of Offer includes following information:
* information identifying created data instance
* publishing context including time-to-live for the offer (that has to match CR TTL)
* purchase price
* simulation royalties
* listing fee (if applicable)
* other relevant information
Proof of Offer may carry payment information alongside it, but it is not intended for the data author to pay storage providers for picking up its data, as it may lead to malicious behavior including draining of data funds, false storage, false providers etc. The payment that may be carried within Proof of Offer is only meant to: a) pay TPRO listing fees b) cover storage providers costs associated with generation of Proof of Storage
### Proof of Storage (PoS)
Proof of Storage is lightweight proof that is provided by a storage provider and settled on the TPRO network as soon as that provider modifies its storage. Proof of Storage is meant to broadcast information to TPRO participants about routing of data instances, meaning publishing the consistent information which data is being stored where, including replication information.
Proof of Storage includes following information:
* Information identifying stored data data instance
* Reference to storage information
Proof of Storage does not carry payment information alongside it. Costs of producing proof of storage is covered mostly by delegating context information to Proof of Offer that has been paid by the data author.
### Proof of Purchase (PoP)
Proof of Purchase is a proof that indicates purchase of a particular data instance from a storage provider. Proof of Purchase is the main revenue for storage providers and its is generated in two instances. First one, while the user wants to purchase information directly from the storage provider (for the purpose of using it off-chain) or while the user wants to use information while performing simulation (for the purpose of using data as simulation input).
Proof of Purchase includes following information:
* Payer
* Payee
* Amount paid
* Information identifying created data instance
* Reference to storage information
* other relevant information
### Proof of Simulation (PoSIM)
Proof of Simulation is a proof that is generated when performing simulation. The main purpose for the proof is to ensure atomicity of operations that are performed underneath the simulation suite hood. In other words Proof of Simulation wraps all other proofs which may be required for purchasing storage and/or processing power required for simulation, and enables execution of those payments all at once.
# Economic Simulations
## Form
The simulation form serves as the foundation of the simulation process, guiding users through the configuration of conditions and parameters. Its flexibility allows users to create unlimited scenarios by providing data across a wide range of possibilities. Below are the detailed steps users follow to complete the form.
#### 1. Project Selection
The first decision users make is selecting the project to simulate. They can choose from two options:
* Existing Project: Select a project already in the TPRO Network database, which has been simulated previously. All allocation rounds and vesting configurations are pre-filled but can be modified.
* New Token: For a new token, users start by entering its name and unique symbol. The symbol must not exist in the database to avoid conflicts.
Next, users provide a unique simulation name and specify the simulation duration. Currently, the duration can range from 50 to 100 months.
#### 2. Liquidity Configuration
The liquidity block determines how the token will interact with exchanges. Users choose between:
* Decentralized Exchange (DEX): Based on an AMM engine.
* Centralized Exchange (CEX): Using an Order Book engine.
Once the type of exchange is selected, users input the number of tokens in liquidity and the corresponding reserve in stablecoin for the simulation. This step defines the initial market environment for the token.
#### 3. Allocation Rounds and Vesting
Allocation rounds define how tokens are distributed across different categories. Users configure rounds by specifying:
Round Type:
* Team: Tokens allocated to team members.
* Ecosystem: Tokens reserved for system goals and project development.
* Investor: Tokens sold to raise funding for the project.
Round Details:
* Name: A unique identifier for the round.
* Number of Tokens: Total tokens allocated to the round.
* Percentage Released at TGE: The percentage of tokens released at the Token Generation Event.
* Cliff Duration: Length of the cliff (in months).
* Vesting Duration: Length of vesting (in months).
* Selling Price (Investor rounds only): The token sale price, which influences sales strategies.
If users select an existing project, these details are pre-filled but remain editable to accommodate specific simulation needs.
#### 4. Supply Strategy Configuration
The next step involves setting supply assumptions for each allocation round. Users select from predefined sales strategies representing typical investor behaviors. Users can configure different strategies for each allocation round, enabling diverse scenarios that impact simulation outcomes.
#### 5. Secondary Market Configuration
This stage focuses on simulating secondary market dynamics. Users configure the following:
* Demand and Supply: Enter expected monthly demand for the token in the secondary market and its impact on secondary market supply.
* Types of agents: Selection of agents for simulation. Users define the maximum monthly budget for token purchases, which will only be used if the conditions of their strategy are met. This budget is divided equally among all agents.
Future updates will include the ability to specify demand and supply parameters in a non-linear fashion, enhancing the precision of simulations.
Once the form is completed, all data is saved to a config.json file. This file serves as the direct input for the simulation engine, triggering the process and defining all conditions for the simulation.
## Simulations
Based on the form data provided in the form of a config.json file, the economic simulation process for a given project is initialized. The simulation engine leverages RadCAD, a Python-based framework designed for modeling and simulating dynamic systems. User-supplied values are converted into simulation parameters and are enriched with parameters that are constant for each simulation and are stored in the system\_params. The order of agents' actions is defined based on config.json, and the result is a partial\_state\_update\_blocks.
#### Simulation step
In the simulation engine, time is divided into discrete units called steps, which serve as the basis for modeling dynamic interactions in the system. Each step represents a specific time interval (month) and covers the progress of the system over that period. The steps are sequential, with each step building on the results of the previous one. This structure makes it possible to analyze emerging behavior and trends that evolve over time.
At the beginning of each step, the state of the system is initialized based on conditions from the previous step or the initial configuration for the first step. The driving force behind the system's progress are agents - autonomous units that make decisions and interact with the environment. Agents operate according to predefined rules or strategies, often containing elements of randomness to reflect the unpredictability inherent in the real world, in particular the cryptocurrency market.
One step of the simulation consists of many substeps, and each of them is responsible for the action of one agent. Some agents act through more than one sub-step. The sequence in which agents act plays a key role in shaping the dynamics of the system. Actions occur sequentially, where one agent completes its turn before starting the next. This approach closely mirrors actual market behavior, where agents respond to the observable actions of others, adding strategic depth through decisions that are adjusted based on changing conditions.
The simulation stage proceeds in a structured manner, including the following key phases:
* Agent actions: Each agent performs actions according to its behavioral rules. For example, an agent may decide to buy, sell or hold assets based on its internal state and external signals, such as market trends or resource availability. These actions are defined by a set of rules specific to the agent's goals and constraints, ensuring diverse and realistic behavior in the system. This logic is implemented through policy functions.
* Status updates: When an agent takes an action, the system updates its global status. This includes recalculating shared variables such as token price, liquidity pool or order book states. This phase also takes into account changes triggered by smart contracts, such as token vesting schedules. States are changed via the state update function.
The policy function and the state update functions form a partial state update (PSUB) block.
A key feature of the simulation engine is its ability to model the interdependencies between agents and the feedback loops that result from these interactions. Agents do not act in isolation; their actions and decisions create ripple effects throughout the system. For example, a sudden price increase caused by the actions of one agent can trigger a cascade of reactive decisions.
#### Randomness within the scenario
A critical feature of simulation is its ability to balance randomness in agents' decisions with predefined scenario assumptions. The agents' actions are not completely deterministic; they include an element of randomness to mimic unpredictability in the real world. While randomness adds variability, the simulation is anchored by a set of defined values and constraints that represent the general conditions of the system. The interaction of randomness and assumptions allows the simulation to explore a variety of situations while remaining consistent with the agents' general operating assumptions.
The simulation engine leverages Monte Carlo runs to capture the variability and uncertainty inherent in dynamic systems such as cryptocurrency markets. This approach involves conducting multiple simulation trials, each with unique conditions determined by the non-deterministic behavior of agents. By incorporating randomness in agent decisions, the simulation studies a wide range of possible market situations, offering insights into the system’s behavior under various scenarios.
#### DEX
The decentralized exchange model is built around the concept of an Automated Market Maker (AMM), reflecting the operational structure of platforms such as Uniswap V2. Unlike the real world with multiple liquidity pools supporting different token pairs, the simulation simplifies this structure by consolidating all trades into one large liquidity pool. This simplification is based on the assumption of the presence of a perfect arbitrageur that ensures consistent prices across the hypothetical smaller pools, equalizing prices immediately when discrepancies arise. The simulated tokens are paired with a stablcoin each time. This pairing eliminates the impact of reserve asset price volatility on token prices, allowing the model to focus solely on the relationship between supply and demand. Consequently, price movements are determined by a fixed-product formula in which the product of token reserves in the pool remains constant after each transaction. The price fluctuations of a stablecoin that is a pair to a simulated token are also not taken into account.
#### CEX
The centralized exchange model is based on the order book trading mechanism commonly used by traditional exchanges. The model reflects the sequential execution of orders by users and market makers, illustrating how prices and liquidity evolve dynamically in a centralized trading environment. The model assumes that user orders are executed without a bid-ask spread, allowing orders to be matched immediately at a single price level. Once user orders are fully executed, a market maker steps in to provide additional liquidity by placing buy and sell orders at varying densities around the current market price. The highest concentration of orders is near the prevailing price, and fewer orders are placed as the price distance increases and a maximum spread of 2% is assumed. This approach mimics the behavior of market makers in real markets, ensuring stability and consistent price discovery. As with the DEX model, the simulation assumes the presence of a perfect arbitrageur, ensuring that prices on the CEX remain consistent with prices in other markets.
#### Vesting
The simulation engine includes linear monthly vesting with cliff, reflecting the most commonly implemented vesting schedules in the cryptocurrency world. This approach is consistent with the engine's monthly time steps, eliminating the need for daily or weekly vesting mechanisms while maintaining sufficient granularity for accurate modeling.
The initial state of the system is always defined as a token generation event (TGE), serving as the starting point for all token allocations and subsequent releases. Tokens are distributed according to a user-defined token release schedule. This schedule defines the scheduled release of tokens over time, ensuring consistency and transparency in allocations.
Tokens go through the following states during the vesting process:
* Unvested State: Tokens are locked, and are waiting for releases in accordance with the release haromonogram.
* Vested State: Tokens are initially released to the vested state according to the release schedule. These tokens are allocated but are not yet available for use.
* Claimed State: Once allocated, tokens can be collected by users. Each agent takes a portion of the available tokens with a certain randomness interval reflecting the unpredictability of behavior in the real world. These tokens can be used to execute strategies, and when more than one strategy is used, they are divided evenly.
* Sold: Tokens can be sold, in which case they go into sold status. This means that the agent no longer owns these tokens, and they have gone to other agents in the system or to the liquidity pool.
Each token state change is implemented by a separate partial state update block.
#### Primary Market Strategies
The simulation includes several strategies for selling tokens in the market. Each strategy reflects a different approach to token sales, focusing on different levels of predictability, profit realization and market behavior. These strategies allow for a nuanced exploration of token dynamics, capturing short-term fluctuations and long-term trends.
**Random Sale**
This strategy models an unpredictable approach to token sales. Agents sell a random percentage of their holdings each month, ranging from 0% to 30%. Often, more tokens are sold immediately after they are claimed, with sales tapering off over time as fewer tokens remain. However, randomization may also lead to scenarios where fewer tokens are sold at the beginning and larger amounts are sold in later months. The Monte Carlo method ensures that all these variations are explored, capturing the broad range of potential behaviors and market impacts.
**Aggressive Random Sale**
The aggressive random sale strategy increases the range of token sales, with agents selling between 10% and 50% of their holdings each month. This reflects more assertive selling patterns, with consistent and significant amounts of tokens entering the market. Randomization allows for variability in how quickly tokens are sold, from rapid liquidation to steady distribution over time. The Monte Carlo method is used here to explore diverse possibilities, including extreme cases of fast or slow token sales and their implications for the market.
**Incremental doubling Sales**
This strategy ties token sales to specific price milestones. Tokens are sold whenever the token price doubles relative to the investors buy price, continuing until the total profit equals the initial investment. For example, if $1,000 was invested, tokens are sold at a doubling to recover $1,000, with additional sales occurring at each subsequent doubling (e.g., x4, x8). While most agents adhere to this systematic profit-taking approach, some consistently sell small amounts of tokens before reaching these milestones, driven by impatience or opportunistic behavior. This adds a steady trickle of token sales to the market, introducing variability into the otherwise structured strategy.
**Extended Profit Multiplier**
Building on the incremental doubling approach, this strategy introduces larger price increases between sales. After the price doubles and the initial investment is recovered, further sales occur only at significant multipliers, such as sixfold (x6), thirtyfold (x30), and beyond. This strategy reflects a long-term perspective, with agents holding tokens for higher profits at major price milestones. However, not all agents strictly follow this approach. Some consistently sell small amounts of tokens earlier, adding steady liquidity to the market. These minor deviations create additional supply while maintaining the overall focus on significant profit-taking.
**Incremental Profit Doubling**
This strategy combines the structured nature of incremental doubling with increasing profit margins. After recovering the initial investment at the first price doubling, agents sell tokens at each subsequent doubling (e.g., x4, x8), generating profits that exceed the initial investment by 20% (e.g., $1,000; $1,200; $1,400). Alongside this systematic approach, some agents introduce small token sales outside the doubling intervals, driven by varying levels of adherence to the strategy.
#### Secondary Market Agents
**Base agent**
Demand Strategy: The agent commits to purchasing tokens every month, utilizing the entire budget allocated for the simulation step. This predictable buying behavior ensures a steady injection of demand into the market, independent of price trends or external factors. Randomness is added to the execution of purchases, creating variability that allows for the exploration of atypical and extreme situations in the simulation. By maintaining consistent purchases, the agent stabilizes market dynamics and reinforces the role of demand as the driver of supply.
Supply Strategy: The agent sells a fixed percentage of their token holdings at every simulation step. However, a high degree of randomness is introduced to the sales process, resulting in significant variability in the timing and volume of tokens sold. This randomness reflects real-world unpredictability in investor behavior, where supply often shifts based on short-term market conditions, sentiment, or individual decisions. This approach reflects the really observable shift in supply over time, relative to demand.
**Low advanced**
Demand Strategy: The less advanced agent buys tokens during upward price trends, purchasing on average every 5% price increase. The value of each purchase is randomly selected from 75% to 100% of the dollars allocated for that month. After at least two purchases, subsequent purchases become progressively smaller, with each being about 7% less than the previous one. The buying pattern resets when the price drops by an average of 20% from the last purchase price. Additionally, the agent makes small purchases at every simulation step, regardless of market conditions, simulating impulsive behavior. This strategy reflects impulsive buying behavior influenced by optimism in rising markets, with reduced activity as price trends weaken.
Supply Strategy: This agent begins selling tokens when the price falls below 20% of their purchase price, selling an average of 5% of their holdings. Sales continue to increase as the price drops further, reflecting a reactionary approach to the down trend. In parallel, the agent sells a small percentage of tokens at every step, regardless of price trends, simulating the actions of impatient investors breaking from the strategy. The Monte Carlo method explores these deviations, capturing how small, random actions influence overall market outcomes. This approach highlights the agent's limited patience and tendency to sell under pressure, exacerbating downward trends.
**Moderately Advanced**
Demand Strategy: The moderately advanced agent starts buying tokens during upward price trends but requires a stronger signal, typically purchasing every 20% price increase. Purchases are randomly selected from 75% to 100% of the allocated dollars. After two consecutive purchases, the value of subsequent buys decreases by about 8%. The buying cycle resets when the price drops by an average of 30% from the last purchase. Moreover, this agent engages in minor, steady buying activity at every simulation step, reflecting occasional market participation beyond their primary strategy. This strategy captures a more calculated approach to buying during growth phases, with measured activity in volatile markets.
Supply Strategy: This agent begins selling tokens when the price drops by 35% from the entry price, disposing of an average of 8% of their holdings. As the price continues to fall, the agent slows its selling activity. Conversely, the agent also sells tokens when prices increase significantly, selling an average of 15% of their holdings when the price triples relative to their purchase price. In addition, small token sales occur consistently at every step, representing minor deviations from their planned behavior. Monte Carlo simulations model these variances, exploring how strategic and steady selling impacts the market. This approach balances opportunistic profit-taking with loss management, reflecting moderate sophistication in decision-making.
**Very advanced**
Demand Strategy: Advanced agents focus on accumulation during market downturns, buying tokens after prices have dropped by roughly 30%. Each purchase is randomly valued between 80% and 100% of the funds allocated for that step. If two consecutive purchases are made, the value of the following transactions reduces by 10%. This buying cycle resets when prices decline further, by about 35% from the last purchase price. Alongside these calculated actions, this agent makes minor, consistent purchases at every step, reflecting opportunistic behavior to ensure consistent market engagement. This strategy embodies a disciplined, focused on accumulating assets during periods of value decline.
Supply Strategy: This strategy sells tokens only after their value doubles relative to the entry price, releasing an average of 15% of their holdings. During price declines, small portions of tokens are sold incrementally to manage risks without significantly reducing their positions. Additionally, consistent small sales occur during each simulation step, introducing slight variability in the agent's otherwise structured strategy. The Monte Carlo method captures the impact of these small deviations, providing a nuanced view of advanced market behavior. This approach reflects a long-term strategy focused on capitalizing on significant gains while mitigating potential losses.
**Speculator**
Demand Strategy: The speculator adopts a fast-paced buying strategy, acting whenever prices increase by 30%. Purchases are randomly selected within a range of 80% to 100% of the allocated budget for that step. This agent also enters the market after a downtrend reverses, buying tokens after a 10% drop from the peak and a subsequent 5% price increase. If multiple purchases are made, the value of each successive transaction decreases by 9%. Small, consistent purchases at every simulation step represent speculative behavior, reflecting opportunism even outside of their primary buying strategy. This strategy highlights the speculative mindset, focused on seizing opportunities during clear price trends and reversals.
Supply Strategy: The speculator sells tokens after a 20% price increase from the last purchase during an uptrend, disposing of approximately 6% of their holdings. This process continues with every additional 10% price increase until the trend reverses into a downtrend. At that point, speculative selling halts, awaiting the next upward cycle. Small token sales occur regularly at each step, mimicking the behavior of opportunistic traders taking advantage of minor price movements. This approach emphasizes short-term gains and rapid turnover, reflecting the behavior of profit-driven traders.
## Scoring Engine
The scoring engine is a system designed to evaluate token performance using simulation-based metrics. This innovative approach, gives a deeper as well as accessible insight, into projects in the cryptocurrency market. It takes into account various aspects of token allocation, demand, availability and price behavior, drawing insights from Monte Carlo simulations.
The final score is calculated as a weighted average of these components, providing a balanced representation of the token's overall potential. The final project score consists of all the scores of individual scenarios. A single scenario is scored according to the following criteria:
**Allocations**
This component evaluates how token allocations are distributed among key categories, including providing liquidity on exchanges and ownership of teams and investors. It tracks these allocations both during the Token Generation Event (TGE) and throughout the simulation period. A high score on this component indicates a balanced and fair distribution of tokens among stakeholders, suggesting lower centralization risk and a fair basis for future token investors.
**Demand**
The demand metric measures the level of assumed demand generated for a token relative to the initial reserve in its liquidity pool. This indicator provides a fair assessment of projects based on their size. A high score suggests a high liquidity of the token, tuned to the demand expected from prospective investors.
**Availability**
Availability examines the percentage of tokens in circulation compared to the total maximum supply four years after the start of the project. This component highlights how available a token is in the broader market. A high score suggests high liquidity, favoring ease of trading, while a lower score may indicate long-term lock-in and potential risk for long-term investors.
**Short-term price**
This component analyzes the behavior of the token price over the first six months, including percentage changes and the frequency of up and down price movements. Good performance on this metric suggests that the project has a well-designed tokenomic for the initial phase.
**Long-term price**
Long-term price evaluates a token's performance after the first six months, measuring percentage changes and the intensity of upward and downward trends. A high score reflects a well-designed tokenomics, which can be an additional asset to convince long-term investors.
#### Additional metrics
These additional indicators enrich the scoring, offering deeper insights into token price behavior and market dynamics throughout the simulation:
Percentage of time above the listing price: Measures how often the token price has remained above the listing price. A higher percentage indicates correct pricing of the token and a well-designed tokenomic.
* Lowest price: Determines the minimum price observed during the simulation, providing insight into the potential risk of the token falling under adverse conditions.
* Highest price: Captures the peak price achieved, reflecting the token's potential for maximum growth in favorable scenarios.
* Percentage time of price increase: Shows the percentage of periods in which the token's price increased compared to the previous period. A higher percentage suggests a steady growth rate.
* Bottom quartile price: Represents the price below which 25% of observations occurred, offering a perspective on the token's risk profile and the behavior of the lower boundary.
* Median price: Highlights the midpoint of a token's price distribution, providing a clear picture of typical performance across samples.
* Longest rising price trend: Tracks the longest continuous period of price growth, indicating the token's ability to sustain growth phases and inspire investor confidence.
* Longest price decline trend: Measures the longest period of continuous price declines, shedding light on the token's vulnerability to prolonged declines.
#### Detailed results of the simulation
Summary Mode:
* Average Token Price Across All Scenarios: Displays the average token price in time, calculated from all Monte Carlo trials for each scenario.
* Average Score Across All Criteria: Shows the overall scoring average, aggregating all performance metrics across scenarios.
* Metrics Across All Scenarios: Summarizes key performance indicators, including price trends.
* List of All Tested Scenarios: Provides a comprehensive list of every tested scenario and its configuration.
* Compare Reality to Simulations: Experimental feature that compares real-world data (if available) to the outcomes of the simulated scenarios.
* Average Supply From Primary Market Over Time: Tracks the average token supply introduced from allocation rounds across time.
* Market Metrics: Highlights tokens sold and bought by secondary market users, along with Fully Diluted Valuation (FDV) and Market Cap averages.
* Vesting States for Each Allocation Round: Breaks down the tokens for each allocation round into four states: unvested, vested, claimed and sold.
Expert Mode:
* Average Token Price: Provides the average token price across Monte Carlo runs with additional details on the number of tokens sold and bought each month.
* Scoring of Single Scenario: Displays the score for an individual scenario, detailing its specific outcomes.
* Metrics of Single Scenario: Includes granular metrics for one scenario, such as lowest and highest price or longest upward trends .
* Compare Reality to Simulations: Experimental feature that compares real-world data (if available) to the outcomes of a single scenario.
* Primary Market Supply Over Time: Shows detailed supply data for all allocation rounds, month by month.
* Revenue Realized by Investors and Strategies: Tracks revenue generated by investors and the effectiveness of their chosen strategies.
* Tokens Sold and Bought by Agents: Breaks down secondary market transactions by agent type, providing a detailed view of market dynamics in time.
* State of Liquidity Pool/Market Maker: Provides metrics on liquidity pools or market makers, including reserve levels and token balances.
* Average Volume, FDV, and Market Cap: Displays the average trading volume, Fully Diluted Valuation, and Market Cap across all Monte Carlo trials.
* Minimum Demand to Sustain Listing Price: Calculates the demand required to maintain the listing price over time.
* State of Tokens for Each Allocation Round: Provides a detailed breakdown of tokens states, with a special focus on tokens sold during the simulation.
Expert Mode Additional Feature: Users can compare multiple scenarios in detail, enabling a side-by-side analysis of key metrics and performance outcomes.
# TPRO Public API
## Assumptions
| Field | Type | Description |
| ---------- | ------ | ----------- |
| dex | String | |
| cex | String | |
| vesting | String | |
| disclaimer | String | |
| others | String | |
## String
The `String` scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.
## SocialEntry
| Field | Type | Description |
| ----- | ------ | ----------- |
| name | String | |
| data | String | |
## Project
| Field | Type | Description |
| ------------ | -------------- | ----------- |
| slug | String! | |
| symbol | String | |
| name | String | |
| averageScore | Float | |
| assumptions | Assumptions | |
| logo | String | |
| sources | \[String] | |
| website | String | |
| socials | \[SocialEntry] | |
| createdAt | Int | |
| updatedAt | Int | |
## Float
The `Float` scalar type represents signed double-precision fractional values as specified by [IEEE 754](https://en.wikipedia.org/wiki/IEEE_floating_point).
## Int
The `Int` scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.
## AgentsParams
| Field | Type | Description |
| ----------------------------- | ----- | ----------- |
| base\_agent\_dollars | Int | |
| base\_agent\_sale\_percentage | Float | |
| sum\_dollars\_other\_agents | Int | |
## SimulationShort
| Field | Type | Description |
| ------------------------ | ------------ | ----------- |
| id | String | |
| execution\_time\_seconds | Int | |
| agents | \[String] | |
| agents\_params | AgentsParams | |
| liquidity\_reserve | String | |
| liquidity\_tokens | String | |
| score | Float | |
| createdAt | Int | |
## Agent
| Field | Type | Description |
| ----- | ------------ | ----------- |
| name | String | |
| data | \[\[String]] | |
## MetricEntry
| Field | Type | Description |
| ----- | ----------- | ----------- |
| name | String | |
| data | \[\[Float]] | |
## Metric
| Field | Type | Description |
| ------- | ----------- | ----------- |
| median | MetricEntry | |
| average | MetricEntry | |
| range | MetricEntry | |
## Strategy
| Field | Type | Description |
| ----- | ------ | ----------- |
| name | String | |
| data | Float | |
## Pool
| Field | Type | Description |
| ----- | ----------- | ----------- |
| name | String | |
| data | \[Strategy] | |
## MetricsData
| Field | Type | Description |
| -------------------------------------------- | ----- | ----------- |
| percentage\_timesteps\_above\_listing\_price | Float | |
| min\_price | Float | |
| market\_cap\_for\_min\_price | Float | |
| max\_price | Float | |
| market\_cap\_for\_max\_price | Float | |
| increase\_timesteps\_percentage | Float | |
| price\_below\_25 | Float | |
| price\_above\_50 | Float | |
| longest\_increase\_trend | Int | |
| longest\_decrease\_trend | Int | |
| price\_change\_24h | Float | |
| price\_change\_7d | Float | |
| price\_change\_30d | Float | |
| price\_change\_180d | Float | |
| price\_change\_365d | Float | |
| price\_change\_max | Float | |
## VestingStackedArea
| Field | Type | Description |
| ------------- | -------------- | ----------- |
| vesting\_data | \[MetricEntry] | |
| extra\_line | MetricEntry | |
## TokenPoolDataset
| Field | Type | Description |
| ------------- | -------- | ----------- |
| name | String | |
| data | \[Float] | |
| unit | String | |
| type | String | |
| valueDecimals | Int | |
## LiquidityPools
| Field | Type | Description |
| -------- | ------------------- | ----------- |
| xData | \[Int] | |
| datasets | \[TokenPoolDataset] | |
## ScoringData
| Field | Type | Description |
| -------------- | --------- | ----------- |
| main\_score | Float | |
| average\_score | \[Int] | |
| categories | \[String] | |
## TokenPriceMonths
| Field | Type | Description |
| ----- | ------ | ----------- |
| name | String | |
| data | \[Int] | |
## TokenPriceAverageTokenPrice
| Field | Type | Description |
| ----- | -------- | ----------- |
| name | String | |
| data | \[Float] | |
## TokenPriceAverageSoldTokens
| Field | Type | Description |
| ----- | ------ | ----------- |
| name | String | |
| data | \[Int] | |
## TokenPriceAverageBoughtTokens
| Field | Type | Description |
| ----- | ------ | ----------- |
| name | String | |
| data | \[Int] | |
## TokenPriceWithSupplyAndDemand
| Field | Type | Description |
| ----------------------- | ----------------------------- | ----------- |
| months | TokenPriceMonths | |
| average\_token\_price | TokenPriceAverageTokenPrice | |
| average\_sold\_tokens | TokenPriceAverageSoldTokens | |
| average\_bought\_tokens | TokenPriceAverageBoughtTokens | |
## UnvestedVestedClaimedSoldRoundData
| Field | Type | Description |
| ---------------- | ------ | ----------- |
| unvested\_tokens | \[Int] | |
| vested\_tokens | \[Int] | |
| claimed\_tokens | \[Int] | |
| sold\_tokens | Metric | |
## UnvestedVestedClaimedSoldRound
| Field | Type | Description |
| ----- | ---------------------------------- | ----------- |
| name | String | |
| data | UnvestedVestedClaimedSoldRoundData | |
## MarketDataset
| Field | Type | Description |
| ------------- | -------- | ----------- |
| name | String | |
| data | \[Float] | |
| unit | String | |
| type | String | |
| valueDecimals | Int | |
## SecondaryMarketCumulative
| Field | Type | Description |
| -------- | ---------------- | ----------- |
| xData | \[Int] | |
| datasets | \[MarketDataset] | |
## Simulation
| Field | Type | Description |
| --------------------------------------- | --------------------------------- | ----------- |
| id | String | |
| execution\_time\_seconds | Int | |
| agents | \[String] | |
| agents\_params | AgentsParams | |
| liquidity\_reserve | String | |
| liquidity\_tokens | String | |
| score | Float | |
| sold\_individual\_agent | \[Agent] | |
| bought\_individual\_agent | \[Agent] | |
| tokens\_bought\_metric | Metric | |
| fully\_diluted\_valuation | Metric | |
| volume | Metric | |
| market\_cap | Metric | |
| cumulative\_sold\_primary\_market | Metric | |
| token\_price | Metric | |
| primary\_market\_profits | Metric | |
| min\_needed\_demand | Metric | |
| tokens\_sold\_metric | Metric | |
| strategies\_profits | \[Pool] | |
| metrics | MetricsData | |
| primary\_market\_sold\_scatter\_plot | \[MetricEntry] | |
| vesting\_stacked\_area | VestingStackedArea | |
| liquidity\_pools | LiquidityPools | |
| scoring | ScoringData | |
| token\_price\_with\_supply\_and\_demand | TokenPriceWithSupplyAndDemand | |
| unvested\_vested\_claimed\_sold | \[UnvestedVestedClaimedSoldRound] | |
| secondary\_market\_cumulative | SecondaryMarketCumulative | |
| createdAt | Int | |
## GetProjectsOutput
| Field | Type | Description |
| --------- | ---------- | ----------- |
| projects | \[Project] | |
| nextToken | String | |
## GetSimulationsOutput
| Field | Type | Description |
| ----------- | ------------------ | ----------- |
| simulations | \[SimulationShort] | |
| nextToken | String | |
## ProjectInfoDexSettingsInput
| Field | Type | Description |
| -------------- | ----- | ----------- |
| reserve | Int | |
| tokens | Int | |
| listing\_price | Float | |
## ProjectInfoCexSettingsInput
| Field | Type | Description |
| ---------------------- | ----- | ----------- |
| market\_maker\_dollars | Int | |
| market\_maker\_tokens | Int | |
| listing\_price | Float | |
## ProjectInfoInput
| Field | Type | Description |
| --------------------- | --------------------------- | ----------- |
| project\_name | String! | |
| project\_symbol | String! | |
| project\_slug | String! | |
| number\_of\_timesteps | Int! | |
| timestep\_duration | String! | |
| dex | Boolean! | |
| dex\_settings | ProjectInfoDexSettingsInput | |
| cex | Boolean! | |
| cex\_settings | ProjectInfoCexSettingsInput | |
## Boolean
The `Boolean` scalar type represents `true` or `false`.
## PrimaryMarketRoundSupplyStrategiesInput
| Field | Type | Description |
| ---------------------------- | -------- | ----------- |
| strategy\_random | Boolean! | |
| strategy\_random\_aggressive | Boolean! | |
| strategy\_1 | Boolean! | |
| strategy\_2 | Boolean! | |
| strategy\_3 | Boolean! | |
## PrimaryMarketRoundInput
| Field | Type | Description |
| ------------------ | ---------------------------------------- | ----------- |
| name | String! | |
| type | String! | |
| number\_of\_tokens | String! | |
| tge\_percentage | Float! | |
| cliff | Int! | |
| vesting | Int! | |
| buy\_price | Float! | |
| supply\_strategies | PrimaryMarketRoundSupplyStrategiesInput! | |
## PrimaryMarketInput
| Field | Type | Description |
| ----------------------- | --------------------------- | ----------- |
| primary\_market\_rounds | \[PrimaryMarketRoundInput!] | |
## SecondaryMarketAgentsInput
| Field | Type | Description |
| -------------------- | -------- | ----------- |
| base\_agent | Boolean! | |
| low\_advanced | Boolean! | |
| moderately\_advanced | Boolean! | |
| very\_advanced | Boolean! | |
| speculator | Boolean! | |
## SecondaryMarketAgentsParamsInput
| Field | Type | Description |
| ----------------------------- | ----- | ----------- |
| base\_agent\_dollars | Int | |
| base\_agent\_sale\_percentage | Float | |
| sum\_dollars\_other\_agents | Int | |
## SecondaryMarketInput
| Field | Type | Description |
| -------------- | -------------------------------- | ----------- |
| agents | SecondaryMarketAgentsInput! | |
| agents\_params | SecondaryMarketAgentsParamsInput | |
## AssumptionsInput
| Field | Type | Description |
| ---------- | ------ | ----------- |
| dex | String | |
| cex | String | |
| vesting | String | |
| disclaimer | String | |
| others | String | |
## SocialEntryInput
| Field | Type | Description |
| ----- | ------- | ----------- |
| name | String! | |
| data | String! | |
## CreateSimulationInput
| Field | Type | Description |
| ----------------- | --------------------- | ----------- |
| name | String! | |
| info | ProjectInfoInput! | |
| primary\_market | PrimaryMarketInput! | |
| secondary\_market | SecondaryMarketInput! | |
| assumptions | AssumptionsInput | |
| logo | String! | |
| sources | \[String!] | |
| website | String | |
| socials | \[SocialEntryInput!] | |
## PrimaryMarketRoundSupplyStrategies
| Field | Type | Description |
| ---------------------------- | ------- | ----------- |
| strategy\_random | Boolean | |
| strategy\_random\_aggressive | Boolean | |
| strategy\_1 | Boolean | |
| strategy\_2 | Boolean | |
| strategy\_3 | Boolean | |
## PrimaryMarketRound
| Field | Type | Description |
| ------------------ | ---------------------------------- | ----------- |
| name | String! | |
| type | String! | |
| number\_of\_tokens | String! | |
| tge\_percentage | Float! | |
| cliff | Int! | |
| vesting | Int! | |
| buy\_price | Float | |
| supply\_strategies | PrimaryMarketRoundSupplyStrategies | |
## PrimaryMarket
| Field | Type | Description |
| ----------------------- | ---------------------- | ----------- |
| primary\_market\_rounds | \[PrimaryMarketRound!] | |
## SecondaryMarketAgents
| Field | Type | Description |
| -------------------- | -------- | ----------- |
| base\_agent | Boolean! | |
| low\_advanced | Boolean! | |
| moderately\_advanced | Boolean! | |
| very\_advanced | Boolean! | |
| speculator | Boolean! | |
## SecondaryMarketAgentsParams
| Field | Type | Description |
| ----------------------------- | ----- | ----------- |
| base\_agent\_dollars | Int | |
| base\_agent\_sale\_percentage | Float | |
| sum\_dollars\_other\_agents | Int | |
## SecondaryMarket
| Field | Type | Description |
| -------------- | --------------------------- | ----------- |
| agents | SecondaryMarketAgents! | |
| agents\_params | SecondaryMarketAgentsParams | |
## ProjectInfoDexSettings
| Field | Type | Description |
| -------------- | ----- | ----------- |
| reserve | Int | |
| tokens | Int | |
| listing\_price | Float | |
## ProjectInfoCexSettings
| Field | Type | Description |
| ---------------------- | ----- | ----------- |
| market\_maker\_dollars | Int | |
| market\_maker\_tokens | Int | |
| listing\_price | Float | |
## ProjectInfo
| Field | Type | Description |
| ------------- | ---------------------- | ----------- |
| dex | Boolean! | |
| dex\_settings | ProjectInfoDexSettings | |
| cex | Boolean! | |
| cex\_settings | ProjectInfoCexSettings | |
## Config
| Field | Type | Description |
| ----------------- | ---------------- | ----------- |
| name | String! | |
| info | ProjectInfo! | |
| primary\_market | PrimaryMarket! | |
| secondary\_market | SecondaryMarket! | |
## RunningSimulation
| Field | Type | Description |
| ------------------ | ------------ | ----------- |
| id | String | |
| project\_name | String | |
| project\_symbol | String | |
| agents | \[String] | |
| agents\_params | AgentsParams | |
| liquidity\_reserve | String | |
| liquidity\_tokens | String | |
| createdAt | Int | |
## FinishedSimulation
| Field | Type | Description |
| ------------------------ | ------------ | ----------- |
| id | String | |
| project\_name | String | |
| project\_symbol | String | |
| execution\_time\_seconds | Int | |
| agents | \[String] | |
| agents\_params | AgentsParams | |
| liquidity\_reserve | String | |
| liquidity\_tokens | String | |
| score | Float | |
| logo | String | |
| slug | String! | |
| scoring | ScoringData | |
| createdAt | Int | |
## GlobalStatistics
| Field | Type | Description |
| -------------------------------------- | ----- | ----------- |
| project\_count | Int | |
| simulation\_count | Int | |
| total\_execution\_time\_seconds | Int | |
| total\_simulation\_data\_in\_kilobytes | Int | |
| total\_simulation\_data\_in\_gigabytes | Float | |
## ScorePoint
| Field | Type | Description |
| ----- | ---- | ----------- |
| score | Int | |
| count | Int | |
## Account
| Field | Type | Description |
| ------- | ---- | ----------- |
| address | ID! | |
## ID
The `ID` scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as `"4"`) or integer (such as `4`) input value will be accepted as an ID.
## AuthResponse
| Field | Type | Description |
| ------- | -------- | ----------- |
| token | String! | |
| account | Account! | |
## AccountAgentsParams
| Field | Type | Description |
| ----------------------------- | ----- | ----------- |
| base\_agent\_dollars | Int | |
| base\_agent\_sale\_percentage | Float | |
| sum\_dollars\_other\_agents | Int | |
## AccountScoringData
| Field | Type | Description |
| -------------- | --------- | ----------- |
| main\_score | Float | |
| average\_score | \[Int] | |
| categories | \[String] | |
## AccountSimulation
| Field | Type | Description |
| ------------------------ | ------------------- | ----------- |
| id | String | |
| project\_name | String | |
| project\_symbol | String | |
| execution\_time\_seconds | Int | |
| agents | \[String] | |
| agents\_params | AccountAgentsParams | |
| liquidity\_reserve | String | |
| liquidity\_tokens | String | |
| score | Float | |
| logo | String | |
| slug | String! | |
| scoring | AccountScoringData | |
| createdAt | Int | |
## GetAccountSimulationsOutput
| Field | Type | Description |
| ----------- | -------------------- | ----------- |
| simulations | \[AccountSimulation] | |
| nextToken | String | |
## GetSimulationFromPromptOutput
| Field | Type | Description |
| ----- | ------- | ----------- |
| id | String! | |
| slug | String! | |
## Query
| Field | Type | Description |
| ------------------------------------ | --------------------------- | ----------------------------------------------------------------------------------- |
| authChallengeMessage | String | Request new challenge message. Used for login through "authLogin" in the next step. |
| authLogin | AuthResponse | Request temporary JWT token for login. |
| getAccountProfile | Account | Get your profile. Requires a valid token. |
| getAccountSimulations | GetAccountSimulationsOutput | Get your simulations. Requires a valid token. |
| getProject | Project | Get a single Project, based on it's slug. |
| getProjects | GetProjectsOutput | Get paginated list of Projects. |
| getSimulation | Simulation | Get single simulation. Requires Project slug and Simulation id. |
| getSimulations | GetSimulationsOutput | Get paginated list of Simulations for Project. Requires Project slug. |
| getLastConfig | Config | Get last used Simulation config for given Project. |
| getRunningSimulations | \[RunningSimulation] | Get paginated list of currently running Simulations. |
| getLastFinishedSimulations | \[FinishedSimulation] | Get last 10 finished Simulations. |
| getGlobalStatistics | GlobalStatistics | Get global statistics. |
| getGlobalSimulationScoreDistribution | \[ScorePoint] | Get Simulation score distribution across platform. |
| getGlobalProjectScoreDistribution | \[ScorePoint] | Get Project score distribution across platform. |
## Mutation
| Field | Type | Description |
| -------------------------- | ----------------------------- | ------------------------------------------------- |
| createSimulation | String | Create new Simulation based on config parameters. |
| createSimulationFromPrompt | GetSimulationFromPromptOutput | Create new Simulation from given prompt. |
# $TPRO Pool
**Innovative Liquidity Pool with Impermanent Loss protection and Yield generation.**
The TPRO Network has developed a innovative liquidity pool system designed to maximize support for all network participants. This innovative approach optimizes earnings for liquidity providers, reduces impermanent loss, and enhances the system’s resilience to market fluctuations.
The **80/20 Weighted Liquidity Pool**, pioneered by Balancer, lowers entry barriers for liquidity providers, driving higher Total Value Locked (TVL) while minimizing impermanent loss. The **Dynamic Fee Mechanism** further boosts profitability by optimizing fees generated from the pool, and an **Impermanent Loss Protection** mechanism ensures additional security for liquidity providers, significantly enhancing the overall yield from investments.
All of the information presented is at the in progress stage, so the final technical implementation could change.
## Liquidity Pool - Balancer
The TPRO Network team evaluated four different types of Balancer pools to optimize liquidity management and ensure economic efficiency. The pools under consideration were as follows:
* Standard 50/50 Pool - A classic Balancer pool where liquidity is equally distributed between two assets, providing balanced exposure and straightforward liquidity provisioning.
* 80/20 Weighted Pool - A pool with an asymmetric weight distribution, designed to minimize impermanent loss for a primary asset while still enabling efficient trading and liquidity. This structure is particularly suitable for projects aiming to support a dominant asset.
* Multi-Asset Pool - A flexible pool that can support multiple tokens with custom weightings. It offers a diversified approach to liquidity management, allowing for broader asset exposure within a single pool.
* Boosted Pool - An advanced pool that integrates with external yield protocols (e.g., Aave) to generate additional returns on idle liquidity while maintaining trading efficiency. This approach combines liquidity provisioning with yield optimization.
The TPRO Network team carefully evaluated four different types of Balancer pools to optimize liquidity management and ensure economic efficiency. After thorough analysis and simulations, we selected the 80/20 Weighted Pool as the optimal solution.
This pool offers a modern and secure approach to liquidity provisioning, addressing key challenges faced by liquidity providers:
* **Reduced Impermanent Loss**: The asymmetric 80/20 weight distribution minimizes the impact of price volatility on the primary asset, ensuring a safer environment for liquidity providers.
* **Lower Entry Barrier**: The reduced requirement for reserve contributions makes it easier for participants to become liquidity providers, increasing accessibility.
* **Increased Attractiveness**: By offering enhanced security and efficiency, the 80/20 Weighted Pool provides a compelling alternative to traditional liquidity models.
Furthermore, the 80/20 Weighted Pool is designed to increase the Total Value Locked (TVL) within the liquidity pool, surpassing the current performance on Uniswap. This makes it an innovative and appealing choice for both the project and its community of liquidity providers.
The implementation of this pool underscores our commitment to fostering economic efficiency, accessibility, and safety in liquidity management.
## Dynamic Fee
The dynamic fee mechanism in the liquidity pool aims to create a more efficient, fair and secure trading environment. Unlike static fee models, this mechanism adapts to changing market conditions, providing flexibility to the system.
The primary objectives of the dynamic fee mechanism include:
* Fairness in Fee Structure: By calculating fees separately for buy and sell transactions, the mechanism addresses the distinct dynamics of each trade type. This ensures fees are proportional to the market impact of individual transactions.
* Adaptability to Market Volatility: The system incorporates market volatility into its calculations, adjusting fees based on the volatility of Ethereum. During periods of heightened volatility, fees increase to mitigate risks, while in stable conditions, fees decrease to encourage trading activity.
* Protection for Liquidity Providers: The dynamic fee mechanism shields all liquidity providers by increasing their income when impermanent loss rises due to volatility. Additionally, part of the collected fees funds a dedicated protection mechanism for providers who are most concerned about impermanent loss, further reducing their risk.
* Support for Ecosystem Stability and Growth: By balancing the interests of traders and liquidity providers, the dynamic fee system fosters a sustainable ecosystem. Traders benefit from context-aware fees, while liquidity providers gain assurance of fair compensation and additional protection.
This dynamic approach ensures that the fee structure evolves with market conditions and participant behavior, creating a fair and adaptive framework. The hedging mechanism for impermanent loss, which complements the dynamic fee system, is discussed in detail in a separate section.
### Mechanism parameters
The table below shows the key parameters of the dynamic fee mechanism. Table 1. Dynamic Fee Parameters
| **Parameter** | **Description** | **Value** |
| -------------------------- | -------------------------------------------------------------------------------------------------------------- | ---------- |
| `min_fee_buy` | Minimum fee on $TPRO token purchase transaction. | 0.01 (1%) |
| `max_fee_buy` | Maximum fee at the transaction of purchase of $TPRO. | 0.05 (5%) |
| `min_fee_sell` | Minimum fee at $TPRO sale transaction. | 0.01 (1%) |
| `max_fee_sell` | Maximum fee at the $TPRO sale transaction. | 0.1 (10%) |
| `min_price_tolerance_buy` | The percentage change in the $TPRO price that triggers the raising of the fee on purchase transactions. | 0.2 (20%) |
| `max_price_tolerance_buy` | Percentage change in the price of the $TPRO token, beyond which the maximum fee on purchase transactions. | 0.5 (50%) |
| `eth_price_min_tolerance` | Percentage change in the price of ETH that triggers the mechanism for raising fees on sales transactions. | 0.07 (7%) |
| `eth_price_max_tolerance` | The percentage change in the price of ETH, after which the maximum sales transaction fee is charged. | 0.15 (15%) |
| `eth_component_weight` | The weight of the component reflects the volatility of the ETH price throughout the fee for sale transactions. | 0.5 (50%) |
| `min_price_tolerance_sell` | Percentage change in the price of the $TPRO that triggers fee raising on sales transactions. | 0.01 (1%) |
| `max_price_tolerance_sell` | The percentage change in the price of the $TPRO, beyond which the maximum fee on sales transactions. | 0.05 (5%) |
| `protection_fee_rate` | The portion of the fee that is charged on from the collected fee on protection mechanism. | 0.2 (20%) |
Based on the above parameters, the mathematical specification of the mechanism is defined.
### Mechanisms mathematical specification
The mechanism for dynamic fee adjustment is divided into several components. The first component handles the fee for TPRO purchase transactions. Two key metrics are defined to support the mechanism, calculated using the following formulas:
$$
price\_-buy\_{min} = avg\_-price\_-24h\_{before} \cdot (1 + min\_-price\_-tolerance\_-buy)
$$
$$
price\_-buy\_{max} = avg\_-price\_-24h\_{before} \cdot (1 + max\_-price\_-tolerance\_-buy)
$$
Formula 1. Dynamic Price Thresholds for TPRO Purchase Transactions
where:
* $$price\_-buy\_{min}$$ is the TPRO price that triggers the raising of the fee on purchase transactions,
* $$price\_-buy\_{max}$$ is the price of the TPRO, beyond which the maximum fee on purchase transactions,
* $$avg\_-price\_-24h\_{before}$$ is the average TPRO price over the last 24 hours preceding the update fee,
* $$min\_-price\_-tolerance\_-buy$$ is a parameter describing the percentage change in the TPRO price that triggers the raising of the fee on purchase transactions,
* $$max\_-price\_-tolerance\_-buy$$ is a parameter describing the percentage change in the price of the TPRO, beyond which the maximum fee on purchase transactions.
Based on these key metrics, the fee for TPRO purchase transactions is calculated as follows:
$$
Fee\_{buy} = \begin{cases}
min\_-fee\_-buy, &\text{if } price\_{current} \leq price\_-buy\_{min} \\
max\_-fee\_-buy, &\text{if } price\_{current} \geq price\_-buy\_{max} \\
min\_-fee\_-buy + \frac{max\_-fee\_-buy - min\_-fee\_-buy}{price\_-buy\_{max} - price\_-buy\_{min}} \cdot (price\_{current} - price\_-buy\_{min}), &\text{otherwise}.
\end{cases}
$$
Formula 2. Dynamic Fee for TPRO Buying Transactions
where:
* $$Fee\_{buy}$$ is the fee applied to a TPRO buying transaction,
* $$min\_-fee\_-buy$$ is a parameter describing the minimum fee applied to TPRO buying transactions,
* $$max\_-fee\_-buy$$ is a parameter describing the maximum fee applied to TPRO buying transactions,
* $$price\_{current}$$ is the current price of the TPRO,
* $$price\_-buy\_{min}$$ is the TPRO price that triggers the raising of the fee on purchase transactions,
* $$price\_-buy\_{max}$$ is the price of the TPRO, beyond which the maximum fee on purchase transactions.
The chart below illustrates an example of how the fee value varies with the TPRO price.
Figure 1. Buy transaction fee.
In the case of the fee for TPRO sales, the mechanism is more elaborate. Its first component works on a similar basis. Based on the parameters and the average price of the previous day, the following metrics are determined:
$$
price\_-sell\_{min} = avg\_-price\_-24h\_{before} \cdot (1 - min\_-price\_-tolerance\_-sell)
$$
$$
price\_-sell\_{max} = avg\_-price\_-24h\_{before} \cdot (1 - max\_-price\_-tolerance\_-sell)
$$
Formula 3. Dynamic Price Thresholds for TPRO Sale Transactions
where:
* $$price\_-sell\_{min}$$ is the TPRO price that triggers the raising of the fee on sale transactions,
* $$price\_-sell\_{max}$$ is the price of the TPRO, beyond which the maximum fee on purchase transactions,
* $$avg\_-price\_-24h\_{before}$$ is the average TPRO price over the last 24 hours preceding the update fee,
* $$min\_-price\_-tolerance\_-sell$$ is a parameter describing percentage change in the price of the TPRO that triggers fee raising on sales transactions,
* $$max\_-price\_-tolerance\_-sell$$ is a parameter describing the percentage change in the price of the TPRO, below which the maximum fee on sales transactions.
These key metrics are used to determine the first component of fee.
$$
Fee\_{sell}^{price} =
\begin{cases}
min\_-fee\_-sell, & \text{if } price\_{current} \geq price\_-sell\_{min} \\
max\_-fee\_-sell, & \text{if } price\_{current} \leq price\_-sell\_{max} \\
min\_-fee\_-sell + \frac{max\_-fee\_-sell - min\_-fee\_-sell}{price\_-sell\_{max} - price\_-sell\_{min}} \cdot (price\_{current} - price\_-sell\_{min}), & \text{otherwise.}
\end{cases}
$$
Formula 4. Dynamic Fee for TPRO Sale Transactions Based on $TPRO Price
where:
* $$Fee\_{sell}^{price}$$ is the fee component for TPRO selling transactions based on price,
* $$min\_-fee\_-sell$$ is a parameter describing the minimum fee applied to TPRO selling transactions,
* $$max\_-fee\_-sell$$ is a parameter describing the maximum fee applied to TPRO selling transactions,
* $$price\_{current}$$ is the current price of the TPRO,
* $$price\_-sell\_{min}$$ is the TPRO price that triggers the raising of the fee on sale transactions,
* $$price\_-sell\_{max}$$ is the price of the TPRO, beyond which the maximum fee on purchase transactions.
Figure 2. Sale transactions fee (price component)
The second component of the fee for selling TPRO is influenced by fluctuations in the ETH price over the past 7 days. To account for this, the fee is calculated based on these price changes as follows:
$$
eth\_-price\_-adjusted\_-fee =
$$
$$
\left( \frac{average\_-eth\_-price\_-24h}{average\_-eth\_-price\_-7d} - 1 - eth\_-price\_-max\_-tolerance \right) \cdot \frac{max\_-fee\_-sell - min\_-fee\_-sell}{eth\_-price\_-max\_-tolerance - eth\_-price\_-min\_-tolerance} + max\_-fee\_-sell
$$
Formula 5. Fee Adjustment Based on ETH Price
where:
* $$eth\_-price\_-adjusted\_-fee$$ is the fee adjusted for TPRO selling transactions based on changes in ETH price,
* $$average\_-eth\_-price\_-24h$$ is the average ETH price over the last 24 hours,
* $$average\_-eth\_-price\_-7d$$ is the average ETH price over the last 7 days,
* $$eth\_-price\_-max\_-tolerance$$ is a parameter describing the maximum tolerance for changes in ETH price,
* $$eth\_-price\_-min\_-tolerance$$ is a parameter describing the minimum tolerance for changes in ETH price,
* $$max\_-fee\_-sell$$ is a parameter describing the maximum fee applied to TPRO selling transactions,
* $$min\_-fee\_-sell$$ is a parameter describing the minimum fee applied to TPRO selling transactions.
This component is subject to specific limitations, outlined in the formula below:
$$
Fee\_{sell}^{eth} =
\begin{cases}
min\_-fee\_-sell, & \text{if } \frac{average\_-eth\_-price\_-24h}{average\_-eth\_-price\_-7d} - 1 \leq eth\_-price\_-min\_-tolerance, \\\
max\_-fee\_-sell, & \text{if } \frac{average\_-eth\_-price\_-24h}{average\_-eth\_-price\_-7d} - 1 \geq eth\_-price\_-max\_-tolerance, \\\
eth\_-price\_-adjusted\_-fee, & \text{otherwise.}
\end{cases}
$$
Formula 6. ETH Price Component of the Fee for TPRO Sale Transactions
where:
* $$Fee\_{sell}^{eth}$$ is the ETH price component of the fee applied to TPRO selling transactions,
* $$max\_-fee\_-sell$$ is a parameter describing the maximum fee applied to TPRO selling transactions,
* $$min\_-fee\_-sell$$ is a parameter describing the minimum fee applied to TPRO selling transactions,
* $$average\_-eth\_-price\_-24h$$ is the average ETH price over the last 24 hours,
* $$average\_-eth\_-price\_-7d$$ is the average ETH price over the last 7 days,
* $$eth\_-price\_-max\_-tolerance$$ is a parameter describing the maximum tolerance for changes in ETH price,
* $$eth\_-price\_-min\_-tolerance$$ is a parameter describing the minimum tolerance for changes in ETH price,
* $$eth\_-price\_-adjusted\_-fee$$ is the fee adjusted for TPRO selling transactions based on changes in ETH price.
Figure 3. Sale transactions fee (ETH component)
Considering both components, the final fee for TPRO token sales is determined using the following formula:
$$
Fee\_{sell} = (1 - eth\_-weight) \cdot Fee\_{sell}^{price} + eth\_-weight \cdot Fee\_{sell}^{eth}
$$
Formula 7. Dynamic Fee for TPRO Sale Transactions
where:
* $$Fee\_{sell}$$ is the fee applied to TPRO selling transactions,
* $$eth\_-component\_-weight$$ is a parameter describing the weight of the ETH component throughout the fee for sale transactions,
* $$Fee\_{sell}^{price}$$ is the fee component based on TPRO price changes,
* $$Fee\_{sell}^{eth}$$ is the fee component based on ETH price changes.
A primary objective of the dynamic fee mechanism is to allocate fees toward the impermanent loss protection mechanism. At a given moment $$t$$, when a purchase transaction occurs, the collected fee is distributed as follows:
$$
fee\_-protection\_-eth\_{t} = protection\_-fee\_-rate \cdot fee\_-collected\_-eth\_{t}
$$
$$
fee\_-lp\_-eth\_{t} = fee\_-collected\_-eth\_{t} - fee\_-protection\_-eth\_{t}
$$
Formula 8. Fee Allocation for ETH pool in the Protection Mechanism
where:
* $$fee\_-protection\_-eth\_{t}$$ is the portion of ETH fees allocated to the protection mechanism pool at time $$t$$,
* $$protection\_-fee\_-rate$$ is a parameter describing the portion of the fee that is charged on from the collected fee on protection mechanism,
* $$fee\_-collected\_-eth\_{t}$$ is the total ETH fees collected at time $$t$$,
* $$fee\_-lp\_-eth\_{t}$$ is the portion of ETH fees allocated to liquidity providers at time $$t$$.
A similar mechanism occurs for sales transactions, where a TPRO fee is charged. This division is determined by the following formula:
$$
fee\_-protection\_-token\_{t} = protection\_-fee\_-rate \cdot fee\_-collected\_-token\_{t}
$$
$$
fee\_-lp\_-token\_{t} = fee\_-collected\_-token\_{t} - fee\_-protection\_-token\_{t}
$$
Formula 9. Fee Allocation for TPRO tokens pool in the Protection Mechanism
where:
* $$fee\_-protection\_-token\_{t}$$ is the portion of TPRO fees allocated to the protection mechanism pool at time $$t$$,
* $$protection\_-fee\_-rate$$ is a parameter describing the portion of the fee that is charged on from the collected fee on protection mechanism,
* $$fee\_-collected\_-token\_{t}$$ is the total TPRO fees collected at time $$t$$,
* $$fee\_-lp\_-token\_{t}$$ is the portion of TPRO fees allocated to liquidity providers at time $$t$$.
## Impermanent Loss Protection Mechanism
The protection mechanism is a key feature of the liquidity pool, offering additional safeguards against impermanent loss for liquidity providers.
**Key aspects of the mechanism include:**
* **Fee-Based Funding**: A portion of the fees collected from the dynamic fee mechanism is allocated to the protection mechanism, ensuring consistent funding for collateral payouts.
* **Token-Based Participation**: Liquidity providers can deposit additional TPRO tokens into the collateral pool. These deposits represent shares in the pool, and the provider’s participation is determined by the amount of TPRO deposited, regardless of the liquidity they initially contributed.
* **Flexible Withdrawal with Lock-In Period**: Deposited TPRO tokens can be withdrawn at any time but are subject to a **14-day lock** before they can be collected. Previously accumulated collateral remains intact even after TPRO tokens are withdrawn.
* **Coverage of Impermanent Loss**: When liquidity is removed, the mechanism calculates impermanent loss as the difference between the value of the liquidity pool and a hold strategy. The collateral is used to offset all or part of the loss, compensating liquidity providers.
* **Management of Excess Collateral**: If the collateral collected is greater than the calculated loss, the excess is redistributed. A portion of the excess is allocated as a success fee for the creators of the mechanism, while the remainder is returned to the collateral pool to benefit other participants in the program.
This protection mechanism minimizes exposure to impermanent loss while fostering a collaborative and incentivized environment for liquidity providers. Its efficient handling of surplus collateral and performance-based fee structure ensures alignment between creators and participants, promoting trust and long-term engagement.
### Mechanism parameters
**Table 2. Impermanent Loss Protection Mechanism Parameters**
| **Parameter** | **Description** | **Value** |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------- |
| `success_fee` | Part of the unrealized protection for the liquidity provider charged as remuneration on effective protection against impermanent loss. | 0.1 (10%) |
Based on the above parameters, the mathematical specification of the mechanism is defined.
### Mechanisms mathematical specification
Fees collected by the liquidity pool for the protection mechanism are collected in separate pools of ETH and TPRO tokens. Each time a liquidity provider joins, leaves the protection program, or increases its deposit, the collected funds are redistributed to users to ensure a fair allocation of collateral. We define $$t\_i$$ as the moments when the distribution of pool shares changes due to user actions. Let $$t\_{i-1}$$ represent the previous moment of such a change, and $$t\_0$$ denote the initial moment of the pool's creation. The amount of collected assets is calculated using the following formulas:
$$
protection\_-eth\_-pool\_{t\_{i}} = \sum\_{t = t\_{i-1}}^{t\_{i}} fee\_-protection\_-eth\_{t}
$$
$$
protection\_-token\_-pool\_{t\_{i}} = \sum\_{t = t\_{i-1}}^{t\_{i}} fee\_-protection\_-token\_{t}
$$
Formula 10. Accumulated Protection Fees in ETH and TPRO
where:
* $$protection\_-eth\_-pool\_{t}$$ is the accumulated ETH fees in the protection pool by time $$t$$,
* $$protection\_-token\_-pool\_{t}$$ is the accumulated TPRO fees in the protection pool by time $$t$$,
* $$fee\_-protection\_-eth\_{t}$$ is the ETH fee allocated to the protection mechanism pool at time $$t$$,
* $$fee\_-protection\_-token\_{t}$$ is the TPRO fee allocated to the protection mechanism pool at time $$t$$.
Both TPRO and ETH are distributed following the same principles. Let $$lp$$ describe a specific liquidity provider, the amount of ETH and TPRO reserved for liquidity provider $$lp$$, at time $$t\_{i}$$ describes the formula:
$$
protection\_-eth\_{t\_{i}}^{lp} = \frac{tokens\_-deposited^{lp}}{\sum\_{k=1}^{N} tokens\_-deposited^{k}} \cdot protection\_-eth\_-pool\_{t\_{i}}
$$
$$
protection\_-token\_{t\_{i}}^{lp} = \frac{tokens\_-deposited^{lp}}{\sum\_{k=1}^{N} tokens\_-deposited^{k}} \cdot protection\_-token\_-pool\_{t\_{i}}
$$
Formula 11. Allocation of Protection Pool to Liquidity Providers
where:
* $$protection\_-eth\_{t}^{lp}$$ is the portion of the ETH protection mechanism pool allocated to the liquidity provider $$lp$$ at time $$t\_{i}$$,
* $$protection\_-token\_{t}^{lp}$$ is the portion of the TPRO protection mechanism pool allocated to the liquidity provider $$lp$$ at time $$t\_{i}$$,
* $$tokens\_-deposited^{lp}$$ is the number of TPRO deposited by the specific liquidity provider,
* $$tokens\_-deposited^{k}$$ is the total number of TPRO deposited by liquidity provider $$k$$,
* $$protection\_-eth\_-pool\_{t}$$ is the total ETH in the protection pool by time $$t\_{i}$$,
* $$protection\_-token\_-pool\_{t\_{i}}$$ is the total TPRO in the protection pool by time $$t\_{i}$$,
* $$N$$ is the total number of liquidity providers with some deposit in the protection mechanism.
As long as the liquidity provider remains active and the collateral is not utilized, these funds remain secured for the provider and continue to accumulate throughout the entire period their TPRO are locked in deposit.
The withdrawal of TPRO and ETH designated for liquidity providers within the protection mechanism occurs only when the user removes liquidity.
Initially, the portion of liquidity being withdrawn by the user is determined. To achieve this, a variable is calculated to represent the proportion of the user's total liquidity being withdrawn:
$$
withdrawal\_-ratio = \frac{lp\_-tokens\_-withdrawn}{sum\_-lp\_-tokens}
$$
Formula 12. Withdrawal Ratio for Liquidity Provider
where:
* $$withdrawal\_-ratio$$ is the proportion of liquidity withdrawn by the liquidity provider,
* $$lp\_-tokens\_-withdrawn$$ is the number of liquidity provider tokens withdrawn by the specific liquidity provider,
* $$sum\_-lp\_-tokens$$ is the total number of liquidity provider tokens in the pool.
*
A key step in calculating impermanent loss is estimating the hold position of a given liquidity provider. This involves tracking the assets contributed by the user to the liquidity pool at the time of adding liquidity. When liquidity is withdrawn, the hold position is adjusted by reducing it proportionally to the fraction of liquidity removed. This process is expressed mathematically as follows. Let $$t\_{i}$$ denote the moment at which liquidity is added or withdrawn. By $$t\_{0}$$ is meant the first addition of liquidity by a liquidity provider, then:
$$
hold\_-position\_{t\_{i}} =
\begin{cases}
hold\_-position\_{t\_{i-1}} + eth\_-provided\_{t\_{i}} + tokens\_-provided\_{t\_{i}} \cdot spot\_-price\_{t\_{i}} & \text{if liquidity is added} \\\
(1 - withdrawal\_-ratio) \cdot hold\_-position\_{t\_{i-1}} & \text{if liquidity is withdrawn}
\end{cases}
$$
Formula 13. Liquidity Provider's Estimated Hold Position
where:
* $$hold\_-position\_{t}$$ is the total hold position value of the liquidity provider at time $$t\_{i}$$, expressed in ETH,
* $$eth\_-provided\_{t\_{i}}$$ is the amount of ETH provided by the liquidity provider at time $$t\_{i}$$,
* $$tokens\_-provided\_{t\_{i}}$$ is the amount of TPRO provided by the liquidity provider at time $$t\_{i}$$,
* $$spot\_-price\_{t\_{i}}$$ is the price of the TPRO at time $$t\_{i}$$, expressed in ETH/TPRO,
* $$withdrawal\_-ratio$$ is the proportion of liquidity withdrawn by the liquidity provider.
**Note:** the $$hold\_-position$$ is updated after the entire withdrawal mechanism is completed, as its value before the withdrawal is required to determine the amount of funds to be withdrawn by the user.
The next step is to calculate the liquidity provider's position, which takes into account the assets withdrawn from the pool and the fees charged. During the liquidity withdrawal process, the entire fee charged to the liquidity provider is allocated. In addition, the system tracks the total fees paid since the user last withdrew liquidity. The lp position is calculated as follows:
$$
lp\_-position = (withdrawn\_-tokens + fee\_-collected\_-tokens) \cdot spot\_-price + withdrawn\_-eth + fee\_-collected\_-eth
$$
Formula 14. Liquidity Provider's Position
where:
* $$lp\_-position$$ is the total value of the liquidity provider's position, expressed in ETH,
* $$withdrawn\_-tokens$$ is the number of TPRO withdrawn by the liquidity provider in current withdrawal,
* $$fee\_-collected\_-tokens$$ is the number of TPRO collected as fees by the liquidity provider since the last liquidity withdrawal,
* $$spot\_-price$$ is the current TPRO price, expressed in ETH/TPRO,
* $$withdrawn\_-eth$$ is the amount of ETH withdrawn by the liquidity provider in current withdrawal,
* $$fee\_-collected\_-eth$$ is the amount of ETH collected as fees by the liquidity provider since the last liquidity withdrawal.
Using the estimated hold position and the liquidity provider's position, the loss incurred from providing liquidity, as opposed to simply holding TPRO and ETH, is calculated. This calculation is expressed by the following formula:
$$
loss = lp\_-position - hold\_-position \cdot withdrawal\_-ratio
$$
Formula 15. Liquidity Provider's Loss
where:
* $$loss$$ is the loss incurred by the liquidity provider compared to the hold strategy, expressed in ETH,
* $$lp\_-position$$ is the total value of the liquidity provider's position, expressed in ETH,
* $$hold\_-position$$ is the total hold position value of the liquidity provider, expressed in ETH,
* $$withdrawal\_-ratio$$ is the proportion of liquidity withdrawn by the liquidity provider.
Once the user's loss is determined, the process of collateral payout begins. This payout occurs only if the calculated loss is greater than zero. A negative loss value indicates that the liquidity provider has not experienced any loss relative to their hold position, and therefore, no compensation is issued. In order to disburse funds, the following metrics are defined:
$$
full\_-value\_-protection = protection\_-eth + protection\_-token \cdot spot\_-price
$$
$$
value\_-protection = full\_-value\_-protection \cdot withdrawal\_-ratio
$$
Formula 16. Value of Protection for Liquidity Provider
where:
* $$full\_-value\_-protection$$ is the total value of protection available for a liquidity provider, expressed in ETH,
* $$protection\_-eth$$ is the ETH allocated as protection,
* $$protection\_-token$$ is the TPRO allocated as protection,
* $$spot\_-price$$ is the price of the TPRO, expressed in ETH/TPRO,
* $$value\_-protection$$ is the final value of protection applied to the liquidity provider's withdrawn liquidity.
The liquidity provider receives both TPRO and ETH, with the amounts of each asset calculated using the following formula:
$$
received\_-protection\_-eth =
\begin{cases}
protection\_-eth & \text{if } loss \geq full\_-value\_-protection, \\\
withdrawal\_-ratio \cdot protection\_-eth \cdot \frac{loss}{value\_-protection} & \text{if } loss \leq value\_-protection, \\\
protection\_-eth \cdot \frac{loss}{full\_-value\_-protection} & \text{otherwise.}
\end{cases}
$$
$$
received\_-protection\_-token =
\begin{cases}
protection\_-token & \text{if } loss \geq full\_-value\_-protection, \\\
withdrawal\_-ratio \cdot protection\_-token \cdot \frac{loss}{value\_-protection} & \text{if } loss \leq value\_-protection, \\\
protection\_-token \cdot \frac{loss}{full\_-value\_-protection} & \text{otherwise.}
\end{cases}
$$
Formula 17. Received Protection for Liquidity Provider
where:
* $$received\_-protection\_-eth$$ is the amount of ETH received as protection by the liquidity provider,
* $$received\_-protection\_-token$$ is the amount of TPRO received as protection by the liquidity provider,
* $$protection\_-eth$$ is the ETH allocated to the liquidity provider for protection,
* $$protection\_-token$$ is the TPRO allocated to the liquidity provider for protection,
* $$loss$$ is the loss incurred by the liquidity provider compared to the hold strategy, expressed in ETH,
* $$full\_-value\_-protection$$ is the total value of protection available for a liquidity provider, expressed in ETH,
* $$value\_-protection$$ is the value of part of protection applied based on the withdrawal ratio.
Since the mechanism aims to offset the loss relative to the hold position, the amount of TPRO and ETH received may exceed the loss incurred. In such cases, a surplus is calculated, which is then split into a fee for the creators and a contribution to the protection pool. The surplus for both TPRO and ETH is determined using the following formula:
$$
protection\_-surplus\_-eth =
\begin{cases}
withdrawal\_-ratio \cdot protection\_-eth & \text{if } loss \leq 0, \\
withdrawal\_-ratio \cdot protection\_-eth \cdot \frac{1 - loss}{value\_-protection} & \text{if } loss \leq value\_-protection, \\
0 & \text{otherwise.}
\end{cases}
$$
$$
protection\_-surplus\_-token =
\begin{cases}
withdrawal\_-ratio \cdot protection\_-token & \text{if } loss \leq 0, \\
withdrawal\_-ratio \cdot protection\_-token \cdot \frac{1 - loss}{value\_-protection} & \text{if } loss \leq value\_-protection, \\
0 & \text{otherwise.}
\end{cases}
$$
Formula 18. Protection Surplus
where:
* $$protection\_-surplus\_-eth$$ is the surplus ETH that remains after covering the loss,
* $$protection\_-surplus\_-token$$ is the surplus TPRO that remains after covering the loss,
* $$protection\_-eth$$ is the ETH allocated to the liquidity provider for protection,
* $$protection\_-token$$ is the TPRO allocated to the liquidity provider for protection,
* $$loss$$ is the loss incurred relative to the hold position,
* $$value\_-protection$$ is the value of protection applied based on the withdrawal ratio,
* $$full\_-value\_-protection$$ is the total value of protection available for a liquidity provider, expressed in ETH,
* $$withdrawal\_-ratio$$ is the proportion of liquidity withdrawn by the liquidity provider.
Based on the surplus, a fee for the TPRO Network is calculated. The calculation is performed as follows:
$$
success\_-fee\_-eth = protection\_-surplus\_-eth \cdot success\_-fee
$$
$$
success\_-fee\_-token = protection\_-surplus\_-token \cdot success\_-fee
$$
Formula 19. Success Fee
where:
* $$success\_-fee\_-eth$$ is the success fee in ETH deducted from the protection surplus,
* $$success\_-fee\_-token$$ is the success fee in TPRO deducted from the protection surplus,
* $$protection\_-surplus\_-eth$$ is the surplus ETH that remains after covering the loss,
* $$protection\_-surplus\_-token$$ is the surplus TPRO that remains after covering the loss,
* $$success\_-fee$$ is the parameter describing the percentage of the protection surplus taken as a fee.
The remaining surplus is allocated to two pools within the protection mechanism and will be distributed among all liquidity providers in the future. Fee for protection pools from surplus is calculated as follows:
$$
fee\_-protection\_-eth = protection\_-surplus\_-eth - success\_-fee\_-eth
$$
$$
fee\_-protection\_-token = protection\_-surplus\_-token - success\_-fee\_-token
$$
Formula 20. Surplus Protection Fee
where:
* $$fee\_-protection\_-eth$$ is the ETH fee allocated to the protection mechanism pool,
* $$fee\_-protection\_-token$$ is the TPRO fee allocated to the protection mechanism pool,
* $$protection\_-surplus\_-eth$$ is the surplus ETH that remains after covering the loss,
* $$protection\_-surplus\_-token$$ is the surplus TPRO that remains after covering the loss,
* $$success\_-fee\_-eth$$ is the success fee in ETH deducted from the protection surplus,
* $$success\_-fee\_-token$$ is the success fee in TPRO deducted from the protection surplus.
From the funds allocated to the liquidity provider in the protection mechanism are deducted $$received\_-protection\_-eth, received\_-protection\_-token, protection\_-surplus\_-eth, protection\_-surplus\_-token$$.