Ouroboros Leios cannot guarantee full determinism by design. A transaction that passes local validation may still be dropped during the finalization process. This is a necessary trade-off to achieve scalability through parallelism. The system embraces probabilistic inclusion and deferred validation, supported by conflict resolution mechanisms and incentive alignment, rather than strict up-front guarantees. Explore a few proposed resolutions addressing duplicate and conflicting transactions in Leios—how transactions are processed in stages and how the system ensures only valid, non-conflicting data makes it into the final ledger. In this article, we will describe these techniques: deduplication, tombstoning, coloring, sharding, and collateralization. Consequences of Parallelism Ouroboros Leios is designed to significantly increase network throughput by introducing a pipelined, parallelized architecture. Instead of processing transactions strictly one block at a time—as in traditional consensus models like Ouroboros Praos—Leios splits transaction processing into multiple concurrent stages. This allows multiple Input Blocks (IBs) to be created in parallel, enabling the network to process far more transactions simultaneously. More precisely, Input Blocks are ideally minted sequentially at a high frequency and potentially in parallel by different nodes, allowing their processing across the distributed network to occur concurrently. This parallelism is the foundation of Leios’s scalability: validators can continuously prepare, validate, and finalize different batches of transactions across independent pipelines. As a result, the system can maintain fast block finalization (every ~20 seconds) while greatly increasing transaction throughput. Why Duplicate Transactions Occur However, this design introduces new complexities. Because validators operate independently and concurrently, they may unknowingly include the same transaction in multiple Input Blocks. This happens because, at the moment of block construction, nodes lack immediate global knowledge of what other validators are doing. In other words, a transaction is likely to be included in multiple Input Blocks before the gossip protocol can let nodes know that the transaction has already been included in a new Input Block. The result is transaction duplication, where the same transaction appears in different speculative blocks across the network. Example: Node A and Node B both see Transaction X in the mempool. They both independently create input blocks and include X. These blocks go through different validation pipelines or are seen by different validators. X is now being redundantly processed, possibly multiple times. In the figure, the yellow transactions are duplicates, i.e., inserted in multiple Input Blocks, and the green ones are unique, inserted in only one block. Although there are a total of 23 transactions in 4 blocks, only 17 are unique. Resolving duplicates requires unnecessary consumption of resources. This duplication is not a consensus failure, but it is an inefficiency. The system must detect and filter duplicates during later stages (validation and finalization), which adds computation and complicates reward distribution. There is nothing that block producers could do better to avoid duplication. Suppose a transaction from the mempool passes local validation, and the producer hasn’t seen it elsewhere. In that case, they will include it, even if it may already exist in another Input Block or might later conflict with another transaction. This is a natural consequence of parallel block production without (fast) global state synchronization, and it's precisely why Leios relies on post-inclusion conflict resolution and deduplication mechanisms. Conflicts High throughput brings another challenge. In some cases, conflicting transactions may be included—e.g., if two transactions attempt to spend the same UTxO. These conflicts must be resolved, since only one can be finalized. In the figure, the red transactions are conflicting, i.e., inserted in multiple Input Blocks, and the green ones are unique. Although there are a total of 23 transactions in 4 blocks, only 21 are unique. Transactions 5 and 9 are conflicting. The conflicts must be resolved, as they are double-spends. Conflicts become likely when dApps or wallets create multiple transactions simultaneously using the same UTxO as input. For example, a dApp might generate and broadcast two transactions at once, both using the same UTxO. It may not be aware that these transactions conflict. In Ouroboros Praos, only one of the transactions is included, and the other is predictably rejected. In Leios, however, both may be speculatively included in different Input Blocks before the conflict is detected. Later, the protocol must resolve the conflict, deciding which transaction is finalized and which is discarded. In the figure, you can see that two transactions consume the same UTXO from the liquidity pool. Suppose transactions 3A and 3B conflict with each other. When Node A sees and includes 3A, it hasn’t yet learned about 3B—so it treats 3A as valid. Meanwhile, Node B does the same with 3B, unaware of 3A. The conflict only becomes apparent after both transactions have propagated. Conflict detection can occur when nodes receive both new Input Blocks, each containing a conflicting transaction. When a node attempts to build an Endorsement Block, it must first identify and resolve such conflicts, ensuring only one of the conflicting transactions moves forward. Locally, a node can and usually does discard a second transaction that conflicts with one already in its mempool. Praos usually does this. Leios can also do this, but it doesn't help. The problem is that the conflicting transactions were independently (almost) parallelly inserted into two (or more) Input Blocks. Leios aims to significantly raise throughput, meaning the network operates closer to its computational limits. In this environment, every wasted cycle — such as validating a transaction that is later discarded due to conflict — represents a lost opportunity to include valid, unique transactions. The higher the throughput, the less tolerance the system has for redundant effort, making conflict resolution not only a technical necessity but also an economic efficiency challenge. Conflicts Can Be Exploited by Attackers Attackers can exploit Leios’s speculative processing model by submitting many transactions that attempt to spend the same UTxO. An attacker could intentionally mimic these conditions to create conflicting transactions at scale, amplifying the impact far beyond what might occur accidentally. This turns a natural vulnerability into a potential attack vector. The goal of such an attack is to force the network to expend resources resolving conflicts, even if only one transaction can eventually be finalized. This type of behavior can act as a denial-of-service (DoS) attack, where the attacker pays for only one valid transaction (if any), but causes validators to perform N× the normal amount of validation work due to duplication and conflict resolution. Notice that if conflicts were handled naively, i.e., by discarding all Input Blocks containing conflicts, it would be easy for an attacker to significantly reduce network throughput. The figure shows that the attacker has managed to invalidate all Input Blocks. All valid transactions must continue to wait in the mempools for another chance to be inserted into Input Blocks. However, if the attack were to continue, it would slow down the processing of valid transactions. Handling Conflicting Transactions in Leios Is More Complex Than in Praos In the current Ouroboros Praos protocol, when multiple transactions attempt to spend the same UTxO at roughly the same time, the situation is relatively straightforward. The network latency can cause some divergence. Different nodes might receive different transactions first, leading to a scenario where a fraction of the network holds Transaction 1, another holds Transaction 2, and yet another holds Transaction 3 in their respective mempools. Eventually, once a block producer includes one of these transactions in a block and that block is propagated, the rest of the network quickly catches up and removes the now-invalid competing transactions from their mempools. Conflicts are resolved neatly at the transaction level, without much overhead or disruption to the system. So, rather than coordination, the system relies on eventual consensus and propagation to resolve duplication and conflicts. However, Leios introduces a more complicated reality. For example, if transactions 1, 2, and 3 all attempt to spend the same UTxO and are broadcast at around the same time, three different Input Blocks can include each one. At this stage, the network must not only detect the conflict, but also decide which transaction to keep, and crucially, how to do so without sacrificing throughput or enabling abuse. Fair Fees Another important challenge introduced by Leios is how to handle transaction fees fairly and efficiently. A user submits only a single regular transaction and pays a fee of 0.17 ADA. However, this transaction can appear in 3 Input Blocks. For Ouroboros Praos, this isn’t a concern. Transactions are processed sequentially, and block producers have an up-to-date view of the UTxO set. A user submits a single transaction, pays the declared fee (e.g., 0.17 ADA), and it either makes it into the next block or is rejected. There’s no ambiguity: one submission, one outcome, one fee. However, in Leios, things are more complex. From the network’s perspective, all these duplicates must be validated and processed, even though only one version of the transaction will ultimately be finalized. The rest are filtered out during later stages (endorsement and ranking) and effectively discarded. But this raises a key question: who pays for the duplicated work? For regular users acting in good faith, the expectation is simple: “I submitted one transaction, so I should only be charged one fee.” And that expectation is reasonable. Users don’t control how their transaction propagates or which Input Blocks it gets picked up by. If the system were to charge them multiple times—once for each inclusion—it would feel punitive and unpredictable. It could even lead to users overpaying or losing collateral through no fault of their own. But on the other hand, the protocol must also guard against adversarial behavior. An attacker could: Intentionally submit many copies of a transaction (or slight variations), Force them into multiple Input Blocks, Waste compute and block space, And walk away having paid only once (or even nothing), if the system is too lenient. This would effectively allow attackers to spam the pipeline at low cost, degrading throughput and validator efficiency. That’s especially risky in a high-throughput environment where every slot counts and where bandwidth and CPU time are at a premium. This creates a clear economic and protocol-level challenge: Honest users should not be penalized for accidental duplication. Malicious actors should not be able to flood the network with cheap noise. Designers must strike a balance that discourages abuse without hurting regular users. This could involve: Fee collection only at finalization (not Input Block inclusion), Collateral or bonding mechanisms for speculative inclusion, which may be refunded if the transaction is finalized and lost if not, Tombstoning of rejected transactions to prevent replay, Or incentive rules that penalize excessive duplication but tolerate minor, accidental overlap. The Ideal Solution Is In The Research Phase Exactly how this will be handled is still under research and debate, and different models may be tested during the rollout and refinement of Leios. This issue ties directly into the efficiency of the Leios pipeline. If the system were forced to discard entire Input Blocks because of one conflicting or duplicated transaction, it would waste all the other valid transactions in that block, significantly harming throughput. Therefore, the protocol is designed to resolve duplication at the transaction level, not the block level—allowing as many valid transactions as possible to continue toward finalization, even if some are filtered out. Handling fees fairly in Leios is not just an accounting issue—it’s a foundational challenge tied to security, performance, and user trust. The protocol must ensure that users are charged predictably and fairly, while also ensuring that malicious behavior carries real cost. You now have a good background in understanding the challenges faced by the team building Leios. Let’s now explore potential solutions to the challenges outlined above. As of now, no final approach has been chosen. The team is still deep in the analysis and simulation phase, carefully evaluating each option before making a decision. Deduplication and Tombstoning The protocol must ensure that redundant transactions do not lead to inefficiencies or inconsistencies in the final ledger state. To solve this, Leios implements a two-part mechanism: deduplication and tombstoning. Together, these mechanisms allow the system to accept short-term duplication as a byproduct of its pipelined design, while still maintaining long-term correctness, efficiency, and fairness. Each transaction is identified by a unique transaction ID, a hash of its content. When Input Blocks are created, block producers include transactions from their local mempool, potentially unaware that another block being produced elsewhere includes the same transaction. These duplicates temporarily enter the pipeline and consume network and computational resources. This is unavoidable, but Leios resolves these duplicates during the endorsement phase, where nodes construct Endorsement Blocks by examining all related Input Blocks and selecting one canonical version of each duplicated transaction. The ID of the Input Block would be defined as the hash of the IDs of each transaction concatenated together, not as the hash of all of the transactions concatenated together. The full list of transaction IDs would be stored alongside the block ID. The hash (block ID) acts as a commitment: it proves that the block included those exact transaction IDs, even if some transaction bodies are later pruned. The figure shows red IDs representing duplicate transactions. Red transactions will be pruned from the Input Blocks while green ones will be preserved. Input Blocks contain a list of all transactions that were inserted into them. Endorsement Block resolves conflicts by referencing Input Blocks and containing a list of IDs of all transactions that will be stored in the ledger. Note: I have simplified the hashing for easier understanding. The transaction number corresponds to its ID. The block ID is formed by concatenating the transaction IDs. Transaction 1 has ID 1. The ID of the Input Block 1 starts with 1, continues with 2, etc. When multiple identical transaction IDs are found, one is selected for finalization, and the rest are discarded. These discarded duplicates are not forgotten; instead, they are tombstoned — explicitly marked as seen and invalidated — ensuring they are not reprocessed or reintroduced in future Input Blocks. This tombstoning process is what keeps the pipeline clean over time, even if it's briefly cluttered with speculative duplication. The system is designed to support this without compromising the immutability or verifiability of Input Blocks. In Leios, the ID of an Input Block is not computed as a hash of the full transaction data, but rather as the hash of the concatenated transaction IDs. This design allows the block to retain a consistent and verifiable identity even if some transactions are later pruned. If a transaction is tombstoned, its full contents can be pruned (deleted) from the ledger, and only its ID is retained. In this sense, the transaction ID becomes an epitaph — a marker of a pruned transaction. The system can still reproduce the original block hash from the remaining IDs, ensuring that immutability and traceability are preserved, even as storage and processing costs are reduced. Transaction 2 was pruned in block 5627. However, it is still possible to find transaction 2 in block 1234. Similarly, transaction 7 can be found in block 87910. This structure also resolves a subtle economic issue. A user who submits one transaction may see it included multiple times across different Input Blocks due to propagation lag, but expects to pay a fee only once. Deduplication ensures only one copy of the transaction is finalized, while tombstoning prevents the others from being processed or charged again. In contrast, if an attacker deliberately floods the network with conflicting or duplicate transactions, the protocol must include mechanisms — such as requiring collateral or penalizing invalid submissions — to ensure that this behavior comes at a cost. While tombstoning ensures that duplicate transactions are flagged and excluded from the final ledger, economic deterrence must be layered on top to prevent attackers from exploiting speculative inclusion for free. Honest users, by contrast, are protected from overpaying, as only the finalized version of their transaction is counted toward fees. In practice, users may be required to deposit a small collateral for each transaction. If the transaction appears in only one Input Block, the full collateral is refunded. If it ends up in multiple Input Blocks, a small portion is deducted from the collateral. While this penalty is minimal for regular users, it becomes costly for attackers attempting large-scale spam. However, this approach breaks fee determinism—users won’t know in advance whether they'll pay exactly 0.17 ADA or slightly more, like 0.18 ADA, depending on how the transaction propagates. It's important to distinguish deduplication from conflict resolution. While tombstoning deals with identical transactions that are duplicated across Input Blocks, conflict resolution handles different transactions that attempt to spend the same UTxO, often resulting from concurrent submissions by different parties. Both processes take place in the endorsement stage, but solve distinct problems. By separating transaction IDs from transaction content in block hashes and leveraging tombstoning for efficient pruning and reuse detection, Leios maintains both the scalability benefits of parallel transaction processing and the integrity required of a decentralized ledger. These strategies reflect a core principle of Leios: accepting short-term ambiguity in favor of long-term efficiency and correctness, resolving duplication and conflict not at the point of entry, but during well-defined reconciliation phases in the protocol. Coloring Coloring is a proposed technique aimed at improving efficiency and fairness during the Input Block creation phase. The central idea is to partition the mempool into colored subsets of transactions, so that different block producers, even when unaware of each other’s actions, are less likely to duplicate effort by including the same transactions in their respective Input Blocks. Each transaction is assigned a color — either randomly derived, deterministically based on the transaction hash, or even explicitly chosen in some cases to support advanced use cases like transaction chaining. Input Blocks are also assigned a color and are designed to include only those transactions that match their color. If a node runs out of transactions for a given color while building an Input Block, it can switch to another color deterministically, ensuring progress without reintroducing ambiguity. The figure illustrates how block producers construct colored Input Blocks, each containing transactions that match the block’s assigned color. A block producer will keep inserting transactions of the current color until there are none left. Then they deterministically switch to the next color in sequence. That’s why the last block producer added a yellow transaction into a purple block. This mechanism introduces a structured way to shuffle the contents of Input Blocks across the network. For example, if multiple nodes are building Input Blocks in the same slot, the coloring mechanism encourages them to draw from different segments of the transaction space, thereby reducing the likelihood that they include the same transactions in parallel blocks. This improves network efficiency by minimizing duplication of transaction processing and reducing the need for downstream deduplication. Importantly, coloring is designed to be honest-party friendly. It doesn’t prevent adversaries from gaming the system, but it improves coordination among honest nodes without requiring direct communication or synchronization. Honest nodes following the coloring rules are more likely to produce non-overlapping blocks, even under partial visibility of the mempool. However, coloring is not a security mechanism — it’s a mitigation strategy for inefficiency. A determined adversary can still exploit the system by crafting multiple conflicting transactions and manipulating innocuous transaction fields (like metadata or ordering) to place each version into a different color. This allows the attacker to bypass the natural partitioning and inject redundant or conflicting transactions into otherwise well-separated Input Blocks. As a result, while coloring helps reduce duplication among honest nodes, it doesn’t eliminate the risk of wasted block space or malicious spam from adversarial actors. Coloring in Leios is a clever and lightweight method to encourage natural distribution and deconfliction of transactions during Input Block creation. It works well in honest scenarios, contributing to higher throughput and less redundant work. Thus, coloring must be combined with other techniques — such as tombstoning, collateralization, or fee penalties — to ensure robust protection against malicious behavior. Sharding Sharding builds on the concept of coloring by going beyond mempool organization and fundamentally partitioning the ledger itself into isolated segments called shards. Each shard contains transactions that are guaranteed not to conflict with those in other shards, by design. Unlike coloring, which is a voluntary, behavioral coordination strategy at the Input Block level (meant to reduce transaction overlap), sharding modifies the ledger rules. In coloring, differently colored transactions can still conflict because color has no effect on transaction validity. Sharding, however, ensures that conflicts across shards are structurally impossible. In sharding, the ledger is logically split into non-overlapping UTxO sets, one per shard. A transaction is valid only if all inputs come from the same shard (or compatible unlabeled UTxOs). This separation is maintained from the Input Block construction through to finalization in the Ranking Block. While Ranking Blocks remain part of a single global chain, each contains shard-isolated state updates, allowing parallel transaction processing without cross-shard coordination. In the UTXO model, the total amount can be composed of multiple UTXOs. Users may accumulate UTXOs from multiple shards over time through payments, dApp interactions, or consolidation. Wallets will need to be shard-aware, selecting inputs from a single shard when building transactions. This can be limiting. The goal of this architecture is to make cross-shard conflicts impossible or extremely rare, even in adversarial conditions. Since conflicting transactions across shards are invalid by construction, attackers cannot abuse the system by spamming conflicting transactions across shards. Honest users remain largely unaffected, while malicious behavior becomes costly and ineffective. The attacker is trying to submit 3 transactions that consume green UTxOs from Shard 1 but attempts to include them as if they belonged to Shard 2 or Shard 3. Thus, blue and orange transactions are invalid by design. Only a green transaction is valid. Nodes can discard blue and orange transactions, so they don't even make it into the mempool. A practical sharding implementation might assign a shard ID to each transaction output, either user-defined or deterministically derived. Transactions could only use inputs from the same shard, including collateral. Input Blocks would be assigned to a shard and would only include transactions from that shard. As long as users don’t submit multiple conflicting transactions within the same shard (which wallets could enforce), they avoid accidental penalties. Attackers who attempt to game the system across shards would forfeit their fees. However, sharding brings significant complexity: Ledger rules, wallet logic, and dApp infrastructure must all adapt to handle sharded logic and outputs. Deciding the right number of shards is difficult: too few leads to more conflicts, while too many cause longer wait times, as shards are selected randomly and may activate infrequently, increasing latency. Sharding does not eliminate the problem entirely. Because shard assignments might be determined probabilistically—such as through VRF-based slot leader selection—multiple Input Blocks can still be created for the same shard at nearly the same time. Network delays and the asynchronous nature of block production mean that these blocks might be built without knowledge of one another, allowing the same transaction, or conflicting ones, to appear in multiple blocks for the same shard. Thus, while sharding reduces the chance of conflicts by design and contains their effects within a specific shard, it does not prevent them altogether. For this reason, Leios must still employ conflict resolution mechanisms like tombstoning, endorsement filtering, or collateralization. Sharding simply makes these problems rarer and more manageable, helping the network scale without central coordination, while still requiring safeguards to maintain correctness and fairness. One promising refinement is using a predefined shard activation schedule instead of random assignment, which could reduce variability and make sharding more predictable, though it wouldn’t reduce infrastructure complexity. Sharding offers true parallelism and conflict isolation, but demands thoughtful design, infrastructure overhaul, and careful balancing between throughput and latency. Collateralization Among the various proposals under consideration to manage conflict resolution in Leios, collateralization stands out as a promising, low-complexity solution, particularly well-suited for lower-throughput targets. While more advanced strategies like sharding or ledger partitioning may be needed to scale into the thousands of transactions per second, collateralization offers a practical way to deliver meaningful improvements now, without imposing major infrastructure changes. The core insight behind collateralization stems from reconsidering what determinism means for users. In existing protocols like Cardano's current Ouroboros Praos, determinism provides one key benefit: users never pay for failed transactions. If your transaction is not included in a block, it simply lingers in the mempool or is dropped, but no fees are charged. However, Leios introduces a new kind of risk: transactions may be included speculatively in Input Blocks, yet ultimately rejected in later pipeline stages due to conflicts. In a naïve implementation, this could mean users pay for a service they didn’t receive, which undermines the deterministic user experience Cardano has long championed. Collateralization seeks to address this tension by introducing a small, bounded amount of risk into the process. The idea is that each transaction includes a collateral deposit alongside its normal fee. If the transaction is finalized without conflict, the user pays only the normal fee, and the collateral is refunded. If the transaction ends up being part of a conflict—say, multiple nodes include different versions of a transaction spending the same UTxO—then one transaction is finalized, and the others are discarded. The forfeited collateral from the discarded transactions is used to compensate for the computation and bandwidth consumed, and this discourages malicious duplication. A particularly novel twist in this model is the idea that the finalized transaction, not the rejected ones, could bear the collateral cost. In this approach, the user whose transaction succeeds in altering the ledger pays a slightly higher fee, which offsets the cost of filtering the redundant or conflicting transactions. This challenges traditional assumptions around determinism, but it also aligns incentives fairly: the party who benefits economically from the transaction is the one who pays slightly more, and users still only pay if they receive the intended service. From a user experience perspective, this introduces a third outcome beyond “included” and “not included.” Now, a transaction might be included, but with an elevated fee, depending on whether it was entangled in a conflict. The feasibility of this approach depends largely on the size of the collateral relative to throughput. If a conflict costs the user an additional 0.8 ADA on top of a 0.2 ADA fee, that’s acceptable in most scenarios, particularly if the transaction has economic urgency. But if the collateral had to be 5 or 10 ADA—due to excessive concurrent block production—that would quickly become impractical. At very high throughput levels—say, thousands of transactions per second—this model may no longer scale well, and more complex solutions such as sharding or ledger restructuring could be needed. But in the short term, collateralization presents an elegant and user-aligned compromise that balances fairness, efficiency, and simplicity. It allows the network to scale by an order of magnitude while maintaining predictable user behavior and avoiding massive changes to the Cardano ecosystem. Conclusion The Leios team is still carefully assessing various strategies through simulations and community feedback. While no final choice has been made yet, a decision can’t be postponed forever—Cardano urgently needs higher throughput. It’s time to identify the most effective path forward and move ahead with implementation. Addressing the challenges above will likely require modifying key aspects of the protocol. DReps may eventually be asked to help decide which direction to take. To make the right call, they’ll need a solid understanding of the topic so that decisions are guided by practical reasoning, not ideology.
