I saw that many tokens are being updated to new versions due to CIP, how can I check if a token is in the old or more current version?
And where can I read more about what this changes to the token?
1 Like
Okay, I just upgraded one of my ADA Handles from CIP-25 to CIP-68: https://adastat.net/transactions/e0f419857b8b5c2773f3858df35be3050de79b97f2e17a0bcde4eb181383507b
So, lets go through it:
CIP-25
The old standard for NFTs as specified in https://cips.cardano.org/cip/CIP-0025 was used for the old handle https://adastat.net/tokens/f0ff48bbb7bbe9d59a40f1ce90e9e9d0ff5002ec48f232b49ca0fb9a68657074617365616e which was burned in that transaction (the one on the left side in Eternl’s transaction summary.
To actually find the metadata – the name, the link to the image, everything except the on-chain asset name (which may or may not be what you expect, some projects have very readable ones, some have very garbage-y on-chain asset names, e.g., if they want to hide what you will get during minting) – one had to find the (latest) minting transaction for the token which was: https://adastat.net/transactions/e08682f0dedd2c0c69326735ce0d94450d2811f4da835a0a4693baf809effadf And in the transaction metadata of that old transaction are the metadata (in this case of a lot of handles since they were minting them in batches, but the one of my handle was in there):
So, to find CIP-25 metadata on-chain you need access to a database of the whole history of the chain because you need to look up transaction metadata of potentially very old transactions. There are APIs/services that do that for you, of course.
CIP-68
The new standard as specified in https://cips.cardano.org/cip/CIP-0068 is used for the new handle https://adastat.net/tokens/f0ff48bbb7bbe9d59a40f1ce90e9e9d0ff5002ec48f232b49ca0fb9a000de14068657074617365616e. CIP-68 NFTs actually come with two tokens. This one is the “user token” and the other one https://adastat.net/tokens/f0ff48bbb7bbe9d59a40f1ce90e9e9d0ff5002ec48f232b49ca0fb9a000643b068657074617365616e is the “reference NFT” which was not transferred to me, but put on a script address belonging to the ADA Handle project.
The on-chain asset name of the user token is 000de14068657074617365616e and the one of the reference NFT is 000643b068657074617365616e. The 68657074617365616e is just heptasean – the name of my handle – in hexadecimal bytes. The bytes before that are the labels which are enclosed by 0 nibbles (4-bit blocks, hexadecimal characters). 00de14 consists of de which is the actual label 222 in hexadecimal and 14 which is a checksum of the label. 00643b consists of 64 which is the label 100 in hexadecimal and 3b which is the checksum of that. So, if you find a token whose asset name starts with 000de140 it’s always the user token – the thing you find in users’ wallets – of a CIP-68 NFT. If it starts with 000643b0 it’s always a reference NFT. And you can identify NFTs using that standard simply by that.
ADA Handle actually did also include CIP-25 metadata in that mint – probably to be backwards compatible to tools and services that do not know about CIP-68 by now:
But the idea of CIP-68 is that metadata are not anymore at those minting transaction metadata, but in output datums of the transaction output that currently holds the reference NFT. You can see them in the Eternl screenshot at the beginning on the right-hand side with the second of the outputs. Unfortunately, blockchain explorers only have limited support for showing them up to now. Adastat does not show them at all and Cardanoscan only displays a long hex string (on the “UTxOs” tab). Eternl does decode them to a JSON structure, but it’s not as comprehensible as the one for CIP-25.
The advantage is that output datums are given to Plutus scripts, so they can verify facts stated in the NFT metadata (if the reference NFT is given to the script at least in a reference input) which was not possible previously, because transaction metadata are outside the scope of validator scripts.
Moreover projects can modify the metadata without having to do artificial mint and burn transactions just by spending the UTxO holding the reference NFT and putting it on a new UTxO with the new metadata. (Since ADA Handle decided to also have CIP-25 metadata, they will have to still additionally do that or the content of both will be inconsistent. I will see how that works out when customising my handles.)
Moreover, if an inline datum is used as here, those are stored in the ledger (the current UTxO set, the set of transaction outputs that are still unspent) and it is not necessary to search the whole transaction history for the metadata. It is also possible to just give a hash of the datum and store the actual datum either in a transaction witness or not on-chain at all, but in some off-chain storage. Both variants lose this advantage of CIP-68.
So, hope this helps a bit.
(By the way: I know that we still have another thread open. Didn’t come to that up to now. Sorry!)
6 Likes
Just realised that you never said NFT. So, fungible tokens:
CIP-26 Cardano Token Registry
Traditionally, fungible tokens do not have any metadata on-chain, but “just” an off-chain token registry. The technical basis is specified in https://cips.cardano.org/cip/CIP-0026 and the registry itself and additional documentation is at: https://github.com/cardano-foundation/cardano-token-registry
As an example, the MILKv2 token https://adastat.net/tokens/afbe91c0b44b3040e360057bf8354ead8c49c4979ae6ab7c4fbdc9eb4d494c4b7632 has its off-chain metadata in https://raw.githubusercontent.com/cardano-foundation/cardano-token-registry/master/mappings/afbe91c0b44b3040e360057bf8354ead8c49c4979ae6ab7c4fbdc9eb4d494c4b7632.json.
CIP-68
CIP-68 already linked above for NFTs also has functionality for putting the metadata of fungible tokens on-chain. An example is FLDT https://adastat.net/tokens/577f0b1342f8f8f4aed3388b80a8535812950c7a892495c0ecdf0f1e0014df10464c4454. Again, the 0014df10 at the beginning of the asset name 0014df10464c4454 is the label with 14d being 333 in hex and f1 being the checksum. 464c4454 is just the token name FLDT in hex. This is the user token that is sent around (just as in the case of NFTs except that there are a lot of them in circulation).
So, as in the case of NFTs, if you see a token whose on-chain asset name starts with 0014df10, you know it’s an FT using CIP-68.
We can again find the reference NFT by replacing the label with 000643b0 for the label 100: https://adastat.net/tokens/577f0b1342f8f8f4aed3388b80a8535812950c7a892495c0ecdf0f1e000643b0464c4454 This reference NFT has just been minted once and never moved from the contract address it is stored on.
We can see the datum on Cardanoscan at: https://cardanoscan.io/transaction/ac7bfd6e7d7639c4b282c9ad9faeb3a516a40245863c1e82d85f08707a1fa28d?tab=utxo (scroll down to the output to the script address with 1 FLDT on it). If you click on the icon indicating that there is a datum on that output, you see the long hex string and it also has a link to decode that which leads to: https://cardanoscan.io/datumInspector?datum=d8799fa648646563696d616c73064b6465736372697074696f6e5f5840546865206f6666696369616c20746f6b656e206f6620466c756964546f6b656e732c2061206c656164696e6720446546692065636f73797374656d206675656c5827656420627920696e6e6f766174696f6e20616e6420636f6d6d756e697479206261636b696e672eff446c6f676f582068747470733a2f2f666c756964746f6b656e732e636f6d2f666c64742e706e67446e616d6544464c4454467469636b657244464c44544777656273697465581868747470733a2f2f666c756964746f6b656e732e636f6d2f0101ff The decoding is still in hex, you’d have to decode that to ASCII/UTF-8, but we can already guess that there are 6 decimal places, that there is a link to the website there and the name and ticker FLDT is specified.
Redundantly, supposedly again for backwards compatibility, they also have registered in the Cardano Token Registry: https://raw.githubusercontent.com/cardano-foundation/cardano-token-registry/master/mappings/577f0b1342f8f8f4aed3388b80a8535812950c7a892495c0ecdf0f1e0014df10464c4454.json
And as with the ADA Handle having CIP-25 and CIP-68 metadata, they’d also have to make sure that these two sources stay consistent should they ever decide to modify one of them. I really hope, the old ways – CIP-25 and Cardano Token Registry – seize to be necessary at some point, since this redundancy just makes everything more complicated.
(Actually, a lot of fungible tokens have abused CIP-25 – originally designed for NFTs – to get a bit nicer and more expressive metadata. So, in the worst case, we could now have fungible tokens with three sources of metadata – Token Registry, CIP-25 in the latest minting transaction, and CIP-68 at a datum with the reference NFT.)
There are also RFTs – Rich Fungible Tokens – specified in CIP-68, but I’ll leave that till I have found a decent example for it.
5 Likes
And I also got an example for an RFT: 444 HAND https://pool.pm/asset1w7acqqk64hrsv8z2pkwjr7fhjxcdf88cxf2u2e
The idea of RFTs is that you have rich information like in NFTs with possibly several media files, all with separate descriptions, …, but you can have a supply of more than 1 even with decimals. For this example, there are 96.
On Adastat: https://adastat.net/tokens/de7b8e3e5add73aaadf3f5d3241ed86973feb22806070bc847ffbeeb001bc2803448414e44
The on-chain asset name 001bc2803448414e44 can again be decoded as we already know by now: 1bc is 444 in hex, 28 is the checksum of that, 3448414e44 are the ASCII hex bytes of 4HAND.
And we again find the reference NFT at 000643b03448414e44 under the same policy: https://adastat.net/tokens/de7b8e3e5add73aaadf3f5d3241ed86973feb22806070bc847ffbeeb000643b03448414e44
But … if we now try to find the datum at the UTxO with the reference NFT in https://cardanoscan.io/transaction/57f2dbd708860bc3eb8cbefba49f584df98d7516a81e8204d399c248f0b9970b?tab=utxo (it’s the second one, the first one is an NFT specifying the royalties with the label 500), we only find a datum hash there, but not the datum itself.
https://api.koios.rest/#post-/asset_info can find the metadata if I use the query:
$ curl -X POST "https://api.koios.rest/api/v1/asset_info" \
-H "accept: application/json"\
-H "content-type: application/json" \
-d '{"_asset_list":[["de7b8e3e5add73aaadf3f5d3241ed86973feb22806070bc847ffbeeb","001bc2803448414e44"]]}' \
I think they have to be in the witness set of the minting transaction and I have just not found the right query to Koios to find them, but I’m not sure.
Edit: The creator of that RFT has written an article about it’s creation using Lucid: https://medium.com/@griffstlouis/how-i-created-one-of-the-first-rich-fungible-tokens-rft-on-cardano-c12c8003dc50
4 Likes