where are these stats coming from and how?
i see that only in Poloniex tier 1+tier2 = 18k ask and 18k bid !!!
These stats are retrieved from the Nu daemon that assistant connects to
NuBot is capable of tracking (and reporting?!) tier 1 and tier 2 liquidity. This is a screenshot of NuBot’s web GUI:
It’s from a test run of nubot-v0.3.2-RC7.
NuBots and fixed cost liquidity in general help getting tier 1 volume on a desired level.
Tracking of tier 1 and 2 helps finding out when action on tier 4-6 is required.
The compensation for tier 1 just needs to be as high as the market demands for a liquidity volume of X.
The flow from and to higher tiers will be steered by the amount of compensation that is paid for tier 1 liquidity providing.
I don’t really think that tier 2 needs to controlled directly. It should be enough to control tier 1 by incentives. Or do I just lack comprehension?
2 Likes
What I want is a thin tier 1 but a thicker tier 2 for BTC/NBT and pools can pay separate interests for funds in both tiers, reducing costs. I think we really only need say 5k walls on poloniex, 1k walls on bittrex and even smaller walls for most other exchanges, and those are directly exposed to volatility risk.
Ideally, when the thin tier 1 walls are filled, some tier 2 funds would be promoted to tier 1 very quickly, so if one wants to make a big dump he only has to wait a bit longer, and there would be deep enough liquidity right on the wall for most days. We can afford larger walls for NBT/fiat.
Thus a BTC/NBT pool should aim to have an adequate level of tier 1 + tier 2 liquidity and design mechanisms so that participants would be willing to put a large amount of funds with a fraction of it on the order books for most of the time.
2 Likes
Now I get it.
Sounds great!
Maybe @desrever can share his thoughts about whether that can be achieved by NuBot.
I think NuBot might already be capable of exactly that - putting only a part of the funds in tier 1 while reporting tier 1 and 2.
The config parameters of NuBot include (amongst other parameters; the “->” are put there by me):
-> "bookDisabletier2": false,
-> "bookSellwall": 10.0,
"bookSellOffset": 0.01,
"bookSellInterval": 0.015,
"bookSellMaxVolumeCumulative" : 0,
"bookSellType": "exp",
"bookSellSteepness": "low",
-> "bookBuywall": 10.0,
"bookBuyOffset": 0.042,
"bookBuyInterval": 0.015,
"bookBuyMaxVolumeCumulative" : 0,
"bookBuyType": "log",
"bookBuySteepness": "low"Achieving that with ALP might be harder, but as far as I’m aware of @woolly_sammoth is working of a NuBot integration of the PyBot that was created by @creon and that is used for current ALP operations.
If NuBot were capable of providing a thin tier 1 liquidity and a thicker tier2 liquidity while ALP operations would focus on tier 1 solely, it wouldn’t be bad at all - don’t you think?
2 Likes
The basic idea as I understand it is that tier 1 becomes the orders placed immediately either side of the $1 mark. Tier 2 becomes liquidity which is still on order but further away from the $1 mark. As per this image from @desrever
https://discuss.nubits.com/uploads/default/_optimized/be4/c55/e8c348fb65_690x341.png
This allows for people to still buy and sell relatively small amounts of NBT at $1 but penalises those who wish to dump or buy large amounts by either making them pay more or receive less, or wait until the bots re-balance the books. The re-balancing will be done almost continuously but there will be a delay of perhaps 30 seconds between a large order being filled and the books re-ordering to the defined shape.
From an operator perspective, the funds in tier 1 (the smaller orders very close to $1) will not make profit and so it is these orders that will be compensated by the ALP/NuBot server I’m currently working on. Orders further into tier 2 (further away from the peg) will generate some profit for the operator as they are filled so will not be compensated by the ALP.
I’ve been integrating NuBot into the ALP client with some success and have turned my attention to the server portion of the ALP software. While the server built by creon is a very solid system it was only ever billed as a proof of concept. It is very obvious looking at the code that it’s a Python app written by a C++ developer. It works but has been a bit of a nightmare to maintain till now.
I have put a good amount of effort into rebuilding the server software and have taken the opportunity to add features that were missing. I’m using a proper HTTP framework as the base of the server (Bottle in this case) and have added a database for persistence rather than holding all the orders, credits, and other workings of the server in memory. I’m also switching the compensation method to the fixed payments method suggested by @Nagalim as it strikes me as a fairer system. It’s easier for everyone to understand, it’s easier to code and, if I’m honest, I still don’t completely understand creons implementation of the dutch auction system currently being used. I understand the theory and intent but that doesn’t seem to always match the code.
Using the database and web framework will also allow for things like user pages so you can see a history of your credited orders and pool payouts. It also makes it more extensible so that features can be added more quickly and it can scale to a multi server architecture with very few changes should Liquidity pools become a big thing (I’m still hoping)
I’ll update again when I’m closer to having something decent to show
9 Likes
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!
2 Likes
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.
2 Likes
Everybody’s always hating on tier 5.
2 Likes
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.
Except tier 2 allows sophisticated algorithm/strategies to be used to control when the fund shows up in the order book.
… if one ignores exchange risk (~50% chance of total fund loss per year I’d say). Risk adjusted return of park interest is very attractive.
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.
4 Likes
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.
1 Like
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 
)
1 Like
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).
2 Likes
Hi @huafei
The current total liquidity in the Nu network is:
Bid: 99388.5169 NBT
Ask: 79739.3896 NBT
It is broken down in the following manner:
Bid: 34767.5387 NBT
Ask: 49354.5038 NBT
Tier 2:
Bid: 3397.48 NBT
Ask: 11227.9972 NBT
Tier 3:
Bid: 17142.29 NBT
Ask: 22089.0 NBT```
1 Like