The minting guide say that you should set the policy to expire after certain slot to make sure that nobody can mint more of the same NFT. This kind of makes sense, but then how can you reuse the same policy to mint more of different NFTs?

I saw that most NFT projects share same policy ID, which makes perfect sense, you can verify that NFT really belongs to that same project and isn't forgery, but does it mean these projects didn't set expiry in their policy? Because if they did, how can they keep minting more and more NFTs over time and add them to their collection? What prevents them from adding two identical NFTs?

  • Can you give some examples? I don't think most projects will use the same policy ID, because it loses the meaning of NFT. If you see that a project is keeping minting, it should use different policy IDs, but just register all policy IDs here as the same project.
    – Joseph Ku
    Jan 10, 2022 at 2:39
  • If a project has thousands of NFTs, the same policy will be used, but the NFTs will have unique names, and they will be unique (non fungible). The purpose for the multiple policies in that list is to allow the policies to be time locked, so that the NFTs can be really unique (because the policy owned can still mint new NFTs with the same policy and the same name as long as the policy is not locked). Jan 10, 2022 at 6:35
  • But they still want to be able to mint new NFTs with the same "Project ID", because registering a project on that github repository takes weeks, and this is why they register in a project multiple polict IDs with different timelock dates. Jan 10, 2022 at 6:35
  • @George-APEXStakePool, you mentioned registering a project on github. Can you say more about this, please? I'm planning an NFT campaign and am not aware of registering anything. Thanks much Feb 20, 2022 at 19:25
  • I think I found it. Just leaving this here for posterity. github.com/Cardano-NFTs/policyIDs Feb 20, 2022 at 19:33

4 Answers 4


You are right, some people consider a NFT being a real NFT only after the policy expires, so that you can be sure it is unique. You can also mint multiple NFTs with one policy in one transaction.

  • OK, so that means most of current popular NFT projects don't do it right, because their policy doesn't seem to expire? (they keep minting more and more NFTs under same policy)
    – Petr
    Dec 23, 2021 at 12:45

There are a couple different ways minters are doing this. First is they create a policy ID that expires 6-12 months in the future. This allows them to mint multiple collections under the same ID but the ID DOES eventually lock. As long as the ID locks at some point in the future, Pool.pm shows a lock icon.

Other artists choose to permanently have their ID unlocked. This allows them to mint collections under the same ID anytime in the future. As you noted, this makes it somewhat simpler for buyers to associate NFTs with the single ID, however, secondary marketplaces these days make it pretty straight forward to confirm NFTs are authentic even with multiple IDs so it's not a huge advantage.

The other reason an artist might choose to keep the ID open is if the NFT has future utility, such as workbench functionality, or some other feature where the artist might want to CHANGE the actual NFT that's in your wallet.


NFT projects tend to use a PolicyId to group NFTs into collections.

A PolicyId is tied to a minting wallet and may optionally contain an expiry date.

Once the expiry date passes, the minting wallet cannot mint or update NFTs tied to the PolicyId.

This gives buyers the assurance that a Collection with a expired policyId has not minted more than the stated supply and cannot change the minted asset's metadata.

The minting wallet can Mint two or more identical NFTs, but the NFTs will not technically be a NFT anymore (it becomes fungible).

NFT asset = PolicyId + AssetName

(If 2 Assets in the same PolicyId have the same AssetName, the block explorer will show a count of 2).

NFT buyers will usually check the total supply of NFTs in a PolicyId and that each NFT asset in that PolicyId is unique (non-fungible).


In my opinion of the English language, the token is fungible if it is possible to make more identical tokens. One could include the splitting or changing of the token itself, but that is perhaps out of context if you regard the "token" to be the set of relevant unique identifiers.

Therefore if the policy is not locked, then the tokens are fungible. Cases where another functionally identical token can be, but has not yet been made, are in the state of fungibility.

Of course various blockchain browsers can render and annotate data as they choose. Users beware.

I am not suggesting that non locked policies are inferior to locked policies. There is obviously a lot of functionality to be obtained from burning tokens to create another with the relevant key hooks. Just don't confuse people, or mislead them into misconception.

Your Answer

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

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