<p>To my knowledge, there is no concurrency issue on Cardano. If multiple people want to perform some transaction, then on Cardano, you can bundle all of those into one UTxO with several inputs and several outputs. Could you please provide some more details?</p>

CC BY-SA 4.0
2021-09-25T16:25:09.497Z
The issue (for others) is that they may have 2 transactions attempt to use same tx-in. This problem was solved 40 years ago via serialised access, a staple to the dev community. Be very proud you are not having this issue. It's so simple it's almost juvenile.
Patrick Sturm
CC BY-SA 4.0
2021-09-04T19:23:11.553Z
2021-09-04T19:23:11.553Z
Noah Jones
<p>Even though the EUTxO model ensures that outputs are not double spent, therefore limiting dApps to one &quot;transaction&quot; per UTxO every twenty seconds, it is not a requirement to use one UTxO only and there are numerous implementations one could think of in order to preserve concurrency.</p>
<p>Instead of keeping a list of all &quot;pools&quot; in one UTxO and use a NFT so as to ensure their validity, for example, you could have a minting policy that requires some specific Datum in these pools (like you would check in the old implementation when validating) and only allows the minting of these specific tokens if the pool has a valid hash, a valid datum and that the token is being transferred to the pool.</p>
<p>Later, off-chain code would be able to identify &quot;authentic&quot; pools by verifying if they hold the token minted by this minting policy, since they would only receive these tokens if the requirements were met.</p>
<p>This is the logic I'm using in a project I'm working on called DigiServices. More details on the implementation can be found here <a href="https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#i-utxo-identity" rel="nofollow noreferrer">https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#i-utxo-identity</a> and here <a href="https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#6-scalability" rel="nofollow noreferrer">https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#6-scalability</a> (though the paper needs a lot of adjustments)</p>
<p>I'm sure there are numerous other ideas and ways. The magic of being open to the public is that anyone can design their implementations. In my opinion, the EUTxO model offers a number of advantages when compared to the account model and most of the disadvantages can be overcome with a little bit of creativity and engineering.</p>

CC BY-SA 4.0
2021-09-17T18:56:21.083Z
2021-09-17T18:56:21.083Z
Mateus
<p>SundaeSwap has already addressed this issue. Feel free to give it a read.
<a href="https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575" rel="nofollow noreferrer">https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575</a></p>

CC BY-SA 4.0
2021-09-19T05:15:17.510Z
The solution is the shortest section in this article cited. And all it basically says is "Stay tuned for more information".
lambda
CC BY-SA 4.0
2021-09-07T14:19:39.753Z
2021-09-07T14:19:39.753Z
Steve
<p>No issues, just inexperienced team at miniswap testing and developing. Great publicity for cardano and opportunity to showcase how advanced the protocol is and ready for the future which may not even be Uniswap type DeFi</p>

CC BY-SA 4.0
2021-09-05T23:12:06.003Z
Answers should be complete, evidence-driven, and with sources/examples - this would be better suited as a comment :) For example a link to an article showing a how a DApp is managing concurrency at scale or a detailed example of why miniswap is wrong would be better.
Eddy Schauman-Haigh
CC BY-SA 4.0
2021-09-05T23:12:31.637Z
Please add further details to expand on your answer, such as working code or documentation citations.
Community
CC BY-SA 4.0
2021-09-05T22:55:12.683Z
2021-09-05T22:55:12.683Z
Gary Johal
<p>The Occam.fi team <a href="https://cointelegraph.com/press-releases/cardano-decentralized-exchange-occamx-reaches-key-technical-milestone" rel="nofollow noreferrer">claims to have a solution</a> that works for their DEX.</p>
<blockquote>
<p>The solution uses an intra-block slot auction system to process multiple transactions simultaneously, which is essential for a fully functional and high-volume DEX.</p>
</blockquote>
<p>Looking forward to learning more about that approach.</p>
<hr />
<p>Another solution I've thought about is introducing an off-chain service provider called a &quot;batcher&quot; who is incentivized and authorized to batch a bunch of concurrent transactions.</p>
<p>Take a DEX for example. If many people are trying to provide liquidity to a pool at the same time, instead of them all trying to access the &quot;liquidity total&quot; datum concurrently, each actor could lock their liquidity + a batching fee in a separate escrow script that requires a minimum amount of liquidity tokens to unlock. They then submit a &quot;batching request&quot; datum to the DEX. The off-chain batcher can filter all the request datums and execute as many as they can simultaneously.</p>
<p>The minimum liquidity token requirement on the escrow script prevents the liquidity providers from being screwed over--they set the terms-- and it also allows some flexibility in a volatile market, but there is still a level of centralization of the batcher. My biggest worry would be regulatory intervention, as the batchers could be seen as <a href="https://www.fincen.gov/money-services-business-definition" rel="nofollow noreferrer">MSBs</a>. You could theoretically solve this with federalization of the batching responsibility.</p>
<hr />
<p>All-in-all, I think there are many ways to solve the concurrency problem. Charles talked about additional side-chain solutions in <a href="https://youtu.be/FVA54yAaLC8" rel="nofollow noreferrer">this video</a>. I think we just need to be comfortable with the idea that the solutions might just look different from what we see on Ethereum, and that's okay. Ethereum has it's own set of problems that needed creative solutions as well.</p>

