How do you specify this liquidity to belong to t2 in the first place?
This is the combined T1 and T2 liquidity reported by that NuBot (sum(T1+T2)).
If you want to see the T1 and the T2 details, use getliquiditydetails instead of getliquidityinfo.
The output unfortunately is crowded and I don’t know how to remove former sessions. NuBot seems to not remove them automatically (I don’t even know whether the can be removed).
The current session is 0.3.2a_1453183358209_90b9fb.
The details for that are:
nud getliquiditydetails B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 300 | grep 0.3.2a_1453183358209_90b9fb -A 2
"1:NBTBTC:poloniex:0.3.2a_1453183358209_90b9fb" : {
"buy" : 2000.0,
"sell" : 2000.0
--
"2:NBTBTC:poloniex:0.3.2a_1453183358209_90b9fb" : {
"buy" : 7342.78,
"sell" : 9917.1642
1 Like
By the way is T2 put on order away from the peg center in the parametric order book scheme or it isn’t (only sitting on exchange)? In order words what s the definition of T2 now?
It needs to defined anew:
In the case of the Poloniex NuBot, the T2 is on exchange, but off the order book.
Parametric order book is effectively disabled.
1 Like
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?