Achieving high throughput in a blockchain protocol like Ouroboros Leios often comes with trade-offs, including a degree of inefficiency. One of the key compromises involves softening strict determinism—the guarantee that a valid transaction, once submitted, will always be included in the same way by every honest node. In Leios, the introduction of pipelining and parallel block production enables much greater scalability, but it also means that transactions can be speculatively included in different Input Blocks before a global consensus view is established. This increases the likelihood of duplicate transactions and conflicting submissions, especially when transactions are submitted concurrently or under network latency. In this article, we explore why these issues arise in Leios and how they reflect the broader challenge of balancing performance with predictability in a highly concurrent blockchain system. Before you read on, make sure you understand pipelining, which we described in the previous article. Data Availability Data availability refers to the guarantee that all relevant transaction and block data are accessible to all validators and participants in a timely manner so they can verify, endorse, and finalize blocks. In a distributed blockchain network, new blocks are created by nodes operating in different geographical locations. With the introduction of parallel block production—as in Leios—blocks are produced more frequently and by multiple nodes at the same time. This naturally increases the demand on network bandwidth and puts greater pressure on timely data propagation. A node cannot validate or respond to information it has not yet received. While it can speculate or assume that certain data—such as a transaction or Input Block—exists somewhere in the network, it cannot act on that data until it actually arrives or is at least referenced in a way it can verify. This inherent limitation of asynchronous communication means that even honest nodes may unintentionally produce conflicting or duplicate blocks simply because they lack knowledge of what others were building at the same time. This delay in visibility is one of the central challenges that Leios must address while increasing throughput without sacrificing consensus integrity. In traditional blockchains like Ouroboros Praos, data availability is relatively manageable. Blocks are produced sequentially, and there's ample time for the block to be fully propagated across the network before the next one is created. This slower pace inherently gives nodes enough time to synchronize and ensures each block is available to all validators before new decisions are made. However, Leios changes this dynamic fundamentally. With pipelining and parallel block production, multiple blocks can be minted concurrently by different nodes. The network does not pause to wait for full propagation before new blocks are created. Transactions can be included speculatively, without global awareness of what other blocks already contain. It is the reason why a block producer builds an Input Block based on an outdated or incomplete view of the network. For example, a node may: Missed a recently produced Input Block from another peer due to latency. Not realize that a transaction has already been included elsewhere. Endorse or finalize data that was not fully visible at the time of decision-making. These issues directly relate to the data availability problem—as throughput increases and block production accelerates, it becomes harder for every node to maintain a complete and up-to-date picture of the blockchain’s state in real time. The figure shows the following scenario: Bob received Input Block 1 produced by Alice in time, so the duplicate transactions were removed from the mempool. Thus, Input Block 2 does not contain duplicates. Similarly, Carol received Input Blocks 1 and 2 in time, so Input Block 3 does not contain duplicates either. Dave's node is geographically distant from the others, so he did not receive any Input Blocks. Therefore, he produced Input Block 4, which contains many duplicate transactions. Duplicate Transactions Leios enables multiple blocks and transactions to be processed in parallel, which significantly increases the number of transactions the network can handle, but also increases the risk of duplication and conflict. Several blocks may be constructed nearly simultaneously, each potentially containing overlapping or conflicting transactions. This makes strict determinism—the guarantee that a valid transaction will always be included—much harder to preserve. High throughput and strict determinism are in fundamental tension: concurrency requires parallelism, while determinism demands serialized, isolated execution. 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. During the construction of a new Input Block, nodes validate new transactions against the latest known Ranking Block, not against the latest Input Blocks. Thus, a transaction is likely to be included in multiple blocks before the gossip protocol can let all nodes in the network know that the transaction has already been included in a new 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 nodes. 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. 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. Input Blocks can be minted so frequently and independently that block producers may not receive the most recently minted Input Blocks in time. As a result, they typically follow a simple strategy: select transactions from their local mempool—prioritizing older ones first—and include them in the next Input Block. Because data propagation in the network takes time, newly minted Input Blocks may not have reached all nodes before a new one is created. Block producers validate transactions locally against the latest finalized Ranking Block and may also consider transactions from Input Blocks they’ve already seen to reduce the risk of including duplicates. Still, 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. Hypothetically, if all Input Blocks arrived at all block producers on time, they would be able to adjust their mempools and build Input Blocks without duplications and conflicts. In reality, a mix of both edge cases is likely to occur. Due to network conditions, some operators may receive all or some of the latest Input Blocks on time, while others may not. This largely depends on factors like geographic proximity and network infrastructure. For example, if two block producers are located close to one another or operate within the same data center, blocks can be exchanged quickly with minimal latency. A single producer might even generate several Input Blocks in succession. On the other hand, if block producers are spread across different regions, network delays increase. This can lead to longer intervals between Input Block propagation, making synchronization across the network less consistent. Resolving these duplicates consumes computational resources and bandwidth, a cost that grows with system throughput. Since new Input Blocks are produced frequently without efficient propagation, many will contain overlapping content, leading to wasted effort. Ideally, faster propagation of both new transactions and recently minted Input Blocks would give nodes a more accurate picture of the network’s current state, reducing the likelihood of duplication. However, achieving this level of rapid dissemination is a bandwidth-intensive challenge. 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 Are Rare for Ordinary Users Conflicts are unlikely to occur in typical user scenarios. If an ordinary user submits a single transaction that spends a unique UTxO, the chances of conflict are minimal. The UTxO model inherently provides transaction isolation, meaning as long as users don't reuse the same inputs in multiple transactions, conflicts won’t arise. Submitting one transaction at a time, as most wallets do, is generally safe and deterministic. Conflicts Are More Likely with Poorly Synchronized dApps Conflicts become more likely when dApps or wallets create multiple transactions simultaneously using the same UTxO as input. This issue is known today, but becomes more pronounced in Leios, which allows speculative inclusion of transactions. 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. Because Input Blocks are produced at a high rate, there's a strong chance a transaction will be included in a block before the gossip protocol has time to alert other nodes about a conflicting transaction. For example, 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. This means dApps and wallet developers will need to be more careful with UTxO management and transaction concurrency under Leios. 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. These conflicting transactions may be accepted into multiple Input Blocks before the conflict is noticed. Conflicting transactions—whether caused by chance (the synchronization issues between batchers) or honest mistakes—can also be deliberately exploited. 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. Duplications and Transaction Conflicts Are Two Different Challenges Conflicts must be resolved. A UTxO can only be spent once. Conflict is a consensus problem and represents a correctness issue. Thus, it must be resolved for ledger consistency. Only one transaction can win; others must be excluded to preserve the single-source-of-truth model. So, if two different transactions attempt to spend the same UTxO, only one can be valid. The other is invalid and must be rejected. In contracts, duplication is inefficient, but not invalid. The same transaction can be included in multiple blocks or pipelines—it doesn't violate any rules, since it's not double-spending. It creates redundancy, wastes space and compute, and complicates rewards, but it's not a consensus failure. Theoretically, duplicate blocks (with overlapping TXs) could be accepted as long as the transaction isn't executed multiple times. Duplications are harmless to consensus but harmful to performance and scalability. Conflicts represent an attempt to double-spend, i.e., they violate the rules of the blockchain. Ouroboros Leios must be designed to tackle both challenges. Users Experience Non-Determinism Now, let’s consider the typical user experience. If a user submits a single transaction that spends a unique UTxO (one that hasn’t been spent elsewhere) and the transaction passes local validation, then under normal conditions, that transaction is very likely to be included and finalized successfully. There’s no inherent conflict in such a case. And since no other transaction attempts to spend the same UTxO, there’s nothing to “win” or “lose” in a conflict resolution scenario. However, even in this clean scenario, the transaction could still be subject to non-deterministic finalization behavior — not because it’s invalid, but because of how it enters the network. For example, the transaction may be picked up by multiple block producers and included in several Input Blocks simultaneously. Since Input Blocks are created in parallel, and not all validators see the same mempool at the same moment, the same transaction can be duplicated across blocks. During the endorsement and validation phase, only one instance of the transaction will be finalized. The others will be rejected as duplicates. In this case, the transaction still succeeds, but users might notice small delays or that it appears in a different block than expected. In other scenarios, the user's wallet or dApp might unintentionally submit the same transaction more than once, either through a network retry, a user double-clicking "Send," or faulty dApp logic. If these submissions are treated as distinct transactions, the network may interpret them as conflicting, especially if they attempt to spend the same UTxO. In this case, the system will finalize only one. While this may not result in user-facing errors, it introduces uncertainty about which version of the transaction will succeed. With Leios, the transaction could also be included in an Input Block alongside other conflicting transactions (submitted by unrelated parties, in our example, it is TX 3). If the block as a whole ends up being partially rejected or reordered, even valid non-conflicting transactions (TX 1) may be temporarily delayed. Although Leios is designed to resolve such cases efficiently — filtering transactions individually rather than discarding whole blocks — the timing and path to finalization may still feel less predictable than in the Praos model. Due to the network's pipelined nature, data propagation delays can also play a role. A transaction submitted to one node may take a few slots to reach others, and during that time, other transactions might change the UTxO state. This isn't common, but it adds to the spectrum of situations where a valid transaction might not be finalized immediately, or might require resubmission. Situations where two batchers try to spend the same UTxO (or the attacker is trying to double-spend) can happen in both Praos and Leios. However, Leios must handle these cases very differently. With Leios, it is much more likely for conflicting transactions to be included in different Input Blocks. As a result, resolving these conflicts becomes more complex and requires additional coordination later in the pipeline. This will be discussed in more detail in the next section. While a single, valid transaction from a typical user is very likely to succeed in Leios, the protocol’s shift toward concurrency introduces some degree of uncertainty. Non-determinism is usually not necessarily the result of errors or invalidity, but of timing, duplication, or asynchronous state views. 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, it's entirely possible for three different Input Blocks to 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. The obvious first idea might be to discard any Input Block containing conflicting transactions and reintroduce the remaining valid ones into the mempool for later inclusion. However, this approach opens the door to a serious exploit. An attacker could submit a single conflicting transaction per pipeline to intentionally trigger this behavior. Because all “invalid” Input Blocks are discarded, the valid transactions they contained must be retried in the next round. Repeating this tactic cheaply and repeatedly could delay valid transactions indefinitely and reduce throughput to Praos-like levels—a classic denial-of-service attack, now with minimal cost to the attacker. 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. 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. Conclusion The Leios research team is navigating a number of complex trade-offs as they work to scale Cardano’s throughput while preserving its core principles. One of the most significant challenges lies in softening certain user-facing guarantees that the community values—particularly transaction inclusion determinism and fee determinism. In a traditional setup, if a user submits a valid transaction, it is either included or rejected in a predictable, binary way, and the transaction fee is known in advance. But under Leios, this predictability becomes harder to guarantee. To manage potential abuse, such as spam attacks that flood the network with duplicates, one proposed mitigation strategy involves collateralization. In this model, a small amount of collateral—for example, 0.05 ADA—would be attached to each transaction in addition to the regular fee (e.g., 0.17 ADA). If the transaction appears in multiple Input Blocks, a portion of the collateral could be forfeited to discourage duplication. However, if the transaction appears in only one Input Block and is finalized cleanly, the collateral would be refunded in full. While effective at deterring attackers, this approach introduces uncertainty for honest users. They would no longer be able to predict their exact transaction cost ahead of time, as it would depend on how widely their transaction is duplicated before finalization. This marks a soft violation of fee determinism, even though the user would still only pay extra in rare edge cases. It’s important to note that this is just one proposed mechanism among several under consideration. The Leios team has not committed to using it. Rather, it illustrates a broader point: achieving high throughput and scalability in a decentralized setting will require carefully weighed compromises. Balancing efficiency, fairness, and user experience is a delicate process, and many of the solutions being explored are still undergoing active research, modeling, and debate.
