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

Cardano’s proposed Leios architecture and input endorsers are intended to increase the network’s transaction capacity without abandoning the security and decentralization principles of its proof-of-stake design. If implemented successfully, the approach could give Cardano more room to support high-demand applications, lower settlement costs and reduce delays during periods of congestion.

That development would matter beyond Cardano’s public ledger. Midnight, the privacy-focused blockchain ecosystem associated with Cardano, is designed for applications that need to protect sensitive information while still using verifiable blockchain infrastructure. Its potential use cases include private identity, confidential finance, business data sharing, regulated applications and selective disclosure.

A faster Cardano settlement layer could make those applications easier to operate. It could also expose weaknesses that higher public-chain throughput cannot solve. Privacy-preserving applications must handle proof generation, encrypted state, data availability, cross-chain messaging and key management. Those processes may remain the main source of delay even if Cardano can process substantially more public transactions.

The result is a two-sided scaling challenge. Cardano must increase throughput while maintaining consensus security and broad participation. Midnight must make private computation and interoperability responsive enough for ordinary users and demanding enterprise applications. The relevant benchmark is therefore not simply transactions per second. It is the time, cost and reliability of the complete journey from a user’s private action to a verified and settled result.

What Leios and input endorsers are intended to solve

Cardano’s current architecture has to balance several competing demands. Blocks must be produced at regular intervals, transactions must be propagated across the network, nodes must validate the ledger, and stake pools must reach agreement on the chain’s history. Every increase in block size, transaction rate or computational workload can affect bandwidth, storage, validation time and the hardware required to participate.

That means the maximum number of transactions that could fit into an isolated block is not the same as the volume a decentralized network can sustain. A system may demonstrate a high theoretical capacity under laboratory conditions but perform differently when transactions arrive continuously, nodes operate with different resources and the network must recover from delays or competing block proposals.

Cardano’s research into Ouroboros Leios and input endorsers is aimed at this broader problem. The architecture is intended to separate the availability and propagation of transaction data from the production of blocks that advance the consensus chain. In simplified terms, transaction-bearing data can be handled through additional structures, while block production and consensus continue to follow the protocol’s security rules.

Input endorsers are a central part of that design. Rather than requiring every transaction to be bundled into the same type of block that determines the chain’s sequence, the proposed approach uses endorsement mechanisms to support the inclusion of transaction data between or alongside consensus blocks. This could allow more transactions to be processed in parallel and reduce the extent to which transaction inclusion is tied to a single block-production event.

The distinction matters because several performance measurements are often treated as if they were interchangeable.

Base-layer transaction throughput refers to how many valid transactions the ledger can process over a period of time. It depends on transaction size, script complexity, block capacity, node resources and network conditions.

Block production refers to the process through which stake pools create blocks and extend the chain. A network can produce blocks regularly without being able to include all the transactions waiting in its mempool.

Transaction endorsement concerns whether transaction data has been accepted and propagated in a way that allows it to be processed efficiently. In a design using input endorsers, endorsement can help separate data handling from the slower or more security-sensitive task of extending the canonical chain.

Confirmation latency measures how long users wait before a transaction is included or considered sufficiently secure. A higher throughput rate does not automatically mean instant confirmation.

Settlement finality concerns the point at which reversing or reorganizing a transaction becomes sufficiently unlikely according to the protocol and the application’s risk tolerance. Faster inclusion and stronger finality are related, but they are not identical.

Leios is therefore not simply a proposal to make blocks larger. Its purpose is to change how Cardano schedules, distributes and confirms transaction data. The design must still account for network bandwidth, computation, storage growth and the ability of independent stake pools to keep up.

Those constraints are important for decentralization. If higher throughput requires expensive hardware, high-bandwidth connections or large storage systems, fewer operators may be able to participate. That could improve raw performance while weakening the distribution of network control. Cardano’s research must therefore address not only the number of transactions that can be processed, but also the resources required from ordinary nodes and stake pools.

The eventual performance of Leios will depend on implementation details, parameter choices, testing and deployment decisions. Published research and simulations should not be treated as evidence that the complete system is already operating on the production network. Nor should theoretical throughput targets be presented as guaranteed real-world performance.

Actual results will depend on transaction composition. Simple transfers consume fewer resources than complex smart-contract operations. A network handling small, uniform transactions may achieve a different rate from one processing large scripts, high-volume state updates or transactions that require extensive validation.

