<p>You need a separate minting policy to mint the tokens.</p>
<blockquote>
<p>we want a smart contract (validator script)</p>
</blockquote>
<p><em>I tend to think of smart contracts as including a set of validators and policies, not just one script. It's typical to use multiple in concert.</em></p>
<p>Essentially the validator holds an NFT with a datum tracking the contract's state. The validator constrains any transaction spending the datum, and checks that the transaction</p>
<ol>
<li>deposits/withdraws the correct amount,</li>
<li>mints/burns the correct amount, and</li>
<li>replaces the NFT + datum with updated state</li>
</ol>
<p>The the minting policy will only mint if the NFT is spent--all the logic is on the validator side.</p>
<p>Check out the discussion on &quot;dummy nfts&quot;/&quot;access tokens&quot; <a href="https://cardano.stackexchange.com/a/4818/1130">here</a> to get a better idea of how that would work.</p>

CC BY-SA 4.0
2022-04-06T15:31:09.010Z
Great explanation, I am a little confused why you'd put all the logic in the validator.
In the case of depositing money at the contract address, I'd expect the minting policy to run as well + make sure a corresponding output with ADA is created at the script address or did I misunderstand? I don't see how else the validator script would run if there is no output spent in the case of a depositing action.
Will
CC BY-SA 4.0
2022-04-06T15:34:28.110Z
Hence, I'd almost say the minting policy could do most of the logic except for validating withdraw ownership based on simple pubkeyHash comparison. But it could certainly ensure deposits to be correct (output at script address with equal amount to minted native token). And also burns which check if a corresponding withdraw is done too...

Please let me know if I misunderstand the context.
Will
CC BY-SA 4.0
2022-04-06T17:07:02.917Z
"make sure a corresponding output with ADA is created at the script address"--that's what I'm saying with "replaces the NFT + datum." Datums must exist on an output. If the validator is already checking that, it would be redundant to have the policy check it again. You could definitely have the minting policy check other things, but remember policies don't have any state, just tx context. There is no datum on the policy. So, if you ever want minting to rely on some state, you need need some validator to manage that state for you. I think it's best to keep all the logic in one spot.
Mitchell Turner
CC BY-SA 4.0
2022-04-05T17:23:23.060Z
2022-04-05T17:23:23.060Z
Mitchell Turner
<p>Suppose we want a smart contract (validator script) that locks a user' fund (e.g. ADA) that she deposits and releases it back if she withdraws it. Suppose when she deposits some fund into the validator script, we want in the same transaction the validator script sends her wallet some native tokens as a proof of deposit.</p>
<p>In this scenario, how can the validator script mints some native tokens in the same transaction as a user sends some fund to the validator script?</p>

<smart-contract><on-chain>
How can a validator script be used to mint native tokens, in addition to perform other checks?
# How can a validator script be used to mint native tokens, in addition to perform other checks?

(Asked by: username_0 on 2022-04-05)

Suppose we want a smart contract (validator script) that locks a user' fund (e.g. ADA) that she deposits and releases it back if she withdraws it. Suppose when she deposits some fund into the validator script, we want in the same transaction the validator script sends her wallet some native tokens as a proof of deposit.

In this scenario, how can the validator script mints some native tokens in the same transaction as a user sends some fund to the validator script?

**Tags:** smart-contract, on-chain

---

## 1 answers

### Answer by username_1 on 2022-04-05. Score: 1 | Accepted answer

You need a separate minting policy to mint the tokens.

> we want a smart contract (validator script)

*I tend to think of smart contracts as including a set of validators and policies, not just one script. It's typical to use multiple in concert.*

Essentially the validator holds an NFT with a datum tracking the contract's state. The validator constrains any transaction spending the datum, and checks that the transaction

1. deposits/withdraws the correct amount,
2. mints/burns the correct amount, and
3. replaces the NFT + datum with updated state

The the minting policy will only mint if the NFT is spent--all the logic is on the validator side.

Check out the discussion on "dummy nfts"/"access tokens" [here](https://cardano.stackexchange.com/a/4818/1130) to get a better idea of how that would work.

> **Comments:**
> **username_2**: Great explanation, I am a little confused why you'd put all the logic in the validator. In the case of depositing money at the contract address, I'd expect the minting policy to run as well + make sure a corresponding output with ADA is created at the script address or did I misunderstand? I don't see how else the validator script would run if there is no output spent in the case of a depositing action.  
> **username_2**: Hence, I'd almost say the minting policy could do most of the logic except for validating withdraw ownership based on simple pubkeyHash comparison. But it could certainly ensure deposits to be correct (output at script address with equal amount to minted native token). And also burns which check if a corresponding withdraw is done too...  Please let me know if I misunderstand the context.  
> **username_1**: "make sure a corresponding output with ADA is created at the script address"--that's what I'm saying with "replaces the NFT + datum." Datums must exist on an output. If the validator is already checking that, it would be redundant to have the policy check it again. You could definitely have the minting policy check other things, but remember policies don't have any state, just tx context. There is no datum on the policy. So, if you ever want minting to rely on some state, you need need some validator to manage that state for you. I think it's best to keep all the logic in one spot.  

---

