Current Liquidity

Liquidity
#1616

I realized I had liquidity broadcast issues with my NuBot at hitBTC.
They have been fixed.

[Liquidity; ALix T1 + gateways (poloniex dual side, numerous sell side)](https://gist.github.co

m/Lamz0rNewb/a76776a50fa8476667ea):

Gateway status at Poloniex (dual side), NuLagoon MLP at Poloniex and several sell side only exchanges

Thu May  5 20:07:38 UTC 2016
status of mOD dual side NuBot at Poloniex:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
        "BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
            "buy" : 0.0,
            "sell" : 0.0
status of zoro dual side NuBot at Poloniex:
nud getliquidityinfo B | grep BJs4YbtaqCmxeHLiR6zzjnZEotYVFAPfMo -A 2
        "BJs4YbtaqCmxeHLiR6zzjnZEotYVFAPfMo" : {
            "buy" : 4660.55,
            "sell" : 14940.5999
status of Cybnate dual side PyBot at Poloniex:
nud getliquiditydetails B | grep B954pkUEdkeT1G5Lq14Cisij5no3RVxHYe -A 20 | grep poloniex -A 2
        "1:NBTBTC:poloniex:LiquidBits" : {
            "buy" : 3425.7193,
            "sell" : 1800.0
status of Cybnate dual side PyBot at Bittrex:
nud getliquiditydetails B | grep B954pkUEdkeT1G5Lq14Cisij5no3RVxHYe -A 20 | grep bittrex -A 2
        "1:NBTBTC:bittrex:LiquidBits" : {
            "buy" : 0.6424,
            "sell" : 1000.0
status of NuLagoon dual side NuBot at Poloniex:
nud getliquiditydetails B | grep BTRnV9uLSPVJw4jn1JMV2Ki2cfFqPYip9o -A 1000 | grep poloniex -A 2 | tail -n 1  | awk -F':' ... and some more stuff
        "1:NBTBTC:poloniex:0.3.2a_1462463616850_e64628" : {
            "buy" : 201.1412,
            "sell" : 10399.162
--
        "2:NBTBTC:poloniex:0.3.2a_1462463616850_e64628" : {
            "buy" : 0.01,
            "sell" : 0.0
status of huafei sell side only NuBot at bter
nud getliquidityinfo B | grep BRUuKfGur7CZSLy65gYUPJUQyQZeT1XQnD -A 2
        "BRUuKfGur7CZSLy65gYUPJUQyQZeT1XQnD" : {
            "buy" : 224.98,
            "sell" : 1795.9565
status of mOD single side NuBot at hitbtc:
nud getliquiditydetails B | grep BETwD8nSjtj9ADSvej2na34xmsMYwPRymv -A 1000 | grep hitbtc | tail -n 1 | awk -F':' ...and some more stuff'
        "1:NBTBTC:hitbtc:0.4.1_1462478491791_6fb569" : {
            "buy" : 0.0,
            "sell" : 500.0
--
        "2:NBTBTC:hitbtc:0.4.1_1462478491791_6fb569" : {
            "buy" : 0.13,
            "sell" : 1499.876
#1617

ALP buy side has some overweight.
This is by and large compensated by Nu funded bots.
Anyway it might soon be time to trade some NBT for BTC.

What do you think?
FLOT could trade, say 7,000 NBT to 15.x BTC at NuLagoon Tube.

Liquidity; ALix T1 + gateways (poloniex dual side, numerous sell side):

1 Like
#1618

i agree.

#1619

the imbalance is really on the poloniex part.

#1620

Tube is balanced. Getting funds into the hands of nupool providers can be difficult. T3 custodians would work fine, but i havent had anybody come forward recently. Other options include having a gateway use a tighter spread than nupool on ask side in order to inject funds. Or we could hope NuLagoon figures out a method.

#1621

zoro’s gateway has about 9k NBT not on orders. By MoD’s summary the liquidity balance isn’t really in critical region. But FLOT’s buy side can use some BTC. It’s probably good to ask gate operators to put more NBT on orders

#1622

can there be a gateway that instead of putting funds on order books, puts fund in pools? We must have talked about this before.

#1623

What would be the purpose? Pools only exist for the economic incentive to lending liquidity. Nubots can be run independently as gateways without a pool. If we just reduce the spread we can use gateways to inject by undercutting unconscious nupool participants. As conscious participants want to remain on the injection side anyway for the higher profits, they also will allow the injection to occur, and may even buy some from the gateway to put into nupool at a higher spread + alp compensation.

Gateways could make use of the shift parameter i introduced in pybot. Basically when a gateway is buy side heavy it will reduce the buy side offset and when it’s ask heavy it reduces ask offset. We can talk about automation methods, another way to do it would be to just have three states, passive and actively injecting nbt or btc. Let the operator flick a switch to begin injection of nbt or btc by reducing the offset of that side.

1 Like
#1624

you answered yourself:

Putting funds in the pool SAVES you from adjusting spread. You reuse the pool’s spread forming mechanism (Dutch auction or fixed cost). There is no telling whose fund is whose to other pool members.

The drawback might be that the custodian for this has room to deal under the table as the liquidity cannot be reported.

#1625

Fixed cost is a reward scheme not a spread mechanism. Whether i run nubot to point at the alp server or not the spread is based on parameters set in the config file (or streamers or whatever). This is independent of the alp server.

Shift on pybot, for example, was a pure client-side change. The actual alp server was not involved at all and could have been paying out 0 nbt, shift would work just the same.

#1626

What you are talking here was the first iteration of the NuBots I designed for Poloniex.
They were a sell side only and a buy side only bot.
The idea was to use them for supporting weak sides and balancing the liquidity in doing that.

Operating them proved to be very tiresome, because they had for some time the only liquidity at Poloniex.
Operating them in addition to the dual side bots, which run with huge spread (and with an economically more reliable NuPool), should be fairly simple.
Just select a spread close to (but slightly above) the one of ALP and you can inject or remove NBT to/from the market over time.

I could set such a NuBot up easily, but had to do that based on motions from months ago in which I offered those gateways for free.
I think I’m rather going to propose a new motion.

#1627

Right but no need to make this a separate account or instance of nubot. For now, you can just restart nubot with a different set of parameters each time you want to change states. So basically, the single dual side gateway you operate has 3 allowed states:

  1. X% offset on both
  2. Y% offset on bid, X% on ask
  3. Y% offset on ask, X% on bid

Where X is like 1.5 and Y is like 0.5. Operator is trusted to change between the states at will.

#1628

Thanks for telling me what fixed cost is. One can certainly set a reward scheme so that spread is a factor in determining reward e.g. reward = side_cost / Sum (liquidity_at_spread_X/X )*normalization-factor . heck you don’t even need to set an artificial spread. the LPs will compete for lower spread

My point is despite the detailed mechanism of setting spread, the spread forms in a pool due to a combination of policy and economic laws. Putting funds in it reuses this spread. For example the order can be put on the low liquidity side in the middle of allowed spread range and Alix shows a balanced wall.

It’s just the old KTm shareholder paid cutodian. But 2.0 – with a pool. My point is that it has usefulness when you want even the sides of pools.

#1629

Agreed, but this requires very active management and discretion of the bot operator whereas a separate set of single side NuBots could only be used by discretion of FLOT.
I doubt that I will ever want to actively manage spreads again.

That!

#1630

You can do this without using the pool. Maybe I’m confused, I just don’t understand why you would want to put them in the pool. The only effect that would have would be to pay less to the people that have their funds on the injection side because you’d be paying a portion of the fixed cost to the gateway operator.

#1631

Using funds in a pool would reduce the incentive for CRFC ALP clients to move funds on the other (weak) side.
Another effect would be receiving compensation (from Nu) for using Nu funds.
This should be avoided.

If you offer funds slightly outside the ALP spread you avoid collisions, but enable ALP clients to trade funds and bolster up the weak pool side (to receive a bigger compensation per USD on pool) more conveniently than via NuLagoon Tube or T3 custodian.

#1632

Thats why I started talking about automation. The issue with making additional accounts is that they make the finances more complicated and introduce additional avenues of wasted liquidity. For example, funds on an injection gateway that are sitting waiting to be withdrawn and could be used in another gateway or in the core reserve. That is also active management because the operator has to withdraw it every time it’s used. If we can think of smart ways to combine passive and injection gateways, I think we can find a much lower bar for activity and participation in gateways while still retaining the ability to inject funds when we want to.

#1633

Work will have to be done to balance the sides. Someone has to pay for it. I think putting funds into the pool costs the least amount of extra work to balance the sides. So that has to be the most efficient way consider all factors.

Consider the details. I think a gateway ops costs more than an injected fund custodian because the latter can be paid by the liquidity he actually provided. For example a such costodian will only be compensated by a certain fraction of pool reward on the fund and once the balancing ops finishes he has to hand back the fund.

Nu can have an aution program to choose custodians who has the lowest “certain fraction”. If I am a pool LP why not make more using existing setups?

#1634

I see gateways e.g. @zoro have extra NBT not on orders. Perhaps we can put those on orders first

#1635

We have sell order on poloniex as follow. Don’t know why not captured by Alix
Sell 0.00223551 10399.16204687 23.24743074 05-06 15:45

We are using the following config setting.
“mainfeed”:“bitstamp”,
“backupfeeds”: [“bitfinex”, “coinbase”]
“bookSellOffset”: 0.0149,
“bookSellInterval”: 0.008,