<p>In your validator, you should check only for what is related to the script logic.</p>
<p>depending on your needs you may want your user only to perform that specific action in the transaction, so you can add additional checks that specify that only that action is intended (e.g. only one input from the buyer) but this of course means transactions with two inputs form the same <code>PubKeyHash</code> will fail.</p>
<p>So, if in order to sell some tokens you only need to pay a certain amount of lovealces and you don't require anything else; then you should check for anything else, allowing the transaction to succeed no matter the number of inputs, as long as the user paid the correct amount</p>
<p>this allows you to reduce your script size and often also optimize script execution.</p>
<p>the example of Plutonmicon says that if the user builds a transaction that doesn't respect the schema expected by your script, you should simply not care about it;</p>
<p>Why care about adding additional code to fail a transaction that would have failed anyway?</p>

CC BY-SA 4.0
2022-09-18T13:09:50.790Z
But in my case transaction wont be failed anyway. Worried about buyer's balance - the possibility of theft of a certain amount of Ada. This can happen if we have "dishonest" off-chain code and on-chain part without checking that transaction outputs are only assigned to seller or buyer and nobody else. Value of spent script output should go back to seller. And without specifying amount of Ada in each output, we can't say exactly how many buyer's Ada it will take for creating new seller's output. If there can be price of tokens < 1 Ada or even free. However, maybe i am just too scrupulous
Anastasia Martyniuk
CC BY-SA 4.0
2022-09-19T18:42:34.763Z
What you are describing is logic that is necessary to the smart contract; so no problem with that. You should not check for example for the ```Data``` to be built as you  wish, because honest users will build the ```Data``` as intended, and if that is not the case then transfoming ```Data``` to a value already fails
Michele Nuzzi
CC BY-SA 4.0
2022-09-18T12:09:50.873Z
2022-09-18T12:09:50.873Z
Michele Nuzzi
<p>In Plutonomicon github <a href="https://plutonomicon.github.io/plutonomicon/transaction-perspective" rel="nofollow noreferrer">repo</a> it says by the end of the page:</p>
<blockquote>
<p>For example, you don't need to prevent an unexpected transaction from locking value away - that's the submitter's own problem - but you do need to stop them from inappropriately spending value.</p>
</blockquote>
<p>As i understood, we dont need our on-chain part to fill in all variants of the off-chain code.</p>
<p>So, if we have, for example, some kind of dex Plutus script that sells tokens, assigned to script outputs: one output - one token. In that case we should avoid checking outputs' addresses of sell-transaction for correctness, even with probability of &quot;dishonest&quot; off-chain(for example, extra constraint &quot;MustPayToPubKeyAddress&quot;)? Consider that fixed amount of minAda for each output is not set by script logic.</p>

<plutus><transaction><on-chain><validation><offchain>
Whether validation checks are necessary
# Whether validation checks are necessary

(Asked by: username_0 on 2022-09-18)

In Plutonomicon github [repo](https://plutonomicon.github.io/plutonomicon/transaction-perspective) it says by the end of the page:

> For example, you don't need to prevent an unexpected transaction from locking value away - that's the submitter's own problem - but you do need to stop them from inappropriately spending value.

As i understood, we dont need our on-chain part to fill in all variants of the off-chain code.

So, if we have, for example, some kind of dex Plutus script that sells tokens, assigned to script outputs: one output - one token. In that case we should avoid checking outputs' addresses of sell-transaction for correctness, even with probability of "dishonest" off-chain(for example, extra constraint "MustPayToPubKeyAddress")? Consider that fixed amount of minAda for each output is not set by script logic.

**Tags:** plutus, transaction, on-chain, validation, offchain

---

## 1 answers

### Answer by username_1 on 2022-09-18. Score: 0 | Accepted answer

In your validator, you should check only for what is related to the script logic.

depending on your needs you may want your user only to perform that specific action in the transaction, so you can add additional checks that specify that only that action is intended (e.g. only one input from the buyer) but this of course means transactions with two inputs form the same `PubKeyHash` will fail.

So, if in order to sell some tokens you only need to pay a certain amount of lovealces and you don't require anything else; then you should check for anything else, allowing the transaction to succeed no matter the number of inputs, as long as the user paid the correct amount

this allows you to reduce your script size and often also optimize script execution.

the example of Plutonmicon says that if the user builds a transaction that doesn't respect the schema expected by your script, you should simply not care about it;

Why care about adding additional code to fail a transaction that would have failed anyway?

> **Comments:**
> **username_0**: But in my case transaction wont be failed anyway. Worried about buyer's balance - the possibility of theft of a certain amount of Ada. This can happen if we have "dishonest" off-chain code and on-chain part without checking that transaction outputs are only assigned to seller or buyer and nobody else. Value of spent script output should go back to seller. And without specifying amount of Ada in each output, we can't say exactly how many buyer's Ada it will take for creating new seller's output. If there can be price of tokens < 1 Ada or even free. However, maybe i am just too scrupulous  
> **username_1**: What you are describing is logic that is necessary to the smart contract; so no problem with that. You should not check for example for the ```Data``` to be built as you  wish, because honest users will build the ```Data``` as intended, and if that is not the case then transfoming ```Data``` to a value already fails  

---

