2

I have found examples indicating that a minting policy can be single shot or restricted by PubKeys, however I would like to secure minting and burning of a token based on if a specific NFT is present in the redeemer.

My current thinking (no code written yet) would be to create an OnChain validator to check for the NFT and set the minting policy to forwardingMintingPolicy.

This makes me a little nervous because from what I understand once a minting policy / token is established it can never be changed which means the validation script can also not be changed.

So with this in mind would it be recommended to make the token contract as simple as possible ie, Mint, Burn only validated as above, then keep any potentially complex behaviour in other contracts that can be changed. Or am I missing something entirely.

Improve this question

1 Answer 1

Reset to default
2

Define a native token minting policy restricted by NFT

This is how the Liquidity Token minting works in the Uniswap example.

isUnity v usCoin

checks that there is included one usCoin. The policy also includes some additional flexibility, but that's the general idea.

I think this is going to be a very common pattern in smart contracts.

Improve this answer
3
  • I've actually been thinking about how to abstract this exact pattern into some library/framework. There is a lot of annoying boilerplate involved in the off-chain and on-chain portions and it would be nice to simplify it to something that writes the script and policy for you to some extent.
    – Mitchell Turner
    Commented Sep 22, 2021 at 0:29
  • Excellent, that nudge helps a lot. Is my initial intuition about the problem correct (or on the right track). If I implement the policy in a similar way to the Uniswap example can I deploy new contracts in the future that mint the coin in new ways (so long as they still provide the NFT as defined in the initial minting policy?). Just trying to get my design right.
    – CodeKiwi
    Commented Sep 22, 2021 at 20:41
  • Future-proofing these contracts is going to be a big challenge. I'm sure there are ways to do it, and it sounds like you have some ideas, but Plutus and Cardano SCs are so new that there isn't precedence. You can look at projects on Ethereum which have multiple versions. I think many of them just started from scratch with subsequent versions though. My advice would be to create the minimum version of your contract, even if it won't make it to production, and that will give you a much better idea of what options you have for upgrading.
    – Mitchell Turner
    Commented Sep 22, 2021 at 20:49

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.