Current Liquidity

[zoro]

gateways with collateral isn’t the same as MLP-ALP?

[masterOfDisaster]

Also, I was thinking: does it mean make sense to impose a collateral to gateways?

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.

[Nagalim]

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.

[masterOfDisaster]

I’d like to point out that a gateway can be run passively, just like I’m doing T3

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.

[Cybnate]

And it didn’t work on CCEDK. Have a look at the volume on CCEDK pairs. Keep in mind what we’re paying for about 200 NBT of volume per day (90 day avg.) on 4 pairs.

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!

[crypto_coiner]

fixed cost can improve liquidity provision at each exchange, because as long as a minimum liquidity is available, the peg is safe!

to test and ascertain asap

And even if not the full total compensation is paid, if the volume on order is below a certain threshold (or maybe the compensation is raised in steps), providing liquidity needs to be especially profitable, if the volume on a side is low and the danger for the peg big.

Liquidity Providing must have a solid business proposition to attract new comers interested just in making money

[masterOfDisaster]

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:

[cryptog]

status of buy side gateway:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
"BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
“buy” : 9342.79,
“sell” : 11919.2544

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

[masterOfDisaster]

It does not seem to be broadcast as T2 into https://raw.coinerella.com/?liquidity.

Maybe coinerella isn’t gathering all T2 information?
Can you see that broadcast liquidity information?

[Cybnate]

The buy side is low, because nupool can’t attract much ALP volume to Poloniex at the moment:

I wouldn’t be surprised if this is the reason making people nervous about liquidity provision: [Outdated] (limited) Warning about Poloniex.

[masterOfDisaster]

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:

[Passed] motion to permit dual side NuBot on Poloniex

Exactly to that… I pulled my liquidity from polo and Bittrex because the compensation didn't fit the risk faced due to the btc swings.

[cryptog]

Can you see that broadcast liquidity information?

in getliquidityinfo B, yes,

[willy]

Maybe coinerella isn’t gathering all T2 information?

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.

[cryptog]

status of buy side gateway:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
"BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
“buy” : 9342.79,
“sell” : 11919.2544

How do you specify this liquidity to belong to t2 in the first place?

[masterOfDisaster]

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

[cryptog]

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]

We need to adjust tier1 and tier2 definition

[masterOfDisaster]

In order words what s the definition of T2 now?

It needs to defined anew:

We need to adjust tier1 and tier2 definition

Since the introductions the multi-tier liquidity in JL's Evolution of liquidity operation thread, many things changed. The Tier1 vs Tier2 definition is now ambiguos and we ended up with at least three interpretation (as attested by @willy and @woolly_sammoth recently on gitter). The scope of this thread is to survey the community to create consensus and finally vote a new motion where a clear definition of T1 and T2 is provided. The origin of the ambiguity is that the software to provide …

In the case of the Poloniex NuBot, the T2 is on exchange, but off the order book.
Parametric order book is effectively disabled.

[Nagalim]

We need to adjust tier1 and tier2 definition

T1.Best - up to 2% away from the defined USD price
T1.Parametric - up to 5% away from the defined USD price

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

[willy]

What’s T3 then?

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