user2277: 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:

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

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

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



user1130: 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 comes from, which is still possible on Cardano.

user2277: 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

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 Txs in the mempool of any individual node.

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
Txs, 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, Txs are held at the edge of the network (e.g. in the mempool of on the local node).
So Txs 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.

2277: <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>
 1130: <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>
 2277: <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>
