Glossary · eUTxO

Contention.

When multiple parties want to spend the same UTxO, only one can win per pool-state transition. The rest must wait for the new UTxO.

Think of it as

A single popular ATM. Only one person can use it at a time. The fix is either more ATMs (fragmentation) or a queue manager (batchers).

In depth

Because a UTxO is consumed in full and only once, any shared-state contract whose state lives in a single UTxO becomes a contention point: every state change produces a brand-new UTxO that the next user has to spend. Solutions: batchers that aggregate user requests off-chain into one tx, pool fragmentation (many small pools), reference inputs for read-only data, or contract designs that avoid global state altogether.

Example

A new AMM pool starts as one UTxO holding all liquidity. Without a batcher, only one swap per block can succeed; the rest fail or wait.

Next on this path

  1. Reference input A UTxO the transaction can read but not spend. Used to look at on-chain data (or a script) without consuming it.
  2. Reference script A script body stored on-chain in a UTxO so transactions can use it by reference instead of bundling the whole script every time.