Opcode: BURN

[PaulRBerg]

Spec

This opcode burns amount tokens with the sub-identifier sub_id from the holder's account.

Input

• holder of type Address
• sub_id of type B256
• amount of type U256

Output

Nothing.

Receipt

• New receipt of type Burn
• Data
  • token_id of type U256
  • sub_id of type B256
  • New total supply of type U256
  • New holder balance of type U256 (maybe?)

Errors

See https://github.com/sablier-labs/SRFs/blob/main/SRFs/srf-2.md#burn.

• holder has less than amount

Notes

• Only contracts can call BURN
• The sub_id passed to BURN will be used to generate the token ID. More concretely, the token ID will be KECCAK256(concat(address,sub_id)).

References

• SRF-2: Mint and Burn
• Fuel: BURN instruction
• Fuel Forum: Ownership of native assets

[PaulRBerg]

Just a heads-up @IaroslavMazur that I updated this spec to include a holder input.

This will lead to a better UX when developing SRF-20 contracts because users won't have to transfer the tokens to the contract before being able to burn them.

For more context, see my discussion with the Fuel team: https://forum.fuel.network/t/can-native-assets-be-minted-to-arbitrary-accounts/3108?u=prberg

[IaroslavMazur]

Note that because:

• we need to make sure the burner should, actually, be allowed to burn the tokens and
• we won't have approvals, the tokens that are to be burned will have to be transferred by the holder in the tx that, ultimately, triggers our Precompile to burn them.

I've checked out the SRF-2: Mint and Burn standard, and here's how I envision this would work:

1. a token holder $A$ calls the burn() function of the SRF-2 contract, transferring (just) the contract-associated tokens to be burned,
2. the SRF-2 contract performs the relevant verifications - and calls the SabVM Precompile, transferring it all of the tokens to be burned,
3. the Precompile does some more checking, ultimately burning the tokens.

In this context,

1. passing the amount argument to the SRF-2 contract is redundant, as this information can be deduced from the tokens effectively transferred in the current tx;
2. similarly, the holder argument is redundant, as every holder may only burn the tokens they own themselves;
3. we need to discuss whether the sub_id argument should, actually, be token_id. An argument for this would be that when a user wants to transfer the token in a tx, they'd need to specify the token_id - and it'd be wrong to expect/ask the users to keep in mind both the sub_id and the token_id of each of the tokens they use.

---

Another thing worth noting here is that because we won't have total control upon the implementation of the SRF-2 contracts, we won't be able to guarantee that the contracts behave correctly in terms of how much they, actually, burn, etc. However, this is similar to how it's, currently, not the responsibility of Ethereum to validate and approve the logic inside the ERC-20 contract deployed to the blockchain.

---

Why output both the token_id and the sub_id in the emitted Receipt, though? The token_id is the only thing that should be present there, IMO.

[PaulRBerg]

Good points about those external arguments being redundant for end users. However, you seem to have criticized SRF-2, not this opcode. The BURN opcode does require all those parameters.

we need to discuss whether the sub_id argument should, actually, be token_id

Maybe. This should be discussed in a separate issue/ discussion, though.

However, this is similar to how it's, currently, not the responsibility of Ethereum to validate and approve the logic inside the ERC-20 contract

Yes.

Why output both the token_id and the sub_id in the emitted Receipt, though? The token_id is the only thing that should be present there, IMO.

The sub_id cannot be derived from the token_id because of how hashing functions work. Adding the sub_id simplifies the discovery process for analytics services, etc.

[PaulRBerg]

Opened a separate issue and hid the comments here as off-topic: https://github.com/sablier-labs/SRFs/issues/15

[IaroslavMazur]

you seem to have criticized SRF-2, not this opcode

Indeed, I was, mainly, speaking about SRF-20, as we have previously decided to depricate the opcode design.

---

The sub_id cannot be derived from the token_id because of how hashing functions work. Adding the sub_id simplifies the discovery process for analytics services, etc.

It's true that there's no way to reverse-engineer the token_id back into the sub_id that has been used to compute the former. However, besides just the sub_id, the address of the SRF-20 creator of the NT would also be needed to fully refer to an NT.

Therefore, the likes of the "analytics services" you've mentioned would be better off referring to the NTs via their respective token_id after the minting (when the token_id is first computed), instead of the NT creator address + the sub_id (which need to be combined to form the token_id before any operation with the NT, anyways).

Outputting all of the 3 pieces of information (the holder address, the sub_id and the token_id (composed from the first 2)) in the Burn receipt would be redundant, imo.