This template recreates a simple token economy where the protocol shares a percentage of their fees with the Stakers.
Learn about our modelling methodology at https://docs.cenit.finance/use-cases/staking-+-burning-token-economy
In the spreadsheet file, we will find multiple sheets that need to be completed. Every single sheet has their own instructions and guidelines at the top for convenience.
The structure of the excel as follows:
Sheets for User Inputs, in yellow color: These sheets cover design parameters, hypotheses, and the vesting schedule that should be tested in the simulation. The parameters incorporated here are the ones that the end user will be able to change in the dashboard once the simulation is up and running.
Sheets for Internal simulation flows, in orange color: These sheets are the core of the modeling logic of your tokenomics design. Here we will define agents, their behavior, and the token flows between them.
Sheets for reporting, in red: Once the token economy has been defined and modeled, there will be some relevant resulting metrics that should be tracked in the dashboard. These values are not part of the computation of the simulation, but rather output KPIs extracted from the simulation results.
Sheets for dashboard, in blue: These sheets define the disposition of elements in the dashboard. With these sheets, you can define which hypothesis will the end-user of the dashboard be able to test, which graphs and metrics should be displayed, and in which order.
Sheets will contain the customized version of the economy according to your criteria and interest. Additionally, there are some special flows, agents, variables and actions that are common to every token economy and that are always included in every simulation without the need for the spreadsheet user to define them, like the token price, or the circulating supply. These will be explained in detail in each sheet.
Base: This sheet contains some key configuration parameters common to every tokenomics simulation.
Static Parameters: It contains all the numerical input parameters to the simulation. This includes design parameters (e.g. a fee percentage in the protocol) and hypotheses (e.g. the expected average usage per user and month for a service). The table defines a default value for each parameter, but generally the parameter will be available in the dashboard sidebar to be adjusted by the user using sliders or a textbox input (see the “Sidebar Configuration” sheet).
Selector Parameters: It contains input parameters with a set of options for the user to select from. For example, these parameters can be used to select between two different designs for a mechanic in the simulation.
Time dependent parameters: It contains all the inputs to the simulation that constitute a time series (e.g. a monthly projection of the number of users of the protocol).
Vesting: It contains the token allocation and vesting schedule. The configuration defined is the one that the end user will see as default in their simulation. However, they will be able to change parameters values on the final dashboard.
Agents
It contains the agents that participate in a simulation. Agents are any element of the token economy capable of obtaining, keeping, or sending tokens. This may include the treasury, token stakeholders, protocol users, etc.
In this sheet we will be able to create actions for the agents such as holding tokens, staking and liquidity providing, which are added as flows into our simulation.
• Holding: purchase (or sell) tokens from the market until the value specified is reached
• Staking: use a percentage of the tokens to stake
• Liquidity providing: sends the tokens into the market for liquidity provision, computed in the AMM (check below)
In addition to the agents that might be defined here, there will always be 3 special agents available in the simulation. No user-defined agent should have the same Reference.
• market: represents the dynamics of the market, simulated with an AMM. Based on the liquidity that it has, and the amount of tokens that are being sold/bought, the price of the token will change.
• mint: a source of new tokens to introduce to the economy
• burn: a sink of tokens to be eliminated from the economy
Variables
It contains internal variables for computing the dynamics of the simulation. While not strictly necessary, using these intermediate variables will simplify the modeling process.In addition to the variables that might be defined here, there will always be in the simulation: (Token price, circulating supply, total supply, market cap, buy pressure...)
Flows
It contains flows of tokens between agents in the simulation. The flows are through mathematical expressions that can use formulas, variables, parameters, and agent properties, as described in the “Variables” tab. The flows always have an Origin, the agent sending the tokens, and a Destination, the agent receiving it.
Special Flows origins and destinations: It is possible to add the following special agent references in the source or destination fields:
• market: with the market as a source, the counterparty agent is buying tokens on the market. With the market as a destination, the counterparty agent is selling tokens on the market. These actions generate buying and selling pressure, and affect the price of the token depending on market liquidity.
• mint: only available as a source, the amount of tokens in the flow is created and added to the destination agent, increasing the total supply.
• burn: only available as a destination, the amount of tokens in the flow is destroyed and subtracted from to the origin agent, decreasing the total supply.
Metrics
It contains additional metrics to be reported in the output graphs. A metric is a special type of variable that does not influence the progress of the simulation, but instead depends exclusively on its results. As a result, they can only be used for reporting purposes.
Graphs
Here you should design those graphs that are custom for your project. To build the graphs, you can use formulas, variables, metrics, parameters and agents properties. In addition to the custom charts, the simulation will always provide some default charts that do not need to be defined.
Sidebar config contains the definition for the dashboard sidebar, where the user is able to adjust the input parameters of the simulation, including tokenomics design parameters, hypotheses, or the vesting schedule.
Dashboard config. It contains the definition for the dashboard results panel. Here you should introduce the order at which the result graphs will be plotted in the dashboard
