<p>Yes, you can use a policy id as a parameter to that script and say that the script can only be consumed if it contains a token with that policy ID. You then mint an NFT and send it to this script (which should have the policy ID from your NFT as a parameter).</p>
<p>Since NFTs are unique, this will be the only UTxO that can be consumed, because the rule enforces that the script can only be consumed if it has that specific unique token.</p>

CC BY-SA 4.0
2022-09-08T14:56:28.163Z
2022-09-08T14:56:28.163Z
Mateus
<p>You generally CAN'T prevent the creation of UTxOs</p>
<p>But you can check that all UTxOs sitting at the validator address are included in the transaction</p>
<p>This way if say you have 2 or more UTxOs, you have to include all of them for the transaction to succeed, and then have one single UTxO as output (or zero if all the founds are sent away)</p>
<p>Doing so should minimize the number of UTxOs, the more the validator is run, the more often the number of UTxOs is reduced to one (or zero)</p>
<p><strong>Edit:</strong></p>
<p>some useful functions that you can use to check all the validator UTxOs are included are:</p>
<pre><code>scriptOutputsAt :: ValidatorHash -&gt; TxInfo -&gt; [(DatumHash, Value)]
</code></pre>
<pre><code>findContinuingOutputs :: ScriptContext -&gt; [Integer]
</code></pre>
<pre><code>getContinuingOutputs :: ScriptContext -&gt; [TxOut]
</code></pre>
<pre><code>findTxInByTxOutRef :: TxOutRef -&gt; TxInfo -&gt; Maybe TxInInfo
</code></pre>
<p>and the list goes on, just have a look at <em>&lt;your docs from plututs-apps&gt;/haddock/plutus-ledger-api/html/Plutus-V1-Ledger-Contexts.html</em></p>

CC BY-SA 4.0
2022-04-09T01:50:00.423Z
In this case, can we design a validator script in a way such that it can ensure ALL UTxOs sitting at the script address are included in the transaction? I think we are not able to achieve it as validator script does not have a global view beyond the spending transaction.
Qin
CC BY-SA 4.0
2022-04-09T07:23:40.197Z
@Qin the validator is part of the transaction, it is possible then to include all his utxos
Michele Nuzzi
CC BY-SA 4.0
2022-04-10T00:13:29.057Z
If all UTxOs sitting at the script address are included in the transaction, then consuming all of them and outputting a single UTxO would be a solution. However, the validator is not able to guarantee that all UTxOs sitting at the script address, without omission, are included in the transaction.
Qin
CC BY-SA 4.0
2022-04-10T07:28:51.697Z
@Qin Yes a validator cannot build a transaction but it can fail if the transaction does not respects some criteria; in this case the validator should fail if not all UTxOs are spent; I'm editing the answer with some function that may turn usefull
Michele Nuzzi
CC BY-SA 4.0
2022-05-10T10:07:39.063Z
"But you can check that all UTxOs sitting at the validator address are included in the transaction". I don't think you can, validatos only have access to what is provided inside the transaction, you might very well have 10 script UTxOs and only provide two of them as inputs
Mateus
CC BY-SA 4.0
2022-04-08T17:09:00.220Z
2022-04-10T07:41:08.763Z
2022-04-10T07:41:08.763Z
Michele Nuzzi
<p>As far as I know there is no such way to ensure that only a single UTxO exists at any given address since anyone can send ADA to some address - independently of whether it's a script address or not.</p>
<p>Also a validator script only runs when an output is spent from the validator's address. Therefore there is no check in place/ available that could possibly run when new UTxOs are created at some address.</p>

CC BY-SA 4.0
2022-04-08T12:46:30.543Z
You are right that anyone can send ADA to the script address, which will make multiple UTxOs sitting at the same script address.
Qin
CC BY-SA 4.0
2022-04-08T12:53:06.737Z
Perhaps I should've asked my question differently. I intended to seek ways to ensure at any given time at most one UTxO sitting at the script address can be consumed. This is to ensure there is a chain of UTxOs sitting at the script address without forking.
Qin
CC BY-SA 4.0
2022-04-09T17:22:42.803Z
Sounds like you sort of state machine to me.Without more context it's difficult to understand the problem. One way I could imagine doing something like that is perhaps by spending and recreating all but one UTxO that is suppose to be chained.That way the validator sees all inputs (chained UTxOs) and can ensure only one is correctly consumed (technically all are consumed) but the validator can check if all other output references are recreated at the script address with the correct datum.
That way you can perhaps chain utxo consumption but still not sure if that's a good solution for your prob
Will
CC BY-SA 4.0
2022-04-10T00:21:02.310Z
State machine indeed sounds a good solution by using its threadToken.
Qin
CC BY-SA 4.0
2022-04-08T10:29:03.230Z
2022-04-08T10:29:03.230Z
Will
<p>I can think of one solution, which is the validator script checks if a specific NFT is locked by the script address. Because of the nature of the NFT, it ensures there is at most one UTxO sitting at the script address at any given time that can also be consumed.</p>
<p>This is to ensure there is a chain of UTxOs sitting at the script address without forking.</p>
<p>I wonder if there are any other solutions.</p>

