Minting Token With Time Base

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.

2 Likes

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