<p>We may need different models than what has been done in Uniswap, Keep in mind that Hyrda is coming and can get us around this problem. Unlike other L2 solutions for other blockchains, Plutus code runs with Hydra out of the box  so by then this may not be an issue.</p>
<p>Prof, Aggelos Kiayias explains <a href="https://www.youtube.com/watch?v=7UAL_6f7PFw&amp;t=1145s" rel="nofollow noreferrer">here</a> I recommend watching the whole video.</p>

CC BY-SA 4.0
2021-07-08T05:38:08.603Z
I understand that Hydra may render all this moot, but I'm still curious about what sort of tricks we'll have at our disposal for achieving something closer to concurrency at the base layer.
AscendantMediocre
CC BY-SA 4.0
2021-07-06T21:43:25.130Z
2021-07-06T21:43:25.130Z
jnprogrammer
<p>I've been thinking on restrictions around concurrency of smart contracts given the deterministic nature of the EUTXO model, and I've had trouble finding an answer to how transactions are prioritized for a block in the case where multiple valid transactions exist
visible to a node redeeming a single UTXO. Is this left to the slot leader to decide?</p>
<p>This question also leads into another question I have, which is: Is network spam somehow a viable concurrency model since fees are not charged for simple validation failure? Like say you change the Uniswap implementation to allow for multiple liquidity pools of a given trading pair (thus multiple corresponding UTXOs) Would it be viable to submit multiple transactions redeeming overlapping UTXO's in the hope that only one transaction would go through?</p>
<p>Maybe this is still being thought about and maybe this question is ultimately silly, but I was hoping to hone in my thinking around this a bit.</p>

<utxo><smart-contract>
How are transactions prioritized from memory?
# How are transactions prioritized from memory?

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

I've been thinking on restrictions around concurrency of smart contracts given the deterministic nature of the EUTXO model, and I've had trouble finding an answer to how transactions are prioritized for a block in the case where multiple valid transactions exist
visible to a node redeeming a single UTXO. Is this left to the slot leader to decide?

This question also leads into another question I have, which is: Is network spam somehow a viable concurrency model since fees are not charged for simple validation failure? Like say you change the Uniswap implementation to allow for multiple liquidity pools of a given trading pair (thus multiple corresponding UTXOs) Would it be viable to submit multiple transactions redeeming overlapping UTXO's in the hope that only one transaction would go through?

Maybe this is still being thought about and maybe this question is ultimately silly, but I was hoping to hone in my thinking around this a bit.

**Tags:** utxo, smart-contract

---

## 1 answers

### Answer by username_1 on 2021-07-06. Score: 2

We may need different models than what has been done in Uniswap, Keep in mind that Hyrda is coming and can get us around this problem. Unlike other L2 solutions for other blockchains, Plutus code runs with Hydra out of the box so by then this may not be an issue.

Prof, Aggelos Kiayias explains [here](https://www.youtube.com/watch?v=7UAL_6f7PFw&t=1145s) I recommend watching the whole video.

> **Comments:**
> **username_0**: I understand that Hydra may render all this moot, but I'm still curious about what sort of tricks we'll have at our disposal for achieving something closer to concurrency at the base layer.  

---

