Simple Strategy to estimate prices

Knowledge Base Archive
1

Estimating clearing prices is important for market makers. Specifically, there might be an incoming market order on the token A->B. A marker maker/ trader now might be interested in calculating what is the worst price they can bid to still trade against the market order given the current state of the system.

A simple strategy might be:
Take all orders on A>B and B<A;

  1. Sort them in a way to get the order that is requesting the lowest price first;
  2. Adjust the order to a volume that is actually backed by user balance;
  3. Reduce the user balance by the sell amount (simulate that this order will be filled)
  4. Repeat 2. and 3. for all orders that involve token A or B
  5. Create synthetic orders via “transitive hull” (e.g. A>C; C>B)
  6. Calculate clearing price on A-B with the aggregate of volume adjusted order and synthetic volume adjusted orders.

If step 5 is used in combination with step 2 the order matters. Tokens A might for example already be virtually spent on a path A->C->B but it turns out the path A->D->B would result in a better A->B rate. To address this it might make sense to think of the problem as a pathfinding problem with tokens as nodes and the order prices are the travel costs of those routes. It might be best to load the problem as a graph problem and use a pathfinding library. In this case step, 1 and 4 can be done simultaneously. The direct path can be the cheapest but does not have to be.

2

If I understand correctly this strategy, we assume A->B prices are more efficient than A->C->B prices, this is why step 2-3 simulate filling those orders first.

As a simple strategy I agree it can be good to match directly the tokens first. Looks like you can get a price faster and it’s a good start.

If we try ring trades and path finding algorithms as suggested in the second part, it looks too me the strategy is not so simple anymore, so maybe I wouldn’t assume A->B is always a better path.

Another concern with this price is that, it shows a segmented view of the system, it would show a price where the execution of orders starts in the tokens they are seeing (makes a better price/liquidity for your tokens). So two users looking at different token pairs will display a price assuming solutions that can’t be true for the two of them at the same time.