vegaprotocol/specs

vAMMs

Closed this issue · 0 comments

High level aims:

  • We want a party to be able to deposit capital, choose some parameters and open a perp (or future) market
  • We don't want them to go bankrupt quickly every time

High level "problems":

  • there is only the settlement asset so we can't just pick up an off-the-shelf CFM curve (except we can more on that later, but it won't be the same)
  • there is margin for the "order volume" that has to be calculated
  • short positions have unlimited downside so the party that set this up can go bust very quickly if there is no position management
  • we have to make it work with SLA

Use CFM curves: possible approach 1:

  • The curve is parametric, in the simplest case, which we won't use is $xy = k$ where initially the party will choose what $x$ and $y$ they want to go with (but don't support it with assets, they just need to provide margin). If a trade occurs we'd update $x$ and $y$ appropriately
  • The "parametric curve" code / module then has to provide the answers to following questions: 1) for a trade of size $S$ (integer multiple of minimum position size), what's the best buy price / sell price? 2) what is the volume at each price level between last trade price until the bound implied by the SLA parameter lpPriceRange. Clearly answers to 1) will be used for trade execution, answers to 2) will be used for margin calculation (order margin) and SLA evaluation. And arguably we could use 2) with VWAP calc to answer 1) as well...
  • An incoming trade (market order / limit order) should be evaluated against book and ever volume, if it's a limit order crossing any volume then it will be treated as market order. There will be routing logic which executes against the best liquidity source (without splitting or by splitting into various chunks, details TBD).
  • The "curve" should help with some position management which is the reason why we won't use $xy=k$. MVP would be to do $xy = k_b$ for incoming buy orders and $xy = k_s$ for incoming sell orders with $k_b$ and $k_s$ adjusted based on position size, so that "if I am already short buy orders get a bad price from me but sell orders get a good price from me".
  • We may want to allow Uniswap v3 type CFM curves.
  • There should be API which will allow UI to visualise the volume implied by all the passive liquidity together with the order book volume; the logic for generating the data should sit on the data node.

Don't use CMF curves, just automatically place volume

This uses the observation that up to discretization CFM curves and LOB volumes are the same thing and we already have the LOB.

  • Setup automated orders that will allow "less active" liquidity. However don't do it using pegged orders but instead just place limit orders on the book based on a simple parametric formula; place the volume relative to last traded price and min / max price implied by the SLA parameter lpPriceRange.

The good thing about the 2nd approach is that it requires on routing or special API work.

Something to consider: allow market to leave opening auction by setting the "mark price" to the underlying oracle input if there were no crossing orders.