Cardano Token Registry Without Minting Token To Policy ID

Developers Native Tokens
, ,
1

Hey guys, I just have a quick question, I’ve created a policy ID that a token is going to be attached to but I haven’t yet decided how many tokens I want, so I just want to register the token’s name and stuff to the registry, without minting any tokens to the policy ID, but the policy ID says “no results” when I search it up on cardanoscan or cexplorer. I’m just wondering does there have to be tokens already minted to the policy ID before I can register the token to the registry or can I do it without minting any tokens to the policy ID? Thanks in advance for your help :pray:

2

Before any tokens have been minted on that policy ID, they won’t appear in blockchain explorers, since those just observe the blockchain and only report what they have seen there. If there was no minting, they haven’t seen the policy ID.

I don’t know if the maintainers of the token registry are willing to merge the metadata before the mint. Technically, they can check the signatures on the metadata before that.

3

Yeah I understand, thank you for your response. I guess I could still try to register the token and see what happens. The only thing I’m worried about is making sure that the time lock for the policy is correct but I can’t check it on the blockchain explorers because it doesn’t show up. Is there any other way to check the time lock to make sure it’s correct?

4

What exactly do you want to check?

That you computed the correct policy ID from your policy script? Just do it again.

That the slot number you wrote into that policy script is the correct point in time that you intended? You’d need some conversion tool.

Or shortly write one yourself.

According to https://cardano.stackexchange.com/questions/8768/how-can-i-calculate-slot-number and the Byron and Shelley Genesis files linked on https://book.world.dev.cardano.org/environments.html#production-mainnet:

  • The Byron era started at 2017-09-23T21:44:51Z or 1506203091 in Unix time.
  • Byron had slots of 20s.
  • The Shelley era started at 2020-07-29T21:44:51Z or 1596059091 in Unix time, which apparently was the beginning of Epoch 208 or absolute slot 4492800.
  • Since then we have slots of 1s.

If we are content with slots in the Shelley era, it’s quite simple:

Convert slot to date:

$ date -Iseconds -u -d @$((100000000-4492800+1596059091))
2023-08-09T07:31:31+00:00

We subtract the absolute slot 4492800 for the beginning of the Shelley era and add the Unix timestamp 1596059091 for it and then use date (-Iseconds says that we want ISO 8601 format with second precision, -u that we want UTC, and after -d we give the point in time we want to print, where @ says that it is a Unix timestamp) to get a human-readable date.

And we find that we will reach the absolute slot 100 000 000 on 9th of August.

Convert date to slot:

$ echo $(($(date +%s -u -d "2023-08-09T07:31:31")-1596059091+4492800))
100000000

Vice versa, we use date to find the Unix timestamp for a given point in time (+%s prints the Unix timestamp, -u says that we give the time in UTC, and after -d we give the time we want to convert) and subtract the Unix timestamp and add the absolute slot of the beginning of Shelley.

If we would want to incorporate also Byron, we’d need some conditions. But not tonight.

1 Like
5

Wow thank you for the very comprehensive answer, I truly appreciate your time and knowledge. I just wanted to confirm that the slot of the time lock on the policy was correct as I wanted to set it for 6 months in the future, from the date I created the policy. I will try your method though to confirm that it’s correct. Thank you once again, God bless and take care friend :pray:

6

OK I have used the code you provided above to generate a policy ID to check the time lock date on it and it’s coming up as the 14th of January 2026, which is not the date I was going for, I was going for the 3rd of January 2024. Can you tell me what I did wrong please?

Here is the code I ran

date -Iseconds -u -d @$((112700800-4492800+1596059091))

//check slot from date
echo $(($(date +%s -u -d "2024-01-03T07:31:31")-1596059091+4492800))
7

Did you try it on preview or preprod? The numbers will be different there.

Unfortunately, I did not find the definitive way to find the Byron-Shelley hard fork on-chain up to now (Cardanoscan and Koios have parameter updates, but not hard forks as far as I can see). The Genesis files just contain the system start time, so the beginning of Byron, but not the time or slot of the switch from one to the other, from 20-second slots to 1-second slots.

So, I’m just going to calculate backwards from a recent block:

Mainnet

  • System start according to https://book.world.dev.cardano.org/environments/mainnet/byron-genesis.json and https://book.world.dev.cardano.org/environments/mainnet/shelley-genesis.json:
    2017-09-23T21:44:51Z, Unix timestamp 1506203091, Slot 0
  • Recent block (I take the first of the current epoch) according to https://cardanoscan.io/block/8987961:
    2023-07-04T21:45:05Z, Unix timestamp 1688507105, Slot 96940814
  • If each second had been one slot since the beginning, the slot would have been 1688507105-1506203091=182304014. The difference is 182304014-96940814=85363200. Since slots have been 20 seconds, so each slot does 19 seconds of this difference, the switch from 20 second to 1 second slots has to have been at slot 85363200/19=4492800 and the Unix timestamp for that is 1506203091+4492800*20=1596059091 (which fits what we already know).
  • Byron to Shelley transition on Mainnet was:
    2020-07-29T21:44:51Z, Unix timestamp 1596059091, Slot 4492800

Preprod

Here we have your 14th January 2026:

$ date -Iseconds -u -d @$((112700800-86400+1655769600))
2026-01-14T09:46:40+00:00

You have used a locking slot calculated for Mainnet on Preprod.

Preview

8

Yeah that was my issue, I used your method on the preprod network to test it but obviously that was wrong. Thanks for the clarification though, I truly appreciate it :heart: