**Draft** motion for currency burning

Indigoman is to be credited with originally presenting the idea of burning currency in exchange for NuShares. This change is consistent with the original intent of the network’s design: to separate the risk asset from the transactional asset.

Exchanging currency for NuShares represents a major improvement to our currency product. It will invalidate the criticism some have voiced that our system will make currency holders bag holders.

The following is the proposed text of a shareholder motion followed by some commentary about it and explanation of it.

Begin draft motion
Shareholders will vote for burn rates. A burn rate vote will consist of an 8 bit currency code and a quantity of one hundred thousandths (1/100,000) of a NuShare satoshi represented by an uint32. This way shareholders can vote that as little as 1 NuShare be granted for each 100,000 units of currency. Conversely, they can vote to grant as many as 42,294 NuShares per unit of currency. For instance, a currency code equivalent to B and a quantity of 1 means 1 NuBit equals a hundred thousandth of a NuShare. The median share day weighted vote over the last 10,000 blocks will be the rate that is recorded in the block (there will be one rate for each currency where the median vote is not null or zero). When a user chooses to burn currency in exchange for NuShares, they will receive the rate recorded in the blockchain 60 blocks deep, which will offer some certainly about burn rates in the very short term.

A currency burning mechanism is already included in the current protocol in the form of transaction fees. To simplify the protocol change, currency will be burned as though it were a transaction fee. When an excess transaction fee is paid, a protocol change will permit an output of NuShares of equal or smaller quantity. The correct NSR quantity limit will be determined using the burn rate currently in effect. For instance, if the burn rate in effect is equivalent to 100 NSR satoshis per NBT satoshi, and there was an input of 10000 NBT satoshis, then there are 9900 NBT satoshis available to burn and convert after the standard transaction fee. If there are no NBT outputs, then an NSR output of up to 100 * 9900 or 990,000 NSR satoshis would be permitted. If there is an output of 5000 NBT satoshis then the NSR output would have a maximum allowable size of 490,000 NSR satoshis. To ensure the transaction will be accepted, the client will be coded to use the lowest burn rate in effect in the next ten blocks.

The mint reward will be adjusted according to the total number of NuShares in the network. Specifically, each time the supply of NuShares reaches 50% and 100% of its orginal base (1 billion), the mint reward will also increase by 50% and 100%. For example, when NSR supply reaches 1.5 billion, the reward should be 60 NSR. At 2 billion, 80 NSR, at 3 billion, 120 NSR, at 4 billion, 160 NSR, and so on.
End draft motion

There are two harded coded NuShare values in the system whose meaning will change as a result of introducing uncertainty about the number of NuShares that will exist in the future. These are the mint reward (currently 40 NSR) and the minimum required in each output to be eligible for minting (currently 10,000 NSR). The purpose of the output size minimum is to enforce the 7 day period where an output is ineligible to mint after minting. Originally, my thinking was that as technology developed to make minting easier and safer, the reward slowly dropping as a percentage of the outstanding NuShares was appropriate. However, with the future supply of NuShares becoming subject to substantial uncertainty, a proportional adjustment is appropriate. A rise in the minimum output size eligible for minting is disruptive. If it were raised from its current value of 10,000 NSR then the vast majority of outputs currently minting would be ineligible for minting. Therefore I propose we leave this unchanged. At present, an output of size 10,000 takes about 5 weeks to mint a block. It is likely to be around 10 weeks when all shares are distributed. This time will rise as additional NuShares are created, but it will also permit smaller shareholders to participate. If this output size minimum were raised proportionately with the supply of NuShares there is a risk that due to loss of NuShares (misplaced private keys), that there would be fewer and fewer outputs capable of minting, which has some negative security implications. This output size minimum is the method for enforcing the 7 day period minting ineligibility after transfer or minting. While this would be degraded if many more NuShares were created, I don’t think the security implications are significant, particularly where an output would take longer on average to mint anyway.

There is no known way for burn rate votes to adjust as quickly as the market rate of NuShares. Fast adjustments in rates carry the risk of a small percentage of shareholders setting the rate in a way that does not represent the interests of shareholders generally, because it is much easier for a minority of shareholders to control the vote for a small number of blocks than a large number of blocks. This means the rate will generally be over or under the market rate at any given time. When the shareholder rate offered is below the market rate, no one will burn, expecting shareholders to offer a higher rate soon. When the rate offered by shareholders is higher than the market rate, it offers an arbitrage opportunity. Arbitraguers will gain value by burning currency, receiving NuShares, and selling the NuShares at the superior exchange rate. This will have the effect of reducing the NuShare price to the exchange rate offered by shareholders. This implies that it will be difficult for shareholders to control the amount of currency burned, as the quantity burned will be proportionate to the opportunity for arbitrage. It therefore appears advisable that shareholders only offer burn rates when the decision has been made to retire a currency, or to retire a large percentage of a particular currency. The amount burned will be somewhat unpredictable. Due to these uncertainties, inefficiencies and the relatively long time required to vote for a burn rate, interest rates are expected to continue to be the primary tool for maintaining currency pegs on the support side. There is a very good chance years will pass before a burn rate is voted for. The most likely scenario for currency burning would be when a supported national currency is abandoned or hyperinflates.


