Let's say I want to run an NFT campaign, where the minting policy only allows minting of 100 NFTs (each one is different), and then the policy should lock.

If this minting policy were a Plutus script, I'm assuming I would need to pass in a parameter holding the current mintCount and then the validation would test if the mintCount is less than the limit.

That seems simple enough, but I'm assuming this relies on the off-chain code obtaining an accurate count of total mints under the policy for the parameter input and serializing access to the transaction minting process (i.e., avoid running minting transactions in parallel). Is this correct?

Suppose this minting policy should lock because the max number of NFTs have been reached, but the off-chain code screws up and passes in a mintCount parameter that allows more minting to occur. Is there some way to write a script that locks for good, once a previous transaction has failed?

Besides passing in a mintCount, are there other strategies for enforcing a minting policy that locks after a certain number of NFTs has been reached? Instead of on-the-fly minting, is there some strategy of minting NFTs up-front that could achieve a certain max count?

1 Answer 1


You could use a combination of a plutus validator script with a specific datum and a minting policy.

The minting policy just checks for the validator script has ran. And the validator script checks the datum's counter to be increased correctly and it fails when your max number has been passed, see other related question below.

Collection Uniqueness using Counter as asset name

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.