gateways with collateral isn’t the same as MLP-ALP?
Of course!
But I wouldn’t be able to provide enough collateral to create a useful gateway.
Plus it would cost Nu some compensation if I had to lock funds as collateral.
Some of it might be true for each potential gateway operator.
The gateway idea is now over 6 weeks old.
Can you still count the number of proposals that deal with gateways?
Oh wait, it’s two - one for buy side and one for sell side; both from me.
And I still think they are valuable - even with no collateral provided by the operator.
In the end it always boils down to the question: which operation scheme is cheaper?
I have no answer to that question.
In the collateralized version it’s much like with ALP:
Nu pays a kind of insurance. With funds provided by Nu, Nu needs to take the risk.
Long-term the insurance can only pay off for Nu, if the business partner providing the insurance is making a loss.
In an ideal world the gateway wouldn’t have been used.
I’d like to point out that a gateway can be run passively, just like I’m doing T3. Thereby the operator would specify a maximum amount they would hold before withdrawing and simply collateralize that amount. The only difference then between a trusted T3 custodian and a dual-side gateway is whether the funds are kept on exchange with an open order or off-exchange with a running record of manual trades.
Right.
I might not be the typical gateway operator and these might not be ordinary times.
With the experience I gathered, it was a mistake to design them as gateways. They would have worked better, if being configured in dual side mode from the start, but with an asymmetric offset (like 0.007; 0.012, or vice versa).
That would have preferred NBT sale from the “NBT entry gateway” and BTC sale from the “NBT exit gateway” while not restricting the other side completely. That would have limited the rebound effect.
I’m sorry that I couldn’t realize that before designing them.
Also keep in mind that we are paying significantly less for that liquidity as it is mainly fiat focussed.
The NBT/BTC pair on e.g. Poloniex is heavily subsidized for a number of traders who earn good money and for some nice statistics on coinmarketcap.com. We need a paradigm change indeed!
to test and ascertain asap
Liquidity Providing must have a solid business proposition to attract new comers interested just in making money
Just in case somebody gets nervous looking at ALix:
The dual side NuBot (formerly known as “NBT exit” or buy side gateway) has 24 BTC, of which only $2,000 at a time are on order (with an offset of 0.009). So there’s a lot more buffer than the eye can see at first glance.
The liquidity is being broadcast. As long as it stays this ways, there is a defense layer:
status of buy side gateway:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
"BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
"buy" : 9342.79,
"sell" : 11919.2544
The buy side is low, because nupool can’t attract much ALP volume to Poloniex at the moment:
It does not seem to be broadcast as T2 into https://raw.coinerella.com/?liquidity.
Also, T1 in https://raw.coinerella.com/?liquidity does not match T1 in https://alix.coinerella.com/walls/?4h .
Why?
Edit:typo
Maybe coinerella isn’t gathering all T2 information?
Can you see that broadcast liquidity information?
I wouldn’t be surprised if this is the reason making people nervous about liquidity provision: [Outdated] (limited) Warning about Poloniex.
There’s now a ‘(limited)’ in the title (I took the liberty to add that after reports of successful withdraws surfaced) and there are lots of reports that the withdrawal works, albeit slower than usual.
The explanation might be closer to this:
in getliquidityinfo B, yes,
This data is coming straight from a nud which averages 50-60 connections.
Decentralized data gathering is a real issue when you need reliable data. You never know who will get which information at what time.
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
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.
T2 is anything over 5% or off the order book.
What’s T3 then?
Off exchange, ready to be converted to T1.Best within x minutes?