Pay a lower rate to the heavy side when unbalanced (MoDs idea)
Pay a flat amount total symmetrically to each side distributed evenly amongst LPs on that side. So if you give out $1 to each side and there’s 100 nbt on one side and 200 nbt on the other, the heavy side gets 0.5% while the light side receives 1%. (Fixed cost)
Have a target amount for buy and sell separately up to which a fixed rate is paid. When liquidity on one side goes above target, enact fixed cost on just that side.
Rate = MaxRate * min(buy,sell) / max(buy,sell)
Some kind of dutch auction mechanism. However, I think this will be impractical to implement.
Make the operator reward linked to how balanced the peg is. Give some leeway for arbitrage and so on, but if one side ever crosses say 75% of the total liquidity we dock operator reward by 25%, then 50% at 90% unbalanced.
It is true that all liquidity services are redundant, by design. This creates the reliability we need. One important difference between the ALP pools and NuLagoon is that the liquidity is more available in the ALP pools. However, NuLagoon has better persistence properties (it won’t disappear immediately in a crisis like ALP liquidity can). I would love to see this persistence improved, perhaps by having a pool with infrequent opportunities to withdraw. NuLagoon also has more flexibility in where it places tier 1 and tier 2 funds.
The motion has been hashed and is now being voted on. It looks like it was hashed with @assistant, but it actually wasn’t as the assistant doesn’t seem to be working right now. You will have trouble with the Verify link accordingly.
Why is so little nothing of the discussion reflected in the motion?
Capping the sell side at 0.08% is less elegant and less fair than other approaches.
It will lead to offloading the sell side to ALPs to pile up BTC at the buy side.
Capping the sell side at 0.08% will likely cause unbalanced liquidity (moving BTC from ALP to NuLagoon).
I strongly encourage you to create your own motion.
Truth to be told, I am not in a stage where I can vote for the OP’s motion since I have not grasped the extent of the issue.
Writing your own motion will create a separate thread but will spark its own discussion that I will closely follow personally.
@masterOfDisaster I would also like to hash a different motion. Perhaps we can come to similar conclusions? I think we need to assume @Henry will resist this, so it’s best if we create something that explicitly states a method of accounting that is simple. I was thinking “if sell or buy side alone exceed 75% of the total liquidity provided in a 1 month period, the monthly reward will be limited to 4,000 nbt instead of the allotted 5,000. If a single side exceeds 90% of the total liquidity only 3,000 nbt will be awarded to NuLagoon for the full month of operation.”
I would prefer continuing the discussion here instead of creating another motion.
But as it now no longer is a draft and instead hashed and up for voting, there might be no other option left - unless the NSR holders are fine with this motion.
I see significant drawbacks in the current version that I tried to outline before and would like to find a solution that is fair for both NuLagoon and Nu - some proposals for different versions are already in this thread.
The solution should be a viable combination of easy accounting for NuLagoon and effective liquidity steering by Nu.
Expect another draft for a motion to reflect this to follow.
It seems that there’s no reference created (at the post from which is linked) when replying as a linked topic.
I announced another draft to follow.
Here it is:
Thank you for your vote of confidence. I can’t foresee the outcome of the other motion, but from the ideas I gathered in this thread, I sincerely hope that the community finds an improved solution which serves both Nu and NuLagoon better than restricting the sell side compensation.
Generally speaking, buy side liquidity is more important than sell side liquidity. Therefore buy side liquidity should be more rewarded that sell side liquidity whether it is ALP or MLP. I believe this is the case of all ALPs. Isn’t that the case of NuLagoon?
We would like to clarify that we are not accept this motion. We will be forced to stop NuLagoon operation at 1 Nov if this motion pass.
Because fund are shared by POOL A C D, all three pools are affected, we can not implement the calculation before 1 Nov, The only choice is to stop NuLagoon operation at 1 Nov.
Because there is a motion to regulate NuLagoon balancing operations, assuming that motion pass, this motion’s effect will be just as to lower the whole compensation. Later will be easier to implement at least.
I was surprised to read this, and I am unable to understand why the only choice would be to cease operations. It is possible there has been a misunderstanding of the motion content. When it states compensation will be lowered for sell side liquidity, this refers to pool users that place NuBits in the pool. It does not refer to pool users who place BTC in the pool which gets converted to NuBits while in the pool in the course of providing liquidity. So, for the purpose of determining compensation levels, it doesn’t matter whether the funds are NuBits or BTC at a certain point in time. It only matters what side the funds entered the pool.
It appears to me that implementation of this motion will be very easy and straight forward. In terms of operating procedures, it will only change the number used to calculate a new NAV. @henry, have I misunderstood something? Why do you say you would have to cease operations?
This motion only has 26.5% support, although it appears it is rising to the low 40’s. It appears some shareholders haven’t voted for it with the expectation that an alternative would be offered by @masterOfDisaster. That hasn’t happened, and the thread opened to discuss alternatives is now inactive (for 7 days). I’m concerned shareholders are making the perfect the enemy of the good. This motion isn’t perfect, as additional improvements in how pools such as NuLagoon are run can be imagined. It is good, though. It is a simple method that will bring significant savings to shareholders. Let’s pass this, and then think about how to iteratively create additional improvements. We are at risk of accomplishing nothing by trying to accomplish too much at once. Successful projects are built iteratively, not all at once.
An alternative was offered. Henry came to consensus with the other shareholders and proposed a motion. I’m completely unclear about your concerns with that motion, as it seems to attain exactly what was desired without imposing an artificial buy/sell asymmetry.