We should bring the agents into a struct Agent instead of creating a vec in each simulation (e.g., steppers in the dynamic_weights.rs). This struct can have the builder design so agents can be easily added.

We should then pull out the loop used in this simulation since it is already generic. The run() methods for the simulations should be changed to setup and return an object that can be looped over.

Whenever the price of a pool changes, the arbitrageur agent uses some math to determine if they should trade in the pool. The math will compute the trade amounts to try and swap.

Idea

Allow the price changer to be generic over a type of price process.

Right now we are doing fees in terms of BPs and we cannot go smaller than one BP. Let's allow ourselves very small fees just so we can see what the right lower bound should be!

Right now the momentum and volatility targeting strategies only use a very basic heuristic for updating weights (namely change the weight by 0.2% over the course of one day depending on realized volatility and net returns, respectively.) These strategies should account for a. how far from the volatility target the current strategy is (in the case of vol targeting) and b. how negative or positive the net returns are for the period (in the case of momentum). If the we are far from the volatility target, weights should likely update by an amount > 0.2%, and vice versa. If net returns are strongly negative or strongly positive, the change should be > 0.2%, and vice versa.

Having seeds is excellent for replayability and debugging. But, if we want to most truly random simulations, we should have the ability to remove seeds. Why?

• E.g., if you use the same seed, say seed==2 for a GBM price path, then that path will only be scaled by drift/volatility but will qualitatively look the same.

We should take extensive notes to document how the simulation was built.

Maybe we can make it in style of REVM docs that @0xJepsen wrote?

Maybe we start with a CLI and evolve into a more sophisticated UI

There are a collection of classic portfolio analysis techniques that we should integrate into our analyze toolkit

• Sharp Ratio
• Raw Growth
• Max Draw Down
• Volatility
• Momentum

Is your feature request related to a problem? Please describe.
I will make arbitrageur a trait so that we can have a consistent interface for any strategy we use. I will then bring in the RMM-01 strategies on top of the g3m.

Idea

Get a basic UI implemented for analysis that let's you pick a file to analyze and which events you want to take in.

Is your feature request related to a problem? Please describe.
Create a basic price changing agent hooked up to a liquid exchange. Can mimic the one used in portfolio_simulations

Describe the bug
add_liquidity on the liquidity provider only works properly if the trajectory.initial_price is 1. Need to refactor the add_liquidity method to work with variable initial price.

The main simulation loop is responsible for:

• Initializing the arbiter environment
• Deploying / setting up the state in the contracts
• Starting the loop
• Initializing + stepping the price path
• Triggering the agents
• Logging the data we want
• Shutting down after finishing

If we use a default price process like GBM we pick static parameters.

We would like to have time dependent vol, or other dynamic parameters.

Short term: Use rustquant fork
Long term: Get it merged in

We can have the analyzer UI automatically read in the selected file once chosen. Then it can use the reader module in analysis to give a list of the events so they can be displayed and chosen from. Then the event selection should collect a set of vectors of those events.

Possibly to test it out, the next AnalyzerState should display a scrollable list of these vectors and their values.

Config file needs to have all the levers we want to change to minimize the amount of recompiling we want to do.

Rough config:

• ref: https://github.com/primitivefinance/portfolio_simulations/blob/alex/addressing-bugs/config.toml
• price process parameters
• environment parameters
• agent parameters, if any
• pool parameters / weight change parameters
• asset token parameters, should be default
• global sim parameters

We should generate some basic analysis for the volatility targeting strategy and visualize it.

Idea

The configs we use currently don't allow for an easy extension to having new agents or instantiating multiple copies of agents that perform slightly differently.
Also, it would be nice to have configs follow a more standard design pattern.

Meta issue of documentation for strategy prototyping

When we generate data from a large amount of simulations in parallel over sweeps, we need to organize their output in a usable way.

What data we want to end up with:

• Track performance of spot assets vs. LP portfolio value performance
• Total balances & weights of the pool over time
• Realized volatility of the pool vs. assets volatilities
• Net arbitrage profits (lp portfolio value changes, if arbirtageur profits its positive, if LP profits its negative, can be graphed on bar chart).

Notes:

• Pipeline will be rust -> csv -> python
• Make a new directory for "box-analysis", holds the python code for processing the data
• All data generated in sim is exported to csv in ./output

• Set up the bindings for the g3m contracts
• Update deploy.rs to handle all of the contract and dependency contract deployment logic
• Add event listener with specific filters that we want to listen on

Should be very easy to:

• Run the sim from the cli
• Run the sim + analysis from the cli
• Run the analysis from the cli

When we are running big simulations, if one environment has an error, everything halts. This SUCKS.

Let's do the following:

• Label the environments as we run them, we can use metadata from the simulation itself to provide a meaningful label. E.g., "gbm_drift=0_vol=0.1_trajectory=0".
• Catch an error in the simulation itself inside of the task and end a single simulation early upon receiving this error. Do not bubble up into the multi-sim context.
• When an error is caught, dump as much metadata as possible into a log file that explains which environment failed and where exactly.

Right now we can ingest data from the JSON output into a nested mapping. Another feature we should add should allow for converting these events into the actual enum/structs that the bindings have. This should be pretty easy given that the bindings have both Serialize and Deserialize for all the structs/enum.

