@assistant liquidity
The current total liquidity in the Nu network is:
Bid: 86462.607 NBT
Ask: 47041.0429 NBT
It is broken down in the following manner:
Bid: 0.0 NBT
Ask: 6500.0 NBT
Tier 2:
Bid: 0.89 NBT
Ask: 10189.3335 NBT
Tier 3:
Bid: 6234.6475 NBT
Ask: 27711.382 NBT```Hey, I was once again faster that this lazy assistant of yours!
You should either fire him or make him (or her?) do what he is getting paid for.
Wait a second: do you compensate him fairly for his efforts?
Iām afraid he might join a union and weāll face more times without a working assistant in that caseā¦
1 Like
Itās an entirely weird bug. Assistant just has a blind spot for @huafei. Iām not sure if itās because Assistant can only see accounts that are older than a certain threshold or what but mentions donāt even show up in the logs as being caught.
The current total liquidity in the Nu network is:
Bid: 88262.336 NBT
Ask: 48605.6256 NBT
It is broken down in the following manner:
Bid: 0.0 NBT
Ask: 6500.0 NBT
Tier 2:
Bid: 0.9 NBT
Ask: 10189.3335 NBT
Tier 3:
Bid: 6234.6475 NBT
Ask: 27711.382 NBT```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