[Passed] Motion to regulate spread values for liquidity operations

dysconnect · June 3, 2015, 12:24pm

UPDATE: New motion body
UPDATE: Newer motion body and modified introductory text
UPDATE: Even newer motion body
UPDATE: Motion hash determined after minor amendments.

When I began drafting this post, there was about 35k-36k NBT liquidity each on the buy side and the sell side.

Liquidity providers face considerable volatility risk and the possibility of exchange default. Shareholders pay a high price to mitigate these risks. Nu provides disproportionately deep liquidity at small spreads, which the network maintains at a non-trivial cost.

Some view this as a salient feature of our network that attracts adoption, and any costs of maintaining this state are hopefully seen as a loss-leader. This is however not well appreciated by the general cryptocurrency community, and our pledge of stability is mostly taken advantage of by speculators, for whom we shoulder the burden of BTC fluctuation without requiring just compensation.

I cannot help but argue that in fact we have been too eager to please, at the cost of shareholders and liquidity providers, to the detriment of the health of the network at this early stage of development, which may eventually undermine our mission of providing a stable, decentralized currency to the world.

I am aware of proposed features such as the parametric order book to reduce the volatility risk of liquidity providers, scheduled to be implemented with NuBot 0.3.2. The aims of this motion are not formally covered by such proposals, where compensation schemes have not been established. This motion is also an initial step towards the regulation of liquidity operations, allowing shareholders to formally agree upon standards expected of the quality of Nu liquidity, offering predictability for parties within or external to the Nu community.

I propose to mandate, in effect, minimum and maximum values of permitted spreads for all liquidity operations. I intend this motion to be an incremental fix with a low technical burden for ongoing operations, and consistent with upcoming planned changes to core software. The motion, though having a long wording, offers a simple provision, and in my opinion the change I propose is rather conservative. This motion may not lead to a very significant reduction of network costs, but is a cautious step towards the right direction.

Motion RIPEMD160 hash: 0ec0be7f113a0bf6ff603545a974cd6410458e00

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=

For all liquidity operations that are paid for with custodian grants, operators shall ensure liquidity providers are not discouraged to provide liquidity up to a specified minimum offset from the target peg of 1 USD = 1 NBT, which we call the guaranteed offset.

With a guaranteed offset of x, NBT asks made within the range of 1 to 1 + x USD, as well as bids made within the range of 1 - x to 1 USD, shall be compensated at the same rate within each operation.

This motion also imposes lower and upper limits of the guaranteed offset.

For liquidity operations between NBT and BTC, the guaranteed offset shall be at least 0.005 plus the exchange fee rate, and at most 0.05 plus the exchange fee rate. For example, if the exchange fee is 0.2%, then the operator shall ensure that the guaranteed offset is at least 0.007 and at most 0.052.

For liquidity operations between NBT and USD, the guaranteed offset shall be at least 0.002 plus the exchange fee rate, and at most 0.02 plus the exchange fee rate.

For liquidity operations between NBT and fiat currencies other than USD, the guaranteed offset shall be at least 0.002 plus the exchange fee rate and at most 0.05 plus the exchange fee rate.

For liquidity operations between NBT and cryptocurrencies other than BTC, the lower and upper limits of the guaranteed offset shall be established through a motion before custodian grants can be given.

Operators shall inform shareholders of the intended value of the guaranteed offset, and participants are also given convenient options to take advantage of the guaranteed offset, such as by having relevant parameters and settings chosen by default.

For ongoing operations running on custodial funds granted before the passing of this motion, the guaranteed offset may be set to any value in the range of the lower limit to twice the lower limit, for each exchange, at the discretion of the operators, until making subsequent requests for custodial funds.

=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

Verify. Use everything between and including the <motionhash></motionhash> tags.

mhps · June 3, 2015, 1:03pm

I support this. It’s long over due. The whole PEG industry has a spread of 2-5% and people regard PEG-issued USD e-currencies as USD. Observing the exchange rates of these e-currencies one can see that the spread is determined by how easy to buy and sell a pair on the market (availablity and liquidity).

Nubit is no different. It should have a less spread as it should have less friction, and needs less infrastructure, to move around. But we should leave the market to determine the spread after the initial promotion period. Artificially tight spread inhibits private for-profit market participation to sell/buy Nubits.

cryptog · June 3, 2015, 1:58pm

