<p>Here is a contrived use case:</p>
<p>Imagine some dApp that includes governance (voting and stuff). Among the requirements for voting on some referendum, you must prove your right to vote with governance tokens. The smart contract doesn't need to be paid the governance tokens, rather just see that they are included in any vote transaction, after which the tokens can be returned to the voter.</p>
<p>To achieve this, you will need to spend the tokens, and just have yourself as the recipient*. You will include the constraint:</p>
<pre><code>Constraints.mustSpendAtLeast govTokenValue
</code></pre>
<p>Which under the hood will select enough UTxOs to spend and meet the minimum <code>govTokenValue</code> (or return an error if you don't have enough).</p>
<p>The dApp smart contract can then check its <code>ScriptContext</code> to ensure that at least the minimum number of governance tokens needed were included in the transaction to perform the desired action, e.g. vote.</p>
<p>*not specifying a recipient will default to returning them to the transaction builder (you)</p>

CC BY-SA 4.0
2021-11-07T00:12:43.370Z
2021-11-07T00:12:43.370Z
Mitchell Turner
<p>What I can figure out:</p>
<p><a href="https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/TxConstraints.hs#L228-L230" rel="nofollow noreferrer">mustSpendAtLeast</a> is basically just a wrapper around <a href="https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/TxConstraints.hs#L44" rel="nofollow noreferrer">MustSpendAtLeast</a>. This gets processed <a href="https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L508" rel="nofollow noreferrer">here</a>, by adding a <a href="https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L213" rel="nofollow noreferrer">required value</a> to <a href="https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L237-L239" rel="nofollow noreferrer">this thing</a>. These values get turned into outputs in <a href="https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L313" rel="nofollow noreferrer">addMissingValueSpent</a>.</p>
<p>With all this, I still don't understand how this constraint is supposed to be used.</p>
<p>edit:
The root of my inability to figure this out was that I was looking in the wrong place for the information. <a href="https://github.com/input-output-hk/plutus-apps/blob/d637b1916522e4ec20b719487a8a2e066937aceb/plutus-ledger/src/Ledger/Constraints/OnChain.hs" rel="nofollow noreferrer">Ledger.Constraints.OnChain</a> is the place to go to figure out what all the constraints actually mean. In the case of <code>mustSpendAtLeast</code>, it simply means that all the values of all the inputs to the transaction must add up to at least that amount.</p>

<plutus><smart-contract>
What is the use case of the mustSpendAtLeast constraint?
# What is the use case of the mustSpendAtLeast constraint?

(Asked by: username_0 on 2021-11-06)

What I can figure out:

[mustSpendAtLeast](https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/TxConstraints.hs#L228-L230) is basically just a wrapper around [MustSpendAtLeast](https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/TxConstraints.hs#L44). This gets processed [here](https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L508), by adding a [required value](https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L213) to [this thing](https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L237-L239). These values get turned into outputs in [addMissingValueSpent](https://github.com/input-output-hk/plutus-apps/blob/404af7ac3e27ebcb218c05f79d9a70ca966407c9/plutus-ledger/src/Ledger/Constraints/OffChain.hs#L313).

With all this, I still don't understand how this constraint is supposed to be used.

edit:
The root of my inability to figure this out was that I was looking in the wrong place for the information. [Ledger.Constraints.OnChain](https://github.com/input-output-hk/plutus-apps/blob/d637b1916522e4ec20b719487a8a2e066937aceb/plutus-ledger/src/Ledger/Constraints/OnChain.hs) is the place to go to figure out what all the constraints actually mean. In the case of `mustSpendAtLeast`, it simply means that all the values of all the inputs to the transaction must add up to at least that amount.

**Tags:** plutus, smart-contract

---

## 1 answers

### Answer by username_1 on 2021-11-07. Score: 2 | Accepted answer

Here is a contrived use case:
Imagine some dApp that includes governance (voting and stuff). Among the requirements for voting on some referendum, you must prove your right to vote with governance tokens. The smart contract doesn't need to be paid the governance tokens, rather just see that they are included in any vote transaction, after which the tokens can be returned to the voter.
To achieve this, you will need to spend the tokens, and just have yourself as the recipient*. You will include the constraint:
Constraints.mustSpendAtLeast govTokenValue

Which under the hood will select enough UTxOs to spend and meet the minimum govTokenValue (or return an error if you don't have enough).
The dApp smart contract can then check its ScriptContext to ensure that at least the minimum number of governance tokens needed were included in the transaction to perform the desired action, e.g. vote.
*not specifying a recipient will default to returning them to the transaction builder (you)


---

