Burning a specific amount of currency

@JordanLee asked me to work on a new motion for currency burning. I’m not sure the discussion about voting continuously for a rate or for a specific amount to be burned has reached a consensus so I bring it back in another topic.

The proposed alternatives are:

  1. The shareholders vote continuously for a conversion rate. The effective rate is the median of the past X votes
  2. The shareholders vote for an amount of currency allowed to be burned at a fixed rate
  3. The shareholders vote for an amount of currency allowed to be burned and when the vote passes they can vote to adjust the rate
  4. The shareholders vote for an amount of NuShares allowed to be created through burning and when the vote passes they can adjust the rate
  5. Shareholders votes for a specific amount of NuBits needed to be burnt and the protocol run a NuShares auction (Raythma’s proposal)
  6. The shareholders can grant an amount of NSR to someone who will burn an amount of NBT (in the same way they grant NBT to custodians) (Benjamin’s proposal)
  7. The shareholders vote for an amount NuBits allowed to be burned per block by the shareholder who finds the block. They also vote for a rate and maybe a maximum amount of NuShares to be created (GreatLogic’s proposal).

(Edit: added options 5, 6 and 7)

In alternatives 2, 3 and 4 multiple burning amounts can happen, in a similar way as with custodians.

Is there a consensus on which solution should be put in the motion? Or should I propose multiple motions?

I’ve quoted below the posts about this topic in the currency burning motion proposal discussion:

Asking whether there is consensus having that many opinions is interesting.

My vote would clearly go to option 1 as it allows the market to do its work continously without much friction and appears similar to e.g. the FED reviewing and setting the interest rates from time to time. Having said that it will be important to inform and educate the Shareholders to enable them to make sensible decisions protecting the network/peg.

The issue is that there would be a feed required to the market rates. Basically shareholders need to vote for a premium above market rates or a cost to market rate to control the amount of burning.

Option 2 has the risk of always being behind what the market rates do
Option 3 is not clear to me on who or what pays for the burning
Option 4 is the second best after 1. In my opinion it has too much overhead for Shareholders but given the issue with option 1 I could vote for this.

Just my opinion though.

I do not really like the idea of creating more NuShares into the system to burn NuBits. I think it could lead to a tremendous loss in NSR price if we allow the protocol to create NSR beyond the block rewards. It also takes away from the speculative properties of holding NuShares by fundamentally changing the rules after the start of the game and any time during, in my opinion.

Just in case anyone new is unfamiliar with this topic, it has been discussed numerous times. The mechanism is designed to save the system in the event that the peg is guaranteed to fail due to an oversupply of NuBits. It helps take the risk away from NuBits holders and puts it on shareholders, whose collective decisions have led to the crisis. Here are the related discussions in order starting from September…

The final link is Jordan’s draft motion.


I think it only changes the rules if this was implemented without shareholders approval. The voting process will decide whether it gets implemented.

This is not always true. External factors could also be at play.

Yes, very true.

Still, the shareholders are the ones who have taken on this risk by purchasing shares. It should be them that are exposed to risk and not the holders of NuBits. They bought NuBits with the expectation that they will always be $1. There should be zero risk for them and I believe the existence of this mechanism will help to build even more confidence in our system and people will be less hesitant to use NuBits.

I like the first option. It is simple and compatible with “creation of NBT via parking rates”.
With parking, Nu creates additional NBT corresponding to n% of parket NBT (could be the whole supply in theory); With burning, Nu destroys m% of whole supply of NBT.

EDIT: additional information.

I like this better because I have little idea how the rate can be determined but I think burning is critical to have. So I want to have it in two separate processed. “Having a burning mechanism” or “Will burn 300m NBT” itself is a huge stablizer.

I imagine once shareholders figure it out the rate, the rate will be calculated from some data feeds. An adjustable rate could allow either be set by hand or by decentralized data feeds (less human factor).

For me I would accept nubits prices to fluctuate by a couple of percent if in return significant existential risks of Nu can be removed. Especially such fluctuation is slow, in a time scale of months.

