Agents and Token Flows
Last updated
Last updated
The Cenit tokenomics simulator is based on agents that exchange tokens under changing conditions. This is abstracted away in the Basic editor. However, in the advanced editor we need to define the agents that are going to participate in the token economy. Each agent represents an entity or group of users with a common interest or behavior, capable of obtaining, keeping, or sending tokens. Some common entities or groups that would be included in a tokenomics simulation are:
Treasury: captures some of the fees and/or allocation and generally uses it to fund operative costs of the protocol and other expenses such as grants, rewards, or marketing, or even payments to the original company behind the protocol.
Market Maker: provides liquidity to the market. Generally has a token allocation that will be provided as liquidity.
Stakeholders: part of the team or initial investors in the project. They have a token allocation and generally seek to get their investment back over time by selling part of their received allocation gradually.
Stakers: look to purchase tokens when there is a good opportunity for staking APY in the protocol when compared to the market. As a result, stakers tend to accumulate tokens until the actual APY reaches some equilibrium with the expected APY.
Incentives Reserve: captures some of the fees/allocation and gives them out as rewards to other entities, such as protocol users, service providers, or stakers.
User: buys tokens when they need to consume the value proposition and seeks no token exposure, so they just buy the minimum quantity of tokens exactly when needed. If given tokens as a reward, they will sell them.
Service Provider: provides a service to the protocol in exchange for compensation. Depending on the mechanism, they might buy native tokens when required for service provision (such as a staking requirement), but maintaining a minimal exposure.
These categories are representative of a token economy. However, we can create as many agents as we want or increase the granularity of these agents. For example, splitting Stakeholders into âStakeholders we trustâ and âStakeholders we don't trust,â where one might dump the token much faster than the other. Another division could be users and providers of different value propositions.
Sometimes, a person or group may be considered to act in multiple agent roles at the same time. If I am using the dApp and staking simultaneously to get some yields, I would be part of of the âStakersâ and âUsersâ agents at the same time.
Create your agents with the proper display name first. This will allow you to select the agent in the flows.
If an agent is providing liquidity to the token economy, as is the case for a Market Maker, set a liquidity provision ratio of 1; otherwise, set it to 0. Check out this section for liquidity provision considerations.
You can set the allocations that each agent will receive based on the vesting schedule. Since we have already defined the allocations and schedules previously, we only need to select which agent will receive them. Multiple allocations might go to the same agent, while others might not receive any allocation.
In the example above we see how multiple allocations go to âStakeholdersâ because every entity participating in the token sales is considered to behave similarly. If we expected their behavior to be different, we could split the âStakehodersâ agent into two or more agents in order to model them separately.
All agents in the simulation participate in token exchanges with other agents. These can be things like buying tokens, selling tokens, fee distributions, minting, burning, etc. In this section give names to those flows and define the participants, selecting the Source and Destination agents. Besides the agents we defined in the agents table above, there are three special purpose agents available here:
Market: used to represent the token markets where the token is bought and sold. A flow with Market as the source represents a token purchase, while a flow with Market as the destination represents a token sale.
Mint: a flow with Mint as the source represents the minting of new tokens, for instance, for some emissions schedule or incentives.
Burn: a flow with Burn as the destination represents the burning of tokens, for instance, the burning of a portion of the protocol fees.
The amount of tokens exchanged on each simulation time step through these token flows is defined in the Simulation Equations section further on.
