Minting Token With Time Base

Thanks a lot this is really helping me. One more thing, can we limit the amount of coin that we can mint at the specific time frame? For example in second period I only can mint 100coin.

Unfortunately, we have to wait for smart contracts to limit the number minted. A simple Marlowe contract will be able to handle this.

1 Like

Thank you so much dude. I understand now… Really appreciate it.

1 Like

You’re very welcome. Explaining this helped me figure out the most efficient way to convert from calendar dates to slot numbers. It also is prompting me to research how synchronized mainnet slot numbers will be with UTC over the years.

BTW, you can use the Marlowe playground to experiment with a simple contract that limits the number of tokens minted, constrainting minting to time windows, etc. If the Alonzo testnet is available soon, then you can test everything out there.

I think Alonzo testnet already here right now. Not so sure. Anyway, if right now I mint with a single time minting policy, can I change the script later?

Changing the script will change the Policy ID. Any tokens minted by the changed script won’t be fungible with those minted by the original script. Even if you use the same Asset Name, the Asset ID will be different for tokens minted by the two scripts because of the different Policy ID, so they won’t be interchangeable.

Also, I now doubt that Marlowe will support this use case–a Plutus contract might be needed.

1 Like

Hi Bwbush,
I need to confirm one thing. I read the script several time and compare the guide about time locking.
So, if we run this policy is that mean that we only can’t mint and burn the token or we cannot do anything with the token during the locking period?
Because I read this note

Note that this is not really time locking in the normal sense, and indeed this is a very dangerous script to use because any funds left in a script address using this script after time slot 3000 will be locked there permanently!

from here Scripts — cardano-node Documentation 1.0.0 documentation

That’s a very good question, and the documentation could be clearer. There is a difference between using a script to mint a token versus sending funds to a script address:

  1. When you use a script to mint a token, the script (and hence any time locking) only is run to validate transactions that mint or burn the token–it has no effect on other transactions. Thus, you can transfer tokens in non-burning transactions, use them in smart contracts, etc. without any restriction. You can look at pool.pm/tokens and cardanoscan.io etc. to see that time-locked tokens have been transferred between addresses well after they have been locked against further minting or any burning. (Note that a time-locked script for a token does lock in a min-ada value associated with the token, but that is a small amount of ADA.)
  2. A different use case (the one that the quote from the documentation warns against) is using a script as an address for receiving ADA transactions (which may or may not also include tokens). Using a script as an address has nothing to do with using it for minting or burning tokens. In this situation, when one attempts to withdraw funds from the script’s address, the script must validate the transaction. A time-locked script won’t validate a transaction after its time has passed, so any ADA or tokens held by the script are stuck there forever. BTW, script addresses can be useful when several people want to hold ADA in common at the same address (a script address) and only spend them when they all agree; there are many other interesting scenarios for script addresses.

The same scripting language is used for both of these use cases and the mechanics of a script witnessing (i.e., validating) a transaction are the same for both, but a minting script only affects minting/burning whereas a script address affects spending out of that address.

P.S. You can experiment on testnet without concern for accidentally losing tADA (test ADA) in locked scripts or unburnable tokens.

1 Like

Thank you for your prompt reply.
So now I understand what’s the different between only the script and script address.
I try to write the policy.script.
Can I write like this?

{
“type”: “any”
“scripts”:
[
{
“type”: “before”
“slot” : 1000
“keyHash”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
}
]
}
My question is can I combine type and slot and keyhash one time or must use type and keyhash, then slot and keyhash. So there will be 2 policy.skey
Please correct me if I’m wrong.

You cannot combine slot and keyHash under a single type (as in your example), and (very important) you need to use all instead of any. Here is what the simplest form of time-locked script looks like.

Regarding signing keys, you only need one .skey per unique keyHash. For a simple time-locked script, you’d need one .skey for the script in addition to whatever .skeys you need so sign the inputs for the transaction.

1 Like

Thanks,
So the structure will be

{
  "scripts": [
    {
      "slot": 28860486,
      "type": "before"
    },
    {
      "keyHash": "d4b9b71fffec086c6a75893735183f28b000894f1f717293a7554a65",
      "type": "sig"
    }
  ],
  "type": "all"
}

Slot comes first then the keyhash come with the “sig” right? Any why I need to use all instead of any? Because I only have one sig.

Yes, this is the structure. The keyHash is always paired with the type sig; the slot is always paired with the type before. One can think of this script as being composed of two “sub-scripts”:

  1. {"slot" : 28860486, "type" : "before"} is a script that restricts minting to before a certain time. By itself, a “before” script doesn’t require a signing key. (This is why you don’t need two signing keys for the overall script.)
  2. {"keyHash": "d4b9b71fffec086c6a75893735183f28b000894f1f717293a7554a65", "type" : "sig"} is a script that requires the minting transaction to be signed by the key with that particular hash. So this does require there be a signing key.

{"scripts" : [ ... ], "type" : "all"} combines the scripts in the square brakets into a composite script that validates if all of the individual scripts validate. In this case it means that the minting must occur before the time and it must be properly signed. One can think of the all as meaning that each of the conditions have to hold true in order to mint.

If one were to use any in a script like this, then it would mean that the minting must occur before the time or it must be properly signed. That would mean that anyone could mint these tokens before the time and they wouldn’t necessarily need to sign the minting transaction; or the person with the signing key could mint anytime, even after the time had passed. One can think of the any as meaning that at least one of the conditions has to hold in order to mint.

1 Like

Wow… That is totally clear… Thanks a lot for explaining in such detail order. I hope your post here can be read by all Cardano Community to help us all minting a token. Anyhow, do you have twitter?
I would love to follow you.

1 Like

Okay, I try it and I got this error

transaction submit Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraMary (ApplyTxError [LedgerFailure (UtxowFailure (ScriptWitnessNotValidatingUTXOW (fromList [ScriptHash “xxxxxxxxxxxxxxxxxxxxxxx”])))])

Any Idea why?

Okay, I got the solution from here.

This is a great breakdown! Answered the question I had about NFT minting on another thread, thank you! So to make sure I understand, if I setup a policy script to mint a new NFT collection before a specific block number, in order to ensure ONLY I can mint those NFTs to that policyID, I would structure my script similar to this, with the All condition, stating before the time and only signed by me (the signer of the hash), do I understand this correctly? Thanks!

1 Like

Exactly, and the all condition ensures that both the key and the deadline have to be satisfied in order to mint.

BTW, if you make a mistake in the minting (such as something wrong like a typographical error in the metadata), you can burn the token(s) before the deadline. That way you aren’t stuck with an unwanted token.

1 Like

Excellent! Yes I’m going to mint a few test NFTs and then burn to make sure I get the metadata and everything else correct/as desired. Thank you again!

1 Like

If you burn a token and then re-mint one with exactly the same name, it might confuse some of the token explorers like pool.pm/tokens: I’m not sure whether those tools look at the first metadata associated with the asset ID or the most recent metadata. Just to be safe, you might want to avoid reusing the asset name of anything you burn.

Oh, good to note, I was going to do fake names for the tests, but that is great to keep in mind.

1 Like