Behind Monad's 100% Uptime

Introduction

Since its public launch on November 24, 2025, Monad mainnet has recorded 100% uptime with no network outages or halts. At a block every 300 milliseconds, that is more than 60 million uninterrupted blocks. Each block requires a supermajority (more than two-thirds of the stake weight) to agree on the state of the network; the 200 validators participating in consensus verify that each block follows the rules of the protocol before signing it.

This level of reliability is the compound result of deliberate choices: a consensus protocol designed around resilience and performance, an open-source codebase with a standing seven-figure bug bounty, a release process built for predictability, and a validator set continuously monitored for operational quality. This post walks through each layer, then closes with block-by-block numbers gathered from consensus telemetry since genesis.

Consensus designed for robustness

At the core of the network's reliability is MonadBFT, the protocol through which validators agree on every block. Monad produces a block every 300 milliseconds and finalizes it 600 milliseconds after proposal, across roughly 200 validators worldwide. At that pace and scale, individual failures are routine: machines reboot, data centers lose power, networks drop packets. MonadBFT assumes this and is engineered to make each failure as cheap as possible for the network.

MonadBFT is pipelined. In each round, a scheduled leader broadcasts a block proposal, the other validators check it and vote, and the votes aggregate into a quorum certificate (QC) — cryptographic proof that more than two-thirds of stake endorsed the block. Each proposal carries its parent's certificate, so every round simultaneously advances a new block and confirms the previous one. A block is speculatively final one round (300 ms) after proposal, and fully final after two (600 ms).

Protocols in this family — pipelined descendants of HotStuff — historically shared a structural weakness known as tail-forking. Because each leader collects the votes on its predecessor's block, an offline or strategically silent leader could cause that block to be abandoned even after a supermajority voted for it. It is also an attack vector: a malicious leader could discard its predecessor's block and re-propose the same transactions reordered to extract MEV. MonadBFT eliminates tail-forking. A leader recovering from a failed round must either re-propose the abandoned block or present proof, signed by a supermajority of stake, that the block could never have reached quorum — if over a third of stake attests that it never saw the block, a two-thirds endorsement was impossible. The research paper proves formally that tail-forking cannot occur.

MonadBFT entered the protocol as the MONAD_THREE revision and was later strengthened with fast recovery and leader fault isolation; this strengthened version has run on mainnet since its public launch. Two refinements do the heavy lifting: validators send each vote to the current leader as well as the next one, allowing the current leader to assemble a "backup" certificate for its own block; and timeout messages carry the highest certificate a validator has observed. For example, validators A, B, and C are scheduled for consecutive rounds, and B's data center loses connectivity. A proposes; validators vote to both A and B; A forms and broadcasts its own backup certificate. B's round expires after the 600 ms timeout, and C — whose incoming timeout messages carry A's certificate rather than any newer proposal — immediately proposes a fresh block extending A's. The ledger records A's block finalized, one timeout for B, and C's block on schedule. Under the original design, the same fault cost two timeouts (roughly 1.2 seconds) plus a round consumed by re-proposal; fast recovery cuts this to a single 600 ms timeout.

These properties map directly onto two additional health metrics examined later in this post. Tail-forking resistance governs the finalization rate: a proposed block can fail to finalize only if it provably never achieved supermajority support, or, in one theoretical corner case, if its own proposer equivocated by signing two conflicting blocks, a cryptographically provable and punishable fault. Leader fault isolation governs the proposal success rate: timeouts overwhelmingly reflect objective infrastructure faults at individual validators, and the protocol contains each fault's blast radius to a single round.

Consensus at this speed also depends on every proposal reaching every validator within the 300 ms budget, which is the job of RaptorCast, an erasure-coded broadcast protocol that fans each block across the validator set in two hops without making the leader's uplink a bottleneck. Execution is kept off consensus's critical path: asynchronous execution lets validators agree on transaction order before executing, while parallel execution and the purpose-built MonadDb state database provide the headroom that keeps nodes within that budget even under sustained load.

Formal verification

Monad's reliability is bolstered by machine-checked mathematics at two levels.

A formal proof covers every possible behavior of a system, giving guarantees that testing alone cannot. At the protocol level, the MonadBFT paper formally proves the protocol's safety and liveness, and proves that the tail-forking failure mode cannot occur at all.

At the implementation level, Category Labs runs an ongoing formal verification effort using the Coq (Rocq) proof assistant, with BRiCk to reason directly about production C++ code. Two results stand out. First, the reserve balance mechanism: because Monad's asynchronous execution model orders transactions before executing them, the protocol needs a hard guarantee that every transaction admitted into a block can pay its fees. A Coq model of the mechanism was proven correct — an exercise that exposed design bugs before implementation began — and the execution-side C++ code was then proven to match the verified model. Second, parallel execution: the optimistic execution algorithm was proven to produce state identical to sequential execution, the invariant on which Monad's entire execution model rests.

