Understanding EUTXO
— The Fundamentals
a simple introduction to eutxo · in six parts
A structured guide to Cardano’s Extended UTXO ledger model — from first principles to the current protocol. Six fundamental parts build the model; the advanced topics extend it. Dev notes mark implementation detail for builders. Sources at the close.
The model decides everything
Picture a shared spreadsheet tracking who owns how much. Anyone can read it. Nobody owns it. Thousands of computers hold identical copies. The difficulty was never storage — it's agreement without a referee. There is no bank to call when two copies disagree, so the rules must be precise enough that every honest computer independently reaches the same verdict on every transaction.
Those rules are the accounting model: the exact way the ledger represents "who owns what" and how a transaction changes it. Look inside any blockchain and you'll find one of two designs behind it — and, in one important case, a third that descends from the first. Here they are, side by side:
+ data on outputs
+ transaction awareness
takeaway — the model decides everything. Every strength and every flaw we uncover from here traces back to which of these three designs a chain chose.
Notes, not totals
Start with the name, read backwards. UTXO — Unspent Transaction Output. An output is a chunk of value a transaction produced, addressed to someone. The transaction is the event that consumed old chunks and created new ones. Unspent means this chunk hasn't yet been used as an input to anything later.
A UTXO, then, is a chunk of money sitting on the ledger with your name on the lock, waiting to be spent. That's the entire concept. Now watch it behave.
The note that must be spent whole
You hold a $50 bill and want a $15 coffee. You cannot tear the bill; you hand over the whole thing and receive change. In this model that's not an analogy — it is mechanically what happens:
A UTXO can be spent exactly once, and only in full. There is no partial spend. Every strange behavior and every power we uncover in this guide traces back to this single rule.
The balance that was never there
Return to the opening question: where does the 50 live? In a bank, the answer is boring — the bank stores a number beside your name and the app displays it. Most people assume a crypto wallet works the same way. In a UTXO system, it doesn't. Search the ledger all you like: no number with your name on it exists anywhere. What exists is the pile of notes — and your wallet counts them, every time, like counting the cash in a physical wallet:
your addresses
unspent notes with your lock
and shows you the sum
Once you see the balance as a count, a second question follows: does it matter which notes make the total? In a bank account, obviously not — 50 is 50. Here, yes, because spending means handing over whole notes. Run the experiment: two people, identical balances, both ordered to pay exactly 10.
no change needed
just like breaking a bill at a shop
Hold that finding — the ledger tracks notes, never totals — because it pays off twice. It's why UTXO chains can validate many transactions in parallel (different notes cannot collide, Part 04), and it's why two hundred people cannot all spend the same note at once (the trade-off, Part 05). The superpower and the headache share one fingerprint.
Locks, keys, and the chain of custody
An output contains an address and a value — the address is a lock on the box. An input is a pointer back to an earlier output plus a key that opens its lock: on Bitcoin, a digital signature matching the address's public key. When an input unlocks an output, the network marks it spent — and the chain of custody is literal. My output becomes your input; your output becomes another's input; follow the trail backwards and you reach the coin's creation. Provenance is exact, which is why this record never lies.
Step back far enough and the whole ledger has a recognizable shape: a directed acyclic graph — transactions are the nodes, outputs are the edges between them, and the arrows only ever point forward. Money flows through the graph; it never loops back. (File a mental sketch of this — it's the map every later step is drawn on.)
Every node (a computer running the blockchain software) keeps a live index of every currently unspent output — the UTXO set, known in a node's technical internals as the chainstate, stored in its data directory and updated as each block arrives. It is, in a very real sense, the entire state of the blockchain.
The UTXO set is the node’s working state: an index keyed by (tx_hash, output_index), mutated only by block application. Wallet coin selection — which notes to spend for a given payment — is a real algorithmic problem (minimize fees, avoid dust, preserve privacy), solved differently by every wallet. If a payment ever produces "too many small UTXOs," coin selection is why.
One side-benefit worth logging: because every note carries a visible size and age, an observer can read the chain's vital signs directly — how much value moves, how old the coins being spent are, how active the economy is. UTXO ledgers make unusually honest sources for analysts.
Plain UTXO — its strengths, and the missing piece
The design's merits are on record. Simple to verify: a transaction is valid or invalid based only on its own inputs. Naturally parallel: transactions touching different UTXOs cannot interfere, so nodes can check them simultaneously. Auditable and privacy-friendly: exact provenance, and a fresh address per output means activity doesn't cluster under one identity.
But ask the lock anything else and it falls silent fast. A Bitcoin lock can essentially only say "open with a signature from this key." It sees nothing but the key being offered: it cannot read stored data (there is none), cannot inspect the rest of the transaction, and cannot say a word about where funds go next. So you cannot express "release after Tuesday" or "only if the machine still has stock." No rich conditions. No memory.
Fixing that without abandoning the cash model required a genuinely new model — not a patch. That's the subject of Part 04. But first, the rival design.
takeaway — notes, not totals. The lock is honest but mute — it can identify the bearer and nothing more.
A moving target
Each account — controlled by a private key or by a smart contract — holds a number. The network maintains a global state: one enormous table of every balance, held by every node, rewritten with every block.
to show transfer of 30
What the design buys: programmability feels natural. A smart contract is a long-lived object with persistent memory that anyone can call, so building a shared pool of anything — liquidity, votes, bids — is straightforward. This is a genuine advantage, and it's why DeFi emerged on Ethereum first. That deserves saying without a sneer.
What it costs traces to one fact, and every incident report contains its fingerprint: everything shares one mutable state, and that state changes underneath you between submitting a transaction and executing it. Fees become a bid, not a price. Transactions can fail mid-execution — and still charge for the work already done. And whoever orders the block can insert themselves ahead of your trade: front-running, the visible edge of a multi-billion-dollar category called MEV (Maximal Extractable Value).
Ethereum has worked on these challenges: EIP-1559 made fees far more predictable, and private relays blunted the crudest front-running. The structural property remains — the state still moves under your feet — but the 2022 framing reads harsher than 2026 reality. A fair comparison doesn't flatter one side by exaggerating the other's flaws.
takeaway — a moving target. The account model's power and its unpredictability come from the same source — shared mutable state.
Two additions, one refusal
UTXO and EUTXO are not the same model. EUTXO descends from UTXO the way a smartphone descends from a telephone — same family, different species. The formal research proves EUTXO is strictly more expressive: it can implement general state machines and enforce rules across entire chains of transactions, which plain UTXO provably cannot.
The cleanest comparison is a single question, put to all three designs: when the ledger runs your script, what is that script allowed to look at? Their answers separate them completely:
bitcoin — utxo
The script sees only the unlocking data — essentially "is this signature valid?" Stateless, safe, and deliberately dumb. It guards who can spend, but can't say a word about where funds go next.
cardano — eutxo
The validator sees its stored state, the spender's argument, and the entire transaction — every input and output — but never the wider chain. Enough to run real contracts; little enough to stay deterministic.
ethereum — account
Contracts can see and modify the whole global state — maximum power, and the source of the unpredictability, re-entrancy bugs, and MEV catalogued in Part 03.
State the bet precisely: keep UTXO's local, deterministic validation, and widen the script's field of view by exactly two things — no more. The extension goes in two directions.
In the research paper’s notation, a plain-UTXO validator is ν(redeemer) → Bool; the EUTXO validator becomes ν(datum, redeemer, context) → Bool — a pure function, no I/O, no clock, no chain reads. All three arguments arrive encoded in one uniform Data type (structured like CBOR/JSON); your contract decodes what it expects. Purity is the load-bearing property: it is what makes the off-chain "rehearsal" below provably identical to on-chain execution. Version note — the formula above is the Plutus V2 interface. Since Plutus V3 (Chang, 2024), a validator receives one merged argument: the context, carrying the datum and redeemer inside it. The datum also became optional, so funds sent to a script address without one are no longer permanently stuck. What the script can see is unchanged — the same three things, one envelope. Part 07 covers the change in detail.
Extension one — the lock can be a program
Instead of a lock that only accepts a signature, an address can contain arbitrary logic: a validator script. When a transaction attempts to spend that output, the node runs the script. True → the spend is allowed. False → rejected. A lock can now hold a position: "open only if the price feed reads above X, and today is Wednesday, and two of these three signatures are present."
Extension two — the output can carry data
An EUTXO output holds an address, a value, and a datum — an arbitrary piece of data riding on the output itself. This is what gives contracts memory. In the account model, a contract keeps memory in variables; here, memory travels on the note. Spending an output and creating a successor with an updated datum is how state advances.
The overlooked clause — money itself becomes plural
There is a third change the headline "two extensions" undersells: multi-assets. In plain UTXO, an output holds one thing — an amount of the chain's single coin. In Cardano's ledger, an output holds a bundle of tokens: ada, any number of custom native assets, and NFTs, all riding in the same note under the same lock.
Register why "native" is doing real work in that sentence. On Ethereum, a token is not money to the ledger — it's a contract (the ERC-20 pattern): a program keeping its own internal spreadsheet of who owns what, with custom code that can be inefficient, expensive, or simply wrong. On Cardano, tokens live in outputs at the ledger level; sending one is an ordinary transaction requiring no contract at all, and every token inherits the ledger's own security by default. The one place code enters the picture is creation and destruction: a minting policy — a script, cousin to the validator — that alone decides when its tokens may be minted or burned. (An NFT is just a minting policy that permits exactly one token, ever.)
The formal record backs the design up in the same way it backed Part 04's opening key idea: the follow-up research paper proved the multi-asset EUTXO ledger strictly more expressive than single-currency EUTXO — a second rung on the same ladder. UTXO, then EUTXO, then multi-asset EUTXO: each provably capable of things its parent is not.
The delta, itemized
Everything established so far, laid on one card — exactly what changed between parent and descendant, and what deliberately did not:
| the item | utxo (bitcoin) | eutxo (cardano) |
|---|---|---|
| The lock | A public key — "show me a signature" | Any program (a validator) — arbitrary conditions |
| What the script sees | The redeemer only | Datum + redeemer + the entire transaction (context) |
| Memory | None — an output is value and a lock, nothing more | A datum rides on every output; state advances by retire-and-recreate |
| What an output holds | An amount of the one native coin | A token bundle — ada, native assets, NFTs — under one lock |
| Time | Effectively none — the script is blind to the clock | A validity interval: bounded, determinism-safe access to time |
| Proven expressiveness | Payments and simple spending conditions | General state machines; invariants enforced across whole transaction chains |
| Unchanged, on purpose | Spend-once, spend-whole, local validation, natural parallelism, the note-based ledger — the entire cash chassis carries over intact. That's what makes it an extension and not a replacement. | |
The four instruments
validator
A program that decides whether a spend is allowed. Returns true → spend goes through. False → rejected.
redeemer
Data the spender supplies to argue their case — "I'm swapping 100 ada," "I'm claiming the refund branch."
datum
Contract-specific state stored on the output — a price, an owner, a deadline, a score. Spending an output and recreating it with a new datum is how state advances.
context
A summary of the whole transaction being validated — inputs, outputs, signatures, validity window — so a script can enforce conditions on the transaction as a whole.
A script address is derived from the hash of the validator — the code is the identity; change one byte and you have a different address. Datums were originally stored as hashes on the output (the spender supplied the preimage); since Vasil’s CIP-32 they can sit inline, readable by anyone. Part 06 has the before/after.
Context is quietly the decisive instrument. Because a validator can inspect the transaction's outputs, it can insist its successor carries the correct datum and the correct script. That property is called continuity — it makes "spend the contract and simply not recreate it" impossible. The lock reads the whole transaction before it opens.
Time is handled with care. Scripts cannot ask "what time is it" — the answer would differ depending on when the script runs, and determinism would collapse. Instead, a transaction declares a validity interval: a window of slots (Cardano's discrete time units; one slot ≈ one second) during which it may be included. A script may assume "now" falls inside the window without knowing exactly where. Deadlines become expressible; determinism survives.
Why determinism is the whole point
A validator's verdict depends only on the transaction and its inputs — never on the wider world. So you can run the exact validation logic on your own machine before broadcasting anything. Compare the two procedures side by side:
— fees taken either way
off-chain, then added
Walkthrough — one contract's full cycle
The four instruments are easiest to grasp in motion. What follows is a walkthrough: a tiny vending-machine contract walked through one complete purchase, step by step. (The vending machine is the classic teaching example from the EUTXO literature — a locked output whose datum is the inventory.) Press play.
A "smart contract" on Cardano is not a running program. It's an output sitting still: some value, a datum holding its state (3 sodas in stock), and a validator as its lock. Nothing happens until someone tries to spend it.
The buyer's wallet does the work: it selects the machine's UTXO and 2 ada of the buyer's own money as inputs, and attaches a redeemer — the argument for why this spend should be allowed. All of this happens on the buyer's computer. The chain hasn't heard a thing yet.
Determinism at work. The validator is a pure function of exactly three things — datum, redeemer, transaction — so the wallet can run it before submitting and learn the outcome and the exact fee. If the answer were ✗, the buyer walks away having spent nothing.
On-chain, nodes run the identical pure function on identical inputs and get the identical answer — that's why the rehearsal was trustworthy. The old machine UTXO with stock 3 is now marked spent. State is never edited in EUTXO; it is retired.
Because the validator could inspect the transaction's outputs (that's the context), it refused to approve any transaction that didn't recreate the machine correctly: value up by 2, stock down by 1, same lock. That guarantee is continuity — you cannot spend the contract and "forget" to put it back.
State advanced not by mutation but by a chain of retire-and-recreate steps — a state machine whose every transition is a transaction. That is the entire EUTXO idea in one sentence. Replay it, or proceed to Part 05, which covers what this design costs.
Plutus — and where the real work happens
The on-chain language is Plutus Core — small, functional, built for formal reasoning. Almost nobody writes it by hand: historically you wrote Haskell and a compiler plug-in produced it. Since the early years, the barrier has dropped considerably — Aiken is now a popular purpose-built contract language, with TypeScript and Python paths for the off-chain side.
And here's a detail worth underlining twice in your notes: on Cardano, the off-chain code is most of the work. The on-chain script only says yes or no; constructing the transaction — choosing UTXOs, computing outputs, assembling datums — happens in your application. This is the biggest adjustment for developers arriving from Ethereum, and the source of most first-year confusion. (On-chain, scripts appear in two roles: validators locking outputs, and minting policies governing tokens — same machinery, different post.)
Promotional summaries of EUTXO tend to close with a box of superiority claims, and cross-examination finds them mixing charges. "More concurrent transactions on a proof-of-stake system drawing a tiny fraction of proof-of-work's energy" — the energy claim is true, but it's a consensus-layer fact about Ouroboros vs. mining, not a property of the EUTXO accounting model; a chain could run EUTXO on proof-of-work tomorrow. Likewise "decentralization and security improve over Bitcoin's" is a network claim, not a ledger-model claim. Such lists often cite the UTXO Alliance — IOG plus seven other UTXO-family chains collaborating on interoperability — which we log as a 2022-era fact of uncertain current standing. The lesson: when a source bundles unrelated favorable facts into one list, unbundle them before weighing any.
takeaway — two additions, one refusal. The lock gained memory and sight — and its refusal to see global state is precisely what makes its verdicts predictable.
The same fingerprint
Suppose a decentralized exchange keeps its liquidity pool in a single UTXO, and two hundred people want to trade against it in the same block. All two hundred build transactions consuming that same output. Exactly one succeeds. The other 199 fail — harmlessly, but they fail. On Ethereum this problem doesn't exist: two hundred calls to the same contract simply execute in sequence.
spendable once per block
How it was solved
An application-design problem, not a protocol defect — and the patterns are now mature. Three techniques appear in every production system:
outputs — users don't collide
a batcher consumes many at once
no contention on shared data
The patterns above are not theory. Cardano’s major AMMs (Minswap, SundaeSwap v2, WingRiders) run batcher networks: user orders sit as independent UTXOs until a batcher bot consumes a set of them plus the pool UTXO in one transaction. Genius Yield runs a pure order-book, where matching two orders touches only those two UTXOs. Research also exists on fully deterministic, decentralized batching that removes trust in the batcher operator — worth reading before you design your own.
EUTXO trades ease-of-development for predictability. Deterministic fees, structural front-running resistance, parallel validation — paid for with harder application architecture and a dependency on batcher infrastructure. Batchers are off-chain actors, and who runs them is a question worth keeping in view: it carries its own centralization risk. Any framing of EUTXO as strictly superior isn't wrong so much as one-sided — a telling that includes only the flattering half.
The full comparison
With the flattering half and the trade-off both on record, the full comparison can finally be scored. Read it column by column — and note that no column sweeps the board:
| the question | utxo (bitcoin) | eutxo (cardano) | account (ethereum) |
|---|---|---|---|
| Fee known before submitting? | Yes — exactly | Yes — exactly | A bid, not a price (EIP-1559 tamed it, didn't fix it) |
| Cost of a transaction that doesn't go through? | Zero | Zero | Gas already consumed is gone |
| Can a transaction fail mid-execution? | No | No — verdict knowable in rehearsal | Yes |
| Profit from reordering transactions (MEV)? | Structurally resistant | Structurally resistant | Endemic; a live industry (mitigations exist) |
| Parallel validation of independent transactions? | Natural | Natural | Limited — shared state forces sequencing |
| Expressive smart contracts? | No — dumb locks by design | Yes — proven state machines | Yes — the original home of them |
| Many users hitting one shared contract per block? | n/a | The hard part — needs fan-out / batching (Part 05) | Native strength — calls just queue |
| Custom tokens? | Not natively | Ledger-native bundles; no contract to trust | Per-token contracts (ERC-20) — powerful, error-prone |
| Developer on-ramp? | Simplest model to reason about | Steepest — off-chain-heavy, new patterns | Most familiar; largest tooling & talent pool |
That is the whole case in one board. UTXO buys simplicity and predictability at the price of expressiveness. The account model buys expressiveness and developer ease at the price of predictability. EUTXO is the attempt to keep both — and its two red cells are the honest bill for the attempt: the hardest concurrency story and the steepest learning curve of the three. Any presentation of this model showing you only the cyan cells, or only the coral ones, is marketing, not analysis.
takeaway — the same fingerprint. Spend-once gives you parallelism and gives you contention. One rule, both consequences. Any account of the model that mentions only one is an incomplete account.
Promises, checked, kept
Verified: all four went live in the Vasil hard fork, 22 September 2022, alongside diffusion pipelining, a block-propagation speedup. The before/after record for each:
Cardano validates in two phases. Phase 1: cheap structural checks — inputs exist, signatures verify, fees suffice. Phase 2: script execution. Collateral exists to charge for phase-2 failures, which a correctly rehearsed transaction should never reach — CIP-40 below governs exactly how much a failure costs.
Reference Inputs
To read data in a UTXO you had to spend it and recreate it — reading was as contentious as writing.
Transactions can reference an output read-only. Oracles and price feeds became practical. The single biggest contention fix on this list.
Inline Datums
Outputs stored only a hash of the datum; spenders had to separately supply matching data obtained off-chain.
The datum itself sits on the output, visible to everyone. Simpler, and far better for transparency.
Reference Scripts
Every transaction carried a full copy of the validator script — complex contracts meant enormous, expensive transactions.
The script lives on-chain once; transactions point at it. Dramatically smaller transactions, lower fees, more throughput.
Collateral Outputs
Fail phase-2 validation and your entire collateral input was consumed — post 4 ada from a 6 ada UTXO, lose all 6.
The excess returns to a collateral output — you lose only the specified amount.
wallet total: 8
wallet total: 10
takeaway — promises, checked, kept — nearly four years ago. Documents age; verify dates before trusting anything labeled "upcoming."
Advanced topics
From this point, the guide goes deeper: the 2024 revision of the validator interface, the new cryptographic capabilities of on-chain scripts, and the technologies — Hydra, Aiken, Leios — built directly on the model’s properties.
⇩ advanced pdfPART 07The validator signature, revised▸
The validator signature, revised
CIP-69, script signature unification, shipped with Plutus V3. Every script role now receives a single argument — the script context — with the datum and redeemer carried inside it rather than passed separately. For V3, the formula reads ν(context) → yes/no.
missing one strands the funds
the script decides the no-datum case
Concretely, the script’s identity is now a six-way type — spending (carrying an optional datum), minting, rewarding, certifying, plus the new voting and proposing roles that validate DAO treasury withdrawals and protocol changes.
Two long-standing problems were solved by this one change. The mutual-dependency problem: one validator can serve every role at once, so two cooperating scripts no longer need to know each other’s hash at design time — a limitation builders had engineered around for years. And the stranded-datum problem: under V1/V2 a datum was mandatory, so funds sent to a script address without one — a wallet bug, a careless exchange withdrawal — failed phase-1 validation before any custom logic could even run, and were unspendable forever. Under V3 the datum is optional: a script can define its own fallback for the no-datum case, such as acting as a shared wallet that the right keyholder can sweep.
Part 04’s comparison still holds: the validator sees the whole transaction and never global state. Only how the arguments arrive changed.
CIP-69 is not backward compatible — it shipped through a hard fork, and V3 scripts had to change. For most contracts the port is a straightforward refactor; the one branch needing genuinely new logic is the spending script’s no-datum case.
takeaway — one envelope. Datum and redeemer now arrive inside the context; a missing datum no longer strands funds, and the same validator can stand guard over governance as well as payments.
PART 08What the validator can now compute▸
What the validator can now compute
BLS12-381 brought seventeen built-in primitives for a pairing-friendly elliptic curve, and the payoff is concrete. Signature aggregation: thousands of individual signatures can collapse into one compact proof, verified with as few as two pairing computations instead of thousands of separate checks. Zero-knowledge proof verification on-chain: a contract can confirm a claim is true — a transaction amount is valid, a computation was done correctly — without seeing the underlying data. These are the cryptographic engines behind Midgard, a ZK-rollup scaling design for Cardano, and the planned Midnight–Cardano bridge, which verifies recursive proofs between the two chains.
Keccak-256 lets a Cardano validator verify Ethereum-style signatures directly — interoperability in the script itself, not a bridge with its own trust assumptions bolted on. And the efficiency layer matters as much as the cryptography: the new sums-of-products encoding and bitwise primitives (CIP-58) make scripts smaller and cheaper, with improvements up to roughly 30% in execution — the same logic, less budget, lower fees. secp256k1 support (the 2023 Valentine upgrade) had already rounded out the signature schemes before Chang shipped.
takeaway — more capable, never more sighted. Three years of additions widened the validator’s computation, and not once its field of view.
PART 09Hydra — the model, off-chain▸
Hydra — the model, off-chain
A Hydra Head is a state channel (a temporary off-chain execution environment): a small, defined group of participants transacts among themselves off-chain using the exact same ledger rules, transaction format, and validator logic as the main chain. That is what isomorphic means here — the off-chain ledger is a structural mirror of the on-chain one, not an approximation. The same Plutus script that runs on layer 1 runs unmodified inside a Head.
is evidence — l1 settles it
That dispute path is why a Head requires no new trust assumptions beyond already trusting Cardano itself. And the closed-group shape unlocks configurations impossible on layer 1: fees and minimum-UTXO values can be set as low as 1–2 lovelace (the smallest unit of ada; 1 ada = 1,000,000 lovelace), which makes high-frequency micropayments and blockchain gaming practical.
The trade-off is explicit and worth naming: Hydra scales throughput for a bounded, known group, not the open network. Leios (Part 11) is the opposite shape — scaling the open network itself. The two are complements, not competitors.
takeaway — portable rules, provable exits. Determinism and locality let the same ledger logic run anywhere — and disagreement off-chain is always resolvable on-chain.
PART 10Aiken — the on-ramp, revisited▸
Aiken — the on-ramp, revisited
either way
What changed, technically: Aiken is a small functional language purpose-built for validators — strong static typing with inference (the compiler determines most types without annotation), first-class functions, and a single toolchain covering compilation, testing, and execution-cost estimation. It compiles directly to Untyped Plutus Core, the same target the Haskell route reaches — a simpler path onto identical on-chain guarantees, not a simplified subset of them.
And the adoption is measurable, not anecdotal: as of 2025, Aiken accounts for an estimated 62% of all Cardano smart contract activity, was recognized as an official language on GitHub in June 2025, and ships in production at Minswap, SundaeSwap, Lenfi, and Levvy — the same production systems described in Part 05, not demonstration code.
What did not change: the structural facts of Part 05 stand. EUTXO applications still demand more architectural thought than account-model ones, because the off-chain transaction-building burden from Part 04 hasn’t gone away. The tooling cliff was graded into a slope; the underlying design trade-off remains.
takeaway — a fading red cell. The model didn’t get easier; getting started did.
PART 11Leios — parallelism, cashed in▸
Leios — parallelism, cashed in
endorsed in parallel
block
double-spends resolved here
The specification, CIP-164 (Cardano Improvement Proposal), is merged, and a public testnet — branded “Musashi Dojo” — launched on June 23, 2026, running through five structured stages covering protocol validation, parameter tuning, real-world load, and adversarial stress testing. The published target is a 10–65× throughput increase over today’s Praos, with mainnet deployment targeted for late 2026, contingent on testnet results and governance approval.
The honest framing, stated once: this is real, dated progress — not a promise repeated unchanged since 2022. But “testnet launched” and “targets validated at scale” are different claims. Treat the throughput figures as the thing the testnet exists to test, and verify the current status before repeating any number elsewhere.
takeaway — live, not yet proven. The design is real and testing; the throughput claim is the thing being tested.
End of the advanced topics. The glossary below covers the entire guide.
Every term, in one place
Every term used in this guide, in one place:
- address
- The lock on an output — a public key (needs a signature) or a script (needs the script's approval).
- batcher
- Off-chain service bundling many users' orders into one transaction, working around contention.
- chainstate
- A node's on-disk copy of the UTXO set, updated with every block.
- cip
- Cardano Improvement Proposal — a numbered public specification for a protocol change.
- coin selection
- The wallet's silent choice of which notes to spend for a given payment.
- collateral
- Ada forfeited if a script fails phase-2 validation. Anti-spam, not a normal cost.
- contention
- Many users needing to spend the same output at once — only one succeeds.
- continuity
- A validator's power to demand its own correct successor, by inspecting the transaction's outputs.
- datum
- Data attached to an output; how EUTXO contracts remember things.
- determinism
- A transaction's outcome and cost are fully knowable before submission.
- fan-out
- Splitting protocol state across many outputs so users don't collide.
- front-running / mev
- Profiting by inserting a transaction ahead of someone's pending one.
- gas
- Ethereum's unit of computational cost, paid at a fluctuating price.
- hard fork
- A backward-incompatible upgrade. On Cardano these are coordinated and routine, not schisms.
- lovelace
- The smallest unit of ada. One ada = 1,000,000 lovelace.
- minting policy
- A script that alone controls creation and destruction of a native token.
- native asset
- On Cardano, tokens live in outputs alongside ada at the ledger level — no contract needed for basic transfers.
- nft
- A token whose minting policy permits exactly one to exist, ever.
- order book
- A DEX design listing standing bids and asks sorted by price; trades execute when they cross.
- redeemer
- Data the spender supplies to satisfy a validator — the request.
- reference input
- An output a transaction reads without consuming.
- script context
- The transaction summary handed to a validator so it can rule on the whole picture.
- utxo set
- All currently unspent outputs — effectively the ledger's entire state.
- validator
- The on-chain script that approves or rejects a spend — the programmable lock.
- validity interval
- The slot range during which a transaction may be included — bounded access to time.