Does the Mint/Burn receipt always happen in the context of the tokens address?

[JasoonS]

I’m looking at these docs: Fuel Specifications | Fuel Docs and Fuel Specifications | Fuel Docs

When there is a mint or a burn is the contract_id of the receipt always the ‘creator’ contract of that asset? IE is sha256(contract_id, sub_id) == asset_id always for all Mint and Burn that can be found on chain? It is impossible for mint/burn to be called from any other context?

I’d assume the answer is yes, and if not there is no way to construct the asset_id.

I ask because I have a script that is erroring, and I’m confused what the issue could be.

[JasoonS]

The issue that I’m having in a script that is analyzing all Mint/Burn on the chain using HyperFuel by Envio [the product my team is building] on Testnet.

I get stuck on the burn that happens in this transaction: Fuel Explorer

I calculate that the assetId should be assetId: 0xf229c838d664dd35e9272af4dc34fe7147ed9491e8ca6c1ac9a6230fe9e23513 (since the subId is 0xcd2662154e6d76b2b2b92e70c0cac3ccf534f9b74eb5b89819ec509083d00a50 and the contract is 0x3550c53890db64a241d3cc6523d4255a9c588c4bd8503f911a39444989626626)

Hover these is no mint ever for an asset that matches this?

It is an immaculate conception of as asset - so I must be missing something.

If I skip any burns from 0x3550c53890db64a241d3cc6523d4255a9c588c4bd8503f911a39444989626626 the script runs fine and goes through the whole chain so far (and culculates the total supply of every asset based on Mint/Burn).

If I click through the ‘inputs’ to the transactions, I eventually get to transactions like this as the source of all these funds: Fuel Explorer from here - there are just lots of UTXOs - so maybe this is some kind of block reward thing or something that I don’t understand.

As seen, the first utxo I follow is: “0x241203072ffc6c091a3072ae7e0073d13880b53ed5e7a97d18eb2b2d9300ecc70003”

I’ll share the script once it is a tiny bit more polished.

[Nazeeh21]

I confirmed with my team internally and they are saying burning tokens is impossible if the contract balance of this token is zero. So, if the token was burned, it means it was minted at some point in the life of the contract.

[david]

Hey @JasoonS, as you mentioned, it appears the UTXO being burned was minted in 0x241203072ffc6c091a3072ae7e0073d13880b53ed5e7a97d18eb2b2d9300ecc7.

Is your script not indexing that transaction/output for some reason?

[JasoonS]

Thanks @david - you are right. It is minted in that transaction!

Sorry for the query. It indeed is some kind of bug in the indexer where it is getting the receipts out of order. I’m really grateful for the help in confirming that there is an issue in our API with this case.

Here is the script btw: GitHub - enviodev/example-fuel-assets-script: An example script that gets information about all assets on Fuel Testnet

And this is a commit that shows there is an ordering issue: Show the buggy transactions · enviodev/example-fuel-assets-script@9a40934 · GitHub

[david]

Glad we were able to get it sorted!