Canonical burn

[murbard]

It can be sometimes useful for contracts to provably burn tez. One way they can do that is by sending the tez to an address to which clearly no one has the key.

Examples include:

• tz1burnburnburnburnburnburnburjAYjjX (as of today 4.2 tez have been burned there)
• tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU (the null address)

It’s also possible to create a smart-contract that simply eats the tez and never releases them.

The benefit of having a canonical approach, that is: have one, standard, way to burn tez is that block explorers can easily take it into account when measuring the supply.

There are roughly two ways to do this:

1. Standardize on an address (e.g. tz1burnburnburnburnburnburnburjAYjjX)
2. Introduce a BURN opcode in Michelson that burns a given quantity of tez from the current balance

The former has the advantage of not requiring any protocol change, just a tzip. It has the disadvantage of being a bit costly in gas and “looking” like there’s an address with tez, even though they are clearly burned.

The latter has the advantage of being more gas sparing, but it would need to be part of a protocol upgrade and its semantic may need to be clarified. What does BALANCE return if called after BURN? Does it get applied at the end? Before the operations? As some sort of virtual operation?

Thoughts?

[perfectparadox]

The first option may be easier but it adds calculations to other metrics like total cap. and volume. Analyst and websites would have to account for Tez that is there, but really isn’t. I know it’s small but for the sake of uniformity across the board, if the second is an option that can be rolled into more upgrades (inevitable) what’s the argument against doing so?

[Katapult]

Hello, the idea of ​​burning Tez surprises me enormously, because it seems to me that since the beginning of the adventure you are not in favor of this kind of practice which, in short, can be likened to the upward manipulation of the cost of the token. may I know what made you change your mind?

[perfectparadox]

I’m sure there are some applications of the chain that burning tokens would be helpful if not necessary. I think that a lot of the negative views come from people trying to get the TF to burn their holdings to artificially drive the price up on the markets.

[murbard]

I’ve said no such thing and I don’t believe that’s true. Burning is present in several parts of the protocol, including account creation and slashing. I’m suggesting a way to allow smart contracts that want to do it to go it in a canonical way.

[Katapult]

it’s true that it was out of context, out of memory, it was a video where everyone can ask the question, and we had addressed the burning of the foundation tokens.

[m-kus]

If we stick to keeping Michelson side-effect-free, first option it is. I also vote for the null address, because it’s probably more suitable as a Schelling point, plus this approach already used in the fake context (to mock SELF_ADDRESS and originated contract addresses).

[murbard]

The problem here is the implicit expropriation, not the concept of burning per se. I’d love to see inflation funded projects that embed a small amount of burning as part of their operation. If the project is successful and has enough of a network effect to make the fee defensible, it can pay for itself by burning more than it initially created.

[sophia]

If we want to have the protocol track outstanding tez and inflation to expose to RPC, a BURN opcode would probably be easier.

[murbard]

Depends. The way I envision the tracking is that you make tez into an abstract type and prevent most operations on it. The only thing you can do is call an accounting module that transfers tez from one account to another (including a source and sink account). It’s then easy for that module to special case the canonical burn address as a sink.

[sophia]

Maybe we have figured out how to make the protocol depend on special addresses.

[xpop]

For the first option, do burnt Tez within the tz1burn… address still get considered by the protocol when accounting for reaching governance quorum on proposals?

In the second option, for the BURN opcode in Michelson, would this result in the XTZ being removed from the supply in terms of accounting for all rolls / XTZ on the chain? And how would it effect things such as reaching governance quorum on proposals?

Would it be possible to start with a tz1burn address, and then in a following upgrade use the BURN opcode to burn and remove the Tez from the protocol straight up?

@murbard

The problem here is the implicit expropriation, not the concept of burning per se. I’d love to see inflation funded projects that embed a small amount of burning as part of their operation. If the project is successful and has enough of a network effect to make the fee defensible, it can pay for itself by burning more than it initially created.

Also just wanted to say that I really like this idea and it would help balance the creation of new supply.