Block time is a user experience problem before it is an engineering problem. When a swap confirms in 400 milliseconds, it feels like a web application. When it confirms in 12 seconds, it feels like a blockchain from 2018. The difference is not cosmetic — it shapes whether users accept the confirmation as final or nervously reload the page.
Sanect targets 400ms blocks with a 50-validator global set. This post explains exactly how that number is achieved, what prevents going faster, and what "400ms" actually means in a Byzantine fault-tolerant system.
BFT Finality vs. Probabilistic Confirmation
In proof-of-work chains like Bitcoin and Ethereum pre-Merge, there is no such thing as instant finality. A block can always be reorganized away if a longer chain appears. This is why exchanges wait for 12 or more confirmations before crediting a deposit. You are not waiting for one block — you are waiting for the probability of reorganization to become negligibly small.
CometBFT is different. Once a block is committed, it is final. No reorganizations. No waiting for six more blocks. The 2/3 supermajority that signed the precommit round cannot be reverted without breaking the BFT safety assumption (which requires a Byzantine majority, something we treat as catastrophic regardless). This matters because finality in 400ms is categorically different from confirmation in 400ms — the former cannot be undone.
The CometBFT Timing Parameters
CometBFT's consensus round is divided into phases, each with a configurable timeout. Sanect's genesis parameters are:
- timeout_propose: 250ms. How long the proposer waits to broadcast a block before peers suspect it has failed and move to the next round.
- timeout_prevote: 150ms. How long validators wait to collect prevotes before proceeding. A validator that doesn't see 2/3 prevotes within this window moves on.
- timeout_precommit: 150ms. Same logic for the precommit phase. The 2/3 precommit threshold here is what produces finality.
- timeout_commit: 400ms. After a block is committed, validators wait this long before starting the next proposal. This is the floor — even if consensus completes in 50ms, the chain pauses here before the next block begins.
The timeout_commit of 400ms is the dominant number. It is set deliberately to match the realistic network round-trip floor of the validator set. Setting it lower would cause frequent timeout escalations, where validators miss the window for honest peers and trigger multi-round consensus — which is slower, not faster.
The Network Floor Calculation
Why 400ms and not 200ms? Because the network imposes a floor that is independent of configuration.
To commit a block in CometBFT, the proposer must collect precommits from at least 2/3 of the validator set by stake weight. In Sanect's Variant A topology — 8 validators in Singapore, 5 in Mumbai, 5 in Frankfurt, 8 in US East, and so on — the round-trip time between the slowest third of the set matters, not the average.
The calculation looks roughly like this:
- Singapore to US East: ~220ms RTT. This is the long leg. US East validators hold 8 of 50 slots — well inside the 2/3 majority threshold, but their latency sets the realistic floor for collecting their precommits.
- EVM execution and state commit: ~70ms for a typical block at target load.
- CometBFT internal overhead (serialization, signature verification, mempool updates): ~40ms.
Add those up: ~180ms of network time for the 2/3 supermajority collection, plus ~110ms of local work, equals ~290ms under ideal conditions. The 400ms timeout_commit provides ~110ms of margin for jitter, asymmetric routing, and the occasional validator that is running slightly behind. Real-world observed block times cluster around 430ms at this topology.
The Topology Design
Sanect's target validator distribution uses Singapore as the network hub, with 8 regional clusters spanning Asia, Europe, and the US. The design is intentionally weighted toward Asia — approximately 52% of stake — while ensuring the European and US East validators together can veto any finalization attempt, since they hold more than 1/3 of the set.
This geographic structure achieves two things simultaneously: it keeps average latency low (most validators are within 100ms of the hub) while preventing any single jurisdiction from controlling finality. No country holds 2/3 of the stake. A government-directed shutdown of Indian validators, for instance, would not halt the chain — it would slow it and eventually trigger rotation to the waiting queue, but not stop it.
Why We Didn't Go to 100ms
The physics of the speed of light across a globe-spanning network set a hard floor at roughly 220ms for a Singapore-to-US-East round trip. No software optimization changes this. A 100ms block time would require either colocating all validators in a single region (which destroys geographic decentralization and creates a single point of regulatory risk) or deploying a validator set with artificial latency controls — which is not a real network.
Fast block time and global decentralization are in direct physical tension. 400ms is the honest number for a globally distributed set. 100ms is only achievable with a datacenter cluster, not a public validator network.
What Happens Beyond 150 Validators
CometBFT's consensus requires O(n²) message complexity in the worst case — every validator needs to hear from every other validator. At 50 validators, this is manageable. At 150, the overhead begins to push block times past one second even at low network latency. Beyond 150, block time scales roughly linearly with validator count unless the protocol is modified.
The path to more validators without sacrificing block time runs through BLS signature aggregation, which reduces the O(n²) message complexity to O(n). This is future protocol work — multiple months of implementation and audit. Sanect v1 ships with 50 active validators and honest 400ms blocks rather than promising a number the current protocol cannot deliver.
Unlimited registrations feed a waiting queue. Validators outside the top 50 by stake are registered and ready — they produce no blocks and earn no rewards until they enter the active set, but rotation is automatic as stake distributions shift. The queue is the decentralization story. The 50-validator ceiling is the performance story. Both are true at the same time.