So the most robust way for Alix in order to get T2 liquidity for each exchange would be to ask each provider to submit its liquidity and the id of the exchange on which it operates…
What is the issue with enabling parametric order book?
So the most robust way for Alix in order to get T2 liquidity for each exchange would be to ask each provider to submit its liquidity and the id of the exchange on which it operates…
What is the issue with enabling parametric order book?
Hi @cryptog
The current total liquidity in the Nu network is:
Bid: 51356.2149 NBT (39.18%)
Ask: 79737.2964 NBT (60.82%)
It is broken down in the following manner:
Tier 1:
Bid: 13366.9561 NBT
Ask: 22299.2472 NBT
Tier 2:
Bid: 14020.43 NBT
Ask: 28424.0492 NBT
Tier 3:
Bid: 23967.3288 NBT
Ask: 29014.0 NBT
Apparently Nu needs at least 10k on Tier1 and 10k on Tier 2 buy side in order to get rebalanced.
In the long term, if NuLagoon tube has enough volume it will need rebalancing to maximize profit. Moreover, without FLOT, I imagine that you could only sustain the balance between pools C and D by purchasing from the open market, which is costly. Further more, when balancing is needed and NBT is sold to NuLagoon, this NBT would likely change hands quickly and give you revenue.
Given this, in theory it is possible for Nu to sell NBT like this at a slight profit, especially when there are multiple services like yours competing for tier 4 liquidity. Though admittedly we haven’t yet reached that stage.
FLOT activities have been rather improvised but regular dealings like this require more discussion among FLOT members, and eventually it needs to be escalated to a motion vote.
It’s not very good use of our time to argue for the 60NBT extra cost in this potential transaction, but this is a precedent, and lines should be drawn.
Personally, in order to support the initiative and until tier 4 operates at a better consistency, NuLagoon can have a say in deciding a low-risk trading price, which may or may not be the 0.4% spread right now, but there should be a monthly or quarterly (possibly partial) refund of exchange fees.
Hi @dysconnect
The current total liquidity in the Nu network is:
Bid: 58707.5966 NBT (43.14%)
Ask: 77372.8371 NBT (56.86%)
It is broken down in the following manner:
Tier 1:
Bid: 15613.8678 NBT
Ask: 24918.9799 NBT
Tier 2:
Bid: 19124.9 NBT
Ask: 23439.8572 NBT
Tier 3:
Bid: 23967.3288 NBT
Ask: 29014.0 NBT
Hi @dysconnect
The current total liquidity in the Nu network is:
Bid: 59554.7164 NBT (46.06%)
Ask: 69756.6593 NBT (53.94%)
It is broken down in the following manner:
Tier 1:
Bid: 14710.7143 NBT
Ask: 24973.7687 NBT
Tier 2:
Bid: 21061.19 NBT
Ask: 15768.8906 NBT
Tier 3:
Bid: 23781.3121 NBT
Ask: 29014.0 NBT
The issue is increased risk, because more funds are put into orders.
That’s pretty much the only thing I worry about and decided to limit the order size.
If more funds than 1,000 USD value are put in orders at the same time, they will be there in case NuBot crashes, gets unresponsive, loses the internet connection, has trouble with Poloniex’ API, etc.
The orders will stay placed until they are deleted.
If the BTC price moves while the orders can’t be deleted (and placed anew) for whatever reason, Nu might lose money.
I thought about it for some time and came to the conclusion that a broken peg (and low funds on Poloniex is the only reason to use one of the gateways) might be more harmful for Nu than some funds that are not sold at optimal prices.
Even if the orders were sold at a few percent below current market price, the economical damage would still be only a few percent of the funds on orders.
And in the best case they are sold at ALP clients running on the other side. That would still be a loss for Nu, but a gain for valuable service providers.
My experience so far with NuBot on a RaspberryPi2 has been overwehelming - it runs like a charm.
That was another reason to dare increasing the order sizes.
I adjusted the configuration of the sell side gateway to:
"bookSellwall": 2000.0,
"bookSellOffset": 0.005,
"bookSellInterval": 0.002,
"bookSellMaxVolumeCumulative" : 6000,
"bookSellType": "lin",
"bookSellSteepness": "low",
And the buy side gateway to:
"bookBuywall": 2000.0,
"bookBuyOffset": 0.005,
"bookBuyInterval": 0.002,
"bookBuyMaxVolumeCumulative" : 6000,
"bookBuyType": "lin",
"bookBuySteepness": "low"
This should place (up to) 3 orders (depending on available funds) sized 2,000 USD value.
The first one has an offset of 0.005 USD value.
The next order an offset of 0.005 + 0.002 = 0.007 USD value (linear order book).
And the last order an offset of 0.007 + 0.002 = 0.009 USD value.
This puts a total of 6,000 USD value at risk of losing some percent if something goes per-shaped.
If anybody has serious ojections, please tell me.
Documentation of NuBot settings is available here:
https://bitbucket.org/JordanLeePeershares/nubottrading/src/7dea551e0794f102b8bc904268e4c42e6e48b064/docs/SETUP.md?at=master
You mean that they will be deleted by nubot during restart phase following a time interval.
It also would be nice if the exchange it self had that option. Then the bot crash risk would be eliminated
since the order will be deleted anyway!
But i don’t see this time limited order feature in Polo, i will sent them a request
Orders will be deleted by NuBot as soon as the BTC price moved enough to require a new price.
That needs to be supported by NuBot as well. Even if it were a general (Poloniex) account setting that deletes orders after a configured time passed by, it might mess up NuBot if NuBot isn’t aware of that.
The idea is good. I doubt it’s possible to use it in a meaningful way at the moment.
I feel the risk of loss due to nubot parametric order book malfunctioning is very small compared to the risk of loss due to exchange default.
NuBot proved to work remarkably stable.
@desrever has created a very sophisticated piece of software!
The risk I sense originates not from the parametric order book, but from the increased amount of funds on orders at the same time.
As you can see I reassessed that risk and increased the total amount of funds the gateway NuBots put on orders as well as I enabled parametric order book functions.
It’s the difference between T1 risk and T2 risk. I agree that T3 to T2 (placing funds on exchange) is a much bigger step than T2 to T1 (placing funds on order), but we should not turn a blind eye to MoD’s risk analysis for T2 vrs T1, it is non-negligible in my opinion.
Overall liquidity: https://raw.coinerella.com/?liquidity and liquidity given by qt do not match. Which one to trust?
Hi @huafei
The current total liquidity in the Nu network is:
Bid: 68184.9908 NBT (48.95%)
Ask: 71117.429 NBT (51.05%)
It is broken down in the following manner:
Tier 1:
Bid: 15789.443 NBT
Ask: 26477.2861 NBT
Tier 2:
Bid: 28636.15 NBT
Ask: 15626.1429 NBT
Tier 3:
Bid: 23757.8978 NBT
Ask: 29014.0 NBT
qt first