I think this is a very valuable tool for the shareholders to keep the peg in the long term.

Although I’m not convinced that this would only be used to retire a currency or large parts of it. I think that a way to control the money supply upwards and downwards is a crucial tool to govern a stable currency in the long term. Theoretically you wouldn’t even need a peg as we have now assuming the markets are perfect and the network could manage demand and supply instantly.

May be I am not an expert on this. But, I really think voting on rates instead of quantities in converting NBT to NSR brings lots of uncertainties and risks.
Can’t we really find a way to let some exact amounts of NBTs to quit circulation? Just like how they are created. A custodian deposit some NBT in to an address and request some NSRs by burning them, then shareholders vote on that. If the custodian’ proposal pass, the protocol burns his NBT and creates NSR for him.

1 Like

I think this is a brilliant idea as a safeguard against oversupply of NBT. Thank you to Indigoman for inventing it.

If this is implemented, the total NSR in circulation becomes unbounded. However, the blockchain cannot store numbers of arbitrary size. What is the actual limit for the number of NSR that the blockchain can support?

@dongshan I think this decentralized approach is to be favored over the exact method you outline, because it does not require trust in a custodian.

I agree that in theory it would be useful to permit shareholders to specify a quantity of currency to be burned. While it can be done, I have been unable to devise a method that is sufficiently simple and elegant, as complexity in the protocol compromises security and reliability.

Let’s examine what the above proposal by @dongshan would look like in some detail. Shareholders could place a vote to permit a certain quantity of currency at a certain address to be burned in exchange for a certain quantity of NuShares. The vote contains these pieces of data: 1) a currency address, 2) a currency quantity, 3) a NuShare quantity and 4) a NuShare address. If the majority of blocks and share days in a 10,000 block period contained the same value for these four elements it would be considered passed, meaning the exchange of currency for NuShares would occur.

One problem with this is that you are allowing shareholders to destroy someone’s currency, which is not necessarily the will of the currency holder. It could be used to destroy currency at a particular address in exchange for zero NuShares. This is undesirable. To avoid this, we could say the vote doesn’t force the exchange but just permits the owner of the currency to choose the exchange by signing the transaction. In that case, the currency address private key is used to sign a transaction much like I have proposed except that the protocol only permits the exchange if the addresses and amounts have been previously approved by shareholders.

This solution requires that the entity signing the exchange have sufficient funds available to purchase the currency to be burned, whereas my proposal permits an unlimited number of people who already possess currency to exchange it. It also requires a much longer latency between when the exchange rate is chosen and when the exchange is effected (maybe three times as long), which means the exchange rate is likely to be further from the present market rate. Imagine the common scenario where the market value of NuShares declines between the time a proposal is submitted by an entity willing to burn currency and the time that proposal is passed by shareholders. The entity will lose value by signing the exchange, and is therefore likely to decline to do so and submit a new proposal at an updated price.

I have described what I understand as the details of dongshan’s proposal to highlight the deficiencies in hopes that someone can devise a modification that removes them. As presently described, I believe the problems introduced by the proposal are greater than the problems solved.

Here is @dongshan’s objective:

Perhaps a max quantity could somehow be included with the burn rate vote?

Because NSR are created in different transactions in different blocks, there isn’t really a limit to the number the blockchain can support. There might, however, be limits on what can be returned by the getinfo RPC that calculates the total money supply. @sigmike, can you verify that the calculation of the total money supply, which this proposal would depend on for determining the minting reward, is not limited by an int32, which would limit it to 2 billion? This is worth looking in to because I have heard it said that Peercoin imposed a limit of 2 billion on its money supply. If this is true, it is likely we have inherited the same limit. This number is consistent with the use of an int32 as the cause, which could be remedied by using an int64 instead.

Initially, I really hated the idea of creating additional NSR through any means other than minting. I believe that serious investors will desire predictable supply growth.

