Cardano’s Leios Scaling Push Raises the Bar for Midnight’s Private-Transaction Performance

Cardano’s work on Leios is intended to increase transaction capacity and reduce confirmation delays through a more parallelized approach to processing blocks and transactions. Midnight, the privacy-focused network being developed within the broader Cardano ecosystem, is pursuing a different objective: enabling applications to use programmable confidentiality while preserving the benefits of decentralized verification.

The two projects are not the same network, and Leios is not a direct scaling upgrade for Midnight. Yet their development is increasingly connected through user expectations, developer choices and the practical demands of operating blockchain applications. If Cardano becomes faster and more predictable, Midnight will face pressure to deliver private transactions that feel similarly responsive, even though privacy-preserving computation can require more complex proving, verification and state management.

The central question is therefore not whether Midnight can produce a high theoretical transaction-per-second figure. It is whether the network can make privacy affordable, reliable and easy to use under realistic conditions.

That test will involve more than cryptography. Midnight will need to demonstrate acceptable proof-generation times, efficient verification, predictable fees, manageable storage requirements, useful interoperability with Cardano and other networks, and tooling that allows developers to build applications without exposing sensitive information by default.

Leios may raise the performance standard across the ecosystem. Midnight’s success will depend on whether it can meet that standard without compromising the confidentiality and selective disclosure features that distinguish it from a conventional transparent blockchain.

Leios and the changing Cardano performance standard

Cardano’s scaling research has focused on improving the way its network handles transactions, block production and communication between nodes. Leios is generally described as a protocol direction that would introduce more parallelism into the production and processing of blocks and transactions.

Traditional blockchain designs often organize transaction processing around a sequential chain of blocks. A block is produced, propagated, validated and added to the ledger before the network proceeds to the next stage. This structure provides a clear ordering of transactions, but it can also limit how much work the network performs at the same time.

Leios explores a more differentiated structure in which transactions and related block data can be handled with greater parallelism. The design is intended to improve throughput while maintaining the ordering and security properties required by the ledger. It also aims to reduce the time users must wait before transactions are sufficiently confirmed for practical use.

The important qualification is that Leios remains a development and implementation effort rather than a simple switch that can be treated as an already delivered production capability. Research results, engineering milestones, testnet performance and eventual mainnet behavior are separate categories. A design can be technically promising without yet providing a production benchmark for ordinary users.

That distinction matters when comparing Cardano with Midnight. Cardano’s current production network should not be described as if it already operates with the full capabilities envisioned for Leios. Likewise, Midnight’s announced architecture and roadmap should not be treated as proof of final network performance.

Nevertheless, development work on Leios can influence the expectations of Cardano users and developers before every planned feature reaches production. The ecosystem is likely to judge future applications against a broader standard of responsiveness. Wallet users may expect transactions to be confirmed quickly, application developers may assume that public settlement can handle periods of demand, and businesses may look for operating costs that remain understandable during network congestion.

Midnight will enter that environment with an additional responsibility. It must handle private or selectively disclosed information while competing for applications that may also be able to use transparent infrastructure. A private transaction that takes significantly longer to prepare, costs substantially more or fails more often than a conventional transaction may be difficult to adopt, even when its privacy benefits are important.

Why privacy changes the performance equation

A transparent blockchain generally exposes enough transaction information for network participants to validate the transaction directly. The ledger may show the sender, recipient, asset, amount, contract call or other public details, depending on the network and application.

A privacy-preserving system attempts to limit what is exposed while still allowing the network to verify that a transaction is valid. This commonly requires cryptographic proofs or related mechanisms. A user, wallet or application generates evidence that a transaction follows the rules without revealing all of the underlying data.

That process can introduce several layers of computational work.

The user or application may need to create a proof. The proof may need to encode facts about balances, permissions, contract states or application-specific conditions. The network must then verify the proof and update the relevant state without learning information that the privacy model is designed to conceal.

The exact costs depend on the protocol, the proving system, the application and the hardware involved. A simple private transfer may have very different requirements from a confidential lending transaction involving several assets, collateral conditions and external data. As a result, a single throughput figure can be misleading.

A network may report a high number of simple transactions per second while handling complex private applications much more slowly. Conversely, a system may process fewer transactions by count but support more useful computation per transaction. Meaningful comparisons must state what is being measured.