The same caution applies to confirmation times. A protocol can increase the number of transactions it processes per second while leaving some users waiting for proof propagation, wallet updates, application-level confirmations or additional settlement guarantees.

Why a faster Cardano matters to Midnight

Midnight is positioned as a complementary environment for applications that need privacy-preserving computation and data sharing. A public blockchain exposes transaction information by design. That transparency is useful for auditability and open verification, but it is unsuitable for every financial, commercial or personal use case.

A private identity application, for example, may need to prove that a user satisfies an age, residency or accreditation requirement without revealing the user’s full identity document. A business application may need to confirm that a shipment, payment or compliance condition has been met without exposing commercially sensitive information to every participant. A healthcare workflow may need to coordinate permissions and attestations without publishing medical records.

Zero-knowledge techniques and related privacy mechanisms can allow a user to prove that a statement is true without revealing all of the underlying data. A blockchain can then record a commitment, proof or public result rather than the original private information.

This architecture creates additional work. A private transaction may require the user’s device or a separate service to assemble a witness from private data, generate a cryptographic proof, encrypt or commit to state, and then submit the result to the network. Nodes may verify the proof without seeing the private inputs, but verification still consumes computation.

Private applications can also maintain state differently from ordinary public applications. Users may hold encrypted records, credentials, notes or keys that are needed to create future transactions. The network may record commitments or encrypted outputs, while the information required to interpret or update that state remains unavailable to the public.

That creates a crucial distinction between different stages of a transaction:

1. Private execution: The application calculates what the user is attempting to do using sensitive inputs.
2. Proof generation: A wallet, device or proving service produces evidence that the action satisfies the relevant rules.
3. Proof verification: Network participants check the evidence without accessing the private inputs.
4. State recording: The system records commitments, encrypted outputs or other public information.
5. Cross-chain messaging: A message, proof or settlement instruction is sent to Cardano or another network.
6. Public settlement: The receiving network confirms the relevant event.
7. Application delivery: The wallet or application updates the user’s interface and makes the result available.

These stages can have different bottlenecks. A faster public chain improves only some of them.

If Cardano processes settlement transactions more quickly, Midnight applications could benefit from lower congestion and faster confirmation of messages that use both ecosystems. Public anchoring may become cheaper. Applications could also make more frequent use of Cardano for settlement, audit records or other public functions without competing as aggressively for block space.

However, Cardano’s capacity does not determine the speed of every private transaction. A user may still wait for a proof to be generated on a mobile phone. A proving service may become overloaded. A relayer may delay a message. A private-state provider may be unavailable. A wallet may require several network confirmations before displaying a final result.

Midnight could consequently have a high theoretical transaction capacity while delivering a slow user experience, or it could process fewer transactions but respond quickly for simple applications. End-to-end performance will depend on the complete system rather than the fastest individual layer.

The cost of privacy is measured in more than computation

Privacy systems are often described as adding “overhead,” but that term covers several different costs.

The first is proof generation. Creating a zero-knowledge proof can require significantly more computation than signing a conventional public transaction. The exact burden depends on the circuit, the amount of private state, the proving system and the hardware available to the user or service provider.

The second is proof verification. Verification is generally designed to be cheaper than generation, but it is not free. A network processing a large number of private transactions must allocate resources to checking proofs, rejecting invalid submissions and protecting itself from deliberately expensive or malformed inputs.

The third is state management. A privacy-preserving application may need to store encrypted data, commitments, nullifiers, authorization records or other structures that prevent double spending and unauthorized reuse. Those records may be smaller or larger than the data used by a public application, depending on the design.

The fourth is data availability. Nodes may not need to see the contents of private data, but users still need reliable access to the encrypted information and transaction-related data required to recover, update or spend private state.

The fifth is interoperability. A private transaction that interacts with Cardano may require messages, proofs, relayers or bridge components. Each additional component introduces processing requirements, fees and potential points of failure.

The cost to the user may therefore include:

• Hardware or cloud resources for proof generation
• Fees charged by the private network
• Cardano fees for public settlement
• Relayer or interoperability charges
• Encrypted data storage
• Data availability services
• Wallet and key-management infrastructure
• Enterprise integration and compliance costs

Lower Cardano fees would reduce one part of that equation, but they would not automatically make private applications inexpensive. A transaction can be cheap to settle publicly and still be costly to generate, store or relay.

