Test price move #142
Test price move #142
Conversation
…ring a price pump
…ring a price pump
There was a problem hiding this comment.
Looks correct. I would suggest extending it as follows, probably in new notebooks initially (but they maybe can replace the existing notebooks once they work):
There are 3 variables that may impact the amount LRNA value changes that I'd like analyzed:
- Size of the temp price move (this is studied in the existing notebook)
- Size of the liquidity added/removed during the price move
- Weight of the asset in pool to which liquidity is added
The existing notebooks pretty much only look at the connection between price move size and LRNA price movement, but all 3 of these matter, I suspect. The existing notebooks make their price moves over time, which is useful initially to see that things are working as expected, but for the new notebooks I think is unnecessary.
I'd suggest that for each variable above, fix the other 2 at something reasonable and just vary the 3rd, and graph that.
- Vary size of liquidity add from 1% to 50%
- Vary size of price move from -90% to 10x (same as current notebooks)
- Vary initial weight of asset from 5% to 80% (which simulates correlated price movement, actually)
hydradx/notebooks/Omnipool/static fees comparison/Peter's agent no_arb.ipynb
Outdated
Show resolved
Hide resolved
# Conflicts: # hydradx/tests/test_omnipool_amm.py
…oken weight and LP percentage
| " [1 / (ticks_number - 1) * i * len(events) for i in range(ticks_number)],\n", | ||
| " [f'{int(i * 100)}%' for i in tkn_weights[::10]]\n", | ||
| " )\n", | ||
| " plt.title(f\"price move: {price_moves[pump_factor]}\")\n", |
There was a problem hiding this comment.
Why does this graph look like a sawtooth graph instead of a smooth one? Doesn't make sense to me...
There was a problem hiding this comment.
It has to do with the optimization in omnipool_arbitrage that we discussed, specifically the one where the arbitrageur skips certain assets if their price differential is too small to make a profit. Since that check is performed at the beginning of the function, and subsequent trades during the function can cause prices to change, this results in some trades being skipped that would have become profitable, ultimately messing up the graph. My for-now solution was to comment out that code block, re-run the notebook, and push the result with the better graph, but I'd suggest adding a way to disable that optimization in the future (maybe skip it if arb_precision > 1?)
There was a problem hiding this comment.
This isn't the solution that's currently checked in, is it?
…nal to prevent errors in some circumstances
…oken weight and LP percentage
…nal to prevent errors in some circumstances
# Conflicts: # hydradx/model/amm/trade_strategies.py # hydradx/tests/test_omnipool_amm.py
Two new notebooks here looking at what happens when an LP invests or withdraws at the height of a temporary price move.