Midnight’s performance challenge is therefore multidimensional. It must provide sufficient capacity for private transactions, but it must also ensure that users can create those transactions without unreasonable delay. Validators and other infrastructure providers must be able to verify them efficiently. Applications must be able to manage private state without creating unsustainable storage requirements. Fees must remain predictable enough for users and businesses to plan around them.

Privacy is practical only when all of these components work together.

Proof-generation overhead is a user-experience issue

The first performance question is often overlooked because it happens before a transaction reaches the network: how long does it take to generate the proof?

In a public transaction, a wallet typically assembles the transaction, signs it and submits it. A private transaction may require the wallet or an application back end to perform substantially more work before submission. The device may need to calculate a proof based on private inputs, application rules and the current state of the network.

If proof generation takes only a short time on an ordinary phone or laptop, users may not notice the difference. If it takes several minutes, requires substantial memory or depends on a remote service, the experience changes. A wallet may display a loading screen, request additional infrastructure or transfer sensitive information to a third party.

This creates a trade-off between convenience and decentralization. Proving locally can provide stronger control over private data, but it may be difficult for lower-powered devices. Outsourcing proving to a specialized provider may improve speed, but it can introduce operational concentration, availability concerns and questions about what information the provider can observe.

The technical answer may involve a combination of local and remote proving, application-specific optimization, hardware acceleration or precomputed information. Each approach has advantages and limitations. A system that performs well in a controlled laboratory environment may produce different results when thousands of users attempt to generate proofs at the same time.

Midnight will need to show how proof generation works across common user environments. Relevant measurements would include the time required on consumer laptops, mobile devices and typical application servers; memory and processor requirements; the effect of transaction complexity; and the behavior of the system when demand increases.

The network’s design may also determine whether proof generation is primarily a user-side responsibility or whether application providers are expected to assist. That distinction should be clear to developers building wallets, exchanges, decentralized applications and enterprise systems.

A private network that requires every user to understand cryptographic proving is unlikely to reach a broad audience. The technical complexity must be absorbed by wallets and applications. Users should be able to select privacy options, manage keys and approve transactions without needing to understand the underlying proof system.

Verification costs can create a different bottleneck

Proof generation affects the user or application submitting a transaction. Verification affects the network.

A central benefit of zero-knowledge systems is that a proof can be much cheaper to verify than to create. That asymmetry allows a user to perform complex computation once while validators or nodes check a compact result. However, “cheaper to verify” does not mean “free to verify.”

If a network receives a large volume of private transactions, validators must still process the proofs, check signatures and update the ledger. The verification workload must be sufficiently predictable to prevent a flood of complex transactions from delaying block production or increasing hardware requirements.

The problem can become more complicated when transactions involve private state. A validator may not see the underlying values, but it still needs to confirm that the state transition is valid and that the transaction does not spend the same private asset twice or violate application rules. The protocol must preserve privacy while preventing invalid or conflicting updates.

Verification costs also influence decentralization. If running a node requires specialized hardware, high memory capacity or unusually fast processors, fewer independent participants may be able to operate infrastructure. That could increase reliance on larger operators, even if the network remains formally decentralized.

This does not mean that specialized infrastructure is automatically unacceptable. Many blockchain networks already use substantial hardware. The relevant questions are whether requirements are transparent, whether they rise over time, whether ordinary operators can participate, and whether the network has mechanisms to prevent a small number of providers from controlling critical services.

Midnight’s technical documentation and future test results will need to identify the resources required for different workloads. Useful metrics would include CPU time per proof, memory consumption, verification time, block-processing time and the number of concurrent transactions that can be handled before latency increases materially.

Finality and latency involve more than block time

Users often interpret blockchain speed through a simple question: how long until the transaction is complete?

For a private transaction, the answer may include several stages. The user must construct the transaction, generate a proof, submit it to the network, wait for inclusion, allow validators to verify it and then wait for a level of finality appropriate to the application.

A network can have a short block interval but still provide a slow end-to-end experience if proof generation takes too long. It can also accept transactions quickly but impose delays before an application considers them final. The relevant measurement is not only the time between blocks. It is the time from the user’s decision to transact until the application can safely act on the result.

This distinction is particularly important for exchanges, payment systems, games and applications that require several transactions in sequence. If each transaction must wait for a proof and confirmation, small delays can accumulate. Developers may attempt to reduce the problem with batching, precomputation or application-side coordination, but those solutions can introduce additional complexity.

