Demand based liquidity

After the discussion in [Draft] Nusafe - Hedging 50k tier 4 funds in USD, discussing DR proposal I became aware of a flaw in our liquidity model.

In rough terms we try to balance liquidity when one side is 40% of the other. That makes sense for sell side, because a lot of people selling does mark a decrease in demand, and could break the peg downwards. In that case (demand decreases) liquidity providers are not enough and T4 end up paying for that.

But what about buy side? To fulfill an imaginary demand? A lot of people could be putting together millions in buy side orders just bellow 1 USD because they realize that buying NBT for less than that is always a wining trade. Does that mean that demand have increased? No, it just meant more people are aware of a profit opportunity, but they will immediately sell the NBT at more than 1 USD (probably at another exchange walls) to make their profit.

So we are considering arbitrage orders as real demand, and what we do about it?
We put NBT in circulation. This is not a problem as long as T4 get at least what they are worth, but what happens if not? Well we just lose 1%+fees of that amount when we have to rebuy all those undemanded NBT at the sell wall.
Even if the money arrives at T4 at more than 1 USD per NBT sold, we eventually spend part of that in a buyback, and when those undemanded NBT come back at some point in time, it ultimately empties T4 and forces us to do a NSR auction. Not desirable.

Some may argue that this argument would also apply to sell side, but sell side are real part of NBT in circulation, thus is size is ultimately limited to the undemanded NBT.

What I propose is consider sell side as a indicator of demand X averaged over a period of time, and apply the 40% rule to that amount for buy side.

Right now we have:
{“time”:1450213744,“blocks”:659307,“total_buy”:76575.3031,“total_sell”:51621.5954}

  • X would be 51621, threshold for NBT buyback would be (51621/60)*40 = 34414.
  • Sell side is not to be touched unless is less than 40% of buy side and a certain low threshold is reached that we agreed beforehand, lets say 30000 NBT (Which would be the NBT introduction threshold).

This avoids introducing more NBT than demanded when “virtual” demand is too high, and allows having a bigger buy side ready to cover demand peaks.

I have drafted some simulations.

What do shareholders think?

So you’re just saying we need to take an EMA for liquidity instead of a point in time? Or are you saying something more subtle that I’m not grasping?

I am proposing to change the formula to calculate the thresholds to NBT buybacks and when to put new NBT in circulation, using an average of the sell side liquidity as the indicator of demand.

So that’s a ‘yes’ to using an EMA then?

That is up for discussion.

With the slow nature of NBT buybacks and NBT introductions I don’t know if a SMA would be better suited than a EMA. We don’t want big (and potentially acute) spikes have a big importance here, that is part of what the formula it is trying to avoid.

Ok, cool. So implementing a formula like that makes the picture a bit more complicated because now we can’t really rely on T4 signers just looking at the numbers and making a decision. Instead, we need someone to be recording the liquidity numbers and run the moving average formulas and come out with a number. This is synonymous with having a feed that suggests T4 signers to take action. Who runs the feed? Are they taking exchange data or custodial address liquidity reports?

The ideal solution is taking exchange data.

That could be achieved in trust-less way designing something like Cointoolkit, where your can run your own copy in each one’s browsers that connects directly to the exchanges, reads liquidity and crushes the data to get your own independent , verified result.

Much like ALiX, but without the problem of licensing/centralization.

Sounds ok. @masterOfDisaster has posted similar ideas.[quote=“Nagalim, post:6, topic:3210”]
Instead, we need someone to be recording the liquidity numbers and run the moving average formulas and come out with a number.
[/quote]

Alix already has 15min and 4hr moving average on display, and in plots soon. My curve fit predictive approach is even better.

Alix is great and all, but how do we take T3 into account? Do we add it to Alix? How do we reconcile the difference between Alix and tiered custodial liquidity reporting?

A cubic polynomial is much like an EMA. The question in that case is the same, how much time has to pass to consider a spike a real movement?. We don’t want to “fit” the curve too soon.

X has to be as conservative as possible, that is why I think a simple average over two weeks would be enough.
There is no problem if the X is not adjusted fast enough.

There are many ways to get similar indicators. Polynomial fits provide coefficients that are conceptually easy to understand, and is predictive by extrapolating the curve into the future.

By trial is the best way, I think.

X is a macro value. The micromanagement task (daily management) needs a quick indicator. I think decision making based on prediction with curve fitting may work out.

I think FLOT can be responsive for macro adjustment using X and T3 for micromanagement of liquidity using fitting of the last 2-3 days’ data.

After understanding what is needed Nu can post a bounty. To understand the more sophisticated indicators, we need to play with them using real data.

Would you mind modifying my simulation to fit your proposition?

I haven’t used google spreadsheet for a while. I will try to add fitting to it.