Perhaps the biggest surprise for me in the course of our monetary experiment is that a growing chorus of voices in the community are advocating policies of intentionally reduced liquidity as a part of planned operations. This surprises me because I would expect the community to understand that NuShares will only have value to the extent the network is viewed as reliable in maintaining liquidity, the quality of which is simply measured by the depth and spread of the liquidity. These proposals represent suicidal tendencies that strangely seem to be growing in our forum at the present time.
Talk of keeping the peg during a time of declining demand by increasing the spread or increasing transaction fees are alarming to me to the extent that there is any acceptance of such techniques among shareholders. These are poorly disguised defaults. A NuShare is an asset that has its value based on giving the owner part ownership of a liquidity engine. It amazes me people involved in the project would propose to plan to dramatically reduce liquidity by choice. The network is supposed to defend liquidity with every fibre of its being. Its like there is some confusion about the identity of the network. This is a liquidity providing machine. Its value is determined by the quality and reliability of its liquidity. So, deliberate and official plans to reduce that liquidity would be deeply injurious to the value of NuShares. A perceived possibility that shareholders will support such reductions in liquidity is an existential threat to the network, and the most serious threat to the network at the present time in my opinion.
Consensus about the importance of reliable liquidity needs to be demonstrated.
When the network first began deploying decentralised liquidity, it cost us 9%-10% per month. Muchogusto’s significant liquidity providing operation is being paid a little more than 1% per month. Liquidity has plummeted in price, just as we needed it to and as I predicted it would. It’s a major success for the project. So, with dramatically reduced prices, we should be buying more liquidity, not less.
While it is not possible to definitively determine the cause of a change in the price of NuShares, it is probable the recent drop is due to reduced liquidity, particularly from NuPool on Poloniex. I’m surprised there hasn’t been a better understanding of this. Volume on Poloniex declined in March precisely because liquidity was reduced at that time. This resulted in a declining demand for NuBits, which brought the NuShare price down due to lack of share buybacks and the threat of NuShare dilution. The system is working exactly as it was designed to, but the community doesn’t seem to fully appreciate this. The system is designed to punish NuShare holders for poor liquidity. That is working. I would expect this result to motivate NuShare holders to renew their commitment to providing liquidity, but the problem is I haven’t seen that occur yet. So, I would like to explore some principles that I will refine into a motion that will hopefully demonstrate the network’s commitment to excellent liquidity:
-
Transaction fees serve two purposes: revenues for the network and spam protection. A notion that the peg can be protected by raising transaction fees during a period of reduced NuBit demand is incorrect and flawed. Merely having a plan to do so would endanger the network by reducing demand for NuBits. A plan to raise transaction fees to address reduced demand is clearly against the interests of NuShare holders.
-
There must be a strong commitment to tight spreads. Perhaps the community should aim to maintain a 1% spread on supported exchanges. Increasing the spread, which reduces the price the organization purchases NuBits at, is a form of soft default. If we normally buy NBT for 0.995 and that is reduced to 0.95, that is taking 4.5 cents from customers when we shouldn’t. Planning to do this would be disastrous to the NuShare price.
Can we all agree that any shareholder plan to reduce liquidity or the pegged price represents a suicidal tendency manifesting within the network?