Motion Hash: 29d364f8677c7c955d423747fcf5005fd00f2e6b
This motion has been discussed here.
The finalized text is available on Daology here.
Motion Hash: 29d364f8677c7c955d423747fcf5005fd00f2e6b
This motion has been discussed here.
The finalized text is available on Daology here.
The link to
https://daology.org/u/muchogusto1/proposals/f6f6eea2e5c8d00b6ff287c8906b93219feae759
in the OP isn’t working.
And I wait to include the hash in my data feed until you’ve replied to
Fixed
I’ve added it to my data feed.
I’m not convinced this is a good use of our funds. Guaranteeing profit to someone is a business model I never believed in to be win-win. Would be happy with a fixed compensation for measuring or logging trading and benefits against certain parameters.
Also question this from the proposal:
Compensation from NuPool and shareholders will be added to funds used to provide liquidity to allow compounding returns.
Not sure how this helps to actually measure and log how profitable liquidity provisioning is. Adding rewards to funds at risk/at play is in my opinion not a great model. Compounding returns can also result in compounding losses. It could make the outcomes more volatile.
In its current state I won’t support this and therefore won’t add it to my datafeed.
I’m not fully convinced, but enough to start a test. @muchogusto followed the suggestion to cap the guaranteed profit to 3% of NAV per month.
If, what some believe, offering funds at a smaller spread is not more expensive, reducing the spread might come cheap.
If the NAV suffers losses, only 3% of $20,000 need to be compensated.
I don’t have enough data to calculate an expectancy value of costs for Nu for this experiment, but the lower limit is 0 NBT per month, the upper limit is 3% of NAV per month or 600 NBT for the first month (close to 600 NBT for the months after that).
It’s crucial to find out how expensive liqudity provision is, because otherwise we won’t be able to know how much liquidity we can attract per $1 compensation offered in ALP, we don’t know how to rate the cost-value ratio of MLPs (e.g. NuLagoon), we don’t know at which point running Nu funded operations is cheaper.
A fixed compensation might be more expensive.
The offer @muchogusto made was
which is 750 NBT per month and above what Nu has to face if
NAV(current.month) < NAV(previous.month)
because it’s capped at 600 NBT (ok, rather 3% of NAV, which won’t change very much, I suppose).
We know about the results from providing liquidity at 1% spread:
Now we make an experiment, have the spread lowered to 0.6% and for that spread reduction @muchogusto receives a capped compensation, if the ROI is worse than at a higher spread.
Based on his experiment (which doesn’t cover a long period of time), we can say that so far the monthly revenue (including pool rewards) was approximately 1.3%1
If the ROI in the coming months is on the same level, Nu needs to compensate 1.7% (3% - 1.3%) of NAV, which is 340 NBT per month.
I dare say this experiment is worth it.
If you want to support such an experiment (albeit on a different market place) where Nu doesn’t need to pay compensation (except for the operator), but needs to take all risk, you might consider voting for this motion:
1 from Liquidity provider profitability experiment
2016-04-11
2016-05-22
difference in NAV (absolute):
20,372 - 20,000 = 372
difference in NAV (percent):
372 / 20,000 = 1.86%
period of time (days):
2016-05-22 - 2016-04-11 = 41
daily reward (percent)
1.01861/41 = 1.0004495921452508277953343878974
monthly reward (percent)
1.000449592145250827795334387897430 = 1,0135760623395393003669600453841
I wouldn’t consider this as an “experiment” rather than a useful service. The outcome may be different
regarding the period, traders, volatility, etc
Of course the outcome might be different.
Yet it’s an experiment as much as it’s an improved quality for the peg of US-NBT at Poloniex.
We will retrieve data about the change of NAV at a reduced spread.
Maybe we are lucky and the BTC volatility stays low. That’d reduce the effect of at least this variable.
We don’t even know all factors that do have an influence on the NAV and in what way.
Creating a formula to calculate that is far beyond of what we can accomplish in the near future.
But it needs to be the direction to head for, if we want to run Nu beyond guesstimating.
If we want to automate, we need algorithms.
If we want to know how expensive how much money at what spread and what circumstanced is, we need data.
Creating market awareness for NuBot will be impossible without it.
In that essence, i am conducting my own personal experiment by providing funds in NuPool’s tight spread. I know that i maybe loose some money but since i am a shareholder also, i am happy to
provide NU liquidity as a service
As said before, I don’t think such an experiment is valuable at anything else than Poloniex. The number of trades on other exchanges is too low to be meaningful. I’ve seen that for myself on Bittrex with my Pybot in the last 2 months and monitoring that exchange a bit closer.
Then we should cut LP at those exchanges completely, because it’s a farce anyway.
Focus on the dominant exchanges: Poloniex and NuLagoon.
Then again, how do we keep backup operations available, if we back out of those exchanges completely?
How do we know about striving markets/exchanges?
How do we know that NuBot still works at a particulat exchange with the wrapper and the API if not continuously tested?
hitBTC offers a formidable trading platform. The website is great and it worked flawless all the time I used it. No troubles with withdrawals, etc. like at CCEDK and bter often happened.
If we don’t want to completely focus on Poloniex, I’d like to have operations at Bittrex, bter (just to keep in touch with the Chinese and not because I like bter) and hitBTC.
CCEDK ceases it’s trading operation and I have no opinion on southXchange.
My motion is not only about an experiment.
It’s about liquidity provision at a tight spread in the first place - something most here seem to want. I just try to produce data as a side effect.
If you don’t like the experiment attribute, you might want to support liquidity at hitBTC.
What is the average liquidity cost in percentage that Nu has been having over the past few months?
3% looks comparatively small.
The proposal does not include the amount of liquidity but I suppose it is 20k equally spread on both sides.
So basically this proposal says that we need to pay roughly 600 nbt for 20k of liquidity.
Looks like a reasonable deal to me.
i cann’t find a target liquidity at the hash text, how many liquidity will you provider ?
what is the different with dual side gateway?
The 3% is on top of pool compensation.
It does. The math is here:
That was the situation at start.
I gather this is a passive operation. I don’t find anything related to balancing in the motion. At least passive operation isn’t prohibited.
With ALPv2 there’s an increased incentive to balance sides. Even if @muchogusto doesn’t actively balance the sides, others will do and if need be balance his operation doing so.
Is the profit affect by BTC price?
Of course. If you have a buy wall and BTC goes up, you have profits.
If you have a sell wall and BTC goes down you have a profit.
Then why the additional 3%? Isn’t the pool compensation already good enough to pay for the risk incurred?
EDIT: I am still studying the proposal. It looks like it could be very valuable for Nu but I need to study the cost.
Based on the assumption that a tighter spread leads to increased costs (increased hedging risk), @muchogusto wants to have a kind of insurance for that - very reasonable.
And if the assumption is wrong and the costs don’t increase everything’s fine.
So the means that the pool compensation is not regarded as sufficient. How much is the monthly rate of reward on Polo right now based on?
Poloniex:
Reward: 0.02 NBT / minute (864 NBT total)
Tolerance: 0.0065 (0.5% tolerance, 0.15% fees. SAF 1%)
Target: 5000 NBT
It increases if there is less liquidity provided. The actual rate is unknown unless you know what the magnitude of provision is.
Of course the compensation is not enough, almost by definition. The compensation is theoretically exactly enough to pull the current amount of liquidity at the current tolerance. If you force an operation to act at a disadvantage compared to their peers, of course they will ask for greater compensation.