It is good that the motion removes the 1% minimum barrier which is clearly not working and I have always been challenging for ALP use. However I think Jordan’s motion doesn’t take properly into account a layer of defence for the peg. Something which has been proven more than useful when ALP funds lay dry. That’s why I won’t vote for this motion.
I think the layered model I propose where 60% of the liquidity is provided by ALPs at the lowest realistic spread for the pair another, 30% at a medium spread and only 10% at a high spread would setup the Nu peg in a way that it can withstand the currently known threats while still being competitive.
I like @Cybnate’s approach that tries to regulate the distribution of volume at different spreads.
But I need to say that I don’t find enough data to make an assessment what’s a wise distribution of funds to different spreads.
We don’t yet know the true cost of liquidity provision at different spreads.
As much as I like clear regulation, I’d prefer room for discretion here, until we know what to do and how to regulate the distribution.
My motion is quite simple:
max. 1% for ALP and MLP, above 1% allowed (but not necessarily used) for Nu funded bots:
I think I will include
in the motion to finally define those terms.
I’m going to promote it to [Voting] if there’s no significant amount of rework detected.
The current motion is sufficiently different from the two other motions that try to regulate the spread to provide a real alternative for shareholders.
Shouldn t the liquidity operators working at > 1% spread be able to get revenues from the spread itself and in that case shouldn t the rewards from Nu be double payment?
We don’t know that, although it might be the case.
Only Nu funded (bots operated with funds that belong to Nu!) operations are allowed at a spread >1%.
An increased NAV (if there’s actually revenue) from these operations is revenue of Nu. If the revenue from an increased spread is able to compensate operator costs and calculatory costs (e.g. exchange default, theft, etc.), Nu can essentially provide that liquidity for free.
ALP and MLP are forced below 1% spread. They get compensated by Nu for liqudity provision. No “double payment” here.
It is a balancing act. Sometimes ALP would be fully drained (high volatility) and sometime just half (some volatility). It will be hard to obtain hard data of the best balance. My argument is to have roughly a backup for the ALP provided liquidity -/- 10% (risk factor). I believe that number could be higher but I like to err on the safe side. It would be dependant on the level of volatility of Bitcoin. Something which will be impossible to obtain data for. One can only make assumptions.
It won’t be possible to get “the best balance”, because the balance is depending on the environment. The exchange (number of users, traders, daily volume), the BTC volatility and a lot of other factors play a role.
You need market aware shifts and need to create an algorithm - ideally a self learning one - if you want to be close to the “the best balance” for a given condition.
As well as the best balance depends on conditions, I suppose the best spread depends on conditions.
There’s a lot of work to do and I fear we don’t have the required skill set to do it properly at the moment.
Someone with a sound monetary or trading bot operation background would be very helpful.
I don’t know what the safe side is: having more or less buffer there?
More buffer means more calculatory costs, but an increased peg support.
Right.
What do you think of this proposal?
Don’t you think we can use that to gather data?
That’s why we need to start some tests and gather data. It would be great to do that in a scientific way, but I don’t have the skills to do that.
As you are saying in your post it won’t barely be possible to get 'the best balance" as there are so many parameters in this environment. So I’m not sure why you want to gather data. Unless we can find someone willing to do that in a scientific was as you are saying and program an AI for this.
So before you gather I believe we will need to know what for and how we could use it, otherwise it is a waste of time.
To be able to know something about offering a small spread.
At the moment there’s the notion that a minimized spread is superior to a slightly increased spread.
That might be true liquidity wise.
It might not be true cost wise.
I want to know about the NAV over time of operating at a spread below 1%.
If Nu is a business, it must care about costs as well as the quality of the products.
Left your ‘if’ out and I agree.
Given the lack of velocity/trading on other exchanges, I think this would only be possible on Poloniex.
There is also the risk that by measuring you actually disturb the normal order making your measurements almost worthless. This won’t be easy to draw conclusions from, but I believe we should try.
Once there was more trading on hitBTC’s NBT/BTC pair (e.g. when I ran modPuddle).
The SAF was 1%.
I don’t remember the trade fee at hitBTC back then, but I remember that I made significant loss from trading. I could only continue for some terms, because the compensation was quite high.
If I had been able to make revenue from trading, well…
Let’s see what happens when orders at 1% spread (not SAF!) are on the order book.
…and we would be liquidity wise in a bad situation, if all liquidity were at below 1% spread.
Just have a look at the recent events (BTC price jump), that drained all funds from buy side, that were at a tight spread.
Only the NuBot @zoro operates has a significant amount of BTC ($9,000) left.
This NuBot operates at a spread outside what ALix records.
Would you feel comfortable with this situation if there’d be no additional $9,000 BTC at an increased spread?
Hope you are not serious with your statement. If this motion, how much I don’t like it myself too, passes we will have to oblige. Of course you can choose to not extent your operation and transfer the funds back to FLOT. I might do the same.
Well, i was thinking about that. In fact it is FLOT that mandates my nubot’s settings. I am a single person, i cannot mandate NU’s strategy. Lets see how this will advance
Please note that the shareholder funding of gateways is different from other models since we do not reward the provision per se (there is only an operator management fee) and we use the Nu owned funds (NuOwned liquidity operation).
Besides, I suppose (please correct me if I wrong) that you assume that all shareholder funded liquidity is then broadcast in the QT client as either T1 T2 or T3 .
I believe that we want to have the best liquidity broadcast into the client with a spread lower or equal to 1%.
Perhaps we can make sure that liquidity offered at spread higher than 1% does not get broadcast but nonetheless can be found on the order books. In that case we could create another Tier. Right now, it seems that it is called T1.2 as defined here.
Right now, I believe the client does not broadcast T1.2 as it only considers liquidity whose spread is lower than 1%.
NuBot broadcasts the first order, that gets placed, as T1, all others at T2 - even if the offset is 5%.
Have a look at getliquiditydetails of the current sessions of @zoro’s and my NuBot.
