How to allow non deterministic spent output

Question

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?

Answer 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.

Answer 2

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 3

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.