Not sure this would be the case. NBT is more liquid among exchanges than USD. There is a ~2% fee to move USD and it takes hours even days to transfer it. The lower friction of moving NBT will make BTC/NBT price more uniform among exchanges. (Compare it with BTC/USD which can vary by 10% among exchanges.) So it seems that people would choose NBT to hedge BTC volatility over USD, given the option.
If we’re talking ALP, we should just talk about how much money we want to spend on each pair. Each pairing should be analyzed independently, i.e. polo btc/nbt is just as different from bittrex btc/nbt as it is ccedk eur/nbt. Then, pick a level of funding and we get what we get.
For example, i am paying 10 nbt/day for my cny pool and 4 nbt/day for my btc pool. Then we simply look at key metrics like volume and provided liquidity and balance. If we like the performance (whatever we want that to be) we can increase the funding or vice versa.
I very much appreciate your efforts to tackle one of the biggest risks Nu faces - depending so much on BTC (especially the price level).
This idea (evade BTC volatility risk) isn’t entirely new as the drawbacks of offering a hedging instrument have become clear quitre early:
Strangely - so far there hasn’t been much interest in it.
NuSafe is the only contracted provider offering a reserve in USD.
MLP could do the same, albeit in different way:
The paradigm shift might pave the road for a more focussed liquidity provision scheme, in which focussing on USD trading pairs for US-NBT could be accomplished as well.
By maintaining only small order sizes (with Nu funds) at an offset of above 1%, Nu evades the hedging risk partially.
Smaller offsets will be covered by ALP, which receive a compensation from Nu for taking the main hedging risk.
So Nu still has to pay a price for that hedging instrument, but only in a limited way compared to now.
To clarify further, I’m not suggesting a push to remove BTC/US-NBT pairings on exchanges. I’m suggesting that our automated buying and selling bots on these exchanges would only operate via USD… Not sure if that came through - if so, sorry for being dense…
For example, on exchanges like Poloniex, a bot technically wouldn’t be maintaining a 1 USD = 1 NBT peg… but a 1 USD = N BTC = 1 NBT peg… And with BTC going up and down a bunch in the middle, that sounds like a bad way to establish a 1:1 USD:US-NBT ratio…
Yea… of course… but I think this is the problem…
Did we intend NBT to be “the thing people use when they want to avoid BTC volatility” ? And then go back to BTC when things calm down?
In other words, are we willing to say “we’ll take your BTC anytime you want to give it to us, and deal with the ups and downs of that, and we’ll also make sure that what we gave to you is always going to be 1 USD” ?
I thought our goal was to make a currency that was good for buying stuff and “saving” money – avoiding stock-market-like volatility (that’s NSR…), not absorbing BTC volatility for people when things get rocky…?
Happy to call this “[Silly]” and move along, just want to make sure I understand…
What im trying to say is that 0 is infinitely far away from 1 nbt/day when considering pool support. Instead of dropping to 0, could shareholders afford 10 cents/day? Then it’s really just about the cost of the operator, which tends to not only be cheap but also be an investment in trustable humans. Dropping support to 0 just seems like we’d be shooting ourselves in the foot for very little gain. Try dropping support by an order of magnitude or two, instead of infinite orders of magnitude.
I think I got that.
Did you read the references that dealt with “proxying BTC to USD”?
The main problem I see (apart from the technical implementation): if you trade received BTC to USD, you
- have to leave the USD on exchange, if you want to have them ready
- have to pay the fee for converting BTC to USD and vice versa
Instead of leaving the USD at the exchange account, you could withdraw them (the risk of an operator going rogue is always there when having operators dealing with Nu funds).
But I bet this can lead to some confusion regarding tax.
So for the T1-T2 liquidity this could be a solution.
T1-T2 deal only with a limited part of the reserve.
The higher tiers require a more complex solution.
If I understand you correctly your proposal is to modify TLLP bot to something like this:
I think the reason is that T4 buyback reserve has 118k NBT on the buy side and liquidity cost is 10k, so at current rate Nu seems to be able to afford to go on for another year, ignoring the value in NSR. Most shareholders have the illusion that the problem is far in the future.
But the problem actually can be felt starting this week as the buyback fund has run out of surplus for the first time ever. From now on if BTC price is stable, every NBT printed to pay for liquidity will push buyback fund to more negative, eventually triggering park rate, followed by share dilution. The resereve-erosion rate due to liquidity ops will be $1,500 a month.
The solution is simple:
Paradigm shift now!
Focus on US-NBT/NBT!
The solution must be to reduce costs or increase demand. If we reduce costs, we have to do it on some pool. We spend 500/month on bter, 1.5k on ccedk, 5k on the tube (for god knows what reason), 1.5k nupool, 500 gateways. It seems obvious to me that we should be focusing on reducing the costs for NuLagoon and ccedk.
what do you think about this reason?
Yah, i basically think we should just cut nulagoon in half and see what happens. Unfortunately, i think we’ll get an ultimatum of all or nothing from @henry. However, i simply dont think liquidity is worth 10k/month anymore now thay we have a working gateway/T4 system. Nupool took a cut, nupond took a cut, only pools left are liquidbits and nulagoon, neither of which have cut substantially in 6 months.
If the “paradigm shift” continues, all ALP and MLP will have to face cuts…
I suppose, those who provide an important service (fiat trading pairs, NuLagoon Tube) will be spared to some degree.
Tube doesn’t need 40k total. Cut it in half, 10k per side is plenty.
As you can see here, the vision of jordan lee is to have a nubits whose liquidity is superior than bitcoin for trading any crypto asset including bitcoin.
So it seems inevitable to be exposed to hedgers’ play.
The problem with “paradigm shift” is that it reduces drastically the liquidity which seems to be incompatible with the original goal but looks like a good band-aid solution that lets Nu try to create a lot of demand for NuBits.
As pointed here by nagalim, [quote=“Nagalim, post:14, topic:3698”]
The solution must be to reduce costs or increase demand.
I think that ultimately we need to increase drastically the demand for NuBits, so that the costs (for liquidity operations) is much lower than revenues.
We might need to increase rates or even dilute nushares, but if it creates a long-standing demand for NuBits, it makes sense.
Nu can’t increase demand by will, but can reduce costs.
Nu won’t survive for very long, if the (liquidity) costs can’t be reduced significantly.
Not performing the paradigm shift endangers Nu and can lead to its bancruptcy.
After the paradigm shift less money will be lost by offering a convenient BTC hedging tool.
There are then still tens of thousands of USD value in NBT and BTC availabe, just no longer anywhere both of it (at some exchanges Nu will be offering NBT only) and no longer tens of thousands of USD value at a small spread.
Don’t be dazzled by the big trading volume that comes from a big liquidity at a small spread!
This is not the business Nu is needing.
That only makes traders rich at the expense of Nu.
This has nothing to do with the payment system Nu was designed for.
I would like a comment (or more) how NU Lagoon can fit into the above scheme. Not as it is right now, i guess.
Only me and Nagalim are expressing our concerns about NU Lagoon recently!
Edit: Moreover, i would be very pleased and feel much more secure about NU if the “active” people here
that “drive” in some way the NU give us some clues about their speciality area (economics,software,management,etc)
Im just going to say science and leave it at that.
I beg to differ
I will support the motion if you guys come up with one.