This distinction will be particularly important for enterprises. A company evaluating confidential blockchain infrastructure is unlikely to measure success only by the fee attached to a Cardano transaction. It may also consider server capacity, service-level agreements, backup systems, key recovery, audit requirements, privacy leakage and the cost of integrating the application with existing databases and identity systems.

Predictable costs could be more important than the lowest possible fees. If proof generation becomes expensive during periods of demand, or if a required data service charges variable rates, developers may struggle to provide stable pricing to users.

How messages could move between Midnight and Cardano

The relationship between Midnight and Cardano depends on reliable interoperability rather than simple co-location. A private application may need to communicate an event to Cardano, use a Cardano-based asset or settlement process, or receive information from a public contract.

That communication can involve bridges, relayers, proofs and message queues. The exact design and implementation status of these mechanisms must be assessed using official Midnight and Cardano documentation rather than assumptions based on other blockchain systems.

A typical cross-chain workflow might look like this:

• A user creates a private action on Midnight.
• The action is proven and accepted by the private environment.
• The system creates a message or commitment describing the event.
• A relayer observes that event and submits relevant information to Cardano.
• Cardano validates the message according to its interoperability rules.
• The transaction is included and reaches the required confirmation threshold.
• Midnight or the application receives the settlement result.
• The user’s interface updates to show the completed operation.

Each step raises technical questions. How does the receiving chain know that the message originated from an authorized state transition? What prevents a message from being submitted twice? How are messages ordered if several events are created close together? What happens if the relayer is offline? Can another relayer submit the same message? How are conflicting or delayed messages handled?

Replay protection is especially important. A valid message from one point in the source chain’s history must not be reused to trigger the same action repeatedly. Bridges and relayers also need rules for chain reorganizations, invalid proofs, network pauses and upgrades.

Failure handling can have a direct effect on the user experience. If a private action succeeds but the Cardano settlement message is delayed, the application must decide whether to show the action as pending, completed or reversible. If Cardano confirms a message but Midnight cannot process the return communication, the two systems may temporarily display different states.

These problems are not unique to Midnight. They affect rollups, sidechains, application-specific networks and other systems that communicate across execution environments. The difference is that privacy can make troubleshooting more difficult. Operators may not be able to inspect the underlying transaction contents, and users may have limited visibility into which stage is delayed.

A faster Cardano layer can reduce settlement time, but it cannot eliminate message-ordering problems, relayer failures or incompatible state transitions. If the interoperability layer remains slow or fragile, it may become the dominant bottleneck.

The complete user journey is the real performance test

For a public cryptocurrency transfer, a user may think primarily about signing, broadcasting and waiting for confirmation. A private application adds more steps that may occur before and after the public-chain transaction.

Consider a private credential application. The user may select a credential, choose which attribute to disclose, generate a proof, submit it to Midnight, wait for verification, and then authorize a public settlement or access request. The public chain could confirm its part in seconds, but the user may still experience a delay if the proof takes too long to generate or if the wallet cannot retrieve encrypted state.

A confidential financial application may face an even more complex workflow. It could need to validate private balances, prove compliance conditions, update shielded state, send a settlement message and wait for confirmation from a public network. The user experiences the total time, not the isolated performance of Cardano or Midnight.

The end-to-end sequence can be summarized as follows:

This is why a headline throughput number can be misleading. A network may process a large number of simple public transactions while a privacy application remains constrained by proof latency. Conversely, an application may deliver a responsive experience if it uses efficient circuits, local caching, parallel proving and carefully designed settlement policies even when the underlying public chain is not operating at its maximum capacity.

Developers should therefore publish more than transactions-per-second figures. Useful benchmarks would include:

• Median and worst-case proof-generation time
• Proof-verification time per transaction
• Time from signing to private-network acceptance
• Time from private acceptance to Cardano settlement
• End-to-end confirmation latency
• Cost per private transaction under different demand levels
• Resource requirements for wallets and proving nodes
• Data-recovery time after a wallet or node failure
• Performance when cross-chain messages are delayed
• Throughput for realistic transaction mixes rather than identical test transactions

Such measurements would make it easier to compare Midnight with rollups, sidechains, application-specific chains and other privacy platforms.

Data availability remains a central privacy challenge

Confidentiality does not remove the need for reliable data access. In some ways, it makes availability more complicated.

Public blockchains allow anyone to inspect the ledger and reconstruct transaction history. A private system may distribute encrypted data, commitments and proofs without exposing the information required to interpret that data. The user, application or authorized service must still be able to retrieve the correct encrypted records when creating a future transaction.