I would strongly support such a motion. I am glad that you decided to write it.
I have been questioning the predictable aspect of liquidity provision starting with this thread.
My internal conclusion was that providing a stable crypto-currency is in itself a useful service and therefore the market should find a right pricing for that.
Right now, such a service is basically offered for free to traders.
This is not right because this is artificially fixed.
We have not tested what the market thinks is the right price and yet we set the price to 0 usd.
Some people say that increasing the spread would tarnish the accuracy of the peg.
I do not feel so.
The peg would still be kept. It is just that you need to pay a commission to have the privilege to use such a stable currency.
Allowing the spread to be 2 times what we have right now is conservative but a good beginning.
I am ready to vote for it.

Nagalim · June 3, 2015, 2:00pm

Spread for nbt/crypto and nbt/fiat should be different. Spread for nbt/crypto should be more.
This motion will reduce the current spread. The current spread operable on most pools is around %0.5 to either side of the peg.

It depends on the chosen operator tolerance, but most have chosen 0.007 or 0.0085 (NuPond_CNY being the exception with an aggressive 0.0025 tolerance). If you take a 0.0015 or 0.0025 deviation, you can easily attain a spread of %0.4 to either side on any operating pool (again, other than my fiat pool).

All you have to do is change the parameters in your trading.py script for your client.

masterOfDisaster · June 3, 2015, 2:04pm

Thank you very much for starting the discussion about that topic.
If you ask me, I’d make it even simpler.
Instead of 0.2% exchange fee + spread, allow on each side a maximum of 0.5%.
This way Nu supports only liquidiy providing with a total spread of below 1%.
1% is slightly higher than your draft, but easier to be handled by people’s minds than 0.8%.

Exchanges may feel motivated to reduce the NBT trading fees at pairs that are supported by Nu to attract liquidity.
Because the lower the exchange fee, the more money can be made with a total spread of 1%.
And that doesn’t mean the spread needs to be 1%, only that it’s supported up to 1%.
Exchanged like CCEDK that provide zero fee trading for trading pairs (at the moment for e.g. NBT/BTC) are attractive for liquidity providers if you don’t tie the spread to the exchange fee.

Liquidity providers that are able to offer a smaller spread for the same compensation will be preferred by Nu.
That helps shifting liquidity providing towards the fiat pairs.
Go forward!

Nagalim · June 3, 2015, 2:07pm

All of this should be spelled out in the individual custodial drafts. ‘Tolerance’ should be a parameter that is pledged before voting begins, and it should be one of the competing parameters in the grant (like ‘rate’ and ‘target’ are).

dysconnect · June 3, 2015, 2:36pm

What you say makes sense, and prompts me to do more research on the current state before finalizing this motion.

I agree that the spread shall be partly up to the discretion of the pool operator and the liquidity provider, but I think it is important that we impose a lower bound across the board for at least BTC/USD, and I also hope to do that with ongoing operations. A uniform lower bound gauges unhealthy competition between different pools, as well as among liquidity providers. What goes into custodian grant proposals are going to be whether they use a larger tolerance.
The actual spreads I’ve measured are about 0.25% on either side (overall about 0.5%) for NuPool. For the BTC/NBT pair on bter I don’t see enough funds for me to take measurements. For NuLagoon I can’t find what exchanges it operates apart from bitcoin.co.id, where there’s very little visible liquidity at a tiny spread.

mhps · June 3, 2015, 2:44pm

When we say USD on, for example, ccedk, we should call it ccedk-USD because as I discussed here, USD entering an exchange already has a cost attached at typically 0.5 - 3% level. Since friction for crypto movement is very low (less than 0.5%), even we offer 0 spread for at ccedk for ccedk-USD, we are actually offering 3% spread for real USD. So my intuation is that NBT/crypto spread will end up smaller than that of NBT/exchange-USD, simply because exchange-USD/real-USD already has a 0.5-3% spread (fee) so people accept a little more overhead. It would also depend on fee charged by competitors.

Nagalim · June 3, 2015, 2:47pm

I agree people are running ~%0.2 spreads. The only reason to this is:
a) they’re ignorant
or
b) they’re generous
It is the individual liquidity providers’ own faults that they are losing money right now, in my opinion. I was running a %.7 spread (%1.4 total) on NuPool on bittrex for a while a few weeks ago, and I tried to announce that as loudly as possible. I even went so far as to design 2 new versions of trading.py that had different spreads for BTC vrs NBT side (prefunit’s Grass and Champion).

