Custodial Rules for the Static Peg with Fiat

This was being discussed in the liquidbits thread.
We would like to encourage people who bring fiat to the table as opposed to nbt, but we want to discourage custodians from trading across the peg to obtain that fiat.

Cooperative model:
One proposed route of solutions came from the concept that we could pay everyone involved equally based on how big the fiat wall is so everyone is equally motivated to ensure fresh money for the buy side.

Historical Custodian model:
Another proposed route of solutions came from the concept that we can look at account histories to find true deposits and withdrawals.

The cooperative model disincentivizes grassroots efforts while the historical model is difficult to implement.
How can we properly compensate supporters of the USD peg?

1 Like

I think it is interesting to note that this problem comes about even with a flat rate and even targets due to the dutch auction. If one side is at target, it is worthwhile to custodians to sell to the side that is not at target. We can control this pressure with the targets, we don’t even necessarily need to adjust the maximum rates (though that would make it more obvious to custodians which side is more profitable).

I’m starting to think the only way to fix this is to track custodial trade histories to see what nbt/usd trades they made. The only way to trade nbt/usd off the books in that case is to do a costly fiat transfer to a non-custodial account.

What opposition do we have to the historical custodian model? @Creon listed the technical hurdles as follows:

Is there a possibility of the server being DDOS’d by large trade histories?

I have a solution!

Y’all won’t like it, but it’s a solution. We have the price for buy side = Volume of buy side / target volume. For sell side, just have a static sell price be $1.002. Cap the buy side at $0.998 just to be consistent. I’ll call this the Price/Volume model.

The benefits of this model are that the people providing support during a period where there is little support get a huge spread, bigger the less money they come in with. It generates competition without profiting custodians trading across the peg. In the condition of full targets, it doesn’t change the outcome. Dutch Auction can still be implimented. Volume caps can be adjusted on buy and sell side independently. I would recommend a flat compensation rate on both sides of the peg, but it can be low, even resembling parking rates.

The detriment of this model is that it does not promote as tight a spread on the peg as we would like. However, you have to ask yourself, should we really even have that tight of a spread if we cannot provide target support?

I’m having a hard time following how this would work in practice. Do you have a sample scenario you could use to explain it with a couple of pool participants (some bringing only USD, some bringing USD/NBT, and another with only NBT)?

Joe, Mary, Ed and Grace are the only people who use CCEDK, and only for the NBT/USD pair. The targets are $10 on each side with 1%/month compensation.

Joe shows up first and has $8 NBT and holds it at $1.002 for 1%/month compensation.

Mary shows up with $4 USD and $2 NBT. She puts the NBT at $1.002 for 1%/month compensation. She also puts up the $4 USD, but the bot puts it at $.4 for 1%/month compensation.

Ed is a trader and just trying to make a quick buck. He buys NBT for arbitrage, but doesn’t sell any here because he can’t get a good price. Maybe he puts up a buy order now and then to try to make a profit on the huge spread.

Now Grace shows up with 10 NBT and 10 USD. She just drops both in her custodial client and walks away. Now the targets are full and Mary’s USD is now placed at $0.998. Ed comes back and starts using CCEDK to arbitrage, since he can get competitive prices on both sides. Mary, Grace, and Joe are getting paid less than 1%/month because they’re in competition.

Once Ed has sold into the buy wall below the target, the buy side support price declines again until the target can be reached once more. Mary, who now has NBT, will not sell to the buy side if it is under target because she will lose a lot on the spread and have a risk of the buy side reaching target before she makes the cost back. Instead, if the sell side is still full, she will move her NBT off exchange to go arbitrage somewhere else, or deal with the low compensation.

Note how important it is to intelligently pick the support target. If it is too big, shareholders will be paying a lot of compensation for a very wide spread. If it is too small, we are denying healthy custodians with good liquidity from getting a decent rate. I don’t think this number should be chosen at motion time, but should instead be controlled by the operator in reaction to the needs of the market. It could be done manually, maybe twice a week or something.

Edit: Thinking about this, I think we actually can take a macroscopic perspective and set the volume at the time of the motion passing.

I think this is an unsolvable problem. You want:

  1. USD and NBT to be freely exchangeable
  2. A greater reward for USD support than NBT

If (1) holds, anyone with NBT can freely exchange it for USD. If (2) holds, such an exchange will qualify the owner for a greater reward. Therefore, if both (1) and (2) hold, the system will not reach a stable state. Owners of NBT will perpetually exercise the exchange in order to obtain the greater reward.

1 Like

That is correct.

This goes back to what @Benjamin wrote, long ago, on these forums. See topic 100% USD Reserves Offers Zero Benefit In Terms of Peg Stability.

Benjamin claimed that, the more NBT in circulation, the greater the risk to the peg. Now we see this in action, because any NBT in circulation is a perpetual threat to be converted to “USD peg support” and require a maintenance fee from shareholders.

1 Like

Yes, I think much of what I say comes down to that same concept that we should be using NSR for leverage. However, in the absence of such a system that can allow for continuous readjustment of marketcaps via coin burning, I would propose that the only thing we have to lose is the tight spread on NBT. Once we make it profitable to leverage the NSR market to keep NBT pegged, we will regain that spread.

This is a deep issue, and will need a long time to be solved and fully implemented. We should look for a way to operate such that we won’t be gamed while allowing for an easy blend with future efforts. In that vein of thought, I ask for criticism on the Price/Volume model with regards to NBT/USD pegging.

I don’t agree with negative interest rates. Other than that, I basically agree with Benjamin about the other stuff. I think the ratio can be held using nsr and nbt burns at rates voted on continuously by shareholders, as we do park rates.

Shoot, in the Price/Volume model we’re letting people push other people’s orders around using volume so someone could submit a large volume to push Mary’s nbt up, then cancel and sell before she can move back down.

The only way I can see around this is to remember Mary was there first with 40% of target and let her keep her position at $.4 while Grace must put hers up at $.998. Both can be compensated fairly with auction style. Note that this benefits people spreading their orders out (not a bad thing for Nu; Mary would have $1 @ $.1/nbt, $1 @ $.2/nbt, $1 @ $.3/nbt and $1 @ $.4/nbt) and requires memory of users.

This is a short term idea that I’ve been poking for the last few days.
Pool operators have a pot of funds (included i the custodial grant proposal) which is used to incentivise pool users to rebalance the sides. Operators can set internal targets so can specify asymmetrical walls if needs be. if one side is over target and the other is under, messages can be sent from the server to the client (this ability already exists) to notify of the unbalance. Pool users who move to rebalance the walls are rewarded from the pot.
It need only be a small amount of reward each time but it increases the gamification of the system which may make it more attractive to users outside of Nu.
Potential downsides I can see are that it is impossible to tell before starting a pool operation how large the reward pot needs to be. This could be overcome by settingthe server to only payout up to the pot limit. If the pot limit looks like it’s going to be reached, funds can be added from any source, or not depending on the outlook of the pool operator.

I agree that there should be more thought given to this but I feel this method may relieve some pressure in the short term.

1 Like

OK, yah, so we have slots at different price points and give a code or something to new liquidity assigning it to a slot. A user can fail to fill the slot for something like 5 minutes before they give up their slot. We don’t even need the slots to all be the same size, we could do a square root dependence on the fraction of the target that slot and all those under it fills.

I like this notification idea and feel it is very useful for something like the nbt/btc pegs we have now. I don’t think it solves the problem of custodians playing hot potato with a seller.

unless the reward is only credited after a certain number of confirmation on the correct side. It doesn;t solve the problem but prevents high speed switching

I considered that, but its not high speed that’s the problem, its that custodians that get their orders filled will sell the nbt back to another custodian right away.

This is only solvable by maintaining a state in which there is a constant demand for nubits because they perform a useful job: enabling fast and cheap transactions on the Net.

Just to be clear here, this is what the order book would ideally look like. Note that every order in this image is getting compensated the same amount and both sides have the same target (which is not actually relevant, the two sides could have completely different targets and this method would still work).

It might be worth pointing out that this sort of orderbook manipulation is being developed for a future release of NuBot. It’s going to be configurable by each bot and potentially reactive to the movement of the market.
As the TLLP software is compatible with NuBot, it may be worth using that when the features are ready.