So the idea is that the more NuBits are exchanged per second (i assume that the more bitcoin price changes frequently, the more nubits are exchanged frequently), the higher the price of using a stable crypto currency should be, hence a higher spread.
Tks a lot.
By the way, i imagine in the next iterations of TLLP’s bot, one would be able to specify directly the offset inside the config file…
As for NuBot, my understanding is that one can already modify the spread (it is not called offset yet) inside the json file but my imaginative interpretation is that if you specify more than 0.2%, you would not be able any more to broadcast liquidity info to Nu.
Is that corrrect?
That is tricky. If not carried out properly, this motion will simply become a “guideline” and turn out to work in a way that @nagalim mentioned earlier, where specific spreads will be decided in custodian proposals. I won’t mind going that way if we can decided that is better for now, but a motion similar to this one will also need to pass sooner or later.
If faster motions are implemented, then when needed we could simply replace this motion with another, if other spread values are desirable. For example, when B&C exchange comes live the lower bound can definitely be adjusted downwards.
We should probably give some leeway if a pool has to change its spread values after securing a custodian grant, where they can choose to explain that change to get the next grant, and we treat it as an exception.
That’s right and that’s why Tier 1 liquidity providing is the most costly one. The parametric order book is going to mitigate that and once the spread is increased in times of high transaction volume, it might be possible to cut losses to a certain degree.
Tier 2 (and in some rare occasions even Tier 3; but that is another story and can hardly be automated) can be protected from hedging risks by proxying NBT/crypto pairs to USD (only the buy side is affected from this risk):
I don’t know whether “NuLagoon pool C” makes use of this idea, but I advocate for future versions of nubot or nupool to include such a feature on bot level.
Development of such a feature might cost money, but it would provide Nu with a return on invest if this allows for smaller compensation of liquidity operations.
I’m no developer, but I think most of the required features (price feeds, API calls to place or remove orders) are already available.
I think such a Tier 2 support is especially important for TLLP based pools, because they’re providing an important part of Tier 1 liquidity. It would be a big blow for Nu’s liquidity providing if providers decided to turn off their bots because of high losses in turbulent times.
It could not only affect liquidity, but endanger the peg.
I might have a solution that helps mitigating risks for them and is a reason to discuss about the offset and maybe to adjust it to a different level. Here’s why and what’s required to enable this:
Tier 1 can suffer from BTC fluctuation big time on supported NBT/BTC pairs.
Tier 2 handling is not included in nupool as far as I’m aware of it.
All available funds are placed in orders.
The latter one would need to be changed.
Tier 2 (funds on exchange but not on orders) is required for my idea to work.
Basically only exchange default risk remains (and risk of theft, etc., but no risk due to BTC fluctuation) for funds in Tier 2, if funds are kept in USD.
After Tier 2 is available in the nupool bot the missing link is a way to (manually) create a level of Tier 2 funds that is to be held in USD or to (automatically) adjust the level of Tier 2 funds in USD based on market activity.
The manual approach might quite easily be implemented.
Say you enable Tier 2 in the bot and define a level of 80% and 5 percentage points of deviation.
When the bot is fired up, your Tier 2 funds (buy side!) in USD the bot automatically shifts the Tier 2 funds to 80%.
Whenever somebody buys NBT from you or sells NBT to you and the buy side USD percentage is beyond the deviation, the bot places orders to move it to 80% again.
This way you can provide liquidity without taking the full hedging risk.
Default values should be Tier 2 level 0%.
In case Tier 2 funds get enabled erroneously the level of USD in Tier 2 should be set to 0%.
That way the bot behavior is by default exactly like it is now - which should allow a smooth transition from current TLLP bot operations
The price liquidity providers pay is that they receive only a reduced compensation as long as Tier 2 is not compensated in any way.
But it might be better to forfeit a part of the compensation than to take the full hedging risk.
And it is beneficial for Nu as it lowers the compensation for liquidity providing.
Until now you might have thought I were about to sidetrack this conversation.
As you can see now, this proxying approach generates costs (additional exchange fees for additional conversions) that need to be covered by
the offset customers face when buying/selling NBT pairs
Nu if it’s considered as a service
Even if this proxying idea isn’t followed by an implementation, the costs for providing liquidity remain - albeit in a less predictable way:
instead of trading fees for proxying (you exactly know the percentage it costs), you pay with a decreased value of funds that haven’t been proxied from BTC (or other crypto; you don’t know the percentage it would decrease).
The offset needs to be different for different trading pairs, like @desrever already pointed out
I’d like to distinguish between NBT/BTC and NBT/crypto in general.
The reason is that exchanges that offer BTC/USD often don’t have “random crypto”/USD. You need to take another proxy step. Wait a second - is there any pool offering non-BTC/NBT liquidity?
I hope this idea of proxying doesn’t sound too weird. This idea is floating around in my head for some time. I thought this might be a good place to describe it in more detail; this thread seemed to be appropriate.
Supporting proxied Tier 2 with an increased offset helps defending against hedging traders as well as malicious traders - they pay for the service Nu provides them with paying for the increased offset.
Even if this proxy approach isn’t feasible (because it is nuts, although I can’t see that yet), an offset of 1% (or more) helps cutting some of the losses until other ways to cut losses are available.
The lower limit as the wording suggests is allowed to differ by exchange (because it is a function of the exchange fee and currency pair), and the lower and upper limits limits for each trading pair is given above this part in the motion text. Can you tell me what forbids you from arriving at my intended interpretation?
Looking at the vote movement it seems the proportion of votes might stagnate below 40%. As this motion is a small part of the bigger picture of shaping liquidity provision standards I urge shareholders to give it some more consideration.
The motion might not be very good as-is but I believe sooner or later we have to move in this direction of deciding what people (shareholders, liquidity providers, users) should expect from NBT liquidity. If we can’t discuss and come to agreement on something as simple as this, it would be even more difficult when we have to adapt to more sophisticated requirements; getting NuBot out isn’t going to make this point irrelevant.
If you do not support this motion for some reason, please let us know why and we can see how to patch things up. Thanks.
I do not like a mandatory offset on top of the exchange fee on the NBT/fiat pairs. I still think that this doesn’t need to be specified and I think Nu is too you to allow large spreads. I think we need to encourage trading, not discourage at this stage. Happy to pay the price for that right now.
Therefore I think the motion is confusing and steering toward an undesirable direction or standard at this stage. The offset can just be zero.