Why Nu’s Liquidity Engine Failed in its First Attempt at Pegging
What I’ve described above is how things should go if Nu’s liquidity engine is allowed to run at full speed. So how do we compare the above ideal scenario with Nu’s first attempt at pegging and where are currently at financially? How did we get to this point? In order to understand, we can go down the timeline and point to events which caused severe disruptions in the liquidity engine, causing it to stall out. These severe disruptions negatively effected both the quality and quantity of liquidity provided by Nu.
Early Success Until Exchange Hacks Lowered Nu’s Reserve
Nu basically started out how I started this thread, by beginning to sell NuBits. It followed the same pattern I laid out above. From launch in September 2014 to the exchange hackings in February 2015, NuBit demand grew exponentially to the point we had $3-4 million dollars worth of trading volume on our various supported exchanges, all due to excellent liquidity provided at tight spreads. This was the beginning of Nu building serious momentum. The liquidity engine was accelerating in speed and gaining traction with a wide number of traders, however in February 2015 Nu was the victim of multiple exchange hackings, which lost us a large portion of our BTC reserve and caused our liquidity engine to stall out.
Premature Zero Reserve Transition Led to Decreased Liquidity & Increased Costs
In the following months, Jordan convinced us to make an early transition to his zero reserve model, since providing liquidity on centralized exchanges using Nu’s reserve funds proved to be too dangerous for Nu. Creon invented the automated liquidity pool software (ALP) in order to help along this transition to the zero reserve model. The liquidity pools however couldn’t compare to the amount of liquidity we had previously offered using Nu’s reserve funds. Nu was still such a small organization and hadn’t yet attracted the attention of people that would have been able to provide large amounts of liquidity. As a result, the amount and quality of liquidity suffered, resulting in reduced demand for NuBits from the market.
I mentioned above that this was an early transition to the zero reserve model. I personally don’t believe Nu was ready for this transition to zero reserves, because the network was not mature enough to handle it. Nu didn’t have the required amount of transaction fees by users of the network in order to cancel out the NuBits that needed to be printed in order to incentivize liquidity providers. Because of this, we were creating more NuBits as liabilities than the network could handle, which was not sustainable.
I personally believe Jordan may have only wanted this early transition to zero reserves as a temporary measure to protect Nu’s reserves from being stolen in the event more centralized exchanges got hacked. Soon after the exchange hackings, Jordan offered up his plan to fund and build B&C Exchange. This was his answer to the exchange hacks. He most likely only wanted to use zero reserves as a temporary measure for security reasons until B&C Exchange was completed. Enough damage had been done to Nu’s reserve through the hackings, so it was important to protect the remaining funds by any means necessary. Once B&C Exchange was complete, Nu would most likely be able to transition back to the reserve model and continue using Nu’s BTC reserve to provide liquidity using the decentralized exchange where counterparty risk was much lower.
NuShare Buybacks Lowered the Reserve & Failed to Support the Peg
The next mistake however came from Jordan himself. As part of the transition to the zero reserve model, he recommened NuShare buybacks in order to convert a large portion of our BTC reserve to NuShares, the idea being that NuShares would provide a backing for NuBits and could be used as tier 6 NSR sales in order to protect the peg when we hit a period of low demand and park rates weren’t enough to support the peg. Here is Jordan’s quote about NuShare buybacks…
It sounded great in theory, but unfortunately reality was not kind to us. NuShareholders sold a large portion of the tier 4 BTC reserve based on this theory of NuShares backing NuBits. However, Bitcoin ended up spiking in value because of the incoming reward halving, causing people to sell a lot of NuBits for Bitcoin. The remaining funds in our tier 4 BTC reserve ran too low and parking rates weren’t effective in bringing back buy side demand.
Loss of Confidence Due to Low Reserves Led to Ineffective Parking
I believe park rates were not effective in this situation for several reasons. First, we were advertising the wrong parking rates. We were advertising yearly APR rates rather than the parking rate for a single duration in time. APR was a scary unsustainable sounding percentage rate compared to the rates for single park periods, and later on we had evidence that people were actually confused by this and stayed away from parking because of the unrealistic scammy sounding rates…
Second, I believe we could have done a better job in advertising and making sure people knew about the park rates. Third, I don’t believe we were offering high enough rates for the crisis we were in. Fourth, pegging was broken because FLOT had lowered the buy side to $0.95 in order to protect the remaining BTC in the reserve from being bled out. This defeated the purpose of parking because any interest made would be lost when cashing out through the lowered buy wall.
And finally the most important point. Jordan was arguing for us to pump the remaining tier 4 funds into the market at a tight spread in order to reestablish the peg, so people would use the parking system. I think Jordan is right that park rates can’t be effective without a tight peg, but they also can’t be effective if the reserve was as low as ours was. People lose confidence that they will get their money back, so they don’t take the risk of parking. I agree with Jordan about a tight spread being necessary for parking to work at all, but disagree that parking would have made a difference in this situation, even with a 1% spread in place. The parking system simply can’t work with such low reserves. People need to have at least some amount of confidence in the system to recover for parking to work. We had stretched the system too far by emptying our reserve into NuShares. With such a low reserve, confidence evaporated and parking didn’t provide any buy side support for the peg.
Tier 6 NuShare sales were also announced, but rather than providing support for the peg in a time of need like Jordan expected (the reason for the NuShare buybacks) everyone frontrunned the sale, collapsing the price of NuShares. This brings us to our current predicament of shareholders facing heavy NuShare dilution. In hindsight, a company’s stock should go down if their primary product is in low demand. It’s impossible for Nu to store the value from our reserve in NuShares because the value per share will collapse in the event a crisis arises, as it did in this situation.
Recap of Events
So to recap, everything turned sour the moment our exchanges got hacked in February 2015. We were well on our way and the liquidity engine was building up momentum. Without the decentralized protection of B&C Exchange though, we were hacked through centralized exchanges and part of our reserve was stolen. We tried to keep our reserve funds safe by hiding behind the zero reserve model and using liquidity pools. This had the immediate effect of lowering the amount and quality of liquidity we provided, lowering the demand for NuBits. Nu was not ready for the transition to the zero reserve model (even though it might have been intended as a temporary measure) because there were not enough transaction fees necessary to cancel out the NuBits we were creating to incentivize liquidity provision. We were stacking up more liabilities than we could handle. NuShare buybacks were the final nail in the coffin, lowering our reserve to a point where funds were quickly depleted in a crisis and there was not enough confidence in the system for park rates to work effectively.
Everything here combined led to decreasing amounts and quality of liquidity, exactly what you don’t want if you want the liquidity engine to work properly. These things caused us to lose all momentum. Jordan also offered his explanation of the events I just talked about…
Conclusion
I believe Jordan’s liquidity engine model would have worked. We were on our way and were gaining momentum quickly. Sadly we hit a bunch of obstacles though, which stalled out the engine to the point where we might not be able to get it back up and running again. The only path forward that I see is if we were able to raise enough money to pay off all debts and start over again. Even if we were able to build our reserve up somewhat, I believe it wouldn’t be enough. It’s too hard to maintain the peg when the reserve is too small, because you have no buffer. Park rates and NSR sales will keep getting triggered every time we see a little bump in the road. The only other option is to abandon the current NuBit supply and the customers we owe, suffer reputation damage and start over with a brand new supply once B&C Exchange is released, allowing us to provide liquidity with Nu’s funds without needing to worry anymore about exchange hackings that can kill our momentum.
I also just wanted to point out once again that this is only my interpretation of Jordan’s liquidity engine model from reading what he says about it and our good experience at the beginning of NuBit’s run before the hackings. I hope @JordanLee comments himself on this to let me know if I’m correct. If I’m wrong in parts then he should pick it apart, since it would be educational for the people who want to fully understand his liquidity model. Understanding this would be the best thing all shareholders can do, that way they know which way to vote on motions in the future in order to make sure our network succeeds.
The biggest reason I wrote this is because I believe the constant criticism about lack of revenue and liquidity provision being too expensive is misplaced. As mentioned in the examples above, the BTC reserve acts as both transmission fluid and fuel in order to achieve increased demand and more sales. Basically as @mhps said, money is burned in order to make even more money. It’s ok that liquidity provision at a tight spread is costly, as long as the BTC is working to bring us even more demand and NuBit sales. It’s all about building momentum to the point where enough people are using NuBits that the system becomes self-sustainable through the revenue from transaction fees and other profit models that shareholders implement in the future. Lack of revenue in the beginning phase of the network is part of the design. Remember what Jordan said…
Of course, all of this is contingent upon the basic assumption that liquidity at a tight spread attracts even more liquidity through increased demand and sales. If true, we don’t need to figure out new ways of making revenue until much later in the process. We would just need to make sure the liquidity engine is being used the way it was meant to be used, as its the only path forward that has a chance of succeeding. We tried once, but ran into obstacles and stifled our engine until it stalled out. Let’s try again after B&C Exchange is released, but let’s do it right this time and let it run full speed ahead!