You understand this would be intended to be used in emergencies, right?. It could be used when the peg was at risk of failing. Perhaps the shareholders deserve to have their shares decrease in price if they allowed NBT amount increase to a point that a currency burn was needed.

1 Like

I would vote for 5 , shareholders votes for a specific amount of NuBits needed to be burnt and the protocol run a NuShares auction, burning NuBits is for emergencies and it should be successful whatever it takes, so leaving the rate to the auction is the best option.

Even if this option adds a significant amount of complexity in the code, but it would facilitate the future transition to a more automated mechanism where the protocol itself start the auction depending on the Shares holders Schelling price feed.

Options 1 and 3 are the only ones that have appeal to me. Option 1 is simpler but option 3 allows for more shareholder control. The question of whether the extra control is worth additional protocol complexity is a difficult question. I need to think more about the risks of the protocol behaving in unexpected ways with this extra complexity, and weigh that against the risk of not having control over the exact amount of currency to burn. The rate, because it uses a median value, can be changed rather quickly, but there is no guarantee that a large amount of currency won’t be burned in a single moment, just when shareholders wish to stop it. Even if that did occur, additional currency could be created to compensate.

I’m still thinking about how the additional complexity of option 3 might be exploited or lead to a fork.

Instead of allowing a potential attacker or privileged person to capture all or most profitable burning opportunities, limit the amount each person can burn by making it proportional to the number of NuShares they control. This aligns the interests of shareholders in protecting the Nu network with the reward of burning NuBits in order to buy NuShares at a discount when stimulating demand for NuBits. In addition to the increased safety, it is also more fair to shareholders.

Additionally, establishing a set rate to properly stimulate the desired amount of demand is extremely difficult to determine precisely. If the rate is too low relative to expected market conditions, not enough people will opt to burn NuBits. If the rate is too high then NuShareholders end up paying a greater dilution cost than was necessary. Therefore, I recommend a NuBit burning rate that changes over time.

  1. Add a function to NuWallet that enables or disables NuBit burning. Ideally, it would allow you to customize conditions for when you would like it to be enabled, and a total number of NuBits that you are willing to burn.

  2. Allow shareholders to vote for the following terms:

Quantity of NuBits that can be burned per solved block. (N)
Initial NuShare reward that can be earned when burning N NuBits per solved block. (S)
Rate at which the NuShare reward (S) changes per solved block. ®
Total number of NuShares that can be awarded in this manner. (T)

If NuBit burning is available, a minting shareholder may choose to burn NuBits (N) in order to receive an additional S NuShares each time they solve a block. Each time a solved block burned NuBits, the NuShare reward (S) decreases by R. Each time a solved block did not burn NuBits, the NuShare reward increases by R. This can be conceptualized by thinking of a solved block that burned NuBits as a vote for “The current rate is a good deal; perhaps slightly too good; therefore I should take it!” whereas a solved block that chose not to burn NuBits is a vote for “The current rate isn’t good enough”. This allows the rate to adjust based upon actual beliefs of individual shareholders, and it also allows it to change more quickly and naturally with respect to market conditions.

1 Like

A few more thoughts:

  1. Another reason it would be advantageous to require NuShares to burn NuBits is that the dilution cost to NuShareholders would be lower than if the burn rate were available to anyone. This is because NuShareholders probably value NuShares more than non-NuShareholders on average, and therefore would require a lower discount rate to be willing to purchase additional NuShares. Non-NuShareholders would be more likely to be interested in acquiring NuShares at a discount for the sake of arbitrage, whereas NuShareholders would likely keep more of the NuShares they acquire through this method.

  2. An additional “acceleration” variable could be voted upon which affects the rate at which the rate ® changes (as described above). This would allow the NuBit/NuShare burn rate to respond more rapidly to changing market conditions. If several blocks in a row opt to either burn or not burn, it makes sense to change the rate more rapidly.

  3. A system like this is a potential source of decentralized buy side liquidity. The current system involving custodians is expensive and vulnerable to certain kinds of attacks. This NuBit for NuShare burning system could incentivize shareholders to provide significant buy-side NuBit support. For those who believe strongly in future NuShare growth, competition for NuBits could be sufficient to replace most of the buy-side demands required of custodians. It may only require a very small discount to stimulate this demand, perhaps less than the current NuShare cost of achieving the same amount of demand from custodians.

