<p>This has been bugging me for a while now. I'm not as worried about it as I was before though. Here are some thoughts:</p>
<p><a href="https://twitter.com/LarsBrunjes/status/1403760389024894979?s=20" rel="nofollow noreferrer">Lars says</a> there are ways around the problem:</p>
<blockquote>
<p>Of course there are ways around. You need to parallelize. In an auction contract, for example, you can have several UTxO's instead of just one.</p>
</blockquote>
<p>This seems <em>fine</em> to me. Of course there is still a chance of collision. A collision isn't the end of the world, but you could make as many UTxOs as you want to minimize the worry. You can also do things off-chain to pseudo-randomly choose a UTxO (with the modulo of your hashed redeemer, for example).</p>
<p><strong>Back of napkin estimates</strong></p>
<p>If you look at something like Uniswap, which has on the order of ~100K transactions/day and ~50 Liquidity pools. Cardano has 4320 blocks/day, so that would be an average of around .5 tx/block/lp (obviously some pools are much more popular). But having somewhere between 10-100 UTxO/pool should be plenty.</p>
<p><strong>How does it work?</strong></p>
<p><strong>EDIT:</strong> This actually still has problems. I can't think of how you would determine the rates without including all the UTxOs in a txn--which defeats the purpose. Hmm, still need to think things through.</p>
<p>For a Uniswap, the way it could work is the sum of all the datums on liquidity pool NFT UTxOs in a pool equal the total liquidity for that pool. Anyone adding or removing from the pool can modify any number of the UTxOs, but for the sake of fees they would tend to modify the minimum number necessary to add/remove from the pool. For pools with a lot of collisions, there might even be a way to incentivize participants to open new pools or even add more UTxOs to existing pools perhaps? The factory token would just need to keep track of how many liquidity NFTs are floating around for each pool.</p>

CC BY-SA 4.0
2021-08-23T00:22:13.803Z
2021-08-23T16:44:28.513Z
2021-08-23T16:44:28.513Z
Mitchell Turner
<p>Theoretically, you can just create multiple eUTxOs to reduce collisions. But that isn't an ideal solution. For example, an oracle would have to maintain a lot of different eUTxOs and create new ones to update the oracle value. This would cause a lot of transaction fees for the oracle provider, linearly increasing by count.<br>
Additionally, I'm wondering <a href="https://cardano.stackexchange.com/questions/769/how-can-an-oracle-guarantee-certain-update-rates-respectively-uptime">How can an oracle guarantee certain update rates respectively uptime?</a></p>

CC BY-SA 4.0
2021-05-27T10:05:24.403Z
2021-05-27T10:05:24.403Z
Johannes Sirsch
<p>Please see my article &quot;Scaling with UTXOs.&quot; I outline several different approaches. These include buffering, state sharding / replication, and using transactions which do not consume UTXOs.</p>
<p><a href="https://journal.platonic.systems/p/scaling-with-utxos" rel="nofollow noreferrer">https://journal.platonic.systems/p/scaling-with-utxos</a></p>

CC BY-SA 4.0
2021-11-12T00:50:23.133Z
2021-11-12T00:50:23.133Z
Morgan Thomas
<p>One possible solution for this is that instead of letting the users of your dapp compete for a single UTxO you let them publish a &quot;request for transaction&quot; and then let an open bot network compete to aggregate and execute these transactions into a single block. If your dapp relies on a single state stored in a single UTxO then only one bot will be able to consume that UTxO but you can design your smart contracts in a way that will allow the winning bot to execute multiple &quot;request for transaction&quot; together with consuming the state UTxO. If these &quot;request for transaction&quot; contain a bounty then bots will be incentivized to execute as many &quot;request for transaction&quot; as possible and it doesn't matter which bot wins since all bots will try to execute all transactions.</p>
<p>Variations of this solution are described in the following blog posts:</p>
<p><a href="https://medium.com/meld-labs/concurrent-deterministic-batching-on-the-utxo-ledger-99040f809706" rel="nofollow noreferrer">https://medium.com/meld-labs/concurrent-deterministic-batching-on-the-utxo-ledger-99040f809706</a>
<a href="https://medium.com/minswap/introducing-laminar-an-eutxo-scaling-protocol-for-accounting-style-smart-contract-d1ac8847dde8" rel="nofollow noreferrer">https://medium.com/minswap/introducing-laminar-an-eutxo-scaling-protocol-for-accounting-style-smart-contract-d1ac8847dde8</a></p>

CC BY-SA 4.0
2021-10-02T09:40:40.393Z
2021-10-02T09:40:40.393Z
user142
<p>Not as far as I know. The current model is limited to one state change (transaction) per block per smart contact.</p>
<p>However, depending on the specific smart contact and its use case, I can see people using a centralized entity (or a group of users) post transition proposals and then have an incentive to bundle all of those up into one that actually modifies the global state. Not ideal, but this is the price to pay to have a state-full smart contact design.</p>

