<p>To add to Jey's answer, UTxOs will always be deterministic, but, as he said, you can create a two-steps flow that would allow results unknown for the first user.</p>
<p>The idea proposed by him would require some centralised off-chain component, but you could also make it decentralised depending on the problem. See this example from the Plutus Pioneers Program:</p>
<p>We want to create a rock paper scissors on-chain game. So Alice could send to our script some ADA with her &quot;answer&quot; as the datum, let's say &quot;rock&quot;. She would hash that alongside with some dust value (like a password). So, the datum would be, for example, hash(rock|foo).</p>
<p>Then, Bob would do the same, but now he doesn't need to hash it he can just put the value it self. The datum would now be {alice: hash(rock|foo), bob: paper}.</p>
<p>Finally, since Alice's choice is hashed, she now has a deadline to reveal her answer. If she does, our logic will verify both values and give the ADA to Bob (because paper beats rock). If she doesn't (maybe because she noticed she would lose) and the deadline passes, Bob can automatically get all the ADA from the script.</p>

CC BY-SA 4.0
2022-10-04T11:12:27.850Z
2022-10-04T13:04:55.273Z
2022-10-04T13:04:55.273Z
Mateus
<p>It is not possible to design a smart contract validator in a way that the user does not know if it will succeed or not. The validator can only &quot;see&quot; the transaction. This means that the validator logic cannot use any information that the submitting user does not also have.</p>
<p>What you can do, though, is to structure the process into two steps, where the user first submits a transaction to request an action, and then you react based on some off-chain information. This will make the whole process centralised, i.e. dependent on you.</p>

CC BY-SA 4.0
2023-11-01T15:11:01.500Z
Good answer. While I do not think that user "submits a transaction" is required, if you mean submitting to blockchain. You can have user-sign-tx-first DApp arch, with user signing it first, and server signing it second and submiting to blockchain.
uhbif19
CC BY-SA 4.0
2022-05-07T07:56:32.920Z
2022-05-07T08:01:48.050Z
2022-05-07T08:01:48.050Z
Jey
<p>You can design the off chain code in a way that it will not pass validation of the contract but that would lead to consuming the collateral of the transaction which I don't think is what you're trying to achieve.</p>

CC BY-SA 4.0
2022-04-06T18:41:55.487Z
2022-04-06T18:41:55.487Z
Will
<p>I would like a validator (or a minting policy) to succeed always but only to spend the output if some conditions are met;</p>
<p>an example use case of such behaviour is to allow burning token (kind of a &quot;ticket&quot; to use the smart contract) in both cases if the conditions are met or not;</p>
<p>also, I would like the user not to know if it is allowed to spend an output (therefore to meet the conditions) because if that was the case then it would be enough just a condition that asserts that 0 token are minted form the offchain if it should fail; or a tot-token are minted if it should succed; but this would require the user to know the result in order to build the rigth transaction.</p>
<p>I know Cardano smart contracts are designed to prevent failing smart contract to execute, but is there a way to allow this bheaviour if controlled such as in this case?</p>

<plutus><smart-contract><utxo>
How to allow non deterministic spent output
# How to allow non deterministic spent output

(Asked by: username_0 on 2022-03-24)

I would like a validator (or a minting policy) to succeed always but only to spend the output if some conditions are met;

an example use case of such behaviour is to allow burning token (kind of a "ticket" to use the smart contract) in both cases if the conditions are met or not;

also, I would like the user not to know if it is allowed to spend an output (therefore to meet the conditions) because if that was the case then it would be enough just a condition that asserts that 0 token are minted form the offchain if it should fail; or a tot-token are minted if it should succed; but this would require the user to know the result in order to build the rigth transaction.

I know Cardano smart contracts are designed to prevent failing smart contract to execute, but is there a way to allow this bheaviour if controlled such as in this case?

**Tags:** plutus, smart-contract, utxo

---

## 3 answers

### Answer by username_1 on 2022-10-04. Score: 1

To add to Jey's answer, UTxOs will always be deterministic, but, as he said, you can create a two-steps flow that would allow results unknown for the first user.

The idea proposed by him would require some centralised off-chain component, but you could also make it decentralised depending on the problem. See this example from the Plutus Pioneers Program:

We want to create a rock paper scissors on-chain game. So Alice could send to our script some ADA with her "answer" as the datum, let's say "rock". She would hash that alongside with some dust value (like a password). So, the datum would be, for example, hash(rock|foo).

Then, Bob would do the same, but now he doesn't need to hash it he can just put the value it self. The datum would now be {alice: hash(rock|foo), bob: paper}.

Finally, since Alice's choice is hashed, she now has a deadline to reveal her answer. If she does, our logic will verify both values and give the ADA to Bob (because paper beats rock). If she doesn't (maybe because she noticed she would lose) and the deadline passes, Bob can automatically get all the ADA from the script.


---

### Answer by username_2 on 2022-05-07. Score: 1

It is not possible to design a smart contract validator in a way that the user does not know if it will succeed or not. The validator can only "see" the transaction. This means that the validator logic cannot use any information that the submitting user does not also have.

What you can do, though, is to structure the process into two steps, where the user first submits a transaction to request an action, and then you react based on some off-chain information. This will make the whole process centralised, i.e. dependent on you.

> **Comments:**
> **username_3**: Good answer. While I do not think that user "submits a transaction" is required, if you mean submitting to blockchain. You can have user-sign-tx-first DApp arch, with user signing it first, and server signing it second and submiting to blockchain.  

---

### Answer by username_4 on 2022-04-06. Score: 0

You can design the off chain code in a way that it will not pass validation of the contract but that would lead to consuming the collateral of the transaction which I don't think is what you're trying to achieve.


---