Cardano’s scaling ambitions place more attention on confirmation responsiveness across the ecosystem. As public transactions become faster or more predictable, users may judge private systems by the same standard. Midnight may not need to match every Cardano workload exactly, but it will need to explain where private execution introduces additional latency and whether that cost is acceptable for specific use cases.

Different privacy levels may also create different performance profiles. An application that hides only selected values may be able to operate more quickly than one that keeps extensive contract state private. A useful network benchmark should therefore report results by transaction type rather than presenting a single average.

Fee predictability will determine whether privacy is affordable

Users can tolerate a fee when they understand what they are paying and receive clear value in return. They are less likely to adopt a system if the price of a transaction changes unpredictably or if a private action is routinely too expensive for its intended purpose.

Privacy-related computation can affect fees in several ways. Larger transactions may consume more space. More complex proofs may require more processing. Encrypted state may increase storage or execution costs. During periods of demand, users may compete for limited proving or verification capacity.

The result could be a fee market that differs from the one used for transparent transactions. Midnight may need to account for proof complexity, transaction size, execution resources and state growth. A simple transfer and a complex confidential application call should not necessarily consume the same amount of network resources.

A detailed resource model can improve fairness and predictability, but it can also make fees harder for users to understand. Wallets will need to estimate costs before submission and explain why a transaction is more expensive. Developers will need tools that allow them to forecast costs under different application workloads.

Enterprises may be especially sensitive to this issue. A company using a confidential blockchain for payroll, supply-chain records or financial settlement may accept a higher cost for privacy, but it will still need reliable operating budgets. Sudden fee spikes can make an application unsuitable for routine business use.

Cardano’s scaling progress could indirectly improve the environment for Midnight if it provides a more stable public settlement layer and greater liquidity. But greater capacity on Cardano does not automatically reduce Midnight’s own proving or verification costs. The private network will require independent evidence that its fee model remains sustainable under demand.

State growth and storage are long-term tests

Transaction throughput is often measured over seconds or minutes. State growth is measured over months and years.

Private applications can create storage challenges because the network may need to maintain commitments, encrypted records, nullifiers, proofs or other data structures associated with hidden state. The exact design determines what nodes must retain, what can be pruned and what information must remain available for future verification.

A system that processes transactions quickly but causes storage requirements to grow too rapidly may become difficult to operate over time. This is a particular concern for decentralized applications with persistent private records. Financial contracts, identity systems and enterprise workflows may generate data that cannot simply be discarded after a transaction is finalized.

Midnight will need to clarify how private state is represented, how nodes synchronize it and whether historical information can be compressed or pruned without weakening security or user access. Developers will also need guidance on designing applications that limit unnecessary state growth.

The issue affects users as well. If a wallet must retain large amounts of private data to generate future proofs, device storage and backup procedures become important. Losing private data may not be equivalent to losing a public transaction history. Users could need recovery mechanisms that preserve confidentiality while allowing them to reconstruct their application state.

These operational details are less visible than a headline throughput figure, but they can determine whether a privacy network remains accessible to independent node operators and ordinary users.

Composability will define Midnight’s role in the ecosystem

Midnight is not being developed in isolation from Cardano. Its potential value includes the ability to support private logic alongside public assets, settlement and identity information. That makes communication between the two environments a central design and adoption question.

Developers may want to issue or hold public assets on Cardano while using Midnight to manage confidential transactions. A business could publish a verifiable commitment or settlement record on a transparent chain while keeping customer details, prices or internal conditions private. A decentralized application might use public data for one part of its operation and protected data for another.

This model depends on reliable interoperability. Assets and messages must move between systems without creating gaps in security or privacy. Users need to understand what information becomes public when an asset crosses a boundary. Applications must be able to verify that a private event occurred without exposing all of the data behind it.

Composability can also affect performance. Cross-network calls may add latency, require additional proofs or depend on relayers and other infrastructure. If an application has to wait for several separate confirmations, the user experience may be much slower than a single-network transaction.

Selective disclosure is particularly important. Privacy does not necessarily mean that information remains hidden from every party forever. A user may need to prove eligibility, demonstrate ownership, satisfy an auditor or provide records to a regulated institution. The challenge is to reveal the required information without exposing unrelated transactions or balances.

For Midnight to serve businesses and financial applications, its disclosure model must be understandable and practical. Developers need standard methods for sharing proofs or credentials with authorized parties. Users need clear controls over which information is disclosed, to whom and for how long.

Developer tooling may matter as much as cryptography

A strong privacy protocol can still struggle if developers cannot use it efficiently.

