I’m aware of the SRC-20 standard, but I’m wondering how to use it.
The problem I’ve encountered: in order to call functions such as name or total_supply from the SRC-20 standard, you need to have two values:
When getting account balances from the fuel node api, you obtain only one of those values - asset id (as per graphql schema).
The question is - what contract id should I use to start calling the SRC-20 functions on an asset?
As an example - is it possible and what contract id should I use if I want to get a name of the base asset id (0x0000000000000000000000000000000000000000000000000000000000000000)?
Hi there!
- As seen in source, the asset_id is calculated by hashing te contract_id and the sub_id.
- The only case where asset_id == “0x000…” is the base asset, which is ZERO_B256.
- The base asset lacks of a wrapper contract so it’s not SRC-20 compliant.
- The metadata lives in the contract that minted the asset.
- what contract id should I use to start calling the SRC-20 functions on an asset
You need the contract_id beforehand since you can’t deconstruct the asset_id hash.
- is it possible and what contract id should I use if I want to get a name of the base asset id
Is not possible, there’s no contract wrapping the base asset.
Let me know if this solves your question 
Thanks for the detailed explanation!
But it doesn’t actually solve the problem I have.
I’d like to give some information about assets that the users posses, but from what you’re saying, it’s impossible unless I know the contract ids in advance. So, every time a new asset comes out on Fuel, I need to contact the issuer and ask for a contract id, is that correct?
This gets even more painful with NFTs (which are also native assets). Every time someone creates an NFT, we need to get its contract id in order to be able to understand that this is an NFT and show some info about it.
Is there a workaround you can think of? If not, I believe that it’s an important feature for a blockchain to have
@sandusky hey, do you have any ideas on how to achieve this?
@sandusky sorry for pinging you again, but do you have any idea on how to implement this?
Hi there!
Sorry for the delay @mpoplavkov
I was out for devconnect.
This issue was the source of an interesting conversation among the Fuel Labs engineers.
The quick answer is that there’s no simple way to solve this.
Internally, the following approaches were discussed.
- A global indexer solution.
- A “ERC-1820” inspired central registry
- An onchain assetId → contractId map attached to the TX.
Since #2 and #3 seem quite out of reach for your current situation, the #1 might be a choice.
Basically is an indexer module tracking all mints.
Right now is not that expensive but can result in a lot of infra in the context of mainnet.
Such a tool might require some kind of query fee service, such as The Graph. Maybe a middleware trying to spend predicates before serving queries. Feels like a product by itself.
I think the source of this question is some kind of portfolio metadata display.
My take is to build this kind of indexer but initially just track the most active contracts and slowly evolve into a wider approach.
I’m bullish on the “indexer marketplace - query fee service” dapp. It might be a fit for some kind of grants program 
What do you think about this?
1 Like
Yes, I thought about the indexer but wanted to avoid implementing it if Fuel was to suggest a better approach 
We’ll estimate the complexity of running an indexer and think about it, thank you!
1 Like
Thanks for sharing your thoughts.
Implementing an indexer solution like this can result in a product by itself.
A better approach requires some tweaking at the client level, so it might take a while, right now the quickest way to unblock is by implementing the indexer.
Let me know if you need further support on this endeavor!
1 Like
Hello @sandusky. Do you have any updates on this topic by any chance? Maybe Fuel has decided to solve this problem somehow?