synthetixio / simulation Goto Github PK

At the moment, agents can place as many orders as they like.
They should only be able to place orders if they have sufficient assets to service them.
Then aggregate demand and supply will reflect true asset levels, not be a distortion based on order book manipulation. What's on the books should all be potentially filled at any time.

Doing x: Dec = Dec(1) and the like seems kinda stupid, and it is. We should try to keep the code as uncluttered by type annotations as we can, I would say.

The refactoring of some aspects of the orderbook/trade logic in branch #41 have raised errors with the used_currency values. Probably stemming from updating values/fees, even though the logic seems sound.

This could be caused by the updated sell function in the market player, as small trades can repeat many times, leading to small inaccuracies being magnified

A fair bit of /simulation/visualization is copied from (https://github.com/projectmesa/mesa/tree/master/mesa/visualization), the licensing needs to be looked at properly if this code ever goes public.

Arbitrageur balances should only increase after a cycle. Current arb assumptions don't make sense when an asset price is falling steadily.

It would be nice to see candlesticks instead of line graphs for the different market prices (nom price, cur price, nom/cur price). The rolling average discussed in #17 could be overlaid on top of the graph. This isn't a huge priority however, as it would take some time to find an implementation/implement it ourselves.

We could always just show highest, start price, end price and lowest as four lines instead.

Currently the _sell_quoted function uses the lowest price to calculate the quantity to place a buy order for. This will lead to errors as multiple order prices can be filled, leading leftover of the quoted quantity.

eg.
Market = NOM_FIAT
quantity = 100
buying FIAT using 100 NOM
lowest ask is [email protected]
So the player attempts to buy 100/1.1 fiat ~ 90.9
order is partially filled: player get 50 fiat, left with 45 NOM, still has to buy 40.9 FIAT
next lowest ask is [email protected]
Player attempts to buy 40.9 FIAT, but only has 45 NOM, can only afford 30FIAT
order will fail.
player left with 50 FIAT, 45 NOM even though they wanted to use all NOM

The simulation is missing a favicon.ico, would be nice to add it

It would be cool to be able to set the initial agent populations/fractions by means of some UI element at sim initiation. It would be nice to be able to experiment with these fractions in order to understand what different population scenarios might entail.

It would be neat if on each bar in the wealth chart, there was a green section for fiat, blue for nomins, red for curits. If they were stacked we would have a nice wealth breakdown for each agent.

Currently the web app creates a new model on the server for every socket that is connected, which will become very cpu intensive if that is how we wish to deploy in the future. A way of dealing with hundreds of users needs to be thought of.

Currently I've limited the fps to 6, and the max number of agents to 250, and still, with 3 users running at those maxes, the cpu reaches 100% quickly (AWS medium instance). Memory doesn't seem to be an issue at this stage.

This should be solved before the whitepaper is released.

There should be a fee variable attached to the Issuing and burning of nomins, even if the value is 0, so it can be adjusted and tested later.

In line with this, there should be a better way of adjusting all the market variables, a UI is probably going too far, but at least a file for loading settings

A lot of variables currently are just set within the code, such as fees and quantities. There should be some added user controls on the UI for setting the more important ones, as well as potentially setting some variables for specific market players.

Not sure how much performance it's really consuming, but really the round_decimal function need only be called on products or quotients. Additive functions shouldn't matter, and neither should we need to call it for comparisons, if we are able to assume it's already been called when needed.

Currently the orderbook was created to just work, without taking into account fees correctly. A few patch jobs were added on top of it to get it to work, and now getting everything to work is a struggle. Some current issues are:

• Selling a quantity can lead to errors with the actual quantity sold, due to fees and the like
• Calculating the price to sell a quantity, and other similar utility functions are inefficient
• Fee calculation doesn't seem consistent (needs to be looked into, and thought about properly)

A few things can also be added to the orderbook/general settings:

• minimal trade limit (value of the trade in terms of fiat(or some other currency) should be at least x)
• better organised data structures:
• • Transaction history by model.time
• • Current orders in terms of price, to keep cached quantity in once place
• Rolling price average: #17

That's all I can think of right now...

Now that this thing looks like it's starting to go public I think we should start thinking about separation of concerns as regards the prototype, analysis, and simulation folders in this repository.

In particular as work on the prototype begins, I think it would be valuable to have separate issue lists in particular.

There could be some value in allowing actors to interact with the central bank to place short/long options (or call/put), and other brokerage/hedge fund functions, such as lending etc.

Agents shouldn't keep on performing the same strategy if it's losing them money. On the other hand, they should also keep a lookout to see if there's anything more-profitable they could switch to.

Agents should be somewhat loyal to their existing strategy to prevent jitter. Maybe different agents can have different timeframes they expect to be profitable over, or different appetites for risk and volatility. Agents should switch strategies stochastically and with a probability in proportion with the
profitability different between their current strategy and any potential rival strategy.

Profitability will be directly measured over different timeframes for each population of agents.
Someone should always be engaging in each strategy as a bellwether for it, so that there are always profitability metrics available -- but perhaps they only need to trade in infinitesimal quantities if the profitability is measured in percentages.

This might also extend to increasing demand for the system by new players who previously had no strategy at all, allowing an influx of new capital.

I'm not sure that mesa can handle floating population levels so perhaps at some point if agents want to change strategies then either the strategies needs to be abstracted out from MarketPlayers, or each agent should have a wrapper so that different agent classes can swap in and out.

This should be optional/switchable so that #26 can still work.

The current agent visualisation system is a bit lacking, labels don't show up for each graph, and the graphs are limited in what they can show. Adding a graph for the orderbook would be the first step in expanding the system to be able to view data in different formats.

Right now the info panel lingers awkwardly and it looks bad.

There should be a system of finite precision on all floating point values implemented, currently the system could end up having some level of floating point error. This should be a realistic number, as trading currencies to 18 decimal places is a bit over the top, somewhere in the range of 8-10 would probably be more than good enough.

Since the main stabilisation mechanisms are facilitated by arbitrage, we need these bots.

We need not only triangular arbitrage, but also bots that go through the issuance/redemption cycle.

As we are deploying the model on a web server, we really need to consider adding a debug mode for more in depth logging, having different max values (i.e. deployed app maxes out at 6, but debug goes to 20), potentially showing more graphs and not being affected by google analytics.

It's not super descriptive, and they're not really shorting. They're really StabilityAssumers or something like that.

Executing on Linux 18.04

Right after install

yash@yash-Lenovo-G50-80:/media/yash/data/agent_based/simulation$ python3 run.py
No settings.ini file present, creating one with default settings.
Running cached data server...

Generating Balanced
  0%|                                                  | 0/1000 [00:00<?, ?it/s]
Traceback (most recent call last):
  File "run.py", line 6, in <module>
    S: ModularServer = server.make_server()
  File "/media/yash/data/agent_based/simulation/core/server.py", line 213, in make_server
    server = CachedModularServer(settings, charts, "Havven Model (Alpha)")
  File "/media/yash/data/agent_based/simulation/visualization/cached_server.py", line 164, in __init__
    self.cached_data_handler = CachedDataHandler(settings)
  File "/media/yash/data/agent_based/simulation/visualization/cached_server.py", line 98, in __init__
    data = cache_handler.generate_new_caches(data)
  File "/media/yash/data/agent_based/simulation/core/cache_handler.py", line 188, in generate_new_caches
    element_data = element.render(havven_model)
  File "/media/yash/data/agent_based/simulation/visualization/modules/wealth_graphs.py", line 79, in render
    if len(data_collector.agent_vars["Agents"]) <= 1:
AttributeError: 'DataCollector' object has no attribute 'agent_vars'

If you run cache_handler.py, for example, the speed of the model seems to fall linearly with the time it has been running. This should not be the case.

It's become apparent that we really need some tests for validating functionality and ensuring we're not breaking stuff as we go.

I've started with #50.

From small tests it seems that the orderbook bid/ask sorted lists are a bottleneck for the running of the model. An optimisation I would suggest would be changing the data structure to a sorted dictionary, that caches the total quantity at any given price.

i.e.
SortedDict.keys = SortedList([Decimal(1), ...])
SortedDict.dict = {Decimal(1) : (total_quantity, SortedList([Ask, Ask, ...]), ...}
Where the SortedList of asks is sorted by time

There could also be two separate dicts for total quantity and the sorted asks

How it currently seems, is that if a bid/ask is placed, the order's quantity is quantity+fee. If you're looking at a market you would want to know how much is available for you to get, so the order quantity should be how much is available for you to receive, not how much the other "player" used to place the order.

However, placing an order shouldn't charge a fee, only when it is filled, so the order should hold both the quantity and fee values (and charge a percentage of the fee if an order is partially filled - this may need some thought if some sort of flat fee will be charged).

Some object to deal with fees should probably be created, as well as changes to the orders.

Apparently the utilisation ratio is not properly accounted for. See mint.py for details.

Right now the prices are just the midpoints of the current order book spread. It's exceeding volatile, perhaps it should be a rolling average, volume weighted, or some other thing, in order to smooth out market shocks?

Otherwise, perhaps it should return the (highest bid, lowest ask) pair and we can render out the candlesticks.