I always thought it is important that the dividends are distributed using a currency which is external to the Nu network … With this motion its more that NSR and NBT have a shared/coupled market cap which gets rebalanced through motions. I just hope that the lack of liquidity in the NSR market will not call manipulators on the plan when we decide to perform such big trades.
What I am missing now is a corresponding mechanism that is complementary to parking
I posted a short code snipped in another thread how something like this could be done very easily. After giving it some more thought though, I think there are many legal issues that come into play when operating with other people’s money. So the bot operator would probably still have the full responsibility when the funds are lost. So a liquidity pool bot operator would not just need some technical skills but also some legal advice and a suitable insurance. This is already out of scope for amateurs.
NuBots must be able to cooperate! In my opinion this is the most interesting approach to get more LPCs, and to really build a decentralized way to provide liquidity. Running NuBot isn’t harder than running a miner, and many people are able to do that. Targeting many people with low to moderate funds will provide a stable liquidity floor which won’t fluctuate as much as with a few very rich custodians.
While I had made a final decision to propose this motion before the failures at Bter and Excoin, the recent events demonstrate the urgency of the matter. Honestly, the Bter failure makes me inclined to move the timelines in the motion so they occur more quickly. Our solution will still work with thin on exchange liquidity (although it increases the risk of momentary swings in the peg). However, loss of shareholder funds can be catastrophic if the amounts are great.
New LPCs may not be so excited about putting their own funds at risk in light of recent events. Its clear the best response is to do everything we can to provide liquidity without exposing the liquidity providers to exchange default risk. That means most LPC funds need to reside on tier 3, off exchange. Perhaps it is time to place tier 3 automation at the top of the NuBot roadmap. We could start with automating exchange deposits and visit the issue of automated exchange withdrawals afterwards. @desrever, @benjyz, @woolly_sammoth and @pennybreaker: what do you think of making tier 3 automation of exchange deposits the top development priority for NuBot?
Let’s examine what a 100,000 NBT Bter liquidity operation would look like by adding tier 3 automation (for exchange deposits): Perhaps 5,000 would be placed on each side (buy and sell) in tier 1. So 10,000 NBT total is on the order book and available for immediate exchange. Perhaps another 20,000 NBT is available in tier 2. As an order is filled and depletes tier 1 liquidity, it only takes several seconds to move liquidity funds from tier 2 to the order book and tier 1, as tier 2 is off order book and on exchange. As tier 2 amounts drop below 10,000 on each side, NuBot deposits funds on the exchange from connected Bitcoin and Nu daemons. In our scenario, only 30,000 NBT of value is exposed to exchange default risk, while 70,000 NBT would be safe. LPC proposals would specify how much liquidity would be provided in each tier. There is no reason an LPC proposal couldn’t be very conservative in managing exchange risk by placing 5% of funds in tier 1, 5% of funds in tier 2 and 90% of funds in the off exchange tier 3. That would still provide good liquidity. Tier 3 liquidity can be promoted to tier 2 in between 6 and 60 minutes, depending on the currency and exchange policy regarding confirmations. Occasionally losing tier 1 liquidity for a specific LPC or exchange for a matter of minutes is only a minor problem.
Most of this post may seem off topic, but it relates to the question of how we will transition to self funded LPCs. An important part of that is reducing exchange default risk.
Edit: I should clarify that while automated withdrawals can be addressed later, the initial tier 3 NuBot implementation must permit manual withdrawals. This way LPCs can manually move funds from tier 2 to tier 3 when tier 2 get too large on one side.
The timing would never be fine for something like that.
It’s a double-edged sword.
On the one hand if there’s no end of @KTm’s and @jmiller’s LPC foreseeable the need to support LPCs might just not be big enough. Having @KTm and @jmiller providing liquidity is very convenient - and risky for NuNet as we see these days.
On the other hand I agree that there are some things that need to be done until operating a NuBot is close to a no-brainer.
We need to be aware that the amount of potential LPCs is still quite limited at the moment.
Ideally each NSR holder should be willing and able to run a NuBot - the fees will reflect the recent experience with exchanges defaulting.
I’d really love to have the Peerbox equivalent for running a NuBot.
Download the image, do basic configuration tasks like choose the exchange, enter an email address that receives regular updates on the NuBot status, provide the wallet with funds and give it a go.
These are things that I’d like to see on the agenda before I could feel fine with creating pressure by a motion to end LPC operations of @KTm and @jmiller.
What if passing the open source motion makes exchanges think about providing liquidity, taking the role of an LPC?
i think exchanges can be great LPCs even without asking of any reward. just the fees would be enough
moreover exchanges can take all the risk of their businesses by balancing their tiers and using multisig as they see fit, i believe better than an external bot can ever handle!
it is pitty to see nubit system to fail due to exchanges’ incompedence!
I’ve read through this motion a few times and support it. Share buy-backs are a clever way to increase the market cap of NSR and consolidate voting power in the hands of those who view Nu as a long-term DAO and not a short-term speculative bet.
I hope the creation of liquidity pools emerges soon. Any prospective LPC can increase their own profit by accepting and managing smaller contributions.
For example, a current LPC proposal might look like this:
A prospective LPC who puts out a call for ten small contributors to join him (who are each willing to put in 2,000 NBT) can now earn this:
Individual liquidity provided: 25,000 NBT
Fee asked for: 2,500 NBT (10%)
Group liquidity provided: 20,000 NBT
Fee asked for: 2,000 NBT (10%). Of this 2,000 NBT, 600 NBT will be a management fee for the LPC.
The LPC now earns 3,100 NBT on his 25,000 NBT liquidity injection for no additional risk, just additional work making the payments to his pool members. The small contributors are able to earn a smaller but sizable return without needing to learn how to use NuBot. Everyone wins in this scenario. I expect open-source automated solutions are eventually possible for these liquidity group managers.
Well as shown in my previous post this can be automated in 50 lines of Python but as mentioned above the pool operator will be legally on very thin ice if something goes wrong. Its something else if people here on the forum coordinate to make a shared proposal, but then the shareholders don’t even need to know how exactly the funding was obtained.
I like the simplicity of the duality played by NuBit/NuShare to control the supply of NuBit.
It decreases at the same time the importance of parking, which is a bit more complicated.
In my understanding, the system envisioned here will be much more decentralized than the current state because shareholders will be able to elect NSR custodians who will be burning the shares on a multi-sig basis, whereas now shareholders’ money is held by only 3 people.
Another thing is that with the decreasing importance of dividends distribution alluded to, most of the value of NSR will be derived by their rarity, not their associated dividends, making NSR more similar to bitcoin than originaly designed, from my perspective.
My position has always been that shareholders need to pay whatever price the market demands for proper LPC operations, although the quantity of liquidity can be relatively small if the price is relatively high. There have been a lot of LPCs rejected, apparently because shareholders thought what KTm and Jamie were doing was cheaper, which has now been conclusively proven false. The operations of KTm and Jamie have proven to be more expensive than any other LPC proposal that has been made. More important than the fact that their operations have been the most expensive is that the cost of their operations are completely unpredictable. The cost is anywhere between their commission of 2% (40,000 NBT) and 2 million NBT. To take a risk of incurring a 2 million NBT loss that would almost certainly break the peg is terribly irresponsible when shareholders could instead buy what is essentially an insurance product that makes the price of liquidity perfectly transparent and predictable. Therefore, while I strongly advocate for shareholders passing grant proposals of proper non-shareholder funded LPCs right now, this motion is designed to essentially force shareholders to do the fiscally responsible thing as the timeline matures and stop gambling the fate of the network on the faithfulness of KTm, Jamie and the exchanges they use. I don’t believe shareholders will choose to reject all LPCs as the liquidity offered by KTm and Jamie winds down.
I sent a PM to @assistant where the body was the motion content prepended with motion hash. I then copied and pasted the resulting reply from the assistant in to my original post. The formatting does look slightly different here than in the PM, so I think some hidden characters were lost or added in the course of that copy, paste and save edit. I checked it at http://www.online-convert.com and indeed I get a different hash. So, I am just going to calculate the hash with the website above. You can verify it using the Tor or Firefox browsers.
You have to click on the small “verify” link on the bottom of the reply of the assistant bot and copy the html shown there back into the OP. Hashing the part in the motionhash tags should give the right hash.
EDIT: it also enables us to easily view this html code and to verify the hash without the forum software.
I tried that but got a hash of d79414279ae22fb217f2b654fb434ad1cf155c8b at quickhash.com instead of the expected value of ed7b9fc65dc4e9d9acad61e528420c2690f599d2. So, I’m going back to manual method and the 72f371610c7e8d3f3c34886635aac6fc1bc7a596 hash.
That is sad, I am not able to verify this hash due to the well known reasons. @woolly_sammoth implemented this unique html representation so others can verify it easily on any platform.
Are you sure that you are hashing the whole motionhash block including the opening and closing tags? Furthermore we are not able to click the verify link in the OP because it links to a private page. I had the same issue and @woolly_sammoth said that it has to be changed manually right now:
EDIT: @JordanLee Or maybe post a raw file on github or pastebin. The newlines in the text above don’t show up when quoting it, so copying it will result in many different results on different browsers and operating systems.
Thanks, the only remaining problem is that the verify link is not accessible to us. I don’t know how to create a raw page here in the forum and to make it publicly available. @woolly_sammoth did it for me in my case.
So right now we still cannot verify the hash but I am sure everything is fine and that the “verify” link will be updated soon.
I d like to know about the ratio of liquidity provided by non-shareholder funded LPCs 1) over liquidity provided by shareholder funded LPCs 2) currently, before voting.
2) would be gradually fading away so it would give shareholders some time margin to increase 1) after pasage but I just want to make sure that we would have enough margin.
For example, if the ratio is too small, we should first increase 1) before passing the motion, I think.
Morning. Sorry for the confusion. I have edited the ‘verify’ link in the OP to point to the actual raw text so verification can take place.
I still need to come up with an elegant way around this issue. As you can imagine it has slipped down the list of priorities somewhat I recent days.