An agent must be responsible for updating the weights of the portfolio. This needs to emit an event in the contract and an updated price.

@Autoparallel Builds agent
@clemlak Adds event to smart contract + function for weight changes

New strategy prototyping.

Rather then computing a target vol, we would compute a notion of "momentum" and use it to describe the weight updates.

For example, if looking at an average price of an asset over time does it trend up or down -> positive / negative momentum.

What we could do is take the last 30 prices and compute a best fit line and draw correlation between slow and target weights. Would also benefit from time varying process parameters.

• Look over the g3m contracts to figure out what parameters we should include in the config
• consider dependency contracts and their configuration, e.g. price path parameters for liquid exchange price updates

The types of plots we have set up in Python are a good start. We should rebuild them in Rust using the Plotters crate!

Document what we are doing, why we are doing. A place for math notes, mathematical descriptions of strategy. Almost like our quant manual for PIAB.

For example: Say we are doing our vol targeting strategfy and we want to analyse it. What kind of analysis should we do? -performance, risk, etc. We can put our results and configs in this.

• #53
• #54

Lets allow these to just be text fields in the UI?
We can type check these.
(Provide dump user bumper rails)

In order to provide sweeping parameter sets, we need to allow our config/settings/parameters to be more easily tunable for this. We should be able to pass either a fixed value or a range of values for relevant parameter sets.

Ship it with markdown. Maybe ad it to the Mdbook?

• Pull in the python framework for postprocessing
• generalize where possible

Right now we have a weight changer for vol targeting and momentum. I think it would be good to just make a weight changer trait that can be implemented for those different types of strategies (i.e., they just have a method like compute_new_weights that can be implemented differently).

We can do the same for RMM parameters.

Then we can have a sim file for each strategy contract and the behavior of the parameters is just abstracted into a trait. We can decide which implementation we want to run for that sim in the config or something.

Reference codebase: https://github.com/squidowl/halloy/blob/main/src/main.rs

Here's a spec for an initial application delivered via ui/:

• I want to load a config for a sim into application (parse config into some application state)
• I want to choose agents to add to simulation (push/pop/insert hasmap or vec)
• I want to run the simulation (button that runs the sim with all the active agents)

This can be the start then we can work on features like modifying the config, modifying individual agents, running multiple sims, etc.

In order to use RMM effectively in simulations, we need the contract to implement the IStrategy interface.

• Create an agent which handles arbitrage between the liquid exchange and the g3m pools

Now we should use this to be able to adjust the properties of (2D) plots

How does Shadow do this?
This could make our existing tools really powerful.
For development we can make whatever contracts we want.

@clemlak is working on these in box-contracts/

Rough api:

• add_liquidity(uint liquidity) ?
• remove_liquidity(uint liquidity, uint min_amount_a, uint min_amount_b) ?
• swap(bool swap_direction, uint amount) ?
• update_weights(uint new_primary_weight) ?
• get_spot_price()
• get_primary_weight()
• create_pool(address token_1, address token_2) can probably put in constructor
• event for each action
• require() with error strings?

Note:

• primary weight is the main weight, secondary weight is 1 - primary weight. i.e. primary weight = 60%, secondary = 40%. Don't need to store secondary weight since it always sums to 1?

We need to be able to run simulations in parallel, so we should have some sort of way of batching simulations together to be run simultaneously.

Point to arbiter 0.6.0 feature branch

Asses viability of on and off chain fees models for Portfolio Protocol and/or generated Portfolio Strategies. Provide clear, quantitative examples of outcomes under different viable revenue models.

Goals

• Align incentives between Primitive and strategy authors. More AUM in Portfolio Strategies = more revenue for Primitive.
• Exercise strong pricing power. On or off chain revenue models must FORCE large AUM Portfolio Strategy authors to pay us.

Constraints

• As a decentralized protocol, there are limited methods for extracting revenue that scales with the growth of successful Portfolio Strategies.
• Compliance is a key concern, as we must retain discretion on who we collect revenue from. Generalized on-chain fee models are not viable.
• Fees directly implemented into Primitive-generated Portfolio Strategies can be removed by savvy firms after-the-fact by redeploying the strategy.
• Off-chain fees must be reliant on a consistent service or value-add provided by Primitive. This consistent service must be CRITICAL to the long term operation of successful Portfolio Strategies in order to exert pricing power. It is unclear what additional services Portfolio Strategy authors would be willing to pay Primitive a % of AUM for. If a strategy has $1B AUM, taking % management fees for basic tooling such as monitoring or anomaly detection will force the author to build their own stack to avoid paying fees.
• Fixed fees or SaaS subscription pricing does not align incentives with Portfolio Strategy Authors.
• We must be able to provide pricing discounts. Otherwise we prevent experimentation within the platform.

Viable Off-Chain Revenue Models

Commercial Open-Source Licenses on Primitive-generated Portfolio Strategies

Opt-In Risk Management Services for Primitive-generated Portfolio Strategies

Viable On-Chain Revenue Models

TBD

• Create an agent dedicated to using the smooth rebalancing to update weights on the g3m pools
• The agent should be configured with a target volatility and should have access to functions that calculate trailing volatility (see aera for methodology)

Should cover

• udeps
• codespell
• clippy
• build
• test