We can make a lower bound if you want, but we could also just verbally agree on that. It will come out in the voting and discussion on individual grant votes anyway.

Nagalim · June 3, 2015, 3:08pm

Right, so let’s call 0.5% the minimum legacy fee. If %0.2 is the exchange fee, and %0.1 is a technical minimum (i can explain this, but let’s call it a trial and error thing having to do with the bots and deviations that I’m working on minimizing), then the minimum tolerance a custodial grant should offer is really 0.008. The resultant operating spread for the client will likely be something like %0.6 with %0.15 deviation. Since %0.2 of this is exchange fee, the actual deviation a custodian can feel on their buy and sell peg prices and still not lose money on the trade is a total of %0.8.

So if tolerances are set to 0.008, we should expect to see custodians lose money only if the price changes by more than 0.8% faster than our granted rate of custodial compensation. (the 8’s are coincidental) This is assuming, of course, that liquidity providers are neither ignorant, nor generous. This is currently not the case.

dysconnect · June 3, 2015, 4:19pm

In that case it is a matter of compelling operators to use a high default setting and then explicitly mention it, possibly also with easy ways to change the settings. I played with NuPool previously and was ignorant, and it also seems to be the case for many people who are running NuPool now. I am willing to say I’m stupid (I fired up nupool again after setting trading.py, thanks), but there have been some obstacles in establishing this knowledge among users.

I also do not think this is too much a formality for this matter. It is meaningful to set a standard for individual grant requests, so that there is formal agreement that non-complying requests should be automatically rejected. It is my understanding that voting is a best way to establish such formal agreement. In creating a motion, we acknowledge the possibility that a majority of the minting shares may disagree with having higher spreads.

Here is a new motion body that reflects upon the discussion above:

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
For all liquidity operations that are paid for with custodian grants, operators shall ensure liquidity providers are not discouraged to provide liquidity up to a specified spread limit, which we define as the tolerance.

Under a tolerance of x%, liquidity providers shall be compensated for bid orders made at x% below the target peg or above, and for ask orders made at x% above the target peg or below, where the target peg is defined as 1NBT = 1USD.

Liquidity providers shall be informed with the tolerance, and provided with convenient options to provide liquidity at the maximum permitted spread within tolerance, such as having such option chosen by default.

This motion also imposes that the minimum tolerance permitted for liquidity operations between NBT and crypto coins is 0.5% plus the exchange fee rate. For example, if the exchange fee is 0.2%, then the tolerance shall be set to no less than 0.7%.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

Nagalim · June 3, 2015, 4:32pm

I would vote for that motion, but I’m scared of the wording. Server tolerance must be strictly greater than client deviation + spread. With the wording as is, we will end up with the ‘spread’ parameter in trading.py = %0.5, which means a %0.3 “spread above fees” as you define it. If you want a %0.5 minimum spread after fees, the wording should say “a minimum tolerance of 0.009.”

I.e. You can assume there is a technical difference of %0.2 between server spread and client spread in addition to the %0.2 exchange fee. As servers can only define ‘server spread’ (called tolerance) via grant, we must keep such technicalities in mind.

dysconnect · June 3, 2015, 6:05pm

Please see if this is alright. I’m putting it into the original post for now.

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
For all liquidity operations that are paid for with custodian grants, operators shall ensure liquidity providers are not discouraged to provide liquidity up to a specified spread limit, which we define as the guaranteed tolerance.

Under a guaranteed tolerance of x%, liquidity providers shall be compensated at a uniform rate for bid orders made at x% below the target peg or above, and for ask orders made at x% above the target peg or below, where the target peg is defined as 1NBT = 1USD.

Liquidity providers shall be informed with the guaranteed tolerance, and given convenient options to provide liquidity at the maximum permitted spread within the guaranteed tolerance, such as by having such option chosen by default.

This motion also imposes that the minimum guaranteed tolerance of liquidity operations between NBT and other cryptocurrencies is 0.5% plus the exchange fee rate. For example, if the exchange fee is 0.2%, then the operator shall ensure that the guaranteed tolerance is at least 0.7%, i.e. all liquidity providers who make orders at up to 0.7% spread on either side are compensated at equal rates.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

Nagalim · June 3, 2015, 6:15pm