CC BY-SA 4.0
2021-05-27T08:55:54.043Z
2021-05-27T08:55:54.043Z
Marek Mahut - StakeNuts
<p>In some applications, multiple users interact with the same smart contract and may want to do it at about the same time. Such interaction involves updating the state of the smart contract as embodied in the UTXOs of the smart contract address. One example application is a DEX.</p>
<p>Because all the users interact with the same smart contract, potentially spending existing UTXOs and creating new ones, potentially only one user can succeed in each block and the other users have their transactions rejected due to double-spending the UTXOs, limiting the throughput of the application.</p>
<p>Is there a general approach for dealing with this kind of situation to allow more transactions for a smart contract to succeed in each block?</p>

<smart-contract><scaling>
General approach for allowing multiple smart contract transactions per block
# General approach for allowing multiple smart contract transactions per block

(Asked by: username_0 on 2021-05-26)

In some applications, multiple users interact with the same smart contract and may want to do it at about the same time. Such interaction involves updating the state of the smart contract as embodied in the UTXOs of the smart contract address. One example application is a DEX.

Because all the users interact with the same smart contract, potentially spending existing UTXOs and creating new ones, potentially only one user can succeed in each block and the other users have their transactions rejected due to double-spending the UTXOs, limiting the throughput of the application.

Is there a general approach for dealing with this kind of situation to allow more transactions for a smart contract to succeed in each block?

**Tags:** smart-contract, scaling

---

## 5 answers

### Answer by username_5 on 2021-05-27. Score: 5

Not as far as I know. The current model is limited to one state change (transaction) per block per smart contact.

However, depending on the specific smart contact and its use case, I can see people using a centralized entity (or a group of users) post transition proposals and then have an incentive to bundle all of those up into one that actually modifies the global state. Not ideal, but this is the price to pay to have a state-full smart contact design.


---

### Answer by username_1 on 2021-08-23. Score: 2

This has been bugging me for a while now. I'm not as worried about it as I was before though. Here are some thoughts:

[Lars says](https://twitter.com/LarsBrunjes/status/1403760389024894979?s=20) there are ways around the problem:

> Of course there are ways around. You need to parallelize. In an auction contract, for example, you can have several UTxO's instead of just one.

This seems *fine* to me. Of course there is still a chance of collision. A collision isn't the end of the world, but you could make as many UTxOs as you want to minimize the worry. You can also do things off-chain to pseudo-randomly choose a UTxO (with the modulo of your hashed redeemer, for example).

**Back of napkin estimates**

If you look at something like Uniswap, which has on the order of ~100K transactions/day and ~50 Liquidity pools. Cardano has 4320 blocks/day, so that would be an average of around .5 tx/block/lp (obviously some pools are much more popular). But having somewhere between 10-100 UTxO/pool should be plenty.

**How does it work?**

**EDIT:** This actually still has problems. I can't think of how you would determine the rates without including all the UTxOs in a txn--which defeats the purpose. Hmm, still need to think things through.

For a Uniswap, the way it could work is the sum of all the datums on liquidity pool NFT UTxOs in a pool equal the total liquidity for that pool. Anyone adding or removing from the pool can modify any number of the UTxOs, but for the sake of fees they would tend to modify the minimum number necessary to add/remove from the pool. For pools with a lot of collisions, there might even be a way to incentivize participants to open new pools or even add more UTxOs to existing pools perhaps? The factory token would just need to keep track of how many liquidity NFTs are floating around for each pool.


---

### Answer by username_2 on 2021-05-27. Score: 1

Theoretically, you can just create multiple eUTxOs to reduce collisions. But that isn't an ideal solution. For example, an oracle would have to maintain a lot of different eUTxOs and create new ones to update the oracle value. This would cause a lot of transaction fees for the oracle provider, linearly increasing by count.  
Additionally, I'm wondering [How can an oracle guarantee certain update rates respectively uptime?](https://cardano.stackexchange.com/questions/769/how-can-an-oracle-guarantee-certain-update-rates-respectively-uptime)


---

### Answer by username_3 on 2021-11-12. Score: 1

Please see my article "Scaling with UTXOs." I outline several different approaches. These include buffering, state sharding / replication, and using transactions which do not consume UTXOs.

<https://journal.platonic.systems/p/scaling-with-utxos>


---

### Answer by username_4 on 2021-10-02. Score: 0

One possible solution for this is that instead of letting the users of your dapp compete for a single UTxO you let them publish a "request for transaction" and then let an open bot network compete to aggregate and execute these transactions into a single block. If your dapp relies on a single state stored in a single UTxO then only one bot will be able to consume that UTxO but you can design your smart contracts in a way that will allow the winning bot to execute multiple "request for transaction" together with consuming the state UTxO. If these "request for transaction" contain a bounty then bots will be incentivized to execute as many "request for transaction" as possible and it doesn't matter which bot wins since all bots will try to execute all transactions.

Variations of this solution are described in the following blog posts:

<https://medium.com/meld-labs/concurrent-deterministic-batching-on-the-utxo-ledger-99040f809706>
<https://medium.com/minswap/introducing-laminar-an-eutxo-scaling-protocol-for-accounting-style-smart-contract-d1ac8847dde8>


---