Confidential applications are more difficult to build and test because developers must reason about hidden data, access permissions, proof generation, key management and the interaction between public and private state. Conventional debugging methods may not work when the most important values are deliberately concealed.

Midnight’s adoption will therefore depend on programming languages, software development kits, documentation, local testing environments, wallets, libraries and deployment tools. Developers need to be able to reproduce transactions, inspect failures without exposing secrets and estimate resource costs before launching an application.

The quality of these tools will influence which applications appear first. If the development process is too specialized, privacy may remain limited to teams with cryptographic expertise. If the tooling abstracts away the hardest elements while preserving security, a wider group of developers may experiment with confidential finance, identity, gaming, commerce and data-sharing applications.

Interoperability libraries will be equally important. Developers may not want to choose between a fully public Cardano application and a fully private Midnight application. They may want to combine both. That requires standard interfaces, clear transaction formats and reliable methods for communicating state between the networks.

The ecosystem should also publish realistic examples rather than relying only on architectural descriptions. A developer evaluating Midnight needs to know how long a typical transaction takes, what a failed proof looks like, how keys are recovered, how fees are calculated and what happens when the network is congested.

What Leios can and cannot do for Midnight

Leios could strengthen the broader Cardano ecosystem in several ways. Higher public capacity may improve liquidity, reduce settlement friction and make it easier for applications to use Cardano as a transparent base layer. Faster confirmation could also make cross-network interactions less burdensome when applications use both Cardano and Midnight.

A more efficient Cardano network may provide public infrastructure for token issuance, identity anchors, collateral records or transparent settlement. Midnight could then handle confidential business logic, private user activity or selective disclosure. In that arrangement, the two networks would complement each other rather than compete directly.

But Leios cannot eliminate the computational costs of privacy. Faster public block processing does not automatically make zero-knowledge proofs quicker to generate. It does not reduce the memory required to manage encrypted state, and it does not guarantee that Midnight’s validators can process complex private transactions at the same rate as public ones.

Nor does a high-throughput settlement layer solve every interoperability problem. Cross-chain communication still requires secure protocols, clear finality assumptions and careful treatment of privacy boundaries. A faster public chain may even increase pressure on Midnight if users expect private components to keep pace with the rest of the ecosystem.

Midnight must therefore publish its own evidence. Important benchmarks should include sustained throughput rather than short bursts, proof-generation time, verification time, transaction cost, failure rates, node-resource consumption and performance under mixed workloads. Test results should specify hardware, network conditions, transaction complexity and whether the measurements come from a testnet, a controlled experiment or a production environment.

Without that context, scalability claims are difficult to compare. A figure based on simple transfers may not represent the performance of a private lending market or an application with large encrypted state. Benchmarking should also show how performance changes as the number of users, contracts and stored records increases.

Adoption will depend on more than privacy guarantees

Privacy has clear potential value for individuals, companies and financial institutions. Users may not want their balances, purchases or interactions visible to everyone. Businesses may need to protect pricing, customer information, payroll data or commercial relationships. Decentralized applications may require confidential bids, private voting, hidden game information or protected identity attributes.

Yet privacy alone may not determine platform choice. Developers also consider network reliability, fees, liquidity, tooling, available wallets, community support and the ease of integrating with existing systems.

Users are likely to compare a private transaction with a conventional digital payment, not with a theoretical cryptographic ideal. They may accept a short delay for a valuable privacy feature, but they may reject repeated proof failures, confusing key-management procedures or unpredictable costs.

Enterprises may have a different set of priorities. They may tolerate additional computation if the network provides strong access controls, audit capabilities, selective disclosure and predictable service levels. However, they will also examine infrastructure concentration, data recovery, legal obligations and the ability to integrate with existing databases and compliance systems.

This creates an opportunity for Midnight if it can present confidentiality as a practical infrastructure layer rather than a niche technical feature. The network does not need every transaction to be private. It needs to give applications a flexible way to protect information where transparency is inappropriate while retaining verifiable outcomes.

That flexibility may also help address regulatory concerns. Selective disclosure could allow a user to prove relevant facts to an authorized party without publishing a complete financial history. But the technical ability to disclose information selectively does not automatically resolve legal questions. Rules vary by jurisdiction, and institutions will need clarity about how cryptographic proofs fit into existing compliance and reporting frameworks.

Risks that could slow the performance race

