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.
For the record: without the NuBots running on Poloniex, there would be 0 buy side at the moment:
The marked orders are from the NuBots. The first order is already being reduced from initially $2,000:
@henry, can you move NuLagoon funds to the Poloniex buy side?
According to ALix there are BTC left on NuLagoon.
edit: I’m going to reduce the sell side offset of the former sell side NuBot even further (it’s the 3,000 order on the left side). Couldn’t get any BTC with an offset of 0.004 so far.
edit2:
NuBot is up with low sell side offset and immense buy side offset to drain BTC.
Except for the NuBot buy side support, there currently is none.
We need more redundancy. Just imagine a failure of my RaPis or my internet access!
How long will you rely on me?
How long will you accept that do what I do (violating the gateway operation terms to support the peg) without discussing it, alternatives, support?
I’m sounding stressed, because I am; please bear with me
It would be good to find a trade offer from an LP that tries to arrange a deal with our first (and sole) T3 custodian.
The nupool ALP is empty on buy side:
It would be good to see action from NuLagoon, which still has BTC left.
Anyway - NuBot is up:
10:14:47.927 [Strategy Secondary Task] WARN - Initializing strategy [c.n.n.s.S.StrategySecondaryPegTask:137]
10:14:47.932 [Strategy Secondary Task] INFO - setting up ordermanager [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegTask:138]
10:14:47.949 [Strategy Secondary Task] INFO - Sell-Wall size : : 0.0 NBT [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:538]
10:14:47.963 [Strategy Secondary Task] INFO - Buy-Wall size : : 0.0 NBT [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:543]
10:14:47.975 [pool-1-thread-1] WARN - Subscribing to websocket push updates from streamer @ tcp://stream.tradingbot.nu:5561 [c.n.n.s.Subscriber:103]
10:14:53.498 [Strategy Secondary Task] INFO - initOrders SELL [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:177]
10:14:55.011 [Strategy Secondary Task] WARN - Putting a cap on SELL liquidity available. [Total Balance : 14243.72156309 NBT ; capped @ 6000.0 NBT] [c.n.n.t.L.LiquidityDistributionModel:85]
10:14:55.025 [Strategy Secondary Task] INFO - SELL- OrderBook : ----- SELL-side order book :
1.002002,0.00264234,3000.0
SELL wall volume : 3000.0
SELL tier2 volume = 0.0 NBT
Total SELL volume = 3000.0 NBT
Best price :0.00264234 (1.0020017514$)
SELL balance left = 11243.72156309 NBT----- [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:227]
10:14:55.031 [Strategy Secondary Task] INFO - Trying to place 1 orders... [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:228]
10:14:55.393 [Strategy Secondary Task] INFO - SELL wall order updated. ID : 1205522333 size: 3000.0 [com.nubits.nubot.trading.TradeUtils:231]
10:14:55.430 [Strategy Secondary Task] WARN - **SELL** orders re-initialized on **poloniex** : 1/1 placed successfully
total amount placed : 3000.0
Tier1 order size : 3000.0
Tier2 cumulative order size : 0.0 (0 orders)
[c.n.n.s.S.StrategySecondaryPegUtils:246]
10:14:59.412 [checkNud] INFO - Executing class com.nubits.nubot.tasks.CheckNudTask [com.nubits.nubot.tasks.CheckNudTask:37]
10:15:29.405 [checkNud] INFO - Executing class com.nubits.nubot.tasks.CheckNudTask [com.nubits.nubot.tasks.CheckNudTask:37]
10:15:59.409 [checkNud] INFO - Executing class com.nubits.nubot.tasks.CheckNudTask [com.nubits.nubot.tasks.CheckNudTask:37]
10:16:08.757 [Strategy Secondary Task] INFO - Order placed = OrderToPlace{type=SELL, pair=nbtbtc, size=3000.0, price=0.00264234} [com.nubits.nubot.models.MultipleOrdersResponse:88]
10:16:08.765 [Strategy Secondary Task] INFO - Order ID = 1205522333
[com.nubits.nubot.models.MultipleOrdersResponse:89]
10:16:08.776 [Strategy Secondary Task] INFO - initOrders BUY [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:177]
10:16:14.915 [Strategy Secondary Task] WARN - Putting a cap on BUY liquidity available. [Total Balance : 22.59977556 BTC ; capped @ 15.82236755 BTC] [c.n.n.t.L.LiquidityDistributionModel:85]
10:16:14.922 [Strategy Secondary Task] INFO - BUY- OrderBook : ----- BUY-side order book :
0.981998,0.00258959,1500.0
BUY wall volume : 1500.0
BUY tier2 volume = 0.0 NBT
Total BUY volume = 1500.0 NBT
Best price :0.00258959 (0.9819984239$)
BUY balance left = 7070.06089011 NBT----- [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:227]
10:16:14.927 [Strategy Secondary Task] INFO - Trying to place 1 orders... [com.nubits.nubot.strategy.Secondary.StrategySecondaryPegUtils:228]
10:16:15.336 [Strategy Secondary Task] INFO - BUY wall order updated. ID : 1205533322 size: 1500.0 [com.nubits.nubot.trading.TradeUtils:231]
10:16:15.348 [Strategy Secondary Task] WARN - **BUY** orders re-initialized on **poloniex** : 1/1 placed successfully
total amount placed : 1500.0
Tier1 order size : 1500.0
Tier2 cumulative order size : 0.0 (0 orders)
[c.n.n.s.S.StrategySecondaryPegUtils:246]Poloniex looks like this now:
The 3,000 sell order at 0.00264234 is from one NuBot (former sell side gw).
The 2,000 sell order at 0.00266607 is from the other one (former buy side gw).
The 1,500 buy order at 0.00258959 is from one NuBot (former sell side gw).
The 2,000 buy order at 0.00260805 is from the other one (former buy side gw).
In case this was overlooked:
We need additional NuBot operators on Poloniex. Soon.
As long as I’m away, I can’t maintain the NuBot. It will run with the last startup config as long as it runs. If the SD card is over a threshold due to the verbose logs from NuBot, nud crashes and the liquidity broadcast stops. I don’t know what happens to NuBot, if the SD card has 0 space left. Maybe it crashes as well.
Funds still can be deposited on the side that’s about to run dry. I won’t be able to withdraw funds from Poloniex, though. Putting more and more funds into the Poloniex account increases the risk, step by step.
I strongly advise agaist doing that!
Sorry for the drama, but the current situation isn’t sustainable.
And we can considerus “lucky”, that due to the de facto centralization of the current liquidity operation, we only need to focus on one exchange.
We could lean back and state that as long as NuLagoon Tube offers 1 NBT at 1 USD (plus spread), the peg is kept. Customers might think differently.
2 Likes
I can setup a dual side nubot for Polo in order to be used by FLOT, like MoD did.
I guess i will need a motion or grant?
The only thing i have to learn is how to submit liquidity (in win7 64 with NU wallet)
and to apply for a credential token since i use it without one right now.
2 Likes
Submitting liquidity is done by nubot. Just get a grant passed and feed nubot your grant address and itll do it all for you.
You need settings like
daemon=1
server=1
port=9090
rpcport=9091
rpcuser=yourUserGoesHere
rpcpassword=yourPasswordGoesHerein nu.conf and a NuBot configuration according to these parameters.
Exactly!
Please do Nu, me and yourself a favour and don’t offer your services cheaply.
Until friction issues have been sorted out, dynamic offset is available, etc., you might have more work than you like, if you really intend to do all youo can to support the peg.
Your computer needs to be on 24x7, which will create some noise and costs in addition.
As long as gateways or dual side NuBots are available for free (or cheaply), NSR holders are tempted to make the ostensible cheap, but very risky choice of relying on them.
Make a bold offer, it should still be accepted, if NSR holders are wise.
There are times ahead, in which I won’t be available.
Nu needs a backup!
Fixed cost ALP based on NuBot need to provided with sufficient funding to compensate LP in these pools.
Ostensibl cheap NuBots, run with Nu funds, must not hinder that.
It’s two hours ago since I was last pinging people, alarming about the situation, adjusting NuBot configuration to support Poloniex liquidity.
The orders sized 2,000 and 1,5000 are still pretty much the only ones on the buy side:
nupool buy side is empty:
Believe me, operating with Nu funds at an exchange is more demanding than you might realize before you have started doing it, especially, because it’s way off from an emergency solution at the moment - or we are in permanent emergency; I don’t know.
The only good thing is, that it seems to be worth it:
3 Likes
I then have to prepare a grant and ask for a payment. But please give me a hint what would be a proper operator payment
in this situation since i will not use my own funds.
edit: i just checked your grant and “Compensation scheme”