I’m sure this is an incredibly simple question, but how do I query an account to show its tokens? I haven’t found a specific query for this in (http://developer.concordium.software/concordium-grpc-api/#concordium.v2.Queries). Should I use invoke_instance with a standard entry point?
The node does not keep track of this directly. CIS-2 tokens are not a native chain concept. They are defined by smart contracts.
You have to extract this information from block events.
Ok that’s clear. Is that only from ‘mint’ events, or also other events?
An account can get tokens also from Transfer events.
And it can also lose them via Burn events.
As a follow up to this. The CIS-2 specification writes:
It MUST be possible to derive the balance of an address for a token type from the logged TransferEvent, MintEvent and BurnEvent events.
I would have assumed reading the above that tokens can only be ‘created’ from a mintEvent, which specifically credits an Address. Then, using a transferEvent, tokens can get sent around, affecting both the from and to Addresses, and finally, in a burnEvent an Address will have an amount of tokens removed.
If the above logic follows, a transferEvent of a token should always be preceded by a mintEvent, if not, then you’re transferring tokens that do not exist?
Yes, tokens can only be “created” (globally) by mint events. An address can get tokens either by Mint or Transfer events.
So you cannot transfer non-zero amounts if they have not been preceded by a mint event, that is correct.
As in: technically not possible, or not in adherence to the specification?
It is technically possible. A contract could emit these events, but then it does not conform to the standard.
Do note that Mint, Burn, and Transfer events can also be emitted during initialization of the contract instance though.
Is it technically possible that contracts send ‘broken’ events, as in: not according to the specification? Ie, if you were to parse a transferEvent but the result is not as expected?
If so: am I to discard those?
Yes, it is possible.
You should ignore those events, since the contract is not following CIS2 spec.
Ok. However, the contract can still report in the supports method that it supports the CIS-2 standard, correct?
Yes, it can. That is not possible to enforce.
Sorry, I did not want to respond until I have looked at the data myself and I have not had the time to do it.
But my guess is that the contract just does not adhere to CIS2 properly. The mint event is just missing. That is assuming you have not missed any events.
I am not sure when I’ll have time to look into it myself, perhaps Wednesday.
Thank you, this is exactly what I need, an independent eye on the data.
I’ve learned that token management is not a native node concept, however I would have thought that a smart contract transaction that violates the principle of transferring tokens an address doesn’t own, would not lead to a successful account transaction? That’s my main concern here.
Again, thank you for your time.
I think I’ve figured this out, finally.
The tokens were from another instance (2163), and they are minted in this transaction.
Phew!