cadCAD Roadmap Plan for the game

[GriffGreen]

OLD! See updated in commons-simulator repo

📋 Description

There are 2 things happening... there is the having a working simulation of a Commons (which will be very useful for the TE Commons), and then there is having a simulation that fits the requirements of the game... there is a lot of overlap but this roadmap is specifically tailored to get cadCAD ready for the game.

For the main Commons Stack Simulation, the goal is to be able to drop in new behavior policies without everything being so messy! This is out of scope for this sprint tho! That is what we do after the sprint but it is important to keep that in the front of your mind when doing the rest of the work.

For the game, the goal is to have a simulation that:

• Gives results that make sense and match the proposed behavior of a Commons
• Has the exact same output of graphs for any given input of parameters
• Is sensitive to the 6 parameters that the users will be able to tweak

🎉 Definition of done for the first Sprint

• Onboard a Second dev
• Defining what a finished cadCAD model looks like for the Simulator!
• Andrew & Griff agree that this is the path forward
• Add selling into the simulation
• Create a config file to make it easy to tweak the 6 variables that the game will be sent to the cadCAD Backend
• Make a very basic front end that sends in the 6 variables to the cadCAD backend
• Display a graph that shows Commons Token Price vs time
• Display a graph that shows Funding Pool vs time
• Get the simulation to pump out a variety of reasonable results... Commons that succeed and Commons that fail
• Be able to toggle between randomness or predictable outcomes where any given input always delivers the same output

🎉 Definition of done for the game

• Tweak the policies of the simulation so that it is sensitive to changes in any one of the 6 variables.
• Finish the Updating the Proposal Object (below)
• Finish the Updating the Participant Object (below)
• Finish the Updating the cadCAD Policies (below)
• Finish the Updating the partial state update blocks (below)

Definition of finished cadCAD model

Responsibility

How are responsibilities are divided between the components? The rule is if it is inherent to a particular thing/concept, then that is the responsibility of that class. Otherwise it belongs to the simulation code, the environment.

Proposal

• is responsible for updating its age
• is responsible for calculating its conviction threshold
• is responsible for reporting if it has gathered enough conviction to pass
• is responsible for reporting if it hasn't enough conviction and will fail

Participant

• needs to decide how much $ to come in with
• needs to decide which Proposal to vote for
• needs to decide how much to stake on each Proposal (rebalance?)
• needs to decide whether or not to create a new Proposal
• needs to keep track of his own sentiment
• needs to update his own sentiment if his proposal was passed or failed
• decides whether to buy more tokens
• decides whether to sell tokens
• decides when to exit

cadCAD

• needs to decide which Participant is influential or not
• needs to decide which Proposals conflict each other
• needs to decide a new Participant's relationship to the existing network
• is responsible for reading from/writing to the graph. The changes are indicated by the methods of Participant, Proposal etc
• is responsible for simulating income through speculative trades
• needs to decide whether an active proposal succeeds or fails
• needs to calculate overall sentiment. New policy: influenced by price + whether proposals are getting completed + Participant's individual sentiment
• needs to notify each Participant of Proposal failure/success
• responsible for keeping track of staked tokens and calculating conviction for each Proposal,
• keeps track of token price (obtained from commons object) for eventual plotting

Metrics of Commons Success

• If price of the token after 700 days is 30% higher than the hatch price
• Ratio of successful projects to failed ones is > 50%
• Overall Sentiment > 0.7
• # Participants 700 days after hatch is double the # of Participants at hatch.
• Over 30 projects were funded in 700 days
• The Funding Pool has spent 10% more funds than it recieved at hatch after 700 days

Metrics of Commons Failure

• If price of the token after 700 days is 20% lower than the hatch price
• Ratio of successful projects to failed ones is < 30%
• Overall Sentiment < 0.3
• # Participants 700 days after hatch is less thant the # of Participants at hatch.
• Under 15 projects were funded in 700 days
• The Funding Pool has spent only 70% of the funds it recieved at hatch after 700 days

Integration test (complete simulation) goals

• Some simulations should meet the success metrics, whereas some should meet the failure metrics.

Simulation steps

• populate network, setup edges (cadCAD)
• generate new participants (cadCAD)
• generate new proposals (cadCAD)
• generate new funding (cadCAD)
• make active proposals complete or fail randomly (cadCAD)
• Proposals with enough conviction become active (Proposal)
• decide which candidate Proposals to vote on (Participant)
• rebalance existing + new tokens over all supported Proposals (Participant)
• decide to buy some more tokens or sell some tokens (Participant)
• and if so how many (bulk buy without slippage may make more sense and be more in line with most Participants' real life experience) (Participant)
• participants may decide exit completely (Participant)

JSON Schema of data to be sent to frontend

{
    "funding_pool": [funds_timestep_0, funds_timestep_1, funds_timestep_2...]
    "token_supply": [token_supply_timestep_0, token_supply_timestep_1, token_supply_timestep_2...]
    "collateral": [collateral_timestep_0, collateral_timestep_1, collateral_timestep_2...]
}

🤼‍♂️ Reviewer

Griff