Some Suggestions To Eliminate Peg Maintenance Expenditures


I thought I would chime in with some suggestions. I will briefly describe a possible revamp of the peg maintenance system and then explain its potential advantages.


  1. In each PoS block, Nushares record a binary vote about the current Nubits/USD exchange rate on external markets.
    1 if the price of Nubits is > 1 USD or
    0 if the price of Nubits is < 1 USD.

  2. Every 24 hours (approximated in terms of blocks), an auction of Nubits and Nushares is conducted within the block chain.

2a) Users wishing to Sell Nushares and Buy Nubits send their nushares to a designated auction address (1SellNSR) prior to closure of the auction.

2b) Users wishing to Sell Nubits and Buy Nushares send their nubits to a designated address (1SellNBT) prior to closure of the auction

3c) Each daily auction is seeded with a value of either Nubits or Nushares equivalent in value to 1% of the outstanding Nubits Supply.

3ci) If the majority of PoS blocks 24 hours prior to the auction indicate a NBT price > 1 USD, then the auction is seeded with Nubits.

3cii) If the majority of PoS blocks 24 hours prior to the auction indicate a NBT price < 1 USD, then the auction is seeded with Nushares. The number of seeded Nushares is determined by the median closing price of the last 14 daily auctions.

  1. When the auction closes the following things happen:

a) The pool of sold and seeded (if any) nushares is divided proportionally across sold and seeded (if any) nubits.

b) The pool of sold and seeded (if any) nubits is divided proportionally across sold and seeded (if any) nushares.

c) If nushares were seeded, sold nubits accruing to these nushares are burnt. This would decrease the outstanding nubits supply by 1% and increase the outstanding nushares supply from circulation

d) If nubits were seeded, sold nushares accruing to these nubits are burnt. This would increase the outstanding nubits supply by 1% and decrease the outstanding nushares supply.

Note: The auction’ s closing price of Nushares in terms of nubits is equal to (Sold + Seeded Nubits) / (Sold + Seeded Nushares).

Note 2: Suppose a seller would like to sell NSR if their price is greater than 2 NBT and buy NSR if their price is less than 2 NBT. He can guarentee this by sending 2 NBT and 1 NSR to the auction. If the NSR price is greater than 2 NBT, he will reduce his NSR holdings and accumulate NBT. If the NSR price is less than 2 NBT, he will reduce his NBT holdings and accumulate NSR. If the NSR price is equal to 2 NBT, then his NBT and NSR holdings will remain unchanged.

DISCLAIMER: There are some minor gaming possibilities here. These can be addressed relatively easily, but I don’t want to get into the details at this point.


If people want to buy NBT right away, they will be willing to purchase them on exchanges for slightly more than 1 USD, say 1.01 USD. If the supply of NUBITS is currently insufficient, then the price of NBTs will tend to sell at a premium over 1 USD on exchanges. The auction system responds to this price pressure by releasing more NBTs into circulation. This depresses the price back to 1 USD.

If people want to sell NBT right away, they will be willing to purchase them on exchanges for slightly less than 1 USD, say 0.99 USD. If the supply of NUBITS is currently excessive, then the price of NBTs will tend to sell at a discount relative to 1 USD on exchanges. The auction system responds to this price pressure by removing NBTs from circulation. This increases the price back to 1 USD.

Market makers will arbitrage small fluctuations in the NBT price to take advantage of price changes. This will prevent large deviations in the NBT price from 1 USD. However, like today, the NBT price will still fluctuate within a narrow band. There is no need to manage this directly as in the custodial system, market incentives will take care of it.


  1. Peg maintenance is automated in the code. There is no need to expend resources to maintain the peg. This will stop the system from bleeding money.

  2. A liquid market for NBT and NSR is guaranteed to exist. Due to the seeding system, the daily volume of NBTs available for sale/purchase in the blockchain will always be at least 1% of the outstanding supply. Guarenteed liquidity in the NBT/NSR market greatly enhances the effectiveness of the burning system. Assured liquidity will attract market participants.

  3. Burning occurs continuously rather than in a clunky, ad-hoc fashion. Continuous gradual sales minimizes losses of shareholder value due to illiquidity in the NSR/NBT market.

  4. The system eliminates custodial risk (e.g. losses due to hacked exchanges).

  5. The system is completely decentralized. This reduces legal risks. (there are no ‘money transmitters’ to go after if nubits attracts attention from the FEDS.)

That’s all.

Edit: Corrected some mistakes in the original post (i.e. I reversed a bunch of things, writing NBT where I should have written NSR, < instead of >, and NSR instead of NBT) This always happens to me with inequalities and ratios, etc.