But the actual operating spread, i.e. the ‘spread’ parameter as defined in trading.py, will end up being %0.5. I don’t want to belabor the point, I just want you to be aware what this means and that it’s different than what you made mention of. For example, under this motion, a liquidity provider will end up placing orders for 0.995 NBT and 1.005 NBT. If you wanted %0.5 after fees, you would want them to place orders at 0.993 and 1.007. To accomplish this, we need to credit orders at 0.991 and 1.009 because the effective price feed deviates from 1 NBT by approximately %0.2.

Your motion is fine, but honestly the only thing it will change is that pool operators will be more aware of their defaults. All current pools satisfy the limits imposed by this grant as is. A tolerance that would allow %0.5 profit above and beyond exchange fees would be more like %0.9 tolerance, and would require all crypto pools to change their server parameters.

dysconnect · June 3, 2015, 6:41pm

I see your point. In the current draft it is for pool operators to make sure 0.7% spreads are actually paid for, even if it means there would be side effects e.g. the practical server tolerance has to be made higher than 0.7%.

I will try to make this more nuanced, but I also want to give it a more general tone. Perhaps we can talk about best effort, and let grant proposals state some of the side-effects if it affects the actual spread.

I am almost guilty for asking pool operators to do more work spelling out details like this, but I also feel that spreads are important enough an aspect that we should regulate.

Nagalim · June 3, 2015, 6:49pm

The issue is that it is not the server’s job to make sure the client is keeping up on the price feed. If an operator uses %0.7 tolerance, then indeed all orders that are %0.7 away from the server’s price feed will be credited. However, in reality this means that the client must operate at a smaller spread if they want to be credited 100% of the time. We could definitely phrase it in a ‘best effort’ way, but then this isn’t exactly a formal statement of minimums.

If you want a formal statement that is also fairly general, pool operators can very straight forwardly comply with:
No TLLP grant shall be provided for a crypto pool operating at a tolerance of less than %0.7 plus the exchange fee.

I just think we should be clear about what we’re asking pool operators to do here, especially with regards to a static number like tolerance.

Edit: I guess what I’m saying is that currently, with our %0.2, we are effectively operating with a %0.4 tolerance. If you want to increase our spread by %0.5, we need to increase the tolerance by %0.5, so we need a %0.9 tolerance.

Nagalim · June 3, 2015, 7:41pm

The talk of tolerance is mostly unnecessary except from the shareholder perspective, I’m sorry I spoke of it so much. I hope this isn’t too forward, I was just having trouble explaining it completely:

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
For all liquidity operations that are paid for with custodian grants, operators shall ensure liquidity providers are not discouraged to provide liquidity up to a specified minimum spread, which we define as the guaranteed spread.

Liquidity providers shall inform shareholders of the corresponding tolerance and give participants convenient options to provide liquidity at optimized values for spread and deviation, such as by having such options chosen by default.

This motion also imposes that the minimum guaranteed spread of liquidity operations between NBT and other cryptocurrencies is 0.5% plus the exchange fee rate. For example, if the exchange fee is 0.2%, then the operator shall ensure that the guaranteed spread is at least 0.7%.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

desrever · June 3, 2015, 9:32pm

This is a very interesting discussion and one that I want to participate since I have been dealing with those walls full time for one year now.

TL;DR; I agree we should agree on a min-max spread range and force custodians to use that.

Whatever the outcome of this motion will be, I will reflect it in the default parameter used locally by nubot and on the push streaming service.

I think that great part of this discussion is not new and there is some “reinvent the wheel going on” in this thread.

I am not sure we ever had a written contract/rule/motion anywhere obliging custodians to use a specific spread. Its about time we find an agreement on this and I am glad you came up with a proposition. So far spread has always been exposed as configuration parameter from 0.1.4 in NuBot ( I am not sure how it works in the TLLP) and several times custodian changed it to see market reactions. The default spread in nubot is 0.4%, aka 0.2% per side (plus the exchange TX fee, which changes depending on the exchange) .

While I am well aware of the spread problem, I believe the solution cannot be imposing an arbitrary large spread alone. Rather it should be a dynamic market-aware spread (planned in a few iterations of nubot) combined with liquidity distributed around a central price rather than single walls.

That’s not actually true. We are now testing now 0.3.1 and 0.3.2 will come shortly after, most of the work is already there. Anyway, regardless the fact that we have the parametric order book in place, this does not affect your motion about imposing a boundary bid/ask spread. So in this sense this motion is very welcome.

