The Big Four blockchain properties

What should someone expect from a real-world financial system?

They should be able to send an order without someone using advance knowledge of it to trade ahead of them. They should be able to hold money without publishing their balance, and pay someone without publishing their entire financial history. The system should remain secure as computing technology advances. And it should do all of this at a cost and speed that make it useful to everyone.

This gives the Big Four requirements for the winning blockchain system -- requirements for making decentralized, permissionless, censorship-resistant, verifiable blockchain systems strictly better for users than their centralized alternatives:

These are ordinary expectations in finance. Front-running customer orders using confidential information is prohibited in traditional markets. A bank would not ask customers to publish their accounts as the price of making a payment. Nor would “quantum computers developed faster than we expected” be an acceptable explanation for losing their money.

In crypto, we are too comfortable asking users to tolerate shortcomings that would be unacceptable elsewhere. A financial system should meet these expectations. But if we can do that, we can give users the best of both worlds: open markets, with exceptional asset selection, where any person (or any agent) can participate; without compromising security, fairness, privacy, or cost.

The challenge is delivering all four properties in one system while preserving those foundations. What we are talking about is adding new behavior, with new overhead, while also making a super-performant system even faster. It is like an athlete needing to bulk up while also cutting their marathon time. Fortunately, with Monad, we have the right team, and are building from the right starting point.

MEV-resistance: decrypt only what is included

Encrypted mempools enable MEV-resistance. The basic idea sounds simple. Users encrypt transactions, and validators build blocks without seeing their contents. In the design we want, validators release decryption shares only after the network finalizes the block, fixing transaction order before execution. Provided that fewer than the threshold of keyholders collude, attackers cannot read those pending transactions to trade ahead of them.

Although the idea is simple, getting it right is difficult. The details -- who can decrypt, which transactions they can decrypt, and when they can do it -- determine whether users are actually protected.

First, decryption needs to be decentralized. If one party holds the key, it can read or reveal transactions early, or stop execution by withholding the key. Threshold encryption splits control of decryption across many validators. Users encrypt with public information, while each validator holds a secret key share. Enough validators must contribute decryption shares to unlock the transactions; no single validator can do it alone, and the system can proceed without every validator participating.

That introduces another challenge: what should each set of decryption shares unlock? One common approach is to have per-block encryption/decryption keys. A user encrypts a transaction for an upcoming block and submits it. Once that block is finalized, validators release the decryption shares needed to unlock its transactions. The problem with this approach is that the user cannot guarantee that their transaction will make it into that block. Suppose 1,000 transactions target the block, but only 800 fit. The decryption shares unlock all 1,000, including the 200 still waiting in the mempool. Anyone can now read and front-run those excluded transactions.

The other approach is to have per-transaction encryption/decryption keys. Validators can then release decryption shares only for transactions that were included. But now they must produce and distribute shares for every selected transaction, adding computation and communication as transaction volume grows. A fast blockchain needs to decrypt thousands of transactions without adding a long pause between consensus and execution.

This is the central requirement: decrypt the transactions that were included, keep the rest encrypted, and do it efficiently at scale. Shutter's roadmap identifies this tradeoff and proposes batched threshold encryption as a way forward. But that discussion stops short of providing a concrete batch construction or benchmarks showing that it can meet a fast blockchain's performance requirements.

BTX addresses this with a more efficient construction for batched threshold encryption. The committee releases a decryption key for the selected batch, with less communication than decrypting each transaction separately. In our example, that key reveals the 800 included transactions while leaving the other 200 encrypted. Users do not have to target a particular block or choose an encryption index that could collide with another user's. A transaction that misses one block can stay encrypted until it is included in a later one.

BTX reduces batch decryption to quasi-linear group computation and linear pairing work. In the paper's optimized single-core benchmark, decrypting a batch of 512 ciphertexts takes about 598 ms, versus 1,197 ms for its optimized comparison scheme.