CC BY-SA 4.0
2022-04-08T13:12:48.173Z
Have you met the statemachine (https://github.com/input-output-hk/plutus-apps/blob/main/plutus-contract/src/Plutus/Contract/StateMachine.hs) 
There are examples in the plutus-use-cases and the later weeks of the PPP.
It works like you describe: using an NFT to keep track of state
waalge
CC BY-SA 4.0
2022-04-08T13:30:56.113Z
Yeah. I was aware of state machine. I was just wondering if there were any other alternative solutions.
Qin
CC BY-SA 4.0
2022-04-09T02:29:35.623Z
By watching PPP Week 7 lecture, using ThreatToken within state machine is another way to achieve it.
Qin
<validator>
Ways to ensure at any given time at most one UTxO sitting at the script address that can be consumed
# Ways to ensure at any given time at most one UTxO sitting at the script address that can be consumed

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

I can think of one solution, which is the validator script checks if a specific NFT is locked by the script address. Because of the nature of the NFT, it ensures there is at most one UTxO sitting at the script address at any given time that can also be consumed.

This is to ensure there is a chain of UTxOs sitting at the script address without forking.

I wonder if there are any other solutions.

**Tags:** validator
> **Comments:**
> **username_1**: Have you met the statemachine (https://github.com/input-output-hk/plutus-apps/blob/main/plutus-contract/src/Plutus/Contract/StateMachine.hs)  There are examples in the plutus-use-cases and the later weeks of the PPP. It works like you describe: using an NFT to keep track of state  
> **username_0**: Yeah. I was aware of state machine. I was just wondering if there were any other alternative solutions.  
> **username_0**: By watching PPP Week 7 lecture, using ThreatToken within state machine is another way to achieve it.  

---

## 3 answers

### Answer by username_2 on 2022-09-08. Score: 1

Yes, you can use a policy id as a parameter to that script and say that the script can only be consumed if it contains a token with that policy ID. You then mint an NFT and send it to this script (which should have the policy ID from your NFT as a parameter).

Since NFTs are unique, this will be the only UTxO that can be consumed, because the rule enforces that the script can only be consumed if it has that specific unique token.


---

### Answer by username_3 on 2022-04-08. Score: 0

You generally CAN'T prevent the creation of UTxOs
But you can check that all UTxOs sitting at the validator address are included in the transaction
This way if say you have 2 or more UTxOs, you have to include all of them for the transaction to succeed, and then have one single UTxO as output (or zero if all the founds are sent away)
Doing so should minimize the number of UTxOs, the more the validator is run, the more often the number of UTxOs is reduced to one (or zero)
Edit:
some useful functions that you can use to check all the validator UTxOs are included are:
scriptOutputsAt :: ValidatorHash -> TxInfo -> [(DatumHash, Value)]

findContinuingOutputs :: ScriptContext -> [Integer]

getContinuingOutputs :: ScriptContext -> [TxOut]

findTxInByTxOutRef :: TxOutRef -> TxInfo -> Maybe TxInInfo

and the list goes on, just have a look at /haddock/plutus-ledger-api/html/Plutus-V1-Ledger-Contexts.html

> **Comments:**
> **username_0**: In this case, can we design a validator script in a way such that it can ensure ALL UTxOs sitting at the script address are included in the transaction? I think we are not able to achieve it as validator script does not have a global view beyond the spending transaction.  
> **username_3**: @Qin the validator is part of the transaction, it is possible then to include all his utxos  
> **username_0**: If all UTxOs sitting at the script address are included in the transaction, then consuming all of them and outputting a single UTxO would be a solution. However, the validator is not able to guarantee that all UTxOs sitting at the script address, without omission, are included in the transaction.  
> **username_3**: @Qin Yes a validator cannot build a transaction but it can fail if the transaction does not respects some criteria; in this case the validator should fail if not all UTxOs are spent; I'm editing the answer with some function that may turn usefull  
> **username_2**: "But you can check that all UTxOs sitting at the validator address are included in the transaction". I don't think you can, validatos only have access to what is provided inside the transaction, you might very well have 10 script UTxOs and only provide two of them as inputs  

---

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

As far as I know there is no such way to ensure that only a single UTxO exists at any given address since anyone can send ADA to some address - independently of whether it's a script address or not.

Also a validator script only runs when an output is spent from the validator's address. Therefore there is no check in place/ available that could possibly run when new UTxOs are created at some address.

> **Comments:**
> **username_0**: You are right that anyone can send ADA to the script address, which will make multiple UTxOs sitting at the same script address.  
> **username_0**: Perhaps I should've asked my question differently. I intended to seek ways to ensure at any given time at most one UTxO sitting at the script address can be consumed. This is to ensure there is a chain of UTxOs sitting at the script address without forking.  
> **username_4**: Sounds like you sort of state machine to me.Without more context it's difficult to understand the problem. One way I could imagine doing something like that is perhaps by spending and recreating all but one UTxO that is suppose to be chained.That way the validator sees all inputs (chained UTxOs) and can ensure only one is correctly consumed (technically all are consumed) but the validator can check if all other output references are recreated at the script address with the correct datum. That way you can perhaps chain utxo consumption but still not sure if that's a good solution for your prob  
> **username_0**: State machine indeed sounds a good solution by using its threadToken.  

---

