Current Liquidity

cryptog 2016-01-19 13:57:16 UTC #1168

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?

Nagalim 2016-01-19 14:10:05 UTC #1169

We need to adjust tier1 and tier2 definition

masterOfDisaster 2016-01-19 14:35:26 UTC #1170

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.

Nagalim 2016-01-19 15:42:11 UTC #1171

T2 is anything over 5% or off the order book.

willy 2016-01-19 17:47:41 UTC #1172

What’s T3 then?

Off exchange, ready to be converted to T1.Best within x minutes?

masterOfDisaster 2016-01-19 18:26:38 UTC #1173

The definition of T3 hasn’t been changed.

That!

Have a look here:

Nagalim 2016-01-19 20:13:56 UTC #1174

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.

masterOfDisaster 2016-01-19 20:30:08 UTC #1175

Not only according to your definition!
According to Finalized evolution of liquidity operations it’s de facto T3.

Your efforts are highly appreciated!

Nagalim 2016-01-19 20:34:30 UTC #1176

JL defines T4 as:

But then I think we’ll find that the phrase ‘liquidity operations’ lacks definition.

masterOfDisaster 2016-01-19 20:55:36 UTC #1177

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

cryptog 2016-01-19 22:00:17 UTC #1178

I think this is the consensus on t2.
Is it actually what liquidityinfo reports?

Nagalim 2016-01-19 22:18:54 UTC #1179

You mean is it what NuBot reports. I believe that is the intent, yes.

masterOfDisaster 2016-01-19 22:21:50 UTC #1180

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.2544

edit: 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

woolly_sammoth 2016-01-20 07:02:37 UTC #1181

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?

[Discussion] Liquidity operations - a paradigm shift

masterOfDisaster 2016-01-20 07:07:30 UTC #1182

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.

woolly_sammoth 2016-01-20 07:10:50 UTC #1183

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

masterOfDisaster 2016-01-20 07:41:26 UTC #1184

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.

cryptog 2016-01-20 07:52:15 UTC #1185

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?

cryptog 2016-01-20 07:52:28 UTC #1186

Nice overall.

masterOfDisaster 2016-01-20 08:01:00 UTC #1187

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.