Torus Network Tokenomics

--- tags: spec --- # Torus Network Tokenomics ## Introduction Incentives are an important aspect of any decentralized protocol. Because the goal of our decentralized key management system is to ultimately provide the most usable key management system for users, applications and node providers, a lot of thought must be put into designing the systems in place, our goals with the mechansims are: - Ensure constructive behavior of all stakeholders. - Peg token value to network growth and utilization at a log scale - Creating a sustainable network equilibra in the long term that balances the different stakeholders and ensures unreplacability Below we’ll review the specific economic decisions that must be made, and the logic behind them. While portion highlights an overview of the main mechanisms that the token is currently proposed to be utilized in. Changes are expected, certain paramenters are to be determined as benchmarks and development proceeds on the core protocol. ## Stakeholders ### Users Individuals whom need to manage their keys on various applications. Users may determine how they want to split their key and additional permission setting on their accounts. Users may or may not want to pay for their usage on applications, but their usage takes computation/resources and will generally require payment. ### Node Operators Operators run nodes which do work in return for compensation. There are two types of node operators currently planned in Torus: - Full Nodes - are designed to be run by operators whom provide for millions of authentications a day. Functionality of the nodes can be split and are parallelizable. These nodes authenticate, generate, store and run computation on user keys, in turn are compensated for their work done. - Light Nodes - these nodes are lightweight nodes designed to be run in mobile or even browser clients. The primary function for these nodes are to serve as "backups" or less available casual options where users can store shares. e.g. Running an application to store a share for your parents. ### Applications Applications use Torus to provide their users with a better key management experience. Depending on the type of application and their extent of monetization, they may or not be willing to pay on behalf of users on their front-end. ## Transaction fees Torus operates a smart contract layer that allows users to deploy contracts with the primary function of verifying secrets. Akin to other existing blockchains, such as Bitcoin, Ethereum and Filecoin, deploying and calling functions on these smart contracts cost gas/transaction fees. ### Base and transaction fee A portion of which are paid to node operators for their work done and a portion burned as a base fee. The base fee is defined per transaction in the protocol. This fee is then adjusted either up or down depending on the the extra "tip" provided in the transaction fee. This results in a higher base fee, and thus tokens burned on high usage of the network, and vice versa a lower fee on low utilization of the network. The mechnism is heavily inspired from [EIP 1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) to address inefficiencies in prior first price auctions and long-term instability. Additionally the mechanism inadvertly ties a token's value to its utility. Transactions fees are paid to an operator when a user: - Generates and stores a key and its respective shares - Authenticates on the network for key retrieval - Resharing, updating or rotation of key shares - Computing threshold signatures, whether full or partial ### Gas Abstraction Gas abstraction is built into the protocol layer that allows either a user or a third party to pay on behalf of the user. This allows for applications to pay on behalf of their users if they wish to do so. ## Staking Staking is designed to incentivise nodes to behave in a way that helps consensus and achieve global outcomes. A node earns the right to mint by putting up stake and then participating actively in the consensus process. Node rewards take into account uptime and amount staked. $T_i$ is the total token supply for period $i$ with $T_0 = S_{genesis}$, total transaction fees is $F_i$, fee burning ratio is $b$, reward ratio is $r$. $u$ represents a staker, with $s_u$ representing the total amount of stake for $u$ and $t_u$ representing the total time staked for $u$. $T_j = T_i + r\sum\limits_{\forall u}f(s_u,t_u) - bF_i$ where $f$ is a parameterized monotonically increasing function such that $f'' \leq 0$. We do not define a strict upper bound on total tokens minted (i.e. capped supply), but we provide analysis below of how token supply is affected by network usage. $T_j = T_i + rG- bF_i$, where $G=\sum\limits_{\forall u} f(s_u,t_u)$ Let $\bar T = E(T_{\infty})$ $\bar T= \sum\limits_{i}(rG - bF_i)$, $d{\bar T}/db = - \sum\limits_{i} bF_i < 0$ As such, expected total token supply varies inversely with the usage of the network, resulting in a deflationary token during high usage, and an inflationary token during low usage. Having an inflationary token during low usage lowers the effective transaction fees, which should encourage more activity on the network. Incentives of node operation are proportional to the demand for key mangement and inversly so to the resources available and thus number of nodes operating. If the network is highly demanded, costs would increase and thus incentives - with the expectation that operators would run more nodes to accomodate for the increase. Vice versa, if demand falls, we expect nodes to be able to leave after offboarding. ### Proof of uptime and preventing griefing As users require constant access to their keys, uptime and data availability are important metrics for the network to uphold. Service and computation on secrets held by the network is guaranteed through a constant amount of stake provided by each node. They store secrets and provide MPC outputs when the contracts are run, threshold signatures need to be signed and other things. In operating these base functions the node is incentivised through user fees paid by applications and users proportional to the resources provided. In the event a node isn't able to provide/present a proof of ownership of a secret (via a signature), there is a one time griefing punishment for, designed to disincentivise secret loss. Stake is utilized thereby used to guarantee liveness and deter griefing attacks described in from the nodes. Given that $n$ is the number of nodes holding a particular secret $z$. Nodes are required to maintain an uptime of these secrets, and in the event they are not they risk a portion of their stake. In this way, we can derive an economic guarentee to a user that their secrets will not be lost through: $Secret\space liveness\space guarentee=(n-t)*Stake\space at \space risk$. Whilst a strictly positive economic incentive should already suffice to guarentee liveness, in practical implementation unexpected technical issues and unforeseen circumstances exist and the guarantee will be a parameter to balance against these mishaps.