# How do I check which CIP a token was created in?

**URL:** <https://forum.cardano.org/t/how-do-i-check-which-cip-a-token-was-created-in/128054>\
**Category:** Native Tokens\
**Created:** [22 February 2024 18:44 UTC](https://forum.cardano.org/t/how-do-i-check-which-cip-a-token-was-created-in/128054 "2024-02-22T18:44:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Endreas](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/endreas/32/74521_2.png) [@Endreas](https://forum.cardano.org/u/Endreas)\
**Post date:** [22 February 2024 18:44 UTC](https://forum.cardano.org/t/how-do-i-check-which-cip-a-token-was-created-in/128054/1 "2024-02-22T18:44:22Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![HeptaSean](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/heptasean/32/82306_2.png) [@HeptaSean](https://forum.cardano.org/u/HeptaSean)\
**Post date:** [22 February 2024 21:01 UTC](https://forum.cardano.org/t/how-do-i-check-which-cip-a-token-was-created-in/128054/2 "2024-02-22T21:01:23Z")

</div>

Okay, I just upgraded one of my ADA Handles from CIP-25 to CIP-68: [https://adastat.net/transactions/e0f419857b8b5c2773f3858df35be3050de79b97f2e17a0bcde4eb181383507b](https://adastat.net/transactions/e0f419857b8b5c2773f3858df35be3050de79b97f2e17a0bcde4eb181383507b)

 ![screenshot-2024-02-22-21:11:51](https://us1.discourse-cdn.com/flex023/uploads/cardano/original/3X/0/5/05cc311df2d52883bf4d5bf0551152737185b2b6.png)

So, lets go through it:

# CIP-25

The old standard for NFTs as specified in [https://cips.cardano.org/cip/CIP-0025](https://cips.cardano.org/cip/CIP-0025) was used for the old handle [https://adastat.net/tokens/f0ff48bbb7bbe9d59a40f1ce90e9e9d0ff5002ec48f232b49ca0fb9a68657074617365616e](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](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):

 ![screenshot-2024-02-22-21:26:06](https://us1.discourse-cdn.com/flex023/uploads/cardano/original/3X/b/f/bf198009c104a9e7e040fae97e6831240349e92d.png)

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](https://cips.cardano.org/cip/CIP-0068) is used for the new handle [https://adastat.net/tokens/f0ff48bbb7bbe9d59a40f1ce90e9e9d0ff5002ec48f232b49ca0fb9a000de14068657074617365616e](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](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:

 ![screenshot-2024-02-22-21:43:24](https://us1.discourse-cdn.com/flex023/uploads/cardano/original/3X/1/1/1189ff37014b3395d3a7f27dec31b7519446f12b.png)

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!)

---

<div class="post-metadata">

**Author:** ![HeptaSean](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/heptasean/32/82306_2.png) [@HeptaSean](https://forum.cardano.org/u/HeptaSean)\
**Post date:** [22 February 2024 22:05 UTC](https://forum.cardano.org/t/how-do-i-check-which-cip-a-token-was-created-in/128054/3 "2024-02-22T22:05:19Z")

</div>

Just realised that you never said _N_FT. 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](https://cips.cardano.org/cip/CIP-0026) and the registry itself and additional documentation is at: [https://github.com/cardano-foundation/cardano-token-registry](https://github.com/cardano-foundation/cardano-token-registry)

As an example, the MILKv2 token [https://adastat.net/tokens/afbe91c0b44b3040e360057bf8354ead8c49c4979ae6ab7c4fbdc9eb4d494c4b7632](https://adastat.net/tokens/afbe91c0b44b3040e360057bf8354ead8c49c4979ae6ab7c4fbdc9eb4d494c4b7632) has its off-chain metadata in [https://raw.githubusercontent.com/cardano-foundation/cardano-token-registry/master/mappings/afbe91c0b44b3040e360057bf8354ead8c49c4979ae6ab7c4fbdc9eb4d494c4b7632.json](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](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](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](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](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](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.

---

<div class="post-metadata">

**Author:** ![HeptaSean](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/heptasean/32/82306_2.png) [@HeptaSean](https://forum.cardano.org/u/HeptaSean)\
**Post date:** [22 February 2024 22:49 UTC](https://forum.cardano.org/t/how-do-i-check-which-cip-a-token-was-created-in/128054/4 "2024-02-22T22:49:26Z")

</div>

And I also got an example for an RFT: 444 HAND [https://pool.pm/asset1w7acqqk64hrsv8z2pkwjr7fhjxcdf88cxf2u2e](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](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](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](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](https://api.koios.rest/#post-/asset_info) can find the metadata if I use the query:

```bash
$ 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](https://medium.com/@griffstlouis/how-i-created-one-of-the-first-rich-fungible-tokens-rft-on-cardano-c12c8003dc50)
