<p>I assume you have a redeemer that helps you understand when to run the &quot;return founds&quot; logic.</p>
<p>there are two options I can think you could implement, depending by how you expect the smart contract to be used</p>
<h1>Use the <code>Datum</code> to keep track of the parties</h1>
<hr />
<p>you could store a <code>PubKeyHash</code> list (<code>[PubKeyHash]</code>) in the smart contract <code>Datum</code> and update the list for each new party.</p>
<p>if ever the &quot;return founds&quot; logic gets called you check that at least half the parties (or all of them if you prefer) have signed the transaction by checking the <code>txInfoSignatories</code> field</p>
<blockquote>
<p><strong>Important:</strong> due to the limited tx size you should use this approach if you expect not to have a lot of partecipants.</p>
</blockquote>
<h1>use tokens to identify parties</h1>
<hr />
<p>when someone decides to take part in the found you could mint some tokens to distribute proportionally to their contribution to the total found, and keep track of the total supply in the <code>Datum</code></p>
<p>when the &quot;return founds&quot; logic is called you check for the input (or burned if you prefer) tokens to be at least half the total supply (or all of them if you prefer)</p>
<p>this approach should work also for a large number of participants since now the datum only stores an integer, no matter how many parties there are</p>

CC BY-SA 4.0
2022-06-28T14:35:34.410Z
2022-06-28T14:35:34.410Z
Michele Nuzzi
<p>If I have assets (can be just ADA for simplicity) locked in a contract, how can I release the funds to the previous owners most efficiently?</p>
<p>Some more context regarding the question.
I created a pay endpoint (for the PAB), where different parties pay the same amount of ADA into a smart contract. Once a certain condition is met, the script can be consumed as an UTXO by another party (= getting paid some ADA). Until that condition is met, I want the parties that pay funds into the contract to essentially cancel the contract (= creating more appropriate UTXOs). In simple terms, the parties get their money back.</p>
<p>I have some code that solves this on a per-party basis, but I would like to get to the point where all parties get &quot;reimbursed&quot;.</p>

<plutus><smart-contract><pab><eutxo>
How to return funds from a smart contract
# How to return funds from a smart contract

(Asked by: username_0 on 2021-10-01)

If I have assets (can be just ADA for simplicity) locked in a contract, how can I release the funds to the previous owners most efficiently?

Some more context regarding the question.
I created a pay endpoint (for the PAB), where different parties pay the same amount of ADA into a smart contract. Once a certain condition is met, the script can be consumed as an UTXO by another party (= getting paid some ADA). Until that condition is met, I want the parties that pay funds into the contract to essentially cancel the contract (= creating more appropriate UTXOs). In simple terms, the parties get their money back.

I have some code that solves this on a per-party basis, but I would like to get to the point where all parties get "reimbursed".

**Tags:** plutus, smart-contract, pab, eutxo

---

## 1 answers

### Answer by username_1 on 2022-06-28. Score: 0

I assume you have a redeemer that helps you understand when to run the "return founds" logic.

there are two options I can think you could implement, depending by how you expect the smart contract to be used

# Use the `Datum` to keep track of the parties

---

you could store a `PubKeyHash` list (`[PubKeyHash]`) in the smart contract `Datum` and update the list for each new party.

if ever the "return founds" logic gets called you check that at least half the parties (or all of them if you prefer) have signed the transaction by checking the `txInfoSignatories` field

> **Important:** due to the limited tx size you should use this approach if you expect not to have a lot of partecipants.

# use tokens to identify parties

---

when someone decides to take part in the found you could mint some tokens to distribute proportionally to their contribution to the total found, and keep track of the total supply in the `Datum`

when the "return founds" logic is called you check for the input (or burned if you prefer) tokens to be at least half the total supply (or all of them if you prefer)

this approach should work also for a large number of participants since now the datum only stores an integer, no matter how many parties there are


---

