<blockquote>
<p>Define a native token minting policy restricted by NFT</p>
</blockquote>
<p>This is how the Liquidity Token minting works in the <a href="https://github.com/input-output-hk/plutus/blob/37f34648cb9e12c7f61f6faf9930a600e103c479/plutus-use-cases/src/Plutus/Contracts/Uniswap/OnChain.hs#L282" rel="nofollow noreferrer">Uniswap example</a>.</p>
<pre><code>isUnity v usCoin
</code></pre>
<p>checks that there is included one <code>usCoin</code>. The policy also includes some additional flexibility, but that's the general idea.</p>
<p>I think this is going to be a very common pattern in smart contracts.</p>

CC BY-SA 4.0
2021-09-22T00:29:34.047Z
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
CC BY-SA 4.0
2021-09-22T20:41:21.113Z
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
CC BY-SA 4.0
2021-09-22T20:49:12.370Z
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
CC BY-SA 4.0
2021-09-22T00:26:27.663Z
2021-09-22T00:26:27.663Z
Mitchell Turner
<p>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.</p>
<p>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 <a href="https://staging.marlowe.iohkdev.io/doc/haddock/plutus-ledger/html/Ledger-Typed-Scripts-Validators.html" rel="nofollow noreferrer">forwardingMintingPolicy</a>.</p>
<p>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.</p>
<p>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.</p>

<plutus><native-assets>
Define a native token minting policy restricted by NFT
# Define a native token minting policy restricted by NFT

(Asked by: username_0 on 2021-09-21)

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](https://staging.marlowe.iohkdev.io/doc/haddock/plutus-ledger/html/Ledger-Typed-Scripts-Validators.html).

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.

**Tags:** plutus, native-assets

---

## 1 answers

### Answer by username_1 on 2021-09-22. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_1**: 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.  
> **username_0**: 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.  
> **username_1**: 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.  

---