The first risk is complexity. Privacy-preserving systems combine sophisticated cryptography, application logic, key management and network economics. More components can mean more opportunities for implementation errors, difficult upgrades or unclear failure modes. Security reviews and formal analysis will be important, but they cannot remove every operational challenge.

The second is centralization of proving. If proof generation is too demanding for ordinary devices, users may depend on a small number of specialized providers. Those providers could become important gateways for private activity. The network would need to consider availability, competition, privacy protections and incentives for distributed proving.

A third risk is privacy leakage through metadata. Encrypting transaction contents does not necessarily hide timing, transaction frequency, network addresses, application patterns or relationships between public and private events. Developers and users may need additional tools to reduce the information revealed by usage patterns.

Interoperability is another unresolved area. Privacy protections can complicate asset transfers, cross-chain messages and smart-contract calls. A bridge or messaging system may need to expose information that would remain hidden inside Midnight. The security model must account for these transitions rather than treating the networks as isolated environments.

Economic sustainability also matters. Fees must compensate validators, proof providers and other infrastructure operators without making private applications too expensive. If subsidies are used during early development, users and developers will eventually need to understand how the system operates once those subsidies decline.

Finally, benchmarking itself can create confusion. A network’s reported throughput may depend on hardware, transaction type, proof size, block limits and network conditions. Comparisons are useful only when those assumptions are disclosed. Independent testing will be particularly valuable because architecture documents and promotional materials cannot substitute for production evidence.

The benchmarks that will matter

As Midnight develops, several measurements should receive close attention.

Proof-generation latency should be reported for ordinary consumer devices as well as professional servers. Results should distinguish simple transfers from more complex contract interactions and should show memory use, processor requirements and the effect of concurrent proving.

Verification performance should measure how many private transactions a validator can process while maintaining stable block production. It should also report the hardware needed to participate and how the system behaves when transaction complexity varies.

End-to-end latency should begin when a user authorizes a transaction and end when the application considers it final. This would capture proof generation, submission, inclusion and confirmation instead of focusing only on block intervals.

Fee studies should show how costs change with transaction complexity and demand. Users need to know whether fees remain predictable during congestion and whether wallets can provide accurate estimates before a transaction is submitted.

State-growth measurements should track storage requirements over time, including the data needed by full nodes, light clients and wallets. The results should explain pruning, recovery and synchronization procedures.

Interoperability tests should measure the time and cost of moving assets or messages between Midnight, Cardano and other networks. They should also identify what information becomes visible during those operations.

Finally, reliability statistics should include failed proof attempts, rejected transactions, outages and recovery times. A private application that is fast when it works but difficult to recover when something fails may not be suitable for high-value use.

These figures should be published with enough information for independent researchers to reproduce or challenge them. Testnet performance is valuable, but it should not be presented as a guarantee of mainnet behavior.

A competition between design goals

Cardano’s Leios initiative raises the bar for what users and developers may expect from blockchain infrastructure. Its focus on greater parallelism, higher capacity and more responsive transaction processing could improve the environment for applications that combine transparent and private components.

Midnight, however, is not engaged in a simple race to match Cardano transaction for transaction. Its purpose is different. It must protect information, support programmable privacy and provide users with mechanisms for selective disclosure. Those features bring costs that a transparent execution environment may not face.

The relevant comparison is therefore not raw transactions per second. It is whether each network performs its intended role effectively.

For Midnight, that means proving and verifying private transactions quickly enough for practical applications, maintaining stable and understandable fees, controlling state growth, supporting composable contracts and enabling secure interaction with Cardano and other networks. It also means making cryptographic complexity invisible to ordinary users wherever possible.

If the network requires specialized infrastructure for every private transaction, has unpredictable fees or makes application development excessively difficult, its privacy benefits may not be enough to attract users. If it can provide confidentiality with reliable performance and clear disclosure controls, it could help move privacy from a specialized feature into a standard layer of blockchain infrastructure.

Leios may create the ecosystem conditions for that transition by making public Cardano activity faster and more scalable. But Midnight will have to prove its own performance rather than inherit it from Cardano’s progress.

The decisive question is whether privacy can scale economically and predictably. That will depend on real measurements: the time needed to create proofs, the cost of verifying them, the behavior of the network under sustained demand, the resources required to operate infrastructure and the ease with which users and developers can combine private and public blockchain functions.

Cardano’s scaling ambitions establish a useful benchmark. Midnight’s challenge is to meet that benchmark without giving up the confidentiality that defines its purpose.