Thank you very much for your elaboration.
Now I understand the meaning of tier 1 and tier 2 in the NuBot world better.
It makes sense - as the funds are already on the exchange, why not put them in orders with a decent spread?
The arbitrage risk is lowered or even eliminated by that (if the spread is big enough, the LP will likely make money getting the funds traded instead of losing money) and the exchange default risk is the same whether the funds are in orders or just idling in the account.
And it contains a lot of promising information about the ALP integration that I can hardly wait to see the results.
It’s good to know that the proof of concept (which the ALP still is…) is now being unified with NuBot and built on sound development.
As much as I’m impressed about the robustness of this PoC so far I’m glad about the steps that are taken to pave the ground for automated liquidity pools becoming a big thing. Fixed payments instead of a dutch auction model are really much easier to understand; a database and a web framework, yeah!
The future of Nu must be bright considering this community and this development team!
I don’t think it would make a big difference in one of the bigger crashes BTC has been experiencing a couple of times a year. The dumper will just need to wait a few minutes longer to eat up both tiers.
This sort of enhances my point that there is no increased risk in thinning tier 1 as long as tier 2 is readily available - any problems we have then would still be a problem under current circumstances.
Either way the separation of interest payouts for different offset values has been something I’ve talked about for some time, and is a necessary feature when combining the parametric order book with ALP. It is great work by @woolly_sammoth. Somehow I further thought that giving yet an other separate interest rate for funds not even on the parametric order book serves some additional purpose, but now I’ve forgotten how I ended up with that.
But it seems that with the parametric order book, combined with the view that there’s no meaningful difference between tier 2 and tier 3 liquidity under BC exchange, it means our top 3 tiers of liquidity would really then become one single thing. We can consider that a huge step towards the final goal of reducing everything to just tier 6, that the value of NSR would be the most direct supporter of NBT.
Now that you brought it up, I think when ALP is deemed mature and decentralized enough, the role of park rates would greatly diminish as we can instead just let ALP pay out (small) interests for excess NBT. Though that kind of ALP requires a seamless integration with decentralized exchanges and our custodian grant system or parking transaction mechanism, so would be much further down the road. Tier 4 would then become a sort of managing body of the Nu network, pointing resources to the right places when needed.
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 .
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.
I am not sure it is, I see the oracle more as a source of truth that does nothing but provide information for other bots to consume. Your super bot also acts and place orders and holds funds. Is it correct?
A “suggesting oracle” can be easily added to the existing streamer which is now used by bots to read price suggestion and clocks ticks for shifts
EDIT: the Streamer has been Indeed designed to support multiple kinds of messages at protocol level, so it will be as easy as adding a new message type
Well, if NuNet is able to make sure that the cost of liquidity provision is less and less (because of BC_Exchange, fixed cost ALPs, parametric order book) while at the same time attracting more and more providers looking for low but steady revenues (a bit like that bitcoin mining currently), we can bet that the sales of NuBits (our primary source of revenue) will outweigh our costs. At that point in time, we will have created a strong confidence in the peg and NuShares’s price will be high.
the ideal would be to have a “skynet”-like NU network that can monitor real time the liquidity and decide
when there is a need to generate more NBT or burn them instantly and automatically!
no need for MLP or ALP. the perfect DAO. but this could take ages to be made.
(yes, i 've watched the latest terminator movie )
Right. But the fund allocation part of superbot doesn’t have to exist if the pools can somehow roll their surplus/deficit to the next term, when shareholders will decide which pool gets how much fund. Only the oracle function is essential. (By the way the superbot doesn’t place orders, it gradually distributes funds to pool’s wallets, according to pool performance, before a term ends).
The buy side liquidity should decrease by 10k every month at least, when contractors and liquidity providers paid in nubits cash out their nubits (hypothesis H).
However it does not seem so.
In fact, the buy side liquidity has more than double compared to 2 months ago.
So it means that there are more and more providers that actually provide buy side liquidity to offset H.