CC BY-SA 4.0
2021-09-06T20:07:03.653Z
Thinking about the “batcher” service more, it could be valuable to speak of the concurrency congestion as a small “risk.” In designing an app, you can offload that risk to some party other than the costumers of your dApp’s core business, for a small incentive. So back to the DEX example, you don’t need the batcher to be authorized, just incentivized. The risk being that their transaction doesn’t succeed and the resources needed to pay attention we’re wasted. A small risk, but the fee needs to be high enough that it keeps batchers’  attentions.
Mitchell Turner
CC BY-SA 4.0
2021-09-06T20:34:33.143Z
In fact, if structured right, the "batchers" might just be the submitters of requests the previous block. You'd just need to be sure that they are incentivized to include other people's requests in their batch.
Mitchell Turner
CC BY-SA 4.0
2021-09-04T22:20:04.417Z
2021-09-11T02:48:22.273Z
2021-09-11T02:48:22.273Z
Mitchell Turner
<p>Here is a big old list of relevant resources. Some of them claim (credibly, I think) to solve the problem without sacrificing decentralization.</p>
<p><strong>From IO</strong></p>
<ul>
<li><a href="https://plutus.readthedocs.io/en/latest/plutus/howtos/writing-a-scalable-app.html" rel="nofollow noreferrer">https://plutus.readthedocs.io/en/latest/plutus/howtos/writing-a-scalable-app.html</a></li>
<li><a href="https://iohk.io/en/blog/posts/2021/09/06/no-surprises-transaction-validation-on-cardano/" rel="nofollow noreferrer">https://iohk.io/en/blog/posts/2021/09/06/no-surprises-transaction-validation-on-cardano/</a></li>
<li><a href="https://iohk.io/en/blog/posts/2021/09/07/no-surprises-transaction-validation-part-2/" rel="nofollow noreferrer">https://iohk.io/en/blog/posts/2021/09/07/no-surprises-transaction-validation-part-2/</a></li>
<li><a href="https://iohk.io/en/blog/posts/2021/09/10/concurrency-and-all-that-cardano-smart-contracts-and-the-eutxo-model/" rel="nofollow noreferrer">https://iohk.io/en/blog/posts/2021/09/10/concurrency-and-all-that-cardano-smart-contracts-and-the-eutxo-model/</a></li>
<li><a href="https://docs.cardano.org/plutus/concurrency" rel="nofollow noreferrer">https://docs.cardano.org/plutus/concurrency</a></li>
</ul>
<p><strong>From projects</strong></p>
<ul>
<li><a href="https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575" rel="nofollow noreferrer">https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575</a></li>
<li><a href="https://medium.com/occam-finance/the-occam-fi-technical-series-on-concurrency-cd5bee0b850c" rel="nofollow noreferrer">https://medium.com/occam-finance/the-occam-fi-technical-series-on-concurrency-cd5bee0b850c</a></li>
<li><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></li>
<li><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></li>
<li><a href="https://github.com/ergolabs/ergo-dex" rel="nofollow noreferrer">https://github.com/ergolabs/ergo-dex</a></li>
<li><a href="https://cardax.blog/concurrency-in-perspective/" rel="nofollow noreferrer">https://cardax.blog/concurrency-in-perspective/</a></li>
<li><a href="https://blog.maladex.com/maladex-solves-concurrency-scales-beyond-memory-limits-and-designs-the-best-possible-cardano-dex-391d7e519e67" rel="nofollow noreferrer">https://blog.maladex.com/maladex-solves-concurrency-scales-beyond-memory-limits-and-designs-the-best-possible-cardano-dex-391d7e519e67</a></li>
</ul>
<p><strong>Videos</strong></p>
<ul>
<li><a href="https://www.youtube.com/watch?v=xlDlNmIFrFM" rel="nofollow noreferrer">https://www.youtube.com/watch?v=xlDlNmIFrFM</a></li>
<li><a href="https://www.youtube.com/watch?v=TxnvYsBnLjQ" rel="nofollow noreferrer">https://www.youtube.com/watch?v=TxnvYsBnLjQ</a></li>
</ul>
<p><strong>Minswap reflecting</strong> on the incident that sparked the FUD storm</p>
<ul>
<li><a href="https://medium.com/minswap/minswap-testnet-reflections-64b01c5e7c45" rel="nofollow noreferrer">https://medium.com/minswap/minswap-testnet-reflections-64b01c5e7c45</a></li>
</ul>
<p><strong>Indie contributions</strong></p>
<ul>
<li><a href="https://twitter.com/DarkeningAges/status/1436308661454975001" rel="nofollow noreferrer">https://twitter.com/DarkeningAges/status/1436308661454975001</a></li>
<li><a href="https://cryptois.land/posts/2021/09/10/simple-cardano-batching-bots/" rel="nofollow noreferrer">https://cryptois.land/posts/2021/09/10/simple-cardano-batching-bots/</a></li>
</ul>

CC BY-SA 4.0
2021-09-24T18:19:53.810Z
I think [this article](https://blog.maladex.com/maladex-solves-concurrency-scales-beyond-memory-limits-and-designs-the-best-possible-cardano-dex-391d7e519e67) from Maladex also deserves some attention.
Jelil Akjaly
CC BY-SA 4.0
2021-09-25T04:50:33.337Z
Appreciate it @JelilAkjaly. Adding this.
Matthew Capps
CC BY-SA 4.0
2021-09-14T04:17:02.657Z
2021-09-25T04:51:55.300Z
2021-09-25T04:51:55.300Z
Matthew Capps
<p>Are there any solutions to the concurrency issue so far without sacrificing decentralization? MinSwap testnet was experiencing this last night and just looking for some clarification, haven't seen much spoken on this subject, thanks.</p>

CC BY-SA 4.0
2021-09-04T18:09:30.197Z
I don't know how MinSwap is implemented, so hard to answer. So what concurrency issues do you have?
j.karlsson
CC BY-SA 4.0
2021-10-02T09:43:16.290Z
Does this answer your question? [General approach for allowing multiple smart contract transactions per block](https://cardano.stackexchange.com/questions/722/general-approach-for-allowing-multiple-smart-contract-transactions-per-block)
user142
<plutus><smart-contract><ada><blocksize>
The Concurrency Issue
# The Concurrency Issue

(Asked by: username_0 on 2021-09-04)

Are there any solutions to the concurrency issue so far without sacrificing decentralization? MinSwap testnet was experiencing this last night and just looking for some clarification, haven't seen much spoken on this subject, thanks.

**Tags:** plutus, smart-contract, ada, blocksize
> **Comments:**
> **username_1**: I don't know how MinSwap is implemented, so hard to answer. So what concurrency issues do you have?  
> **username_2**: Does this answer your question? [General approach for allowing multiple smart contract transactions per block](https://cardano.stackexchange.com/questions/722/general-approach-for-allowing-multiple-smart-contract-transactions-per-block)  

---

## 6 answers

### Answer by username_12 on 2021-09-14. Score: 6

Here is a big old list of relevant resources. Some of them claim (credibly, I think) to solve the problem without sacrificing decentralization.

**From IO**

* <https://plutus.readthedocs.io/en/latest/plutus/howtos/writing-a-scalable-app.html>
* <https://iohk.io/en/blog/posts/2021/09/06/no-surprises-transaction-validation-on-cardano/>
* <https://iohk.io/en/blog/posts/2021/09/07/no-surprises-transaction-validation-part-2/>
* <https://iohk.io/en/blog/posts/2021/09/10/concurrency-and-all-that-cardano-smart-contracts-and-the-eutxo-model/>
* <https://docs.cardano.org/plutus/concurrency>

**From projects**

* <https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575>
* <https://medium.com/occam-finance/the-occam-fi-technical-series-on-concurrency-cd5bee0b850c>
* <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>
* <https://github.com/ergolabs/ergo-dex>
* <https://cardax.blog/concurrency-in-perspective/>
* <https://blog.maladex.com/maladex-solves-concurrency-scales-beyond-memory-limits-and-designs-the-best-possible-cardano-dex-391d7e519e67>

**Videos**

* <https://www.youtube.com/watch?v=xlDlNmIFrFM>
* <https://www.youtube.com/watch?v=TxnvYsBnLjQ>

**Minswap reflecting** on the incident that sparked the FUD storm

* <https://medium.com/minswap/minswap-testnet-reflections-64b01c5e7c45>

**Indie contributions**

* <https://twitter.com/DarkeningAges/status/1436308661454975001>
* <https://cryptois.land/posts/2021/09/10/simple-cardano-batching-bots/>

> **Comments:**
> **username_13**: I think [this article](https://blog.maladex.com/maladex-solves-concurrency-scales-beyond-memory-limits-and-designs-the-best-possible-cardano-dex-391d7e519e67) from Maladex also deserves some attention.  
> **username_12**: Appreciate it @JelilAkjaly. Adding this.  

---

### Answer by username_11 on 2021-09-04. Score: 4

The Occam.fi team [claims to have a solution](https://cointelegraph.com/press-releases/cardano-decentralized-exchange-occamx-reaches-key-technical-milestone) that works for their DEX.

> The solution uses an intra-block slot auction system to process multiple transactions simultaneously, which is essential for a fully functional and high-volume DEX.

Looking forward to learning more about that approach.

---

Another solution I've thought about is introducing an off-chain service provider called a "batcher" who is incentivized and authorized to batch a bunch of concurrent transactions.

Take a DEX for example. If many people are trying to provide liquidity to a pool at the same time, instead of them all trying to access the "liquidity total" datum concurrently, each actor could lock their liquidity + a batching fee in a separate escrow script that requires a minimum amount of liquidity tokens to unlock. They then submit a "batching request" datum to the DEX. The off-chain batcher can filter all the request datums and execute as many as they can simultaneously.

The minimum liquidity token requirement on the escrow script prevents the liquidity providers from being screwed over--they set the terms-- and it also allows some flexibility in a volatile market, but there is still a level of centralization of the batcher. My biggest worry would be regulatory intervention, as the batchers could be seen as [MSBs](https://www.fincen.gov/money-services-business-definition). You could theoretically solve this with federalization of the batching responsibility.

---

All-in-all, I think there are many ways to solve the concurrency problem. Charles talked about additional side-chain solutions in [this video](https://youtu.be/FVA54yAaLC8). I think we just need to be comfortable with the idea that the solutions might just look different from what we see on Ethereum, and that's okay. Ethereum has it's own set of problems that needed creative solutions as well.

> **Comments:**
> **username_11**: Thinking about the “batcher” service more, it could be valuable to speak of the concurrency congestion as a small “risk.” In designing an app, you can offload that risk to some party other than the costumers of your dApp’s core business, for a small incentive. So back to the DEX example, you don’t need the batcher to be authorized, just incentivized. The risk being that their transaction doesn’t succeed and the resources needed to pay attention we’re wasted. A small risk, but the fee needs to be high enough that it keeps batchers’  attentions.  
> **username_11**: In fact, if structured right, the "batchers" might just be the submitters of requests the previous block. You'd just need to be sure that they are incentivized to include other people's requests in their batch.  

---

### Answer by username_3 on 2021-09-04. Score: 1

To my knowledge, there is no concurrency issue on Cardano. If multiple people want to perform some transaction, then on Cardano, you can bundle all of those into one UTxO with several inputs and several outputs. Could you please provide some more details?

> **Comments:**
> **username_4**: The issue (for others) is that they may have 2 transactions attempt to use same tx-in. This problem was solved 40 years ago via serialised access, a staple to the dev community. Be very proud you are not having this issue. It's so simple it's almost juvenile.  

---

### Answer by username_5 on 2021-09-17. Score: 0

Even though the EUTxO model ensures that outputs are not double spent, therefore limiting dApps to one "transaction" per UTxO every twenty seconds, it is not a requirement to use one UTxO only and there are numerous implementations one could think of in order to preserve concurrency.

Instead of keeping a list of all "pools" in one UTxO and use a NFT so as to ensure their validity, for example, you could have a minting policy that requires some specific Datum in these pools (like you would check in the old implementation when validating) and only allows the minting of these specific tokens if the pool has a valid hash, a valid datum and that the token is being transferred to the pool.

Later, off-chain code would be able to identify "authentic" pools by verifying if they hold the token minted by this minting policy, since they would only receive these tokens if the requirements were met.

This is the logic I'm using in a project I'm working on called DigiServices. More details on the implementation can be found here <https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#i-utxo-identity> and here <https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#6-scalability> (though the paper needs a lot of adjustments)

I'm sure there are numerous other ideas and ways. The magic of being open to the public is that anyone can design their implementations. In my opinion, the EUTxO model offers a number of advantages when compared to the account model and most of the disadvantages can be overcome with a little bit of creativity and engineering.


---

### Answer by username_6 on 2021-09-07. Score: 0

SundaeSwap has already addressed this issue. Feel free to give it a read.
<https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575>

> **Comments:**
> **username_7**: The solution is the shortest section in this article cited. And all it basically says is "Stay tuned for more information".  

---

### Answer by username_8 on 2021-09-05. Score: -1

No issues, just inexperienced team at miniswap testing and developing. Great publicity for cardano and opportunity to showcase how advanced the protocol is and ready for the future which may not even be Uniswap type DeFi

> **Comments:**
> **username_9**: Answers should be complete, evidence-driven, and with sources/examples - this would be better suited as a comment :) For example a link to an article showing a how a DApp is managing concurrency at scale or a detailed example of why miniswap is wrong would be better.  
> **username_10**: Please add further details to expand on your answer, such as working code or documentation citations.  

---