After some additional thought my view is the additional complexity of option 3, with its associated heightened risk of unplanned forking or exploit, imposes a hazard greater than the benefit of additional shareholder control over the burning process. Please consider the following scenario to understand why:

Suppose we implement option 3 from the original post, allowing shareholders to specify an amount of currency to be burned, where currency burners specify their burn as fitting within the limits of a specific allotment. Say a specific allotment is 1,000,000 currency units. At a particular block height, 995,000 of these units have been burned, leaving 5,000 currency units available for burning. At the same instant, two burn transactions (we will call burn A and burn B) of 3,000 units each are broadcast to the network. The protocol does not permit both of these transaction using option 3, although each transaction by itself does meet the protocol specification (but they are both permitted under option 1). In other words, option 3 creates a scenario where whether a transaction is valid depends on other transactions. This situation is not unknown in blockchain implementations and is comparable to double spends in some ways. In a double spend the existence of the first spend makes the second invalid, just as in our scenario the existence of the first burn makes the second invalid.

Let’s continue observing how this ‘double burn’ plays out in our network. Part of the network sees burn A first and rejects burn B as invalid. Another part of the network sees burn B first and rejects burn A as invalid. A block is found by a client that accepted burn B. Within a second a block is found by a client that accepted burn A.A fork one block high, such as is seen many times per day is now under way. But this fork has a different cause and will require a different resolution than an ordinary fork where all transactions are valid. It is also different in nature than a fork caused by a double spend and requires special code to resolve (to expunge a burn transaction and its associated NSR creation transaction from the memory pool based on the presentation of a conflicting transaction presented in a broadcast block).

What if this arcane, unlikely but clearly possible scenario were overlooked during coding? What if some variant of the scenario is not understood and not handled by the protocol? What if three years from now developers not involved in the project now implement a protocol change that alters the handling of this unusual situation, being unaware of the details of the scenario? The flaw would be unlikely to be uncovered in testing. The protocol flaw could be introduced without any problems initially, only to have a disastrous fork occurs two years later, resulting in many double spends and an emergency protocol change.

Our 0.5.0 release featured a protocol flaw that caused a permanent network fork long after the protocol change date, so these things do happen. An unplanned network fork due to a subtle and latent protocol flaw may be the biggest risk to decentralized networks forging consensus based blockchains such as Nu, Bitcoin and Peercoin.

As a result, I believe the protocol simplicity permitted by option 1 is of greater benefit than the additional control offered by option 3.

1 Like

This one appeals to me the most. The decision, amount, and rate are all atomic. Per JordanLee’s concern about forking, I would think that a binary pass/no pass would mitigate that to some degree.

If multiple proposals could be voted on concurrently, then I think this could approximate the fluidness of continual adjustments. This could easily be adapted to feeds – “burn proposal #1#2#3” etc

Edit: interesting. When quoting a list, Discuss renumbers starting at #1. This was idea #2 from the above

I agree option 1 is the most simple to implement and thus reduces the risk of introducing bugs.

But the scenario you describe with option 3 would not be a problem. There will be code to prevent too much currency to be burned, and it’s the same code that will solve the fork you describe. There’s nothing special here, except maybe we will have to clean up the memory pool transactions that became invalid because enough currency have been burned. But that’s something we will have to in option 1 too (for example when the rate changes and some already accepted transactions become invalid), and also with the upcoming dynamic fee system. We don’t need special code to resolve the fork. All the proposed alternatives require some new checks before a transaction is added to a block to make sure the block won’t be rejected. But that’s not consensus code: a bug here would just make some blocks rejected by every nodes (including the node producing it), it would not produce a fork.

So options 2, 3 and 4 don’t bring more risk of forking besides the fact they require somewhat more complex code.

They could. That’s what I tried to express here:

I’m all for simplicity to start with :sunglasses:

Option 1 please.