Something interesting happened in late February 2026. The Ethereum Foundation published a document that, if you squint at it from the right angle, reads like a roadmap toward the kind of consensus design that Cosmos ecosystem chains have been running for years.

The document is called the "strawmap", a mashup of "strawman" and "roadmap", which tells you everything about how the authors want you to read it. It's not a binding specification but rather one possible sketch of Ethereum's future, put out by EF researcher Justin Drake as a conversation starter. But it's a remarkably detailed one: roughly seven hard forks through 2029, spaced about six months apart, each nudging the network toward five long-term goals the document calls "north stars". Faster base layer, massive throughput, quantum-resistant cryptography, built-in privacy, high-performance L2 scaling.

If you've been following our recent piece on CometBFT, this is the sequel we hinted at. We're going to zoom in on one of those north stars, "Fast L1", because it tells the most interesting story about where blockchain consensus design is heading.

Twelve Seconds Is a Long Time

12 is a number that matters because that's how many seconds Ethereum currently takes to produce each block. One validator proposes a block, committees of other validators vote on it, and 12 seconds later the cycle repeats. For a lot of use cases, 12 seconds is perfectly fine. For others, especially anything involving cross-chain coordination or time-sensitive automation, it's an eternity.

The strawmap wants to shrink that number with the proposed approach being rather methodical than dramatic. Instead of jumping straight to faster blocks, Ethereum would step down gradually using what's been described as a "√2 at a time" formula:

Each step only happens after testing confirms it's safe. The last two steps (3 and 2 seconds) are flagged as speculative, dependent on research that hasn't been completed yet.

Why can't you just flip a switch? Because shorter slots compress the time available for blocks to travel across the network. If your slot is 4 seconds but it takes 3 seconds for a block to reach every node, you've got a problem. So before slot times can drop, the entire peer-to-peer networking layer needs an upgrade. Researchers are working on an approach using erasure coding, where each block is split into fragments so that any sufficient subset can reconstruct the whole thing, making propagation faster and more resilient.

It's a reminder that blockchain performance isn't just about the consensus algorithm. The plumbing matters too.

Finality Gap

Slot time is only half the puzzle. The other half is finality: the moment a block becomes truly irreversible.

If you're new to this distinction, here's the short version. When Ethereum produces a block every 12 seconds, that block isn't immediately permanent. It has probabilistic confirmation, meaning it becomes more likely to stick as more validators vote on it, but true finality (the point where reversing it would require destroying an enormous amount of staked ETH) doesn't arrive until about two epochs have passed. An epoch is 32 slots. Two epochs is roughly 12.8 minutes.

During that window, chain reorganizations can happen. A block you thought was confirmed can get replaced by a competing fork. For everyday transactions, most people treat a few confirmations as "good enough". But for systems that need to act on the certainty that something happened, like cross-chain automation, 12.8 minutes of ambiguity is a structural problem, not just an inconvenience.

The strawmap proposes fixing this by replacing the current finality mechanism with something fundamentally different.

Enter Minimmit

The current finality system, called Casper FFG, works like a two-round voting process layered on top of the block production cycle. The strawmap envisions replacing it with a one-round BFT algorithm called Minimmit.

"BFT" stands for Byzantine Fault Tolerant, the family of consensus designs built to handle participants who might actively misbehave. If that rings a bell, it should. CometBFT, the engine we explored in our previous article (and the one now running under Reactive Network), belongs to the same family. The Tendermint lineage that CometBFT descends from has been doing BFT consensus since 2014.

The trajectory from today's finality to Minimmit's end state looks like this:

For perspective, our CometBFT-based implementation already achieves instant finality with roughly one-second block times. The endpoint Ethereum is aiming for by 2029 is the neighborhood we moved into this year.

That's not a criticism of Ethereum. It's an observation about where things are heading. Two very different systems, designed under different constraints and philosophies, are arriving at remarkably similar conclusions about what good consensus looks like: finalize fast, finalize in one round, make it BFT.

Small Committee Question

There's one more piece of the puzzle worth mentioning. Ethereum currently has over a million validators. They're divided into committees, and in every slot a slice of them cast votes. All those signatures need to be collected, aggregated, and verified, which takes time and bandwidth. It's one of the reasons slots can't easily get shorter.

The strawmap floats an idea: what if only 256 to 1,024 randomly selected attesters signed each slot? For the fork-choice rule (deciding which chain is correct), that's enough. Fewer signatures means no aggregation phase, which shaves off the milliseconds that make shorter slots possible.

If you read our CometBFT article, you might remember that CometBFT-based chains typically run with 50 to 175 active validators, and that this compact set is exactly what makes single-block finality feasible. The tradeoff is real: fewer validators per round means faster rounds, but it also means concentrating trust in a smaller group at any given moment.

Ethereum is now exploring its own version of that tradeoff at a completely different scale. How they solve it will be one of the most important consensus design stories of the next few years.

Where We Fit In

We didn't build on CometBFT because we predicted Ethereum would eventually move in this direction. We built on it because instant finality solves a specific problem for reactive contracts: when your system listens to events on one chain and triggers actions on another, you can't afford ambiguity about whether a block is real.

But it's worth stepping back and noticing the broader pattern. The design choices behind our Omni fork, instant finality, compact validator participation per round, BFT-style consensus, are the same ones Ethereum's researchers are now working toward for the largest smart contract platform in the world. Different starting points, converging destination.

Our Lasna Testnet, running the full CometBFT-based architecture, is now undergoing testing for reactive transaction and callback delivery, and will soon open to the public. Mainnet is next and we'll share more on that timeline shortly. 

Bigger Picture

The strawmap is one document from one team, offered as a starting point. Plenty will change between now and 2029. Forks will be delayed, designs will be revised, new ideas will emerge.

But the direction it points toward reflects something larger than any single roadmap. Fast finality is moving from "nice to have" to "expected". The consensus design space that BFT-based chains have inhabited for years is becoming the destination for the entire industry.

That overlap raises deep questions. How do you get fast finality at the million-validator scale? What happens when dozens of chains run variations of the same consensus philosophy, each making different tradeoffs? How do you balance speed against decentralization when both matter? For now, let it be some food for thought.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. It runs on CometBFT consensus, providing instant finality and roughly 1-second block times while maintaining full EVM compatibility.

Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, deciding autonomously when to send cross-chain callback transactions. This model supports conditional cross-chain state changes and continuous cross-chain workflows.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!