TimeLock policies

Hi

Please can you clarify for time lock policies e.g

{
      "type": "after",
      "slot": 54146343
},

What is the slot unit equivalent in real time say I want to set it for 3 months ?

Hi,

1 epoch = 420000 slots
1 epoch = 5 days
1 month = 6 epochs

U will need to sum the current slot + slots for 3 month (420000 x 18 epochs)

For example, if u want to lock the policy after 3 months and if the current slot is 54146343 then

420000 slots per epoch x 18 epochs = 7560000 slots
54146343 + 7560000 = 61706343

e.g

{
“type”: “after”,
“slot”: 61706343
},

Cheers,

Thanks so much I literally could not find that anywhere in Cardano docs.

To mint a token that has to be held for one month before resale is that best placed in policy metadata or minting script do you know thank you again !

The policy lock option meaning that after that period another tokens can’t be minted/burned under that policy… so if u already know how much tokens u need to create from the begining then u don’t need to lock the policy after 3 months…

Let’s take hosky token for example

The policy is

image

Metadata:

image

Conclusion: if u want to create a fix number of tokens and u will not want to create/burn more tokens (under the same policy) then u can lock the policy imediatly…
If u want to keep minting tokens on future then u should not lock the policy imediatly (u should lock after few months or even 1 year)

1 Like

Also, use "before", not "after". The logic is that this is a requirement, when tokens are allowed to be minted.

"after" would mean that you are only allowed to start minting at that slot.

Does not make sense at the top level, but in a more complicated policy, you could say that before a certain slot this key can mint and after that slot this right goes to that other key.

2 Likes

Right, before

Hi ok I that helps my understanding.

Yes so the token plan is

Mint amount = 190mill > payment wallet
targetaddr (mainnet wallet ) 5 million (at time of mint)

then either :slight_smile:

Transfer amount 5 mill every month for 3 months.
Could / should that be automated in a script else I can manually do that.

How do I calculate the fees so that I add the amount to the token amount so that I have minted round numbers ?

Can I use a normal editor on the policy.script after making the key hash I mean ?

So normal JSON format, do you use any linting apps else I use Visual Studio ?

Then, you have transferred 20 million and 170 million stay in the minting/payment address forever?

If you mint all at once you could also time lock to immediately after that minting.

I’m sure a Plutus script could do that, but I would not want to learn that with you, right now.

I’m using (n)vim with JSON syntax highlighting, but Visual Studio (Code) seems like a good choice, too.

EDIT: Oh, I forgot:

I don’t know what you mean, here. The minimal fees for the transactions and the minimal ADA that have to be sent along the tokens will always be some very non-round fraction, but that does not prevent at all that you mint and transfer round numbers of your token. You cannot pay fees in your just-invented token, anyway.

1 Like

Ah ok that is good news then so the fees are lovelace the minted token will be whole numbers I now dont know why I event thought differently. ? :- :crazy_face:

What does the policy.script syntax look like for immediate locking ?

Is it before: somepast slot number ?

{
“type”: “before”,
“slot”: 61706343
},

It’s not a special syntax. It’s just a slot number in the very near future. (But not so near that you cannot finish your work – including repairs to f’ups – in that time frame. I’d probably choose one to three days if you expect to perhaps need some answers from these forums or so.)

Slot number in the past will not work. The minting will get rejected, … because it’s policy says, it’s not allowed anymore.

BTW: The cardano-cli transaction build will need an --invalid-hereafter parameter with the same or an earlier slot number. At least it barked at me, when I didn’t include that. Makes some sense to ensure that the transaction will not go through if it violates the policy.

Ok noted.

Wonder is it best to mint like one test token first and check everything is there then burn it ?

I will have to test that my Mainnet connection is syncing as per my other thread first before I can do any minting. Just to add I have Deadalus wallet also running the mainnet version maybe I can try to query the tip of mainnet with that or do I need special ports ?

Its quite nerve racking with many possible variables.

So if I did equivalent 1 epoch is that 420000 slots after Epoch 314 should be ok if I add that number to current slot using explorer ?
https://explorer.cardano.org/en.html

