[Passed] 1% Maximum Spread in Shareholder Funded Liquidity Operations

Allowing 1% spread on the order book means 1.25% tolerance, forcing 1% spread means 1% tolerance where LPs would sometimes only be compensated at 0.75% spread.

Asset liquidity should be defined by volume, where there is at least one easily accessible exchange with considerable volume. Litecoin doesn’t cut that nowadays.

Technically possible and practically viable are different things. Yes, it is technically possible to have a 0.00001% spread. However, it is not practically viable because if two LPs have a devaitation in when they place their orders that amounts to a 0.00001% difference then they will collide and both LPs will needlessly waste money on fees.

If we assume two LPs can have a deviation in price of 0.25%, we get a smallest maximum spread of 0.5%, by the math i just showed. But that’s still a minimum of -0.4% SAF (and a maximum of 0.1% SAF) and so can be gamed. For 0% minimum SAF you need 0.9% spread with a maximum SAF of 0.5%.

I would never vote for less than 1% maximum spread because it’s just not practically viable. At least it isnt with pybot, nubot may have tricks (streamer service) to try to help this.

@Nagalim’s proposal in this thread isn’t a competing motion because it deals with setting a minimum spread, so I will just note that our two motions are complimentary. His regulates minimum spread while mine regulates maximum spread. I can see the potential usefulness of defining a minimum spread, although there hasn’t been a need to regulate this so far. It is a very technical motion and those who are closer to liquidity operations are better qualified to comment on the appropriateness of Nagalim’s specific formulas and numbers.

The motions presented by @Cybnate and @masterOfDisaster are competing proposals. While these two motions differ significantly in the tightness of the spread they require, they share the notion that we should offer liquidity at different spreads simulaneously. Some liquidity providers are to offer liquidity at a low spread while other liquidity providers will offer at a higher spread. This approach is quite inefficient because the main cost of liquidity is due to the exchange default risk. Liquidity at a 0.5% spread and a 3% spread both have the same exchange default risk. However, NuBit customers will place much greater value on the 0.5% spread than the 3% spread. The 3% spread has most of the costs of the 0.5% spread but might only encourage NuBit adoption 10% or 20% as much (I admit that is a speculation based on little data) as the 0.5% spread.

When exchange default risk is involved, we will get our best value from paying for tight spreads. My motion in the OP is the only one that wouldn’t waste funds with wide spreads that are less cost efficient.

I am going to begin voting on my motion. Thanks to @masterOfDisaster for pointing out that illiquid trading pairs required an exemption from the 1% maximum.

2 Likes

The motion in the OP has been hashed on Daology and voting has begun.

The motion hash is:

b71a585de0b5e552648036fbc8282e11fea4a1cc

Except the current motion implies a 1-2% minimum and this motion states a 1% maximum, so they’re entirely contradictory. If the other motion is still valid then NuLaw will be contradictory at passagw of this motion and I will not feel compelled in any way to obey both, because that would be an impossibility.

I marked bold what is a claim for which we don’t have evidence.
The exchange default risk and all assiciated risks (account hack, theft, etc.) and operator costs are indeed the same.

But we don’t know how the spread affects the costs of the NAV of the operation, which will in one way or another have an effect on the costs, which in the end allpies for both Nu funded operations like the gateways and decentralized liquidity like ALP and MLP.

The smaller the spread, the smaller chance of making revenue from the spread. If you operate at SAF=0 there is 0 chance to make revenue.
If the spread is too high, the chance for making revenue is small, too. People just won’t trade. No trades -> no revenue.

Between an insanely close spread and a too big spread might be a sweet spot, where
trading volume * revenue (in percent) per trade
has a maximum per time frame
If the quality of the peg is perceived as great at this sweet spot, we should focus on that spread or else find a place close to it, where the peg is good and the costs are minimized.

There might be effects on that other than the spred alone: the particular exchange, the BTC volatility, the total volume at the order book, etc.
Market aware trading might be necessary.

Just saying a smaller spread is better just doesn’t work in such a complex world!
It might be better for the brand image of Nu, but it possibly comes at costs, we currently don’t know.
If the value of Nu increases by $100k from a better brand image, but you need $300k to get there, it might be better to increase the brand image by $50k while spending $100k. These numbers are random and just an example to make clear what I mean.

We need data.

That’s why I drafted

I want to gather data!

1 Like

That s true but I feel that Nu should not aim at trying to make revenues from the spread.
The reason being that it is not attractive from the user standpoint.
Instead it should make revenues from selling lots of NuBits at a tight peg while at the same decreasing the necessary reserve and liquidity to sustain confidence in the peg.
Large spreads gateways are useful to protect the peg while we are thinking about the next steps but we are not doing business with large spreads, I feel.

1 Like

This spread debate reminds me the Laffer curve :stuck_out_tongue:


where tax = spread
we just need to find the (T*) point :wink:

Not necessarily, but at least Nu should reduce costs.

One can argue whether that’s revenue or liability.
How is decreasing the reserve in favour of the peg perception?

I fully agree - based on theory and experience.

No one - not even me - is arguing for doing business solely with large spreads.
But maybe we need to define what “large” is in this context.

1 Like