If those records are lost, corrupted or unavailable, the blockchain may remain operational while the application becomes unusable. A user could be unable to prove ownership, update a credential or access funds even though the relevant commitments remain visible on-chain.

Midnight’s architecture and official documentation will need to clarify which information is stored on-chain, which information is held by users, and what infrastructure is responsible for distributing encrypted data. The design also needs to explain how users recover from device loss, key loss, service outages or changes in wallet software.

Data availability affects nodes as well. Validators must have enough information to determine whether a private transaction is valid, even if they do not see the underlying private content. If a proof refers to unavailable data, the system must define whether the transaction can be delayed, rejected or challenged.

There are also long-term storage considerations. Sustained demand can increase the volume of commitments, encrypted payloads, proofs and metadata that must be retained or distributed. The system may require pruning, archival services or specialized data providers. Each solution has implications for cost, reliability and decentralization.

A private application may therefore depend on several infrastructure layers:

• Wallets that store or access private keys
• Proving services or specialized hardware
• Nodes that verify proofs and process state
• Encrypted data stores
• Indexers that help applications find relevant records
• Relayers that deliver cross-chain messages
• Backup and recovery systems

A failure in any one of these services can affect the user even if the consensus layer has not failed. This is a broader definition of network reliability than block production alone.

Scaling brings security and decentralization trade-offs

Cardano’s Leios research must address the effect of higher throughput on node requirements and network coordination. More transaction data means more bandwidth. More complex transactions mean more computation. More historical state means more storage or more sophisticated pruning mechanisms.

Input endorsers could help distribute transaction data and reduce the pressure placed on ordinary consensus blocks, but the architecture still has to ensure that participants can obtain and validate the data needed to follow the chain. If only a small group of well-funded operators can keep up, the system may become more centralized even if its consensus rules remain formally unchanged.

The important question is not whether higher performance is possible under ideal conditions. It is whether the network can sustain that performance while preserving meaningful participation by independent operators.

Midnight faces different but related security questions. Zero-knowledge systems rely on cryptographic assumptions, carefully implemented circuits and secure key management. A flaw in a circuit or proving system could have consequences that are difficult to identify from public transaction data. Upgrades must be governed carefully, especially when applications depend on long-lived credentials, financial state or compliance records.

Privacy is also not absolute. A protocol may hide transaction contents while still exposing metadata such as timing, transaction frequency, fee patterns, public addresses or interactions with known services. Wallet behavior can leak information. Application interfaces can collect identifying data. Public settlement events can sometimes be correlated with private activity.

Privacy therefore depends on protocol design, implementation quality and user practices. It may also vary by application. A system that protects the contents of a transaction may not protect the fact that a user interacted with a particular public service at a particular time.

Denial-of-service risks require attention as well. If malicious users can submit proofs that are unusually expensive to verify, they may consume network resources without paying a cost proportional to the damage. Protocols may need limits on proof size, verification complexity and transaction frequency.

Relayers and bridges introduce another security boundary. If a relayer fails, the message may be delayed. If a bridge component is compromised, it could submit false information or censor valid messages, depending on the design. Multiple relayers, cryptographic proofs, challenge mechanisms and clear recovery procedures can reduce those risks, but they also add operational complexity.

Key recovery is another practical issue. Privacy systems can give users more control over sensitive data, but lost keys may make that data permanently inaccessible. Enterprise users may require recovery policies that do not undermine confidentiality. The system must balance recoverability with resistance to unauthorized access.

The economics of a combined public and private system

A faster Cardano network could improve Midnight’s commercial prospects by making public settlement more affordable and predictable. Reduced congestion could also help applications that use Cardano for public assets, final records, identity anchors or settlement instructions.

But the economic model must account for all the components involved. A business cannot evaluate a private application by looking only at Cardano’s base-layer fee.

A realistic cost model may include the private transaction fee, proof-generation resources, encrypted storage, data availability, relaying, public settlement, wallet infrastructure and compliance operations. In some cases, proof generation may be performed by the user’s device. In others, a cloud provider or specialized service may carry the cost.

That distinction could influence adoption. Consumer applications may need lightweight proving that works on ordinary phones and laptops. Enterprise applications may accept cloud-based proving but demand predictable service levels and strong confidentiality guarantees. Developers may also need to decide whether users pay directly or whether the application absorbs infrastructure costs.

Fees can also affect privacy. If users are encouraged to reuse addresses or combine several actions to reduce costs, transaction patterns may become easier to analyze. If applications route activity through common service providers, those providers may become important sources of metadata.