Crucially, much of BTX's computation can start once the batch is fixed, before the decryption key arrives. That gives the implementation room to overlap computation with other work. The remaining task is to integrate and parallelize these stages so they sustain the chain's throughput within its latency budget.

Protecting pending transactions also reduces a major source of builder centralization: the advantage of seeing order flow before others. For example, as of this writing, 48% of Ethereum blocks are built by the top block builder, Titan Builder, and 94% are built by the top 5. Encrypted mempools are crucial to breaking the proposer monopoly.

Quantum-resistance: consensus without certificates

Making blockchains quantum-resistant involves replacing quantum-vulnerable signature schemes with quantum-resistant ones. But post-quantum signatures are much larger; the additional overhead makes it harder to keep a fast blockchain fast, let alone to make it faster.

Let's start by focusing on ordinary transaction signatures. Ethereum and Monad use ECDSA on secp256k1 for conventional user accounts. Its standard recoverable signature representation is 65 bytes. By comparison, an ML-DSA-44 signature is 2420 bytes, about 37 times larger. Even before considering consensus, replacing transaction signatures adds a substantial amount of data to distribute and store.

For consensus, the comparison gets much worse. Ethereum and Monad both use BLS signatures to combine many validators' signatures into one short aggregate. Ethereum uses this for aggregated attestations; MonadBFT uses it for quorum certificates, or QCs, that show a quorum voted.

But ML-DSA-44 has no native BLS-style aggregation. A direct replacement would have to carry the individual signatures. For a 200-validator set with equal voting weight, take a quorum of 135 signatures as an example: 135 × 2,420 bytes = 326,700 bytes ≈ 327 kB.

That is about 3,400 times larger than a 96-byte BLS aggregate of the kind Ethereum uses, counting only signature bytes on both sides. Signer identifiers and other certificate metadata are additional.

Signature replacement becomes a massive bandwidth problem for the entire consensus protocol.

Ethereum's post-quantum consensus work is attempting to address this with hash-based signatures and SNARK-based aggregation. A proof establishes that a collection of signatures is valid, and validators can check the proof instead of receiving all the signatures. This introduces a proving workload, which must itself be fast enough for consensus. The proof system also needs post-quantum security.

Monad is taking a different direction with Quantum Cadence. Validators count quorums in messages they receive directly, eliminating the need to circulate QCs within slot consensus.

Several changes make this work. Quantum Chorus replaces certificate-based voting with locally observed votes. Each validator signs at most two votes per slot, covering all proposers together, so adding proposers does not multiply its vote signatures. Coda, a new signature-free fallback agreement protocol, resolves cases that cannot finish on the fast path. The core safety and liveness guarantees rely on authenticated channels and hashing; signatures provide evidence of misconduct.

As detailed in the Quantum Cadence paper, we are seeing roughly 200 ms average time from proposer broadcast to finality in simulations with 200 validators, 20 proposers, and 1 Gbps links. Category Labs is moving quickly to productionize Quantum Cadence.

Every usage of signatures in a blockchain protocol requires hardening. Today's BTX construction is pairing-based and needs its own post-quantum replacement. Wallets, application signatures, and proofs also need migration paths. Monad's roadmap addresses these separately, including account authentication that can change without forcing users to abandon their addresses.

Privacy: private transactions, shared liquidity

A bank needs its customers' balances and payments to remain confidential.

The usual response is a private blockchain. But if every bank operates an isolated ledger, we recreate much of the existing financial system: separate balances, separate liquidity, and custom connections between institutions. A customer should be able to pay someone at another bank without the two institutions having to build a new settlement network for that relationship.

Monad Private Settlement gives institutions private execution domains connected to the public chain. A bank selects its domain operators and access policies. Customers can use applications within that domain without exposing their records to the public, while authorized parties can receive the access their role requires.

Consider Alice at Bank A paying Bob at Bank B, with an application that supports transfers of a common settlement asset. The domain architecture supports this sequence:

1. Alice submits an encrypted instruction to Bank A's domain through Monad's public hub contract.
2. Monad orders it. Bank A's operators execute it privately and attest to the resulting state and outbound-message commitments.
3. The hub accepts the attested message root, then checks an inclusion proof and replay protection before routing the message to Bank B. Private-domain messages are encrypted for their destination.
4. Bank B processes the message under its own rules and updates Bob's balance once the required settlement asset has arrived.

These calls are asynchronous, and more complex atomic exchanges require coordination and locking. In the first version, cross-domain token transfers pass through public bridge contracts: customer addresses stay private, but transfer amounts and the participating domain bridges are visible. Confidential cross-domain amounts are planned. The first version also relies on operator multisignatures to attest to correct execution; public sequencing does not remove that trust assumption.

The useful distinction is between sharing settlement and sharing everyone's private state. Bank B needs an authenticated payment from Bank A, not a copy of Bank A's customer database. A liquidity venue needs the inputs to an exchange, not the sender's full financial history.

Monad's architecture makes this separation natural. Its consensus already establishes ordering independently of execution. Private domains extend that approach to execution with different visibility and verification rules. The hub still executes as a public contract, but the public network does not have to execute the bank's private business logic.

Scalability: removing the wait between blocks

We are pursuing these significant improvements while also increasing Monad's performance: making blocks more frequent and reducing time-to-finality. This is enabled by Cadence and its successor Quantum Cadence, which are designed to move Monad to a multiple concurrent proposer (MCP) consensus mechanism with extreme pipelining of block proposals. Quantum Cadence replaces Cadence's certificate-based slot consensus, enabling quantum resistance and scalability to be developed in the same protocol.

MonadBFT already pipelines consensus, configured for 300 ms blocks and 600 ms finality under normal conditions. But each round has one leader, and the next leader collects votes into a quorum certificate before proposing a block that builds on its predecessor. This dependency puts network communication between successive proposals.

Quantum Cadence removes that dependency. Each slot runs an independent consensus instance, and slot numbers determine ledger order. Several proposers contribute to each slot. New slots can start while earlier slots are still reaching agreement, allowing block intervals shorter than a global round trip.

The challenge is keeping that concurrency useful when participants are slow, offline, or dishonest. Quantum Chorus uses a common proposal-arrival deadline, with distant proposers able to transmit earlier. Validators decide separately whether to include each proposer's contribution, so an offline proposer need not prevent fast-path finalization. Agreement proceeds alongside encoded data dissemination, with recovery guarantees. Under the protocol's timing conditions, every honest proposer's contribution is included.

The fast path takes three communication rounds, including dissemination. Coda handles fallback agreement without certificates. Slot scheduling must also limit unfinished work during network stalls; the Quantum Cadence paper outlines this scheduler, with its full specification and analysis forthcoming.

Why Monad will be the blockchain to deliver this

Monad is already a well-oiled machine. We have put years into a high-quality, modular client: the consensus and networking code, the execution engine and database, and the interfaces between them. That work gives us an exceptional foundation for improving individual parts of the system.

Modularity starts with asynchronous execution. Validators agree on ordering without waiting for the current block's execution result. Execution follows in a separate pipeline, giving it more time while consensus continues.

This choice has consequences well beyond throughput. It lets Monad order encrypted transactions before decrypting them. It lets ordering and private execution have different participants. It removes an execution dependency from the work of implementing extreme pipelining through MCP.

We believe that every blockchain will eventually converge on an asynchronous execution design. Currently, Solana is working toward this separation through its Bankless Leader roadmap. Monad already has asynchronous execution in place.

The Big Four properties are how we go from a blockchain that people can use, to a financial system they can depend on. A user should get fair execution, affordable transactions, durable security, and privacy without giving up access to the wider market. We must deliver these improvements while preserving decentralization, permissionless access, censorship resistance, and verifiable settlement. That is the challenge, and we are well on our way.