After having thought about it for a while, I realize that there is not much harm that could be done because it’s simply not likely that there will be a burn rate greater than zero unless the peg became quite unstable. No rational investor would ever vote for a burn rate greater than zero unless the risk of NSR value loss due to a failing peg was greater than the risk of NSR value loss due to creation of additional NSR.

I believe that Jordan has outlined a good approach.

If we use an unsigned int64, we could support up to 18,446,744,073,709,551,615 NSR. That would probably be enough for now. :laughing:

First of all, I agree that this is the only state where shareholders are likely to offer burn rates. Voting for rates that dilute shares while they are profitable goes against the economic self-interest of a shareholder.

I still struggle a bit with how this burn proposal will work in practice. For the purposes of simplicity I’m imagining a single-currency system like the one that currently exists. When this retirement scenario is reached, it implies that the demand peak of the individual currency has definitively passed. In a scenario where demand is decreasing and is forecasted to never again reach a new peak, the value of NuShares should be equal to its intangible assets (whatever the intrinsic value of its branding elements, the number of existing users as defined by Metcalfe’s Law, etc.). There shouldn’t be any additional value present in the price because future dividends would be expected to be zero.

In that scenario, it should already be very easy for a speculator to buy a large amount of NuShares on the open market for cheap. In a situation with very cheap market-rates for NSR, this would lead to very large NSR/NBT burn exchange rates being offered, to the point that very few NBT would be purchased. This is the same final outcome that is present in our current design.

(I shared this with Jordan privately but want to include it publicly just in case anyone has any thoughts):

In my view the current weakness of NuBits is that the network is attempting to monetize ownership of a permanent asset that unfortunately has an eventual obsoletion date. This is at odds with traditional views of the permanency of money. A different approach to structuring should be to monetize not the asset itself, but the value the network provides (convenience, speed, privacy) by charging variable transaction fees. It looks like this feature might be included in Nu in the future, which is great.

I think the monetary policy that allows for expansion and contraction of NuBits while placing the risk on NuShareholders should come through two mechanisms:

  1. Shareholder adjustment of the transaction fee. I originally thought that distributing transaction fees to shareholders would be ideal, but Jordan correctly pointed out that destroying them achieves the same functional purpose. Larger transaction fees correctly monetize the value the network provides and allows for very flexible expansion and contraction of the currency supply.

  2. Extremely conservative dividend rates. If the system only distributes dividends for NuBits that can confidently be said to have been lost forever or abandoned (1% per year? 5% per year?) it significantly reduces the chances of a mass number of users being left holding the bag. In this design, if an exchange fails and steals the custodial USD funds present on its books, losses would be covered by the dividend funds set aside by custodians. This coverage would lead to a decrease in expected dividends and would negatively impact the price of NuShares. Thus, NuShareholders would be fairly penalized for their poor choice of an exchange.


There is a very limited power in this mechanism, I think. Transaction fees would have to be prohibitively high in order to have a noticeable effect on NBT supply. $0.01 fee already seems reasonable. Would you use NuBits if the transaction fee were USD $1? I expect not. Of course, this is just a guess.

OK, let’s look at the worst-case scenario: demand for NBT has peaked, and is in a potentially-permanent decline. Expected future dividends are near zero, so the value of NSR is low.

It may be that the total amount of NBT that needs to be burned to save the peg is greater than the total market cap of NSR, which means that even this mechanism fails to save the peg. However, it’s still a step in the right direction.

I think this range may not be optimal, in the case that NuShare supply grows arbitrarily large. I would propose instead a quantity of one thousandths (1/1000), which allows votes between 1NSR for 1000 units of currency, and 4,229,400 NSR for 1 unit of currency. Alternatively, a quantity of ten thousandths (1/10,000) might be best.

However, even if the first motion is passed as it stands, it may be within the discretion of the Nu dev team to make this amendment without a supplementary motion, considering that the functionality is nearly equivalent.

If there is controversy about the range permitted, it may make sense to use uint64. This requires an extra 4 bytes of blockchain space for each vote, but considering that burn rates will rarely be voted for this is probably not very important. It would also provide us additional granularity on the burn rate.

Therefore, I intend to change the draft motion to use uint64 where the quantity will consist of billionths (1/1,000,000,000) of a NuShare satoshi. This will permit shareholders to vote for as little as 1 NuShare for each billion units of currency. I haven’t done the calculation the other direction, but it is safe to say more than a trillion NuShares could be offered per unit of currency.

Pillow at Peercointalk had an interesting idea: timelock the NSR granted by burning. What if the received NSR could not be moved for 7 days (10000 blocks), for example? This would prevent the user from dumping them on the market immediately, helping to protect the value of the network.