Re OP : your reasoning is correct when you say that we have high cost of maintenance. I find it a bit flawed when you make a comparison with the orderbook of LTC at a random instant of time taking only the top bid/ask. One of the points of NuBits is providing liquidity in a way other coins cannot provide, resulting in outstanding market velocity. Please see some interventions here and here where @JordanLee calls for nubits as an “intermediary coin” thanks to its liquidity operation, along with all my opposition and final outcome. So really, the LTC comparison doesn’t help much the discussion imho.

We deal with three kinds of pairs, grouped by volatility level
NBT/USD (0 volatility)
NBT/FIAT (little volatility)
NBT/CRYPTO (high volatility)
Please specify boundaries for each specific case.

When you say guaranteed tolerance do you mean the bid/spread ask? Or are you saying that sell orders should be placed at the crypto equivalent of 1$+0.07$ and buys at 1$-0.07$ ? In the latter case, its more an offset expressed in $ from target price rather than the traditional bid/ask spread of orderbooks. Wording is important in motions, please edit.

How do you measure the bid/ask spread in percentage btw? In different codes/docs I’ve found at least three different ways to compute the spread and the result is different.
let bestbid be the price of the highest bid and bestask the price of the lowest ask.

 spread1= |(bestbid/bestask) -1| * 100
 spread2= |(bestask/bestbid) -1| * 100
 spread3= (|bestask-bestbid|) / (((bestask+bestbid)/2)/100)

Beside some adjustment to the text of the motion, I think the rest looks good.

Also, please take into account that while I think that setting gross boundaries for the spread is a good idea, the next step is to make the spread dynamic, aka, market-aware.

Comments on other replies

very correct

So @masterOfDisaster is also proposing a maximum spread for compensation. Is this clear in your motion?

c) in the early stage of a product custodian and the network had to pay a price to comply with the “always 1$” promise rather than “more or less 1$”.

Also here I am getting a bit lost. I am not even sure who is developing what. We had long discussion on price feed/averages/tolerances/sync across exchanges, custodians, etc. Hours have been spent in design and development in this regard. Last time I spoke with creon I told him that we were about to roll out a “push” service that suggests prices to bot (and spreads soon). It is being tested as I type actually, and I strongly believe that TTLP clients should consume this service and be advised on prices (and spreads later). Did someone else took over development of pools? Whoever is working on it, can please make sure that we don’t make (wrong) things twice? This is also at the expense of shareholders.

Nagalim · June 3, 2015, 9:53pm

Ok, that’s really cool. That’s different from the current setup where the client picks the price to put the order up at and I applaud it.

As far as the people running %0.2 spreads being ignorant, I just meant from the perspective of TLLP, where most pools can actually be run with >%0.5 on either side without penalty. If a person is offered free money and doesn’t take it, either they are ignorant of the offer or they are feeling generous. Running with a low spread intentionally for the good of the network at the cost of your own finances is considered generous in my opinion.

I propose a global minimum spread of %0.5 to either side (%1 standard trading spread) for all liquidity operations on currencies that are deemed ‘high volatility’. So if BTC were worth exactly $1, we would do best efforts to compensate sell orders at $1.05 and below and buy orders at $0.995 and above. It’s a little convoluted, because the minimum allows for pools which compensate sell orders well above market price, but I believe such pools will never get a grant proposal passed. This is meant to be a minimum guideline for pool operators, and a requirement that they state what their actual compensated spread is, such that shareholders can use it as a voting parameter.

Maximum global spread compensated should be something like %5, I think, to correlate with legacy.

desrever · June 3, 2015, 10:53pm

nope.
There is a misconception here, and it is very important to clarify it.

Even with very sophisticated algorithms, wide spreads, small walls, custodians on crypto pairs are at high risk of losses in term of USD. Custodians will generally be on the wrong side of trades. They will buy NuBits when BTC price is raising , because traders want to enter BTC and leave NBT. Viceversa, traders will buy NBT from custodians when they “feel” BTC price is going down, leaving custodians with a devaluing asset.
This is a fact. The spread can do nothing against it. A 1% spread protects us from instantaneus arbitrage, mispricing , hft bots, bugs. A 1% spread will not protect us from BTC swings that are generally in the order of 5-10% , daily.