Runtime API for burning NEAR

[ilblackdragon]

We need a way to burn NEAR, for example for Top level account name registry account.

The burning is different from just sending NEAR to locked account without retrieval, because it decreases the total supply - which affects a bunch of other parameters (like inflation and pay outs).

[bowenwang1996]

@ilblackdragon is this required for phase 1?

[maxzaver]

This does not sound like a host function, but rather a specific use case that is handled by the runtime when account is created.

Also, why not stake instead of burning? What happens when people create top-level account and then delete it?

[ilblackdragon]

Burning tokens means:

• They are taken out of circulation
• Total supply that is accounted for all economic activity (rewards, burn, etc)

I don't think there is a way to do this outside of host function.

Specifically for TLA auction contract - when auction is burned, the proceeds from the auctions are burned. Same for example for some "selling NEAR contract" which would rebuy NEAR later and burn it. Also bunch of other use cases, including in the POA MainNet we currently have inflation that we need to burn it.

[ilblackdragon]

Currently address for burning is not very clear: https://explorer.near.org/accounts/0000000000000000000000000000000000000000000000000000000000000000

It's not clear if it's a valid address and there are a bunch of fake addresses with less 0s

Few considerations:

• adding some UI on explorer
• creating a custom TLA like "burn" / "blackhole" / etc for this purpose.

[vans163]

Is there any clarity on this?

On ETH the tokens fully leave circulation so its reflected on total supply as mentioned above.
https://ethereum.stackexchange.com/questions/16188/best-way-to-burn-ethers-and-other-ethereum-tokens/29695

[bowenwang1996]

Is there any clarity on this?

As mentioned previously, if we want to have this feature, the only reliable way is to implement a host function on the protocol level.

[vans163]

Is there any clarity on this?

As mentioned previously, if we want to have this feature, the only reliable way is to implement a host function on the protocol level.

Any current workarounds? I see its should be theoretically possible to call

internal_withdraw("0000000000000000000000000000000000000000000000000000000000000000", amount_to_burn)

that should lower the total_supply on the contract too. But I dont want the tokens to be stuck on 000... when the proper solution comes along. (i guess they cant really be stuck, the contract can just move them off 000.. manually some day in the future)

Maybe it makes sense to just keep a counter called total_burned on the contract and to subtract total supply but increment total_burned as a stopgap?

Or do as mentioned above and total_burned == the balance on 000.. address, and to burn internal_withdraw to 000.. (without calling ft_transfer / deposit)

[bowenwang1996]

Oh you are referring to fungible tokens. That is indeed different and it could be handled on the smart contract level entirely. I suppose we just need a standard for this. cc @frol @jberrytech @mikedotexe

[vans163]

Oh you are referring to fungible tokens. That is indeed different and it could be handled on the smart contract level entirely. I suppose we just need a standard for this. cc @frol @jberrytech @mikedotexe

Yea you can see this comment, lightsea90/near-ft#2 how they implement it is calling this.internal_withdrawal to what I think is contract itself (maybe they use invalid address), but I think the final solution should take into account the total_supply is properly decremented and as well perhaps a total_burned counter is available.

[lightsea90]

Oh you are referring to fungible tokens. That is indeed different and it could be handled on the smart contract level entirely. I suppose we just need a standard for this. cc @frol @jberrytech @mikedotexe

Yea you can see this comment, lightsea90/near-ft#2 how they implement it is calling this.internal_withdrawal to what I think is contract itself (maybe they use invalid address), but I think the final solution should take into account the total_supply is properly decremented and as well perhaps a total_burned counter is available.

Really interested in this as we are introducing a token burn feature to users. My design in lightsea90/near-ft#2 is that the token creator should be the only one is allowed to burn i.e control the token supply. Just feel free to chime in if you guys think of any.