Hi @Benjamin
I like the approach. It would certainly be a good prop for the peg.
My one concern is with the recording of the NBT value in the blockchain. Where does this information come from? Some sort of aggregated feed of the NBT markets? If so, who maintains this? Or is the minter expected to record the value when the Block is minted (I assume not but it’s a possible method).

Hey, I was wondering if you would show up again Benjamin. Welcome back. :smile:

I would say the minter. With data-feeds this won’t be too hard. Ideally you would need different sources though. I suppose you wonder about the sources. The exchange feeds and CMC would be good for that I suppose.


Yes it was more a thought about the sources. Everyone would need to use the same feed or amalgam of feeds. That would indicate some sort of central Oracle which provides the “truth” of the NBT price. It’s doable, just seems to be a weak link.

You could have a datafeed for each exchange + CMC. Each minter chooses their own feed. Or even better have a random option in the client to choose which feed you use for the price.

The only feed is the series of binary POS votes indicating whether the external market price of nubits is greater than or less than 1 USD.

The price of NSR in terms of NBT is based on the revealed market price in each auction. This price is only used to determine the qty of seeded NSR equivalent in value to 1% of the outstanding NBT supply in subsequent auctions. This price doesn’t need to be accurate. Even a very large margin of error would be fine.

tl;dr no price feeds are used, feeds from exchanges = centralization = bad

But yes, it would make things easier for miners if they could obtain prices from an exchange’s API. Things are very slow to change in this system, so the API isn’t really a point of failure. As long as someone notices it’s screwy eventually, everything would be fine.

The miner records a binary vote when the block is minted. If a majority of miners over the past 24 h vote yay the price is greater than 1 USD, then nubits are seeded. If a majority vote nay, then NSR are seeded.

Brilliant. Your method is a very robust to capture the external signal (NBT price) through shareholders. Reminds me of the RPROP optimization algorithm.

What it would require is “burning to an address”, i.e. that you can send coins to an address which are afterwards are not considered to be part of the supply anymore. Since we cannot “send coins” from an unknown address (how to sign it), the only way is to destroy the coins and to recreate new coins at the recipients address.

Unfortunately this will not be possible anytime soon. Burning was not implemented this way, but through a special output which script only contains OP_RETURN and nothing else. @sigmike can tell you more about this.


Interesting. If one restricted sent amounts to discrete units, say powers of ten: 0.1, 1, 10, …, then this could serve as an effective means for coin mixing.

The guarantee of liquidity would ensure a pool large enough to obfuscate identities, at least after multiple passes.

Not necessarily advocating this though. Just a possibility.


@Benjamin there was a discussion about a similar feature where the shareholders post NBT/NSR auction rates and a user could burn their NBT to get new NSR and vice versa.

Unfortunately to do this on blockchain is not trivial with the current system. The reason is that we cannot mix NSR and NBT transactions. Some proposals were made like to use 2 transactions with OP_RETURNs or the creation of a new transaction type that can mix the native assets (the new transaction type is more robust but complex to implement).

Having an automatic auction system in place can justify the cost of implementing the new transaction type. The additional bonus is the possibility to exchange NBT<->NSR<->NEW-FUTURE-ASSET in an atomic and 100% trust-less fashion.

What about a ternary value: higher, lower, unchanged. The neutral value is needed for the feedback loop to stabilize, otherwise it would oscillate.

In this case Alice would create the new transaction type that will have an NSR input and an NBT output (or vise versa). Because there is no NSR outputs the NSR she spent are burned as fees and because there are no NBT inputs the NBT are newly created. The minter will check those transactions to verify that the correct auction rate was used and that the total amount of sold coins does not exceed the protocol defined values (1% as you proposed).

Could you expand the a bit the gaming part a bit?

Check also the “Hayek Money: the Cryptocurrency Price Stability Solution” paper, if you haven’t done already.

This is not true anymore. In the last release we developed a new RPC call “burn” that burns coins as fees that in effect removes the coins from the total supply (the fees are burned, not collected by the miners like in Bitcoin).


I am a little confused by erasmospunk’s comments. For now, I’ll respond to the issues that I think are most important. Let me know if this fails to clear things up.

First and foremost, I do not think that voting on auction prices is a good idea. The problems are as follows:

  1. You cannot allow individual votes to be highly influential. Otherwise, individual sellers can game the system using strategic voting (even if the majority of voters are honest).

  2. Due to (1), adjustments to auction rates are necessarily much slower than movements in external market prices. Slow adjustment implies a spread between the internal blockchain price and external market prices. Speculators will arbitrage this spread to capture shareholder value.