Formal verification at Category Labs runs as a pre-merge gate on correctness, protecting the mission-critical live network.

Standing adversarial pressure

A bug bounty creates economic incentives for white-hat security researchers to check for potential issues that could lead to a network halt. The blockchain codebase is fully open-source (monad-bft and monad), and the Monad Foundation maintains a bug bounty program on Cantina, offering up to $1,000,000 for critical findings, $100,000 for high-severity issues, and $35,000 for medium.

Boring releases, by design

Release discipline determines whether the network realizes the reliability its architecture and proofs allow. Monad ships on a deliberately predictable rhythm. Client releases land on testnet first and reach mainnet roughly a week later, and the soak period has real weight: the testnet is comprised largely of mainnet validators, so the rehearsal network is staffed by the same teams as production. More extensive upgrades, such as the upgrade to MIP-8, undergo longer rollout cycles with phased upgrades that provide a fallback mechanism for individual node operators.

The full release history is public, and each release ships with upgrade instructions and a timeline.

High-performance node operators

A resilient protocol still depends on the people who run it. Monad mainnet is validated by an active set of roughly 200 operators, globally distributed and running on bare-metal servers with deliberately economical requirements: a 16-core CPU, 32 GB of RAM, and NVMe storage, which keeps the operator pool broad.

The Validator Delegation Program (VDP), launched alongside mainnet, drew its initial cohort from operators proven across Monad's pre-mainnet testnets. Its intake evaluates industry experience, monitoring and security processes, and geographic decentralization, and its tiering rewards performance on other high-throughput networks.

Delegation from the VDP carries obligations that continue after intake. Validators in the program must sustain at least 98% uptime — reviewed weekly, with repeated shortfalls leading to removal — expose node metrics to the Monad Foundation, respond within 24 hours to performance outreach, and apply releases within 48 hours. Participation and uptime are re-evaluated on a rolling six-month basis. The network is publicly observable in real time at gmonads.com: validators, blocks, and stake distribution, live.

Beyond uptime: proposal and finalization rates

It is worth discussing several other metrics that are related to reliability and UX.

Slot completeness

MonadBFT divides time up into 300 ms slots, and is designed to produce a block in every slot unless the designated proposer misses its slot, in which case the next proposer picks up where it left off. Thus, a related but more demanding measure is the percentage of slots in which a block is successfully proposed.

The successful proposal rate — proposed blocks / (proposed blocks + timeouts) — measures how often the scheduled leader produced a block. From public mainnet launch to the time of writing (August 30, 2026), we observed 62,829,834 proposed blocks and 61,266 timeouts — a successful proposal rate of 99.903%.

Timeouts are skipped proposals, and the Monad Foundation's follow-ups with operators have consistently traced them to infrastructure faults: the scheduled leader was offline, rebooting, or experiencing data-center or connectivity issues.

Finalization of observed proposals

Transactions in a block "happen" when they are included in a finalized block. From a user's perspective, the process is simple: submit a transaction and wait for a finalized block. On Monad, this is fast: finality takes two slots, so it typically occurs within 600 ms. (On Ethereum and L2s, this currently takes 12–18 minutes.)

A user seeking even lower latency could wait only for a proposed block that includes their transaction. This carries some risk: a proposal may reach the user without reaching the rest of the network. The approach saves 600 ms on Monad at the cost of occasionally observing a proposal that does not finalize.

Say you are an ordinary user who observes a new block proposal; what percentage of the time does it finalize? We ran a sidecar on a full node to observe block proposals and compute the successful finalization rate — finalized blocks divided by number of observed proposed blocks. From public mainnet launch to Aug 30, we observed 62,829,834 proposed blocks vs 62,829,146 finalized blocks - a finalization rate of 99.999%.

On the rare occasions when a block proposed by the designated validator did not finalize, a supermajority proved that it had not received the proposal, usually because of connectivity issues affecting the proposing validator. Under MonadBFT, a supermajority is required to attest that it did not receive a block; any block received by more than 1/3 of the stake weight will be re-proposed.

The very high successful finalization rate implies that users who wish to speculatively execute can do so with a very low likelihood of needing to backtrack.

Conclusion

Monad's reliability results from many layers of defense. Consensus keeps supported blocks from being abandoned, formal verification enforces expected behavior, the bug bounty puts a price on undiscovered flaws, staged releases catch regressions on testnet before mainnet, and operational standards hold validators to measurable uptime. The uptime record is the combined result.