Cardano scaling could reduce the cost of public anchoring, but it may also encourage more applications to use that capacity. Demand can rise to fill available block space. If the private ecosystem grows quickly, proof services, data providers and relayers could become congested even while Cardano remains underused.

Predictable economics will therefore require capacity planning across both networks. Developers should test not only average demand but also bursts caused by market events, application launches, credential issuance, payroll cycles or regulatory deadlines.

The wider scaling race

Cardano’s approach is one of several strategies being used across the blockchain industry.

Layer-2 rollups execute transactions away from a base layer and submit compressed data or proofs for settlement. Sidechains and application-specific chains use separate environments with their own performance and security assumptions. Modular systems separate execution, consensus, settlement and data availability across specialized layers.

Zero-knowledge rollups use proofs to demonstrate that batches of transactions were processed correctly. Confidential-computing systems protect data through trusted hardware or other execution safeguards. Privacy-focused smart-contract platforms build confidentiality directly into their transaction and state models.

Midnight’s challenge sits at the intersection of these trends. It must support private computation while providing a credible path to settlement, interoperability and application development. That is different from simply scaling a transparent public ledger.

Cardano’s Leios research addresses the throughput and coordination of a public settlement layer. Midnight must address the cost of hiding information, proving correctness and maintaining usable private state. The two systems can reinforce each other, but improvements in one do not automatically solve the other.

This distinction may become increasingly important as applications combine public and private components. A financial application may keep customer balances or eligibility information private while settling a public asset on Cardano. A supply-chain system may disclose compliance proofs publicly while protecting supplier contracts. An identity system may allow selective disclosure without publishing personal records.

In each case, the application’s performance depends on how efficiently the public and private components communicate. The strongest chain in isolation may not produce the best user experience if the connection between systems is slow, expensive or difficult to operate.

What would demonstrate that the two ecosystems work together?

The most useful evidence will come from reproducible benchmarks rather than broad claims about future capacity.

For Cardano, researchers and developers should report sustained throughput under realistic transaction mixes, block and endorsement propagation times, node resource requirements and the effect of different network conditions. They should also show how performance changes when participation is distributed across operators with different hardware and bandwidth.

For Midnight, benchmarks should include proof-generation time on consumer hardware, verification cost, private-state growth, encrypted-data retrieval and recovery behavior. Developers should test applications with multiple concurrent users rather than isolated transactions.

Cross-chain testing should measure the entire process from private execution to Cardano settlement and back again. It should include relayer outages, delayed messages, duplicate submissions, conflicting events and temporary congestion on either network.

Important benchmarks could include:

• Median and 95th-percentile end-to-end latency
• Cost under low, normal and peak demand
• Proof size and verification requirements
• Message delivery time between networks
• Recovery time after a relayer or data provider failure
• Storage growth over extended usage
• Hardware requirements for validators and proving services
• Privacy leakage from timing and public interactions
• Success rates for wallets with limited connectivity
• Performance during protocol upgrades or parameter changes

The results should distinguish between confirmed functionality, testnet experiments, simulations and future plans. Official roadmaps can establish direction, but they are not substitutes for deployed performance.

Faster settlement will raise expectations

Cardano’s Leios and input endorser research could provide a stronger public foundation for applications that need frequent, low-cost settlement. If the design reaches production with its security and decentralization objectives intact, Midnight could benefit from greater capacity, improved confirmation responsiveness and a more practical environment for public-private applications.

But the relationship is not automatic. Cardano throughput will not determine the speed of private proof generation, encrypted-state recovery or application-level message handling. Midnight could remain constrained by its own execution model, proving infrastructure, node resources, data availability and interoperability design.

That makes the development strategically important. A faster public settlement layer does more than improve back-end capacity; it raises the standard against which connected applications are judged. Users will notice if a public transaction confirms quickly but a private credential takes minutes to generate. Enterprises will question the value of cheap settlement if data recovery is unreliable or relayers create unpredictable delays.

The success of the combined ecosystem should therefore be measured by the entire user journey: from private transaction creation and proof generation to verification, state recording, cross-chain communication and final settlement.

The broader lesson is that blockchain scaling is no longer only a question of how many transparent transactions a single network can process. As applications combine public settlement with confidential computation, performance will be defined by the interaction between layers. Cardano and Midnight offer a test case for whether public and private infrastructure can scale together while preserving security, decentralization, privacy and predictable economics.