So many interesting point have been made in this discussion and you are all spot on.
We are offering too much T1 liquidity, because there is a financial incentive to do so.
However, “Too much” is a complicated concept and the exact “right much” of T1 liquidity provided at each point of time must be studied, empirically and non, and then voted by shareholders.
This is what would be needed - theoretically - to make a distributed liquidity operation smooth :
-
We need a formula to compute the “right” amount of total buyside_liquidity and sellside_liquidity to provide at each point of time, given market condition and other inputs.
-
We need have a (distributed?) oracle that the bots can connect to so they can ask “How much T1 liquidity should I be putting on now, buyside and sellside, given what the other bots are already putting?” .
-
We also need the oracle (if any) to be able to able to suggest to LPs on which exchange that T1 liquidity is needed at each point in time, given market and other factors.
-
Finally we must have a system that cuts off the incentive for providing T1 that exceeds the suggested max.
NOTE : the so-called-oracle might be not necessary if we let NuBot query liquidityinfo to know how much is already being provided and where reliably. It was just an example .to make thinking about it easier.
Once we have that, if that is what we really want, we can achieve the goal of providing the right level of liquidity.
If this is what we want, it must be voted, scheduled, and its development prioritised.
Exactly. LPs probably need very little reward (if any at all) at all for tier2 liquidity because each time one of these order gets filled they are making a profit from spread, as @woolly_sammoth said .
yep.
yes, it is capable of reporting it.
There is now a delay, a bit more sophisticated than described but still very static and rudimental.
This very specific question - i.e. how often should T1 walls be replenished after (partial) depletion? - it is what I hope we can implement with the next scheduled milestone in the roadmap : market-adaptive orderbooks (0.3.3) .
This dynamic is very interesting and must take into account multiple factors.