T2 is anything over 5% or off the order book.
2 Likes
What’s T3 then?
Off exchange, ready to be converted to T1.Best within x minutes?
The definition of T3 hasn’t been changed.
That!
Have a look here: 
1 Like
T3 tends to be a specific address where you can just look at the balance of the address to verify the reported T3 liquidity. The type of contract is another story, but as far as what defines liquidity as T3 is that of a contracted address that is not controlled by a Nu elected multisig. According to my definition, technically JL’s BTC address is T3 not T4. That was in fact my starting point for trying to make the trusted T3 grant: attempting to emulate and scale up what JL was doing.
3 Likes
Not only according to your definition!
According to Finalized evolution of liquidity operations it’s de facto T3.
Your efforts are highly appreciated!
JL defines T4 as:
But then I think we’ll find that the phrase ‘liquidity operations’ lacks definition.
I interpret it as “not directly involved in liquidity operations”.
After all, the whole Nu network (T1-T6) is dedicated to liquidity operations - that’s all what Nu’s about 
I think this is the consensus on t2.
Is it actually what liquidityinfo reports?
You mean is it what NuBot reports. I believe that is the intent, yes.
No. Normally yes, but not necessarily. Here’s why:
Liquidityinfo reports what’s broadcast by custodial addresses.
T1 is treated and reported as funds “on order” no matter what offset (even if the spread is above 5%) - @desrever, you might correct me if I’m wrong!
I wrote “on order” in quotation marks, because NuBot can be configured to put T2 funds on order as well, but with an insane spread; they are still not treated as T1 then.
Have a look here and read the details of the parameter “bookDisabletier2”.
T1 orders by NuBot aren’t necessarily within 5% spread (although they should be way below).
T2 is either off the order books or on order, but with a spread that should be far above 5%.
ALix in difference reports, what’s on the order books. That’s why ALix is so valuable!
The NuBots on Poloniex run currently with an offset of (0.009, 0.009) and (0.015, 0.015), because both exchange accounts are quite balanced and the offset reduces the hedging risk while still offering a defense layer for the peg.
I’m going to withdraw more funds from the Poloniex accounts after as the withdrawal limit has been reset.
Status:
Tue Jan 19 22:21:27 UTC 2016
status of sell side gateway:
nud getliquidityinfo B | grep BETwD8nSjtj9ADSvej2na34xmsMYwPRymv -A 2
"BETwD8nSjtj9ADSvej2na34xmsMYwPRymv" : {
"buy" : 8544.3,
"sell" : 14295.3766
status of buy side gateway:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
"BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
"buy" : 9342.79,
"sell" : 11919.2544edit: if you look at ALix, you might be glad about $18,000 available to Poloniex NuBots to support the buy side if need be - although the lines of defense created by their spread will not ensure a very tight peg.
The offset of the first line of defense is close to 1%, the scond line has 1.5%.
I will need to investigate (together with @desrever), why priceincrement doesn’t work and only one order (per side) gets placed.
A parametric order book would be so nice
Morning all. I’d like to wade into the liquidity tier definition debate.
What I’ve done with ALP v2 is keep the traditional tier definitions (tier 2 is funds on exchange but not actively on order). Tier 1 has been split into “ranks” with rank 1 being the funds directly supporting the peg and rank 2 being all other funds on order.
That is the model for the initial release, the code does allow for many more ranks in tier 1 and for those ranks to have individual tolerances and rewards. In the future, that should allow for parametric reward distribution to help target liquidity where it is needed within tier 1.
For reporting this liquidity, I need to do some testing but, I would like to use the dot notation mentioned in the post by @desrever. liquidity tier 1.1 would be funds on order, directly supporting the peg (tier 1, rank 1). Tier 1.2 would be tier 1, rank 2 and so on. I’m not totally sure that nud will allow a Decimal in the tier descriptor when sending liquidity. If it doesnt I will put the rank (and tolerance of the rank?) In the liquidity identifier, currently set to just the pool name (or session id in NuBot).
How does that definition sound to everyone?
3 Likes
That sounds very fair! LPs who face more volatility risk, receive more compensation.
Sounds great.
Why not leaving the decimal stuff out and use 11 and 12 instead of 1.2, 1.2?
I think it’s more useful to find it at the beginning of the output rather than somewhere in between.
Good call on leaving the Decimal out. I’ll still test the dot but fall back to your suggestion if it fails. I will likely still put the tolerance of the rank in the identifier. The intention is for the pool software to be able to change the tolerance figures dynamically in response to changes in liquidity pressures. Being able to see the tolerance of the rank at that snapshot in time would be useful I think
That makes sense, but
this will create a whole lot of different liquidity identifiers in the network.
It would be amazing to record that (@willy: ALix? ) to learn from the recorded data how offsets and offset changes relate to the market situation.
Crazy idea:
We will learn that the offset needs to be bigger the steeper the change of BTCUSD price (upwards, downwards).
The offset could be tied to the first derivative of the function of BTCUSD price over time. Unfortunateily we don’t have that function and can only deal with it numerical.
Still the velocity of price change should in some way be reflected in the offsets.
In addition to the velocity, the balance between walls can play a role. For that reason I manually adjusted the offset of the dual side NuBot on Poloniex to prefer NBT sale to BTC sale:
"bookSellwall": 3000.0,
"bookSellOffset": 0.003,
"bookSellInterval": 0.002,
"bookSellMaxVolumeCumulative" : 6000,
"bookSellType": "log",
"bookSellSteepness": "low",
"bookBuywall": 1500.0,
"bookBuyOffset": 0.017,
"bookBuyInterval": 0.02,
"bookBuyMaxVolumeCumulative" : 6000,
"bookBuyType": "log",
"bookBuySteepness": "low"The buy side is degraded to a line of defense with a big offset. The sell side is quite close to the BTC price.
So basically you are putting the buy wall far away from the peg center compared to the sell wall in order to make traders reluctant to reverting back to bitcoin at this point?
Nice overall.
What about using colon as field separator?
nud is already able to handle that:
nud getliquiditydetails B | grep BETwD8nSjtj9ADSvej2na34xmsMYwPRymv -A 1
"BETwD8nSjtj9ADSvej2na34xmsMYwPRymv" : {
"1:NBTBTC:poloniex:0.3.2a_1449093980642_dd6880" : {Or is the number of fields, that can be separated by colon, limited to 4?
If we can make it 5, it could be:
{tier}:{rank}:{tradingPair}:{exchangeID}:{sessionID}
and I’d prefer having the tolerance in such a field to having it mingled in the session ID:
{tier}:{rank}:{tolderance}:{tradingPair}:{exchangeID}:{sessionID}
It makes dealing with the information easier, if you know the delimiter and don’t have to hope for finding it using regex;)
Right!
The buy wall is far enough off to make traders reluctant selling into it, if all walls before it (e.g. from ALP) fail, yes.
This will not prevent the price from being more than 1% off, but can delay (or even prevent) the price to be more off than the offset of the wall - it’s just a line of defense and no ordinary liquidity operation.
At the same I try to grab BTC by having a small sell side offset, which is still enough to make Nu money if traders buy NBT outside big volatility.
The former buy side gateway, which is now dual side as well, has symmetric offsets (0.009, 0.009), operates with in the 1% offset (2% spread) and comes in between ALP and the asymmetric NuBot.
In reply to (because it fits here better):
Sure. Have a look at my last post (in that other thread).
Partially correct. The former buy side bot has an offset of (0.009, 0.009). This is creating a SAF (including tolerance before the walls get shifted) of
0.9% + 0.2% + 0.1% = 1.2%
This is more SAF than desirable, but leaning on that suggestion
it’s still ok (and in fact quite close to 1%).
The idea is to slow down trading once all funds in the front line are consumed to save Nu some money by not being used for hedging excessvely and protecting the peg by hindering trade due to/at an increased offset.
With a not very close spread traders will think twice before buying into such a wall and I bet there are a lot of bots doing the trading there, which hopefully have thresholds to make them stop at such an uplift.
Not having a super close spread is the trade-off for saving money.
But I can’t predict the future. I don’t know whether that pans out.
I’d be highly interested in feedback!
1 Like
Correct: NuBot currently calls (and reports) tier1 liquidity as the amount of liquidity on the single order at the best price. Being the best price set by custodian via offset params, that could be well above and below 5%.
I am not going to change that until we have reached an agreement on it using the thread : We need to adjust tier1 and tier2 definition .
There is an open issue planned for 0.4.2 , so I hope we have this discussion soon. It’s not something I can decide alone.
Is this issue causing troubles?
It effectively disables the parametric order book and I tried to resemble that to some degree by running two NuBots (one with curent offset 0.009, 0.009, the other currently with offset 0.003, 0.017 to drain BTC; before it was 0.012, 0.012).
I’d appreciate having the configured
"priceincrement": 0.001,
in action, leading to orders with offset
0.009, 0.009
0.010, 0.010
0.011, 0.011
We can discuss this in private and post the results here, to not spam this thread with NuBot configuration issues.