Ownership of native assets

General
1

Based on my reading of this thread and this GitHub issue, I understand that SRC-20 purports to implement a contract standard for associating metadata (name, symbol, decimals) and indexing parameters (e.g. total supply) to native assets.

That’s cool. But what I don’t understand is how these contracts are owned, particularly how the minting and burning processes are managed.

As per the Fuel specs, I gather that assets can be minted by any contract whatsoever. But how does this opcode work when $rB (the asset id) has already been minted by some other contract?

Only the original contract is allowed to mint further coins, right?

2

But how does this opcode work when $rB (the asset id) has already been minted by some other contract?

When calling the mint opcode, the $rB provided is the Sub Id, this can be seen here in the standard library.

Internally, the Asset ID is then created from the hash of the calling contract’s Contract ID and the Sub ID as per the spec here.

Only the original contract is allowed to mint further coins, right?

Due to the hashing of the Contract Id and Sub Id, the coins minted from a contract can ONLY be minted by that contract and it’s Sub Id. Any other Contract Id or Sub Id will generate a different Asset Id.

The same goes for burning, the Sub Id is provided and hashed with the calling contract’s Contract Id. This must hash to the Asset Id.

2 Likes
3

Upon minting and burning, a receipt containing the Contact Id and Sub Id is provided which can be fetched via the indexer. This can be used to verify that a particular contract is the minting contract.

1 Like
4

Thanks for the detailed answer, @bitzoic. All clear now!

Is the sub id $rB supposed to be a random value generated by the contract developer?

5

It’s up to the developer!

  • If the contract only creates a single token, we expect the SubId will often be 0
  • For NFTs, the SubIds might be sequential
  • In the case of “vault” type tokens, the subId might be the AssetId of the underlying asset
  • ENS-style naming applications might use a namehash-type algorithm
  • You can even use asset sub-ids to represent contract state! Pass some state into the asset subId, and you can then reconstruct the assetId in a separate contract or predicate to prove state (I’ve called this idea “packet-oriented programming”, probably needs a better explanation than this)
1 Like
6

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.