yah but the shareholder voted prices like park rates. Does that require a fork?
Of course, the voting has to be extended by two parameters r and q with r * q = 0, where r is the rate to exchange NBT for NSR and q is the rate to exchange NSR to NBT. Both values have a maximum cap, which in the case of NuBits is also voted on in both cases (share and unit). Nu DAC shareholders are only allowed to vote on a max cap of shares, the cap of the credits is defined by the blockchain and does not allow to overspend.
The lending process furthermore requires to implement OP_CHECKLOCKTIMEVERIFY. This was done for blackcoin and was really extremely easy. Then of course the lending rates will be additional parameters to vote for.
All these parameters are 16bit or maybe 32bit words. In order to reduce the blockchain bloat, motions and grants can be indexed on the blockchain and specified over IDs in the voting, but it would take longer to go into detail about that.
So yes, its quite some stuff, but totally doable and if its only about the decentralized burning, then I expect it to be very safe because a lot of (well tested) code can be reused from the park rate voting mechanism.
So you would have the OP_CHECKLOCKTIMEVERIFY and the r, q happen in the same motion?
Also, what do you mean by r*q=0? Isn’t r completely independent of q as long as r < 1/q ?
Also, the long and short term trader model you were talking about, would that even need a new API call to run? In server.py, in credit(), the submitted=[] variable, does that contain the order number as known by the exchange?
That’s up to Ben or whoever intends to step up to merge this into Nu. I’ll write it in my branch and Nu is always free to merge it into its repo.
I don’t see any reason why shareholders should provide a positive rate to burn NBT and a positive rate to burn NSR which are not equal, because then you can make money by clicking buttons in your client. Having r = q > 0 would work, but would be very dangerous because the blockchain is actually not fast enough to come up with an exchange price and it will allow for opportunities on the cost of the shareholders.
So in my opinion either r or q or both should be 0 and if one is not 0 then shareholders should take care that it will stay below the exchange price. Note that all this should be solved by a professional data feed provider who just has a script running that takes the data from a ticker.
I am looking forward to such a motion.
Would you regard b & c as a nu dac ?
Why can’t we have something like 1 NBT burns for 1,000 NSR and 1,000 NSR burns for 0.1 NBT?
Totally! B&C has a private credit system. However, so far it is not intended to be pegged but to be valuated by the market. But B&C shareholders could decide to switch to a pegged credit and contract Nu to provide this service.
You are totally right! The spread should be gigantic as proposed by you, to react quickly enough in a fast market movement (note the 1 min block time). But this would work I think.
EDIT: However, I would really suggest to vote for a second parameter that specifies a maximum amount that may be burned at this rate. Shareholders can basically build up an order book at different price levels. This is important to control inflation better.
We can’t adjust the maximum burn volume via motion without forking if burning is decentralized like this?
When you say rate, you don’t mean volume do you? You think there should be a cap to the NSR/NBT price?
Indeed.
Would you think that using a non-pegged credit ( though 1 credit would be sold for 1 usd therefore for 1 nbt ) is design-wise a right decision?
A motion is a hash and doesn’t trigger anything on the blockchain when it passes. We can only elect a custodian to do the job for us in a trusted way.
I am almost afraid to answer but no. B&C holders will have to vote on fees and should pick the fees which maximize the profit. In a non-pegged credit system you have two random variables which determine the optimal fee, the credit price and the valuation of your service and no, in a low volume market with no liquidity as a credit of a DAC will have the valuation of the service is not calculated in the price, before someone starts with stock market examples now. The fee of a pegged credit only has one random variable and that is the user demand of the service, which allows for much more robust estimates.
So a DAC has a clear incentive to peg their credit and should be willing to pay a corresponding fee for the promise that the peg is stable.
I see. Tks for sharing your view.
Would we have confidence implementing this for liquidbits before the motion?:
That’s not hard to implement, but it is a crucial change in the system dynamic. You would have to ask the pool operators if they would want to do that. Actually my conclusion is, as stated in the post that made us totally go off-topic, that liquidity operations are not the right tool to encourage buy or sell side liquidity over the other side.
Maybe I’ll write a modified client that lets you place orders at an arbitrary spread on one exchange and rebalance simultaneously using existing LPCs on other exchanges. I think this could provide some more buy side liquidity(!) or at least it could prevent the peg to break too seriously.
Slightly off-topic (sorry for that).
I am not 100% convinced about the profitability of liquidity provision.
As I pointed out here, because of the volatility of btc/usd, as a lpc it seems it is very difficult to guarantee being in the black on crypto pairs.
What do you think about that?
I suspect most providers right now are doing it either for fun or because they are making a mistake between daily interest and portfolio return rate and/or because they want to try out or because they are altruistic.
I hope I am wrong in my assessment though.
But I feel this is one of the major issues of Nu right now.
The short and long term investor model helps to cure this concern by paying nbt orders at a flat rate and paired crypto orders at a rate that increases with time. This is more on topic than the burning stuff or B&C, in my opinion.
Yes, I didn’t want to say that liquidity operations are not good to provide liquidity but just not the right tool to encourage one side. To be honest, we all still have no clue what a reasonable price is. In the server log on the nu-pool I saw several interest rates below 0.1%/day and actually that is also a number I wanted to get the price to.
However, since there IS nobody willing to provide liquidity right now, and since there is also no organic liquidity, I am totally with you that much higher interest rates must be paid.
This would have somehow to take into account the bitcoin volatility…
Ideally Nu should cover (=pay back) the losses taken by the lpc in case the lpc loses money because of btc/usd going down.
I agree on that. After more than 6 months from being released, Nu has only 40k of buy side liquidity.
(nupool is contributing greatly to that.)
This is obviously very small and cannot get NuBit very far as a currency for the Internet.
We would need 1000 times that figure I guess, I feel.
I do not feel there is a simple solution to the profitability issue for crypto pairs.
Ideally, LPC should be only paid for taking the risk of exchange default, which implies LPCs should only exist on FIAT pairs.
I am worried about the fact the community does not seem to be aware of this crucial issue, although we have seen @mhps calling for providing liquidity on FIAT’s gateways or @woolly_sammoth providing liquidity to bittylicious.
I am imagining somehow that the b&c would help lpc’s profitability by giving them back a portion of the trade fees since Nu and b&c would have a very special relationship enabling them to pass special deals
What is the point of decreasing the liquidity costs from Nu perspective if there are only a few LPCs in the first place (because of the low predictable profitability)?
I expressed my opinion on that several times including in the TLLP operation and don’t want to comment any further on that. The nu-pool works very well, indeed. It was the community feedback which brought it in this (relatively) stable state.
The problem is that the money in the pool is mostly shareholder participants, so just increasing the target of the nupool or launching on multiple exchanges won’t be enough. Its fresh money that has to flow into NBT and that ideally should also stay there, otherwise its just ponzi.
The FIAT gateways are still my absolute favorite from the ideas proposed, it was also discussed in the ethereum hangout. It gives a wonderful use to stable currencies.
1 Like
What you need is a triple bot that matches orders on btc/usd, usd/nbt, and nbt/btc markets.
What I’m offering should be observed as a payment plan for buying nbt with btc, in my opinion. Jeffrey comes in with btc and wants nbt to park cause he believes in Nubits. So he puts up btc on the liquidity wall. If we assume the btc price is a random walk then he knows less and less about the price with time and his bid gets riskier and riskier, so we pay more and more. Eventually, someone buys his order and he makes a little extra holding on the sell wall until the rest of his order fills. Now that he has the nbt, he goes off to do something else with it, like park or convert to USD or whatever (burn for nsr).
If the buy wall is low, they won’t be able to stay on the buy side long. However, in that case we should have high park rates anyway.
Sure, I’m down with that. Multiply the growth of the payment rate by some factor relating to the number of times the bitcoin price has shifted recently.
I don’t think we should be providing bitcoin insurance. I definately agree that we should be focusing on nbt/fiat pairs, and realizing the intricacies of dealing with a static peg.
1 Like