We can always offer bigger compensation in order to make LPs risk their money in exchanges that require a lot of liquidity.
The interest rates in Polo for ALP should be much higher than in other exchanges. Of course this will “help” in
"centralizitation" but it would also help Nu keeping the peg.
i second that. i feel nulagoon is absent from poloniex!
The fixed cost scheme will help big time here.
But I don’t think it needs to be something special for Poloniex.
Fixed cost can improve liquidity provision at each exchange, because as long as a minimum liquidity is available, the peg is safe!
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.
I’m thinking of something like a “parametric compensation scheme” that was already sketched in another thread.
Liquidity provision must be more rewarding if the walls start to run dry, because the risk for the peg is getting bigger. The monitoring and the effort to act in such situations must be worthwhile.
A failing peg has a price, too, although we don’t know it.
I’m not sure whether Poloniex was ever supported by NuLagoon - I just thought so!
I think it will be good to have open-source tools for custodians to run multi-sig pools off-exchange. This will be important along the line of heavy-duty subsidiary applications like NuBot and NuPool.
A rough idea is as follows:
Suppose Alice and Bob jointly run NuBooth, a semi-distributed market-marking off-exchange platform. It allows people to deposit NBT to get BTC and vice versa via Blockchain transactions.
In order to reduce risks, NuBooth addresses are 2-of-3 multisig addresses, where one private key is in cold storage by another trusted third party (or whatever arrangement that has both multisig security and robustness against loss of private keys).
Being multisig, they both need to sign a transaction in order to deliver funds to their customers. They should be separate entities for this to make sense, and this inevitably leads to a discrepancy in price feeds.
First I note that I want to put in a market-maker element for ALPs. We need to be able to get people to buy at non-arbitrage pricing, or Nu will risk an eventual break down by excessively subsidizing cryptocurrency speculation. So a crucial difference between this and NuLagoon Tube (apart from the availability of pool funds) is how the selling price is determined. The crux is that NuBooth will always be on the safer side of the trade, and try to avoid trades when there is a large discrepancy between price feeds.
A rough work flow is as flows:
I send in 1 BTC without replace-by-fee.
Alice and Bob each has a price feed, sees the unconfirmed transaction and starts tracking the lowest “real-time” non-arbitrage selling prices of NBT based on their feeds, Alice tracks p_1a,p_2a,…,p_Ta; Bob tracks p_1b,p_b,…,p_Tb.
If Alice sees that the 1 BTC is confirmed at time T,a she computes compute the highest values p_max(a) and lowest value p_min(b) among all p_i’s and sends them to Bob. When Bob sees that the 1 BTC is confirmed at time Tb, he does the same, computing values p_max(b), p_min(b) Suppose Ta < Tb, in which case Bob also sends in his prices.
Because Bob receives the price pairs from Alice first, once he works out his own prices he will decide whether to propose a transaction. If the range of the 4 prices exceeds say 1% he will decide to refund my 1 BTC and tell that to Alice, in which case the refund transaction is signed. Otherwise he will propose a transaction at the price point max(p_max(a),p_max(b)) and ask Alice to sign it.
Due to the pricing issues I don’t think this will be high-volume; however, as long as a service like this is live and known, we do not have to worry about the peg being at risk when liquidity is low on main exchanges - we readily provide non-arbitrage price that is slightly biased to ourselves, effectively organically applying a “spread” to adjust for the occasion.
When BCExchange comes out, the multisig-part might not survive, but the non-arbitrage element will still be needed and refined.
I think that T3 custodianship with collateral is much better than without.
I expect the other T3 custodianship proposals to include a collateral in order to pass.
Also, I was thinking: does it mean make sense to impose a collateral to gateways?
If it involves Nu’s money, I think it should.
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.2544The 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.1642By 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?