so for example
[50620499] + 420000 =
50662499

{
“type”: “after”,
“slot”: 50662499

},

Also are there any other security recommendations or can you refer me to where I may find them ?

Also a complete list of metadata variables too please ?

Honestly, you seem to be in quite a hurry to learn everything at once.

Hi yes I am due to mint this weekend so its how my brain is wired. Am sure there is always room for learning more, I do live that way.

You can do that. Just costs transaction fees, not more.
And everyone can see these transactions forever. But judging from the forum traffic, very few are nosy and at the same time blockchain explorer fluent enough to do it. And it doesn’t matter much.

5×24×60×60=432 000, not 420 000.

"before" not "after". The policy says, when minting is allowed, not when it is forbidden.

There are not many security considerations when minting. You do not operate something on the Internet for a longer time, but just submit some transactions. Keep your .skey files safe! Backup them! Best together with all the files used in the minting process. They are not big.

CIPs/CIP-0025 at master · cardano-foundation/CIPs · GitHub contains everything that is standardised up to now. I’m not aware that they treat any other variables in a special way. On pool.pm, additional elements on the top-level are just all listed as they are given in the JSON.

1 Like

Brilliant answer as standard from you Sean thanks

If am honest I am not sure I got the understanding of what you are explaining here I think you are saying to clarify then that the policy “after” because then it will be locked and no more changes after that, That sounds right as I type it :smiley:

Feels very lean on what is standardised metadata tags. So everything other than whats on this list is treated as custom and does nothing on Pool.pm ?

 "<policy_id>": {
      "<asset_name>": {
        "name": <string>,

        "image": <uri | array>,
        "mediaType": "image/<mime_sub_type>",

        "description": <string | array>

        "files": [{
          "name": <string>,
          "mediaType": <mime_type>,
          "src": <uri | array>,
          <other_properties>

pool.pm shows everything else verbatim. Take, for example, one NFT that I personally do not find as senseless as all the ugly apes:

If you look at its minting transaction and click on the metadata value, there:

You see all the custom fields from “Abundance” till “Temperature”. pool.pm doesn’t know what they mean and doesn’t need to. It just shows them.

(Other than that, this one is special, since it doesn’t use IPFS, but the content is completely included on the blockchain, the large data: URIs you see there. One of the reasons I like it.)

Let’s go by example:

{
  "type": "all",
  "scripts":
  [
    {
      "type": "before",
      "slot": 58500000
    },
    {
      "type": "sig",
      "keyHash": "XXXXXXXXX"
    }
  ]
}

This says that tokens under this policy can be minted (or burned, which is just minting with a negative amount) if all of the following are satisfied: the slot is before 58 500 000 (which is in a little more than three months) and the transaction is signed by XXXXXXXXX.

So, an after wouldn’t make much sense, here. You can only mint after that slot, but you then couldn’t submit a transaction with this policy before that slot, anyway.

You want this type of script, probably.

But why does after exist, when it makes not so much sense? If we take a slightly more complicated example:

{
  "type": "any",
  "scripts":
  [
    {
      "type": "all",
      "scripts":
      [
        {
          "type": "before",
          "slot": 58500000
        },
        {
          "type": "sig",
          "keyHash": "XXXXXXXXX"
        }
      ]
    },
    {
      "type": "all"
      "scripts":
      [
        {
          "type": "after",
          "slot": 58500000
        },
        {
          "type": "sig",
          "keyHash": "YYYYYYYYY"
        },
        {
          "type": "sig",
          "keyHash": "ZZZZZZZZZ"
        }
      ]
    }
  ]
}

Under this policy, the token can be minted if any of the following are satisfied:

  • all of before slot 58 500 000 and signed by XXXXXXXXX, or
  • all of after slot 58 500 000 and signed by YYYYYYYYY and ZZZZZZZZZ

So, the right to mint is transferred from one key to two other keys at that point in time. In this case (if someone wants that for whatever reason), an after makes sense.

The most complete documentation of these scripts that I have found is at cardano-node/simple-scripts.md at master · input-output-hk/cardano-node · GitHub.