<p>The question was also answered by a member of the IOHK team, on a secondary channel. I will post the answer here for community reference.</p>
<h4>Answer</h4>
<ol>
<li><p><code>UTxO</code> entries are consumed &quot;<strong>immediately after</strong>&quot; the <code>Tx</code> that uses them as an input is validated. That is <em>&quot;after&quot;</em> in the <em>blockchain order</em>. No subsequent transaction in the same block or later blocks can use the <code>oRef</code> input. This is the <strong>&quot;no double spend&quot;</strong> property, also enforced for <code>Tx</code>s in the mempool of any individual node.</p>
</li>
<li><p>The order of execution is inherently non-deterministic. If one <code>Tx</code> is submitted well before the other then the first one is most likely to make it in first. If they are submitted from different points in the network (i.e. by different users) then it is very much non-deterministic which one makes it first. In future there will be limited ways to prioritise, but this example would still depend on timing and be non-deterministic. (The priority mechanism is aimed at ensuring a certain class of latency for inclusion).</p>
</li>
</ol>
<h4>Extra information</h4>
<p><code>Tx</code>s, disimilar to bitcoin, don't hang around in the <code>mempool</code> for long. The Cardano mempool only acts as a small buffer to smooth out the traffic flow. If the system is saturated, <code>Tx</code>s are held at the edge of the network (e.g. in the <code>mempool</code> of on the local node).</p>
<p>So <code>Tx</code>s are not in the <code>mempool</code> for long at all. Its behaviour is more like a <em>narrow pipe of fast-flowing water</em> rather than a <em>pool</em>.</p>

CC BY-SA 4.0
2021-10-28T12:23:29.823Z
2021-10-28T12:23:29.823Z
cstml
<p>Great questions.</p>
<blockquote>
<p>When does oRef get consumed? Would oRef exist until the next block?</p>
</blockquote>
<p><code>oRef</code> will be consumed when a transaction spends it. If <code>txn1</code> is executed before <code>txn2</code>, even in the same block, <code>txn2</code> will fail. Luckily, the sender of <code>txn2</code> will not pay a fee for such a failed transaction.</p>
<blockquote>
<p>Would oRef be observable in the same block to a third transaction tx3 which was submitted later than the initial two?</p>
</blockquote>
<p>No. See above.</p>
<blockquote>
<p>Is there a deterministic mechanism choosing which of the two/three transactions gets accepted?</p>
</blockquote>
<p>By default, the block builder will just include the transactions in the order they see them. Of course, no one is able to stop the builder from putting them in whichever order they want (or excluding them altogether). This is where the concept of <a href="https://ethereum.org/en/developers/docs/mev/" rel="nofollow noreferrer">Miner Extractable Value</a> comes from, which is still possible on Cardano.</p>

CC BY-SA 4.0
2021-10-28T07:40:51.690Z
2021-11-03T07:16:55.497Z
2021-11-03T07:16:55.497Z
Mitchell Turner
<h4>Scenario</h4>
<p>There are two transactions <code>tx1</code> and <code>tx2</code> both trying to consume an arbitrary eUTXo <code>oRef</code>. Both <code>tx1</code> and <code>tx2</code> are submitted to the mempool in the same block, and are valid transactions; we can consider them identical for the purpose of the question.</p>
<h4>Questions:</h4>
<ol>
<li><p>When does <code>oRef</code> get consumed? Would <code>oRef</code> exist until the next block?</p>
</li>
<li><p>Would <code>oRef</code> be observable in the same block to a third transaction <code>tx3</code> which was submitted later than the initial two?</p>
</li>
<li><p>Is there a deterministic mechanism chosing which of the two/three transactions gets accepted?</p>
</li>
</ol>

CC BY-SA 4.0
2021-10-28T10:27:55.147Z
Some further relevant contextual information [transaction events](https://cardano.stackexchange.com/questions/214/what-events-are-kicked-off-when-a-transaction-is-submitted?rq=1)
cstml
<transaction><validation>
When is an eUTXO consumed?
# When is an eUTXO consumed?

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

#### Scenario

There are two transactions `tx1` and `tx2` both trying to consume an arbitrary eUTXo `oRef`. Both `tx1` and `tx2` are submitted to the mempool in the same block, and are valid transactions; we can consider them identical for the purpose of the question.

#### Questions:

1. When does `oRef` get consumed? Would `oRef` exist until the next block?
2. Would `oRef` be observable in the same block to a third transaction `tx3` which was submitted later than the initial two?
3. Is there a deterministic mechanism chosing which of the two/three transactions gets accepted?

**Tags:** transaction, validation
> **Comments:**
> **username_0**: Some further relevant contextual information [transaction events](https://cardano.stackexchange.com/questions/214/what-events-are-kicked-off-when-a-transaction-is-submitted?rq=1)  

---

## 2 answers

### Answer by username_0 on 2021-10-28. Score: 4 | Accepted answer

The question was also answered by a member of the IOHK team, on a secondary channel. I will post the answer here for community reference.

#### Answer

1. `UTxO` entries are consumed "**immediately after**" the `Tx` that uses them as an input is validated. That is *"after"* in the *blockchain order*. No subsequent transaction in the same block or later blocks can use the `oRef` input. This is the **"no double spend"** property, also enforced for `Tx`s in the mempool of any individual node.
2. The order of execution is inherently non-deterministic. If one `Tx` is submitted well before the other then the first one is most likely to make it in first. If they are submitted from different points in the network (i.e. by different users) then it is very much non-deterministic which one makes it first. In future there will be limited ways to prioritise, but this example would still depend on timing and be non-deterministic. (The priority mechanism is aimed at ensuring a certain class of latency for inclusion).

#### Extra information

`Tx`s, disimilar to bitcoin, don't hang around in the `mempool` for long. The Cardano mempool only acts as a small buffer to smooth out the traffic flow. If the system is saturated, `Tx`s are held at the edge of the network (e.g. in the `mempool` of on the local node).

So `Tx`s are not in the `mempool` for long at all. Its behaviour is more like a *narrow pipe of fast-flowing water* rather than a *pool*.


---

### Answer by username_1 on 2021-10-28. Score: 4

Great questions.

> When does oRef get consumed? Would oRef exist until the next block?

`oRef` will be consumed when a transaction spends it. If `txn1` is executed before `txn2`, even in the same block, `txn2` will fail. Luckily, the sender of `txn2` will not pay a fee for such a failed transaction.

> Would oRef be observable in the same block to a third transaction tx3 which was submitted later than the initial two?

No. See above.

> Is there a deterministic mechanism choosing which of the two/three transactions gets accepted?

By default, the block builder will just include the transactions in the order they see them. Of course, no one is able to stop the builder from putting them in whichever order they want (or excluding them altogether). This is where the concept of [Miner Extractable Value](https://ethereum.org/en/developers/docs/mev/) comes from, which is still possible on Cardano.


---

