A world computer worthy of the world’s money
Monad began with the goal of doing for the financial system what the internet did for information.
The internet made it possible for people to publish, communicate, and build services for a global audience at very low cost. Open protocols gave people a common foundation on which to create things no single company could have planned. We want that same freedom to extend to money: to how people save, pay, trade, and fund new ideas.
That requires a financial system people anywhere can access and developers anywhere can build on. Exchanges, lending markets, payments, and assets should be able to work together in one shared system. People should retain control over their money, and new businesses should be able to compete without asking permission from the companies they challenge.
As an industry, we have made some progress toward that goal. However, there are significant shortcomings. MEV is treated as an inevitability. Key application logic frequently lives off-chain. Institutions needing confidentiality are tempted toward private blockchain solutions. These problems stand directly in the way of decentralized, self-sovereign money.
In my view, development is moving far too slowly. We have become too willing to accept these failures as permanent features of crypto. Users pay the cost every day. We should expect more from the infrastructure.
Our approach with Monad has been to build the architecture needed to address these problems. Moving more application logic on chain requires cheap computation and state access. Keeping transactions encrypted until finalization requires ordering them before execution. The first phase of Monad established those foundations. We built parallel execution, asynchronous execution, JIT compilation, MonadDB, MonadBFT, and RaptorCast. Together, these make it possible to do more work, access more state, and reach agreement quickly across a distributed network.
With that foundation in place, the next phase is to deliver the protections and capabilities it makes possible. A user should be able to send an instruction without exposing it to someone who can trade ahead of them. An institution should be able to settle privately. A developer should be able to choose how an application orders transactions while connecting it to a common settlement layer.
Our ambition is a world computer that billions of people can use. That requires performance, cryptography, and open access to work together as protections people can actually use. We intend to build it, and we should be judged by what we deliver.
What the first phase makes possible
A transaction requires several kinds of work. The network must distribute and agree upon ledger additions, execute instructions, and update the relevant state. Monad lets more of that work happen concurrently.
Parallel execution uses multiple processor cores while preserving the agreed order of state changes. Asynchronous execution separates transaction ordering from execution, so consensus can advance while the execution engine processes earlier transactions. JIT compilation turns EVM bytecode into native machine code.
MonadDB supplies efficient access to state. With MIP-8, its page-aware storage tries commit to groups of consecutive storage slots, bringing the commitment structure closer to how disks read data. RaptorCast shares the work of distributing block data across validators. MonadBFT provides 300 ms block times and 600 ms finality in normal operation.
These choices also create opportunities for the next phase. Separating ordering from execution gives us a place to order encrypted transactions before opening them. Efficient computation and storage make it practical for applications to do more work on the user's behalf. A network that already shares data distribution work can take concurrency further in block construction.
The direction can be expressed through the properties we want users and developers to have:
| Part of the system | Foundation or starting point | Direction for the next phase |
|---|---|---|
| Transaction execution | Parallel execution, JIT compilation, and efficient state access | More decisions made on chain using the state at execution time |
| Protection before execution | Ordering is separate from execution | Transactions encrypted until their order is final |
| Block production | MonadBFT with 300 ms blocks and 600 ms finality | Concurrent proposers and extreme pipelining, targeting 100 ms blocks and 200 ms finality |
| Confidentiality | Public execution and shared settlement | Confidential institutional activity connected to shared liquidity |
| Application design | A shared base layer | Native rollups and support for application-specific sequencing |
| Long-term security | The existing cryptographic system | Quantum-resistant authorization and network security |
| Access to the system | EVM tools, existing RPC methods, and mera in preview | Cheaper and more powerful queries, passkey access, and easier application development |
The right-hand column describes the direction we intend to deliver through separate advances in the protocol and its tools.
From a visible order to a protected intent
Consider what should happen when someone wants to buy an asset.
They should be able to tell an application what they want to buy, how much they want, and the maximum price they will accept. The application should find a good route using the market state available when the trade executes. Sending that instruction should not give another participant an opportunity to exploit it.
Two problems stand in the way. First, almost all aggregators implement their routing logic off-chain - thus making routing decisions based on information that is already out of date when execution begins. Second, an observer who can read a pending order can react before its position is fixed, front-running the user's intent.
MEV is a powerful centralizing force. In Rated's 30-day view of Ethereum's builder market, the top two builders account for 72.9% of tracked blocks, and the top three account for 88.8%, as of October 3, 2026. Access to valuable exclusive order flow helps builders win blocks, which makes them more attractive to order-flow providers and harder for new participants to challenge. A distributed validator set alone does not prevent this concentration. We need to address the incentives that produce it.
Encrypted mempools address a central part of that problem. When orders remain encrypted until their position is final, privileged access to those protected orders no longer lets a builder read them and trade ahead. That reduces the value of early access and the incentive to concentrate it. This is a reason to build encryption into the protocol: protecting users and preserving decentralization are connected engineering goals.
Our direction combines on-chain routing with threshold encryption. Efficient computation and state access allow the routing decision to move closer to execution. Encryption protects the instruction during ordering. I have described this as the path toward better execution for users.
The intended sequence is straightforward:
- The user submits an encrypted instruction.
- The network finalizes the order of encrypted transactions.
- Enough decryption participants release shares to reveal the contents.
- Applications execute the instructions in the fixed order, using the state available at that point.
Finalization here fixes the transaction order. Execution results follow decryption. The protection depends on the threshold security assumptions and on participants releasing shares at the correct time. Category Labs' BTX research on batched threshold encryption provides important tools for this design.
This changes what the user needs to know. They can express an outcome and its limits, while the application handles routing and the protocol protects submission.
Fair execution should be a property of the infrastructure. It is unreasonable to expect every user to become an expert in avoiding extraction before they can trade safely. If we want people to bring their financial lives on chain, we owe them a system designed to protect their interests.
More concurrent work and less control by one proposer
The next performance targets are 100 ms blocks and 200 ms finality. Shorter block intervals create more frequent opportunities for inclusion. Faster finality reduces the wait for a fixed order. Users should feel the benefit of each improvement.
Cadence takes concurrency further. Each slot has its own consensus instance, so later slots can proceed before earlier ones finish or propagate. Multiple validators propose content for each slot. The network agrees which proposals to include and combines their transactions under a fixed rule.
This has a consequence beyond speed. A single proposer no longer controls the complete set of transactions in a block. Under the protocol's timing and fault assumptions, a transaction included by an honest proposer cannot be dropped or deferred. Proposal encryption also prevents proposers from reading one another's proposals and changing their own in response before the deadline.
That deadline protection is distinct from keeping user transactions encrypted until finalization. The two operate at different stages. We want both the path into a proposal and the construction of the final block to limit opportunities for interference.
Privacy and shared settlement
Encryption until finalization protects a transaction before execution. Businesses also need confidentiality afterward. Banks must protect customer records, and trading firms must protect positions. We cannot ask them to expose their books as the price of participation.
Private chains provide confidentiality at the cost of isolation. Assets and liquidity become fragmented across separate networks, with bridges and custom integrations needed to reach outside markets. If every institution builds its own closed system, we reproduce the fragmentation that makes finance difficult today.
The goal is privacy with access to shared liquidity. Two banks should be able to settle a payment and obtain currency conversion through a common market while keeping customer records confidential. Auditors should receive the access they need without making those records public. The design must establish what each participant can see, including when private activity interacts with a public market.
Applications also need more control over how user actions reach settlement. An exchange may need to process cancellations before new orders. A game may need to acknowledge an action before the next block. These choices affect the product, yet teams often have to build custom infrastructure to support them.
Alongside native rollups, we want better support for application-specific sequencing and fast responses, with settlement on Monad. Developers should be able to choose ordering rules that serve their users. Users still need clear guarantees about when a response becomes final and how to submit transactions if the application operator stops responding.
Those connections need clear rules for asset transfers, withdrawals, and recovery if an operator fails. Sharing a settlement layer does not automatically make every interaction instant or atomic. The goal is to make private and public activity work together reliably.
Security and access over the long term
A financial system must protect assets over many years. Its security cannot depend on cryptographic assumptions remaining suitable forever. Waiting for a crisis before giving users a migration path would be a failure of engineering.
We therefore want a quantum-resistant Monad. The work must cover user authorization and the cryptography that protects the network, with a practical transition for existing accounts and applications. Post-quantum methods address the threat that sufficiently capable quantum computers pose to widely used public-key systems.
This must be a requirement across the design. Threshold encryption by itself does not establish quantum resistance. New capabilities must fit into a long-term security plan, and users need usable ways to adopt stronger protection.
Usability matters at the application boundary too. MIP-16 proposes consistent query methods for blocks, transactions, logs, traces, and transfers. Mera, already available in preview, lets developers create accounts from passkeys and support signing sessions. These reduce different kinds of friction: obtaining data and helping a user access an account.
Developers should be able to spend more time on their products. Every team forced to rebuild the same workaround pays for an infrastructure problem we should fix once. Users should be able to obtain the system's protections through an interface they understand. The complexity of the underlying architecture creates value only when applications can make it useful.
Why build this as one neutral system
The reason to bring these capabilities together is the value of shared state: more efficiency, more opportunities, and global optimums. Users get access to more opportunities, unlocked by a borderless financial system with composable money legos.
Neutrality gives competing businesses a reason to participate in that shared system. A wallet, exchange, or financial institution should be able to build without depending on infrastructure whose rules favor a competitor. This is central to the general-purpose network we set out to build.
If we accomplish these goals, we get a new financial system that meets the expectations of users and the needs of businesses. People can control their money, submit an order without inviting someone to trade ahead of them, and receive a fast result. Businesses can protect customer information, meet their disclosure obligations, and transact with the wider economy. Developers can compete to serve both on infrastructure that is open to everyone.
Bringing that activity together is how we aim to build the best liquidity, pricing, and opportunities. More participants, more shared liquidity, better asset selection, cheaper prices, better lending or borrowing rates; it all can be summarized as better opportunities.
This is what doing for finance what the internet did for information should mean in practice. More people able to participate, more businesses able to compete, and more opportunities available through a common network. People should choose this system because it works better for them. That is the standard we intend to meet.