<p>That is because the interface of the source you have is for a spending validator, and NOT for a minting policy.</p>
<p>Let me explain.</p>
<p>for the chain there is not difference between spending validators and minting policies, it is all just UPLC.</p>
<p>on top of that, the node considers any script that doesn't fail (aka. never evaluates an error) to be correct.</p>
<p>so when you run a script you apply a bunch of data and then you only check if it throws an error or not.</p>
<p>now, the key difference is that a spending validator expects 3 pieces of data ( datum, redeemer, context );</p>
<p>all the others (minting policies, staking validators, etc) expect <strong>only 2</strong> pieces of data ( redeemer and context )</p>
<p>when you use your source ( that takes 3 inputs ) as a minting policy ( which expects 2 inputs ) the node only passes 2 of the 3 inputs.</p>
<p>now applying those two inputs is equivalent to a partial function application.</p>
<p>so the result of the application is a new function, and it is a totally valid evaluation because no error is evaluated!</p>
<p>basically, when applying only two inputs (as in this case) the evaluation always succeeds.</p>
<blockquote>
<p><strong><em>NOTE:</em></strong> behind the scenes aiken (and also plu-ts and many other languages) are wrapping your contract that returns a boolean in a simple &quot;if then else&quot; that evaluates an error if the condition is false!</p>
</blockquote>

CC BY-SA 4.0
2023-08-20T15:14:09.533Z
Been trying so many different thinks... Also had with a redeemer datum and context only but also got an error. Seems like I must have forgotten to compile or something. It works now at least thank you
user9852
CC BY-SA 4.0
2023-08-20T14:25:43.070Z
2023-08-20T14:25:43.070Z
Michele Nuzzi
<p>Hey I have this simple stupid validator:</p>
<pre class="lang-haskell prettyprint-override"><code>validator {
  fn nft(datum: Datum, _redeemer: Void, context: ScriptContext) {
    let ScriptContext { transaction, purpose } = context
    when purpose is {
      Mint(policy_id) -&gt; False
      _ -&gt; False
    }
  }
}

</code></pre>
<p>Now when performing a call to this validator to Mint it still returns <code>True</code> for the transaction and the native token is minted. I'm confused, how can this be?</p>

<plutus><cardano-cli><minting><mint>
Validator always accepts and Mints (but it shouldn't)
# Validator always accepts and Mints (but it shouldn't)

(Asked by: username_0 on 2023-08-20)

Hey I have this simple stupid validator:
validator {
  fn nft(datum: Datum, _redeemer: Void, context: ScriptContext) {
    let ScriptContext { transaction, purpose } = context
    when purpose is {
      Mint(policy_id) -> False
      _ -> False
    }
  }
}


Now when performing a call to this validator to Mint it still returns True for the transaction and the native token is minted. I'm confused, how can this be?

**Tags:** plutus, cardano-cli, minting, mint

---

## 1 answers

### Answer by username_1 on 2023-08-20. Score: 1 | Accepted answer

That is because the interface of the source you have is for a spending validator, and NOT for a minting policy.

Let me explain.

for the chain there is not difference between spending validators and minting policies, it is all just UPLC.

on top of that, the node considers any script that doesn't fail (aka. never evaluates an error) to be correct.

so when you run a script you apply a bunch of data and then you only check if it throws an error or not.

now, the key difference is that a spending validator expects 3 pieces of data ( datum, redeemer, context );

all the others (minting policies, staking validators, etc) expect **only 2** pieces of data ( redeemer and context )

when you use your source ( that takes 3 inputs ) as a minting policy ( which expects 2 inputs ) the node only passes 2 of the 3 inputs.

now applying those two inputs is equivalent to a partial function application.

so the result of the application is a new function, and it is a totally valid evaluation because no error is evaluated!

basically, when applying only two inputs (as in this case) the evaluation always succeeds.

> ***NOTE:*** behind the scenes aiken (and also plu-ts and many other languages) are wrapping your contract that returns a boolean in a simple "if then else" that evaluates an error if the condition is false!

> **Comments:**
> **username_0**: Been trying so many different thinks... Also had with a redeemer datum and context only but also got an error. Seems like I must have forgotten to compile or something. It works now at least thank you  

---