I totally agree with you about #1. Here in China, bank transfer fee is set at 1% of the amount of transaction , with the limit of min 2cny and max 50cny,
Only concern about #2 is how to safely hold those dividend if they are not distributed in time.

1 Like

Sorry, the mechanism mentioned in my previous post is not thoughtful. Just as Chronos point out, my objective is find a way to let some exact amounts of NBTs to quit circulation.

Doesn’t this mean it only shifts the dump-risk of one week in the future?

I think using the excess fees as the burned amount will makes the code complex and error prone. It will be even more complex when the fee becomes dynamic. I’d rather use the standard burning mechanism we already use: provably unspendable output with OP_RETURN. And it would allow us to add meta-data.

Right now the unit (NBT or NSR) of a transaction is recorded at transaction level, not at output level. That means that we cannot take NBT and output the change in NBT and the shares in NSR in the same transaction. That was a design choice and I’d rather not change that just to allow this burning process.

Instead we could use 2 transactions: 1 to burn NBT and 1 to generate NSR. The 1st one would make the network accept the 2nd one.

A burning transaction would take some NBT inputs and output the burned NBT to an unspendable script that also provides the NSR address that will be allowed to generate the NSR. The change would be sent to another output as usual and the same fees as in other transactions would be required.

The NSR generation transaction would take the burned NBT as input (without any signature) and output the generated NSR. The network would verify that:

  • the input is a burning transaction (and it’s the only input)
  • the input has not already been used to generate NSR
  • the output address is the one recorded in the burning transaction (split outputs would be allowed, but all to the same address)
  • the total output amount is equal or less than the NSR rate multiplied by the amount burnt (the NSR rate being the vote result in the 60th block before the one that confirmed the burning transaction)

This would be the only situation where a cross unit transaction is allowed (input in (burnt) NBT and output in NSR).

I think both transactions could be confirmed inside the same block, but I’d have to verify that.

All the amounts are expressed as signed or unsigned 64 bits integer so the theoretical limit is 9 223 372 036 854 775 807 satoshis (9e18). But there’s an extra MAX_MONEY constant used at many places that limits most amounts used in the protocol. I think it exists to avoid mistakes and overflow errors. This limit is 2 billion coins right now (20 trillion satoshis). That means you cannot sent or receive more than 2 billions in a transaction. That applies to both NBT and NSR. We can change this value easily (although it’s still a protocol change).

But these limits only apply to individual or transactional amount, not to the total supply. The total supply is not recorded as a value in the blockchain, it’s just the sum of the generated units. The client does record that data in an int64 but it’s only used to display it in the getinfo RPC. Having a total supply above the int64 limit would not break the network, it would just make getinfo return a negative supply.

If we plan to use the total supply as protocol data (to change the reward for example) and expect it to overflow then we can store it in a BigNum (an integer of arbitrary size). But we would also have to do that with many other values (the wallet balance for example). But I think the current limit (9e18) is large enough.

One way to do that would be to vote for a burnable amount with an identifier like we vote for custodians with an address. Once a burn amount has been granted people would be allowed to burn NBT with this identifier until the burned amount on this identifier reach the voted amount.

For example a shareholder could vote to burn 1 million NBT at rate 0.003 with identifier “1”. If the majority of shareholders vote for the same amount and rate on this identifier, then this burn vote passes and is recorded in the blockchain.

The network would then allow burning transactions that mention the identifier “1”, but only until the total burned amount on this identifier reach 1 million. After that any burn with this identifier would be rejected by the network.

There may be multiple burn identifiers allowed at the same time.

1 Like

That’s much different than using a rolling median. However, it seems that the identifier-quantity feature could be used with the 10000-block median vote outlined by Jordan. Is this correct?

Assuming the cause of the trouble in maintaining the peg is that there are too many NBT in circulation (Nb) compared to the networth of Nunet in dollars (call it V for value), then the amount of NBT burned (x) to restore equilibrium can be calculated. The euqation is Nb - x = V + Rb * x * (V/Ns), where Ns is the total number of Nushares, Rb is the burn rate (Nushares per Nubit), and (V/Ns) the Ns price per net value of Nunet. If we use market price of NSR/USD for (V/Ns), then x can be calculated with a given Rb.

A special solution is Rb=0, which means someone holding NBT burns NBTs without getting any NSR in return, until all excess NBT is gone.

V is a combination of how many USD in NuNet reserve, how much liquade asset NuNet has, and profit earning prospect. The price of NuShares (V/Ns) and the ending of the NuNet is tied to these three factors.