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]

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.