Approaches to burning NFT

Question

I see the objkt marketpklace transfers the token to tz1burnburnburnburnburnburnburjAYjjX instead of burning the token when I click on the burn Token, that results in making the supply of the nft same as that of previous and the ledger value will be different .

In simple words, I call the burn from objkt and then the nft is being transferred to the above address, but the supply remains same. I am confused why are objkt using the burn feature this way.

However, In smartpy code(FA2 template), whenever burn function is called supply is deducted.

can someone share some thoughts here on which approach to use on tezos ?

Answer 1

tz1burnburnburnburnburnburnburjAYjjX is one of the burn addresses used in Tezos, like tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU(=0x0000000000000000000000000000000000000000) used in SIRIUS.

There is no way in Tezos to destroy tez, the native token, so burning tez means sending tez to an address you are sure nobody have the private key.

For tokens you can have 2 approaches:

• same as for tez to have a straight proof of burn and avoid any deletion code in the contract. That's the one chosed by objkt.
• deleting the token in the storage

The later save burn and you can still look at the operation as a proof of burn

Answer 2

As you have already mentioned, there are two approaches to FA token burn implementation:

1) Transferring to "burn address". In this case you don't really burn tokens, but just send them to a random valid address that supposedly no one has access to, so they supposedly cannot be accessed anymore.

Pros:

• no need to implement a "burn" entrypoint.

Cons:

• transfer operation spends more gas, because it updates 2 balance records in contract's storage, instead of just one;
• transfer operation spends extra storage, because when it sends a token to a burn address first time, in writes a new balance record (burn_address, token_id) -> balance to contract's storage;
• complicated supply calculation, because "burned" tokens still exist, especially when people use multiple different burn addresses (nothing stops them from doing so);
• there is no 100% guarantee that really no one will ever get access to the burn address, despite the fact that this is almost impossible :D

2) Removing from contract storage. In this case you simply decrease or even remove someone's balance from the contract storage, that means that tokens are really burned.

Pros:

• doesn't spend extra gas (i.e. less baker fee);
• doesn't spend extra storage (i.e. less storage fee);
• simple supply computation (just a sum of all balances);
• there is 200% guarantee that really no one will ever access burned tokens :D

Cons:

• you will need to implement a "burn" entrypoint.

So, removing tokens from the contract storage is the best approach, IMO.