Well the idea is to decrease the ratios 1) reserve/outstanding_nubits and 2) total_liquidity/outstanding_nubits to increase profitability like central banks seem to be doing in regard to FIAT.
Right now we have 150k of total liquidity.
So 1) is around 15% as well as 2) .
One can argue that 1) and 2) are already low.
In fact compared to theter (100%) or bitusd (200%) they are very low and yet nubits is the only real decentralized crypto fiat and yet holders of nubits are not asking at the same time to redeem their nubits: there is a certain confidence in the peg despite the fractional reserve aspect.
But is 15% the min ratio?
I do not feel so.
I think we neef to take a risk and bet that reducing further would be ok, as a DAO startup.
But we need to increase the confidence in the peg at the same time.
In order to do so the idea is to increase liquidity and reserves while decreasing the ratios.

It is good that the motion removes the 1% minimum barrier which is clearly not working and I have always been challenging for ALP use. However I think Jordan’s motion doesn’t take properly into account a layer of defence for the peg. Something which has been proven more than useful when ALP funds lay dry. That’s why I won’t vote for this motion.

I think the layered model I propose where 60% of the liquidity is provided by ALPs at the lowest realistic spread for the pair another, 30% at a medium spread and only 10% at a high spread would setup the Nu peg in a way that it can withstand the currently known threats while still being competitive.

Please consider my motion: [Withdrawn] 0.6% Maximum Spread for ALP/MLP, 1.2% for Nu Funded Liquidity Operations. Happy to tweak some sharp edges if that helps to get it over the line. Without further feedback I will put it up for voting after 24h.

I like @Cybnate’s approach that tries to regulate the distribution of volume at different spreads.
But I need to say that I don’t find enough data to make an assessment what’s a wise distribution of funds to different spreads.
We don’t yet know the true cost of liquidity provision at different spreads.
As much as I like clear regulation, I’d prefer room for discretion here, until we know what to do and how to regulate the distribution.

My motion is quite simple:

max. 1% for ALP and MLP, above 1% allowed (but not necessarily used) for Nu funded bots:

I think I will include

in the motion to finally define those terms.

I’m going to promote it to [Voting] if there’s no significant amount of rework detected.
The current motion is sufficiently different from the two other motions that try to regulate the spread to provide a real alternative for shareholders.

1 Like

Shouldn t the liquidity operators working at > 1% spread be able to get revenues from the spread itself and in that case shouldn t the rewards from Nu be double payment?

We don’t know that, although it might be the case.

Only Nu funded (bots operated with funds that belong to Nu!) operations are allowed at a spread >1%.
An increased NAV (if there’s actually revenue) from these operations is revenue of Nu. If the revenue from an increased spread is able to compensate operator costs and calculatory costs (e.g. exchange default, theft, etc.), Nu can essentially provide that liquidity for free.

ALP and MLP are forced below 1% spread. They get compensated by Nu for liqudity provision. No “double payment” here.

It is a balancing act. Sometimes ALP would be fully drained (high volatility) and sometime just half (some volatility). It will be hard to obtain hard data of the best balance. My argument is to have roughly a backup for the ALP provided liquidity -/- 10% (risk factor). I believe that number could be higher but I like to err on the safe side. It would be dependant on the level of volatility of Bitcoin. Something which will be impossible to obtain data for. One can only make assumptions.

It won’t be possible to get “the best balance”, because the balance is depending on the environment. The exchange (number of users, traders, daily volume), the BTC volatility and a lot of other factors play a role.
You need market aware shifts and need to create an algorithm - ideally a self learning one - if you want to be close to the “the best balance” for a given condition.
As well as the best balance depends on conditions, I suppose the best spread depends on conditions.
There’s a lot of work to do and I fear we don’t have the required skill set to do it properly at the moment.
Someone with a sound monetary or trading bot operation background would be very helpful.

I don’t know what the safe side is: having more or less buffer there?
More buffer means more calculatory costs, but an increased peg support.

Right.

What do you think of this proposal?

Don’t you think we can use that to gather data?

That’s why we need to start some tests and gather data. It would be great to do that in a scientific way, but I don’t have the skills to do that.

1 Like

As you are saying in your post it won’t barely be possible to get 'the best balance" as there are so many parameters in this environment. So I’m not sure why you want to gather data. Unless we can find someone willing to do that in a scientific was as you are saying and program an AI for this.

So before you gather I believe we will need to know what for and how we could use it, otherwise it is a waste of time.

To be able to know something about offering a small spread.
At the moment there’s the notion that a minimized spread is superior to a slightly increased spread.
That might be true liquidity wise.
It might not be true cost wise.

I want to know about the NAV over time of operating at a spread below 1%.

If Nu is a business, it must care about costs as well as the quality of the products.

Left your ‘if’ out and I agree.
Given the lack of velocity/trading on other exchanges, I think this would only be possible on Poloniex.
There is also the risk that by measuring you actually disturb the normal order making your measurements almost worthless. This won’t be easy to draw conclusions from, but I believe we should try.

Once there was more trading on hitBTC’s NBT/BTC pair (e.g. when I ran modPuddle).
The SAF was 1%.

I don’t remember the trade fee at hitBTC back then, but I remember that I made significant loss from trading. I could only continue for some terms, because the compensation was quite high.
If I had been able to make revenue from trading, well…

Let’s see what happens when orders at 1% spread (not SAF!) are on the order book.