@assistant liquidity
Hi @cryptog
The current total liquidity in the Nu network is:
Bid: 98878.8001 NBT
Ask: 62949.908 NBT
It is broken down in the following manner:
Bid: 6391.9908 NBT
Ask: 14052.9362 NBT
Tier 2:
Bid: 0.87 NBT
Ask: 10189.3335 NBT
Tier 3:
Bid: 7587.0923 NBT
Ask: 31072.702 NBT```Bid and Ask should be Ask and Bid in
Also, unknown tier is still not displayed but am i correct in thinking that it is 100% Tier1 liquidity?
Its 100% ALP, so yes, tier 1.
1 Like
well anyway:
- we have 87k on the buy side and 97k on the sell side.
But the daily volume is quite low comparatively: only 6.5k
Assuming that most of the demand for NuBits currently comes from hedgers, and assuming that in the worst case, this daily trade volume was caused by someone who sold 6.5k at once, we are offering at least 10 times what we should be on the buy side.
Of course, the more buy side liquidity the better because the hedgers’ demand could go up instantly if bitcoin drops suddenly in value.
But still, I think we are offering too much liquidity, right now.
Since it is more difficult to reduce the buy side liquidity rather than the sell side, I think we should be reducing the sell side liquidity now.
2 Likes
The tricky part is that we want to aim so that tier 1 + tier 2 correspond to some historical high volumes, so perhaps between 50k ~ 100k each side. For now I might agree to limit that to about 50k each, and aim to find a good way to manage tier 3 to compensate for the reduction.
For NuLagoon one can simply control compensation and regulate how much money should be maintained within different tiers.
For ALPs we can’t get any real tier 2 funds yet. The easiest thing we can do with current software is probably to set up separate compensation levels tied towards spread level, as I wanted to say in here (which was abandoned because I’ve since seen some action in the community). There may be some kind of mechanism that helps with this.
I’ll give an example.
Instead of only looking at proof of order placement, a client can have a pledge phase that shows it is willing to commit funds to liquidity. At the end of the pledge phase, the client should place an order, and give the proof the server. Then, the client enters the normal placement phase where it does what it does now. Then after some time it is allowed to retract the order and return to the pledge phase. During the placement phase, the server will pay the interest rate for the pledge phase (exchange risk) as well as the interest rate for the placement phase gradually.
If there can be proof of funds held on exchange then the pledge phase might be easy. Otherwise, it should be made short. However, if the aim is to have 10% funds in tier 1, then the placement phase should, given the same amount of funds, be 1/10 of the pledge phase in length. The server then tries to rotate between clients by a suitable schedule to ensure roughly 10% of funds are on order books, the risk and rewards are spread appropriate among clients, and that the funds that are not on order books can be used when needed.
There are many practical issues with this and many holes to be filled, but it could be a good starting point.
1 Like
Hi @cryptog
The current total liquidity in the Nu network is:
Bid: 100004.8099 NBT
Ask: 88173.991 NBT
It is broken down in the following manner:
Bid: 7945.4314 NBT
Ask: 11817.504 NBT
Tier 2:
Bid: 0.9 NBT
Ask: 10796.8686 NBT
Tier 3:
Bid: 17730.8173 NBT
Ask: 22789.152 NBT```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.