By contrast, In the system I am proposing:

  1. internal blockchain prices (“burn rates”) are determined directly within an auction market.

  2. Voting only affects the direction of supply changes. This does not open up arbitrage opportunities, even if voting outcomes are inaccurate.

  3. In theory, voting outcomes only need to be marginally more accurate than random chance for the system to maintain a stable peg. That is, if votes are temporarily inaccurate (i.e. 51% of miners vote the wrong way several days in a row), this would not compromise the peg. As long as the NBT supply tends to move in the correct direction in the long-term, the NBT price should remain stable at 1 USD.

Note: I don’t want to discuss gaming yet. It is a very minor issue. I would like to make sure everyone is clear on the above points before discussing refinements.

Note 2: Oscillation is innocuous. A third voting category introduces some significant issues. There is no need to go there. However, if you insist, please first explain why you think oscillation is undesirable.

Oscillation is a sign an unstable system. Quoting a wikipedia article:

Making a change that is too large when the error is small will lead to overshoot. If the controller were to repeatedly make changes that were too large and repeatedly overshoot the target, the output would oscillate around the setpoint in either a constant, growing, or decaying sinusoid. If the amplitude of the oscillations increase with time, the system is unstable. If they decrease, the system is stable. If the oscillations remain at a constant magnitude, the system is marginally stable.

Another way of thinking about the neutral value is the no vote situation that could be caused for other reasons, like API errors.

What issues a third voting category can cause?

Some other questions.

  • How is the NBT/NSR burn rate defined?
  • Does each user choose their own rate and the best wins?
  • What if there is low participation or competition, would the price go down i.e. they burn less coins than necessary?

I would like a detailed description of the algorithm.

edit: clarification and typos

This is the part of your quote that caught my eye. It seems to contradict the generality of your assertion. So again, unless you can come up with a more specific reason for concern, I don’t think discussion of a third type of vote is a good use time at this point.

Briefly, though, I would suggest creating a rule that requires the existence of a 1 or 0 vote for a block to be valid. (i.e. miners should not be allowed to abstain)

  1. The “burn price,” as you call it, is defined as the market clearing price in each auction.
    A market-clearing price is the price of a good or service at which quantity supplied is equal to quantity demanded, also called the equilibrium price.

As stated clearly in the original post, the price of NSR denominated in NBT is simply the total amount of NBT sold+burnt divided by the total amount of NSR sold+burnt.

  1. Users do not know the market clearing price until the auction closes. Prior to this point, participants simply send NBT and/or NSR they want to sell to the auction address. This represents a binding commitment to sell at the market clearing price, whatever that may turn out to be.

  2. A high level of participation is guaranteed to exist at all times. lf no one participates, the first participant to commit to an auction sale would pick up the entire pot of seeded NSR or NBT at zero cost, i.e. he would get 1% of the NBT market cap for a nominal fee. The presence of this prize provides a powerful incentive to participate. You can think of it like a gambling game.

As far as a detailed description of the algorithm, 90% of the information necessary to implement it is in the original post. The only important missing piece is a discussion of gaming and timing issues. Your questions suggest that we are talking past each other, i.e. all of your questions were answered in the OP. It makes sense to wait until we are on the same page before discussing gaming and timing issues (which are closely connected).

Note: I am aware that I can be a little unpleasant when answering (or refusing to answer) questions. Sorry about that. I really do appreciate your interest.


I like this so much, it can be the missing step to a full decentralized cheap and automatic long term pegging scheme, which is necessary before thinking of developing Nu’s business model and the various profitable services that can be developed on the top of the first decentralized convenient stable currency.

I wonder if we can write a code that test how could this mechanism goes to demonstrate its efficiency over various periods of operation !


I am wondering how @JordanLee thinks about this idea.
Having a pegging mechanism that gets rid of liquidity pools completely while preserving the core component of Nu, which is the voting trust-less decentralized mechanism to make Human beings intervene and collaborate would be ideal and still in accordance with the original spirit of Nu, I am feeling.

1 Like

This looks like a brilliantly simple and robust method on protocol level available to pave the ground for eliminating peg maintenance expenditures by automatic NBT/NSR burning.

I’ve stumbled upon an article about “Hayek-Style Cybercurrency” and that article describes a lot of what Nu already has implemented and the article carries out a method to automatically keep a peg in a way that is close to what @Benjamin proposed here.
If you read only the following quote, you might lack some definitions. I recommend to read the article anyway.


Bumping as this idea offers a way how to balance liquidity and keep the peg on a protocol level.
This idea is just too good not to be discussed.

What do we need to do to get going on this? Does someone need to propose a motion? I think we do need to wait for nsr grants, but that’s coming out soon. Other than that, what do we need as a precursor?

Who wants to take responsibility for hashing this motion? I would do it, but I’ve proposed a lot of votes recently and the last time I proposed a burn motion it didn’t go so well.

@Benjamin? @masterOfDisaster?