In January 2026, we wrote about Fiet integrating with Reactive Network to take the manual labor out of asynchronous DeFi settlements. That was the promise. Milestone 2 is the delivery: the contracts are live on Arbitrum and Reactive mainnet, and a full end-to-end run is on record, a real settlement processed and a queue drained without anyone pressing a button. Here's what Fiet's automation does, why it's one of the more sophisticated things built on Reactive, and where our network fits. 

The short version for newcomers: Fiet lets professional market makers plug off-chain liquidity into on-chain markets. Traders swap as if it were any normal AMM, but when the underlying asset isn't immediately available, the trade parks in a settlement queue until it is. Reactive Network watches that queue and settles it automatically the moment liquidity shows up. Everything below is about why doing that well is harder than it sounds. 

Problem revisited

Here's the situation Fiet creates by design. A market maker promises to deliver an asset they hold off-chain; a trader buys it on-chain. When the underlying is ready, settlement is trivial. When it isn't, the trader joins a queue and waits.

In the old world, waiting meant you, the trader, had to come back and claim your funds in a second transaction, watching the chain yourself or trusting a keeper to do it. And the experience got worse exactly when markets got fast and volatile, when you'd least want to be babysitting a pending claim.

So the job sounds simple: watch for liquidity, settle the queue. But "settle the queue" hides hard sub-problems once you do it trustlessly, at scale, across two chains. What happens when a hundred settlements queue and only enough liquidity arrives for thirty? When liquidity shows up before the settlement is even recorded? When one item in a batch fails? Who pays for all this, and how do you stop one user subsidizing everyone else?

Reactive’s role

For anyone new here: a reactive contract isn't triggered by a user sending it a transaction. It's triggered by events happening on other chains. It subscribes to logs, say a `SettlementQueued` event on Arbitrum, and runs its own logic in response, then emits callbacks that execute back on a destination chain.

Fiet's settlement automation has no off-chain bot, no centralized keeper, no cron job on someone's server quietly holding a private key. The thing watching the queue is itself a smart contract, and the thing executing the settlement is a cross-chain callback that the network delivers. If you've ever worried about who's actually running the automation you depend on, the answer here is "nobody, and that's the point".

Settlement flow 

Let's trace one trade on the mainnet. It starts with a trader doing an exact-input swap on Arbitrum, but the output side can't settle yet, so `LiquidityHub` queues the obligation. `HubRSC`, already subscribed to that recipient's events, observes the log and records the pending work. Then it waits for liquidity. When liquidity arrives (in the live run, the market maker settling their position and closing the RFS), `HubRSC` dispatches a bounded batch to `BatchProcessSettlement`, which calls `LiquidityHub.processSettlementFor(...)` for each item. The queue drains. The trader's funds land. Nobody did anything.

In the recorded run, a swap created a queued obligation of about 34.79 (in the token's smallest units). After the maker settled and Reactive dispatched, the protocol queue went to exactly zero, matching the queued amount to the last digit. That precise reconciliation across two chains, with no human in the loop, is the milestone.

Why this matters

In the original announcement we said this integration would show Reactive handling "queues, aggregation, and batched execution across chains." Milestone 2 is the receipts. This isn't event mirroring, copying a log from one chain to another. It's a stateful, bounded, fault-tolerant, fairly-billed settlement engine that aggregates work across many users and acts exactly when conditions are met, with the accounting living entirely on-chain.

For Fiet, that turns asynchronous settlement from a UX tax into something that just works. For us, it's one of the most sophisticated things built on Reactive to date: not a toy, but infrastructure with real money moving through it on mainnet.

As more off-chain capital wants on-chain exposure, asynchronous settlement stops being an edge case and becomes the default shape of a lot of DeFi. If that's true, the automation underneath it can't be a bot someone forgot to restart; it has to be as trustless as the settlement itself. Fiet and Reactive just showed one way to build that. What's the next workflow waiting for someone to automate it properly?

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!

Reactive Network is entering a new era.

The first version of REACT tokenomics was built around an Ethereum-style model: no fixed ceiling, validator rewards issued over time, and every network fee burned through real usage. The logic was coherent. It made sense for a young network still proving the shape of the protocol.

But Reactive is no longer a network run by a single team.

The code is opening. The stack is moving to CometBFT. Validators will secure the network directly. Governance is being phased in. The Foundation is taking on long-term stewardship. Builders, validators, exchanges and token holders now need something stronger than a model they have to interpret.

They need a model they can verify. So REACT is moving from open-ended issuance to a fixed supply model.

The maximum supply will be 2.4 billion REACT. Reactive Network’s move to Omni fork will mark the transition to open source model where all code and changes will be visible publicly. 

This is not a cosmetic change. It removes discretion.

Under the old model, future validator rewards came from ongoing issuance. Under the new model, those future rewards are brought inside a fixed cap. No hidden mint path. No future supply curve to debate. No privileged key that can mint tokens later.

The point is simple: nobody should have to trust the team to handle future issuance responsibly.

Why the number is changing

The original public tokenomics used a 500 million launch supply and an open-ended validator reward model.

That meant the network could issue new REACT over time to pay for security. The redesign changes that. Instead of leaving future emissions open-ended, the tokens needed for validator rewards, ecosystem funding and long-term contributors are now made explicit from the beginning.

That is the trade.

The fixed number is higher than the original launch supply because future network incentives are now inside the cap rather than outside it. The benefit is that every future allocation becomes visible, capped and scheduled.

We calculated these figures to ensure security budget, ecosystem growth, and liquidity for new and existing exchanges will be accessible whenever and wherever needed. 

To be clear, existing holder balances will not change. No migration, swap, bridge, claim or wallet action is required.

What does not change

The fee burn stays.

Every protocol fee generated by Reactive Network is still burned permanently. 

That part of the original design survives because it was the right part.

Usage will reduce total supply.

The difference is that the burn no longer has to outrun uncapped future issuance. Under the new design, total supply starts fixed and can only fall through burns.

There is one important distinction. Total supply can only move down once the cap is live and minting is impossible. Circulating supply will still change as locked allocations vest. Those unlocks do not create new tokens. They release tokens from fixed, visible schedules.

Where the tokens go

The fixed maximum supply is 2.4 billion REACT.

Locked Supply Wallets and Contract Addresses:

Validator Rewards: 0x30F4F134296b5698b05A799c3d56959Bb30Cf604 (These will be moved to contracts at Reactive Network Omni Mainnet)

Ecosystem Development and Grants: 0xA07d990c2cA0e26D0239cCcc92279a8f02b1901C 

Core Contributors: 0x40d589db8c135602b836cbc14563f5a5b75ccbb1

The additional supply of circulating REACT gives access to tokens which may be required for the network to grow: liquidity across trading venues, inventory for new exchange listings and market-making, and reserve capacity for operational needs. REACT has to trade reliably enough for builders, users, validators and partners to access it without liquidity becoming a constraint as Reactive enters new markets.

Validator rewards

Validators receive 500 million REACT from a fixed allocation.

Validators and stakers will be paid from scheduled rewards paid from a pre-allocated pool. Validators secure the network, produce blocks, participate in consensus and support the move toward a more open validator set.

The schedule is intentionally long-term (96 months). Security incentives should not disappear after launch. Validators need a reason to stay aligned with the network over years.

At the end of the eight-year reward period, the allocation will be exhausted and no further REACT will be distributed from this pool. Validator compensation will then transition to the network’s fee market: a share of transaction fees will support validators, while a portion will continue to be burned. The objective is to move from a funded security budget to a network whose security is sustained by its own activity, without introducing further supply. 

If you hold REACT, the goal is for staking and delegation to become part of the network’s security model. That does not mean every holder has to run infrastructure. Delegation gives token holders a way to participate in network security by staking, without operating a validator themselves.

The validator reward schedule begins at Reactive Network Omni mainnet launch.

Core contributors

Core contributors receive 420 million REACT.

This allocation exists because Reactive is not finished. The codebase is opening. The consensus layer is changing. Governance is being phased in. The developer experience has to improve. The network needs people who stay with the protocol through that work, not just through a launch cycle.

This pool will not necessarily be distributed in real time. The unlock schedule is linear block-by-block, but will likely be built up and distributed only when needed for specific strategic initiatives. 

The principle is simple. Contributors should do well only if the network does well.

Ecosystem development and grants

The ecosystem allocation is 280 million REACT.

This is for the work the core team will not do alone: open-source tooling, developer grants, integrations, research, audits, infrastructure, documentation, community programs and applications built on Reactive.

As Reactive moves toward Foundation stewardship and phased governance, grants become part of the protocol’s growth engine. This pool exists to fund work that advances the network’s goals, strengthens the ecosystem and creates meaningful utility.

The dashboard

The tokenomics only matter if people can verify them.

Reactive public dashboard shows supply across chains, venues, vesting contracts, treasury wallets and allocation categories. 

It also shows total supply, circulating supply, burned supply, locked supply, vesting schedules, allocation wallets, bridge or wrapped supply across supported networks, market-making or liquidity wallets, Foundation and grants balances, and all relevant contract addresses.

You can find the dashboard here: https://portal.reactive.network/distribution

Why this matters now

This change fits the wider Reactive roadmap.

The code is opening. The network is moving to CometBFT. Validators are being introduced. Governance is being phased in. The Foundation is taking on long-term protocol stewardship.

Each step moves Reactive away from a single-company network and toward infrastructure other people can inspect, secure and govern.

Tokenomics has to move with it.

An open validator set cannot rest on ambiguous issuance. Governance cannot begin with a supply model people have to interpret. Exchanges and data trackers should not be left deciding what maximum supply means. Holders should not have to ask whether future minting is possible.

The answer should be visible.

The only variable left

Reactive exists to turn event logs into programmable triggers. Contracts should not sit passively waiting to be called. They should react to the on-chain world around them.

The same standard now applies to REACT.

No mint path. No future issuance. No spreadsheets. 

Fixed supply, visible schedules, permanent burn, and a network moving toward validators, open code and governance.

The economics are fixed, the only question left is what gets built.

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!

There's a question lurking underneath a lot of blockchain engineering that sounds almost too simple to be worth asking: when a transaction lands on a chain, how long until you can be sure it's never coming back off? Not "probably safe" but truly, irreversibly done.

For Ethereum today, the honest answer is somewhere around 13 to 16 minutes. For a Byzantine fault tolerant consensus engine like CometBFT, it's a second or two. That's an enormous gap, and it raises an obvious question: why doesn't Ethereum just do whatever CometBFT does and finalize fast too?

As it turns out, Ethereum desperately wants to. It has a multi-year research program and a string of planned hard forks aimed squarely at the goal, and it's finding the whole thing genuinely hard. The reason comes down to a single number. Ethereum has over a million validators; CometBFT-based chains run with a few hundred. The answer lives in a protocol called 3-Slot Finality, or 3SF, and in a stubborn physical bottleneck that turns out to be the whole story.

A Quick Recap on the Problem

To see why a million validators changes everything, it helps to hold the shape of Ethereum's finality story in your head. Its post-Merge consensus, Gasper, doesn't finalize a block the moment it shows up. A block earns a kind of provisional confirmation as votes pile up, but true, irreversible finality doesn't arrive until two of these voting cycles have passed, which is roughly 13 to 16 minutes. During that window, a block you thought was settled can still get reorganized away.

For sending tokens around, that delay is tolerable. For a rollup-centric future, where Ethereum is meant to be the settlement layer sitting underneath dozens of Layer 2s, it's a real bottleneck. As long as L1 takes fifteen minutes to finalize, any L2 sequencer or bridge offering faster "pre-confirmations" has to personally absorb the risk that those blocks get reorganized during that window. The fix everyone agrees on is to go after the problem at the protocol level: make the base layer itself finalize fast. The disagreement is about how.

Finalize in One Round

The intuitive answer is Single Slot Finality (SSF): take the vote-it-and-lock-it-in process that CometBFT already runs, and squeeze the whole thing into a single slot, so a block is proposed and finalized in one shot.

This is essentially what CometBFT pulls off, and Ethereum's proposed Minimmit design is its own version of the same one-round idea. CometBFT runs each block through a short, structured round of voting, and the block is final by the time it ends, with no waiting around for confirmations to accumulate. So if a one-round design like that is good enough to finalize blocks in a second on more than a hundred live chains today, the obvious question writes itself: why can't Ethereum just adopt it and be done?

A Million Validators

CometBFT-based chains typically run with somewhere between 50 and 175 validators. Ethereum's Beacon Chain has over a million.

That single difference changes everything, and the reason comes down to how voting works. For the network to agree on a block, validators have to tell each other how they voted. With a couple hundred of them, each one can just announce its vote to everyone else and nobody breaks a sweat. The trouble is that the number of messages doesn't grow gently as you add validators. It explodes. Think of a room where everyone has to shake hands with everyone else: five people is ten handshakes, but a thousand people is nearly half a million. A million validators all messaging each other directly would melt the network instantly.

So Ethereum doesn't let them. Instead, votes flow through aggregators, special nodes that work like a delegate for each table at a vast banquet. Rather than every guest shouting across the hall, each table's delegate collects the nearby votes, bundles them into one compact summary, and passes just that summary onward. Thousands of individual votes go in; one combined message comes out. That bundling is the only thing that makes agreement among a million validators thinkable at all.

Cost of Aggregation

Bundling solves the message explosion, but it quietly adds a delay, and that delay is the reason fast finality is so hard.

Think about what an aggregator actually has to do. First it waits to collect the votes coming in, which take time to travel across the network. Call one such network trip a delay, written Δ. Then it broadcasts the bundled-up result, which takes another Δ to reach everyone. So a round of voting that looks like it should cost one Δ really costs two, once you count both the gathering and the sending back out.

Now stack those costs up, as in the diagram above. A single-slot design needs a block proposed, then two separate rounds of voting (one to agree on the block, one to lock it in), and a final acknowledgment. With aggregation doubling each voting round, the whole thing comes to six network delays crammed into a single slot. And six Δ is a lot to fit into a few seconds. If the network slows even slightly, the slot runs out of time, the round fails, and the chain stalls. That's the trap that has kept true single-slot finality "great on paper, miserable in practice" for years. It's exactly the problem 3SF was built to escape.

Pipelining Trick

3SF's insight is to stop trying to fit everything into one slot. Instead of cramming all the voting into a single slot, it spreads the work across three consecutive slots and runs them like an assembly line, each block advancing to the next stage as a fresh one enters the first.

The clever part is how it avoids piling on extra messages. Older designs make every validator cast two separate votes per slot: one to pick the chain's head, one to push finality forward. 3SF folds them into a single vote that does both jobs at once: one message that says "this is the block I'm building on" and, at the same time, "I've seen enough agreement on the previous block to treat it as locked in." Half the traffic, same information.

Across the relay, a block moves through three stages. It's proposed and fast confirmed in the first slot, justified in the second as its votes get carried forward, and finalized in the third, written to irreversible history. Finality just trails the chain tip by a couple of slots.

There's a nice property hiding in that first step. Fast confirmation already makes a block economically safe well before it's technically final, because reversing it would require more than a third of all validators to vote two ways at once and get themselves penalized for enormous sums in the process. So for an everyday user, an exchange, or an L2 sequencer, the practical wait is short even though formal finality takes three slots.

One more trick keeps the relay from dropping the baton. Just before each vote, every validator briefly syncs to the same picture of the chain, handed over by the slot's proposer, so they're all judging from the same starting point.

The short version: everyone agrees on what they're looking at before they vote, so nobody can be tricked into voting on the wrong thing. Without this step, an attacker could feed different validators different information at just the right moments and keep them split between two competing chains indefinitely. Syncing everyone up first shuts that down: a built-in guarantee rather than the patchwork Ethereum leans on today.

The payoff is in the diagram above. 3SF runs one combined voting phase per slot instead of two, trimming the slot from SSF's 6Δ to 5Δ. And because the phases are pipelined rather than tightly coupled, a slowdown in the network delays finality for the affected blocks instead of halting the chain. That's the same "prefer delayed finality over a halt" instinct Gasper already has, worth contrasting with CometBFT's opposite call: it prioritizes correctness and pauses block production entirely if participation drops below a threshold. Different priorities, different failure modes.

The Catch That Sounds Familiar

For all its pipelining elegance, 3SF doesn't actually make the million-validator problem disappear. As the research candidly admits, that single voting phase still has to bundle over a million votes through peer-to-peer gossip within a few seconds, which still congests the network and saturates node bandwidth. Pipelining bought a smoother schedule; it didn't repeal the laws of networking.

So the 3SF research sets validator-set management aside as a separate problem. Two approaches are in play. Orbit uses a cryptographic lottery to pick a smaller committee to vote each slot rather than all million, cutting network load by an order of magnitude. Rainbow Staking instead splits stakers into "heavy" nodes that handle the bandwidth-hungry finality voting and "light" nodes that focus on censorship resistance without the constant signing burden. The current preference is to ship Rainbow Staking first, since it doesn't require reworking the consensus engine.

The punchline writes itself: to make finality fast at a million validators, Ethereum's leading proposals quietly involve not having a million validators vote every round.

Bigger Picture

3SF is one track of Lean Ethereum, a sweeping redesign that also folds in quantum-resistant signatures, SNARK-friendly execution, and a drop in the staking minimum from 32 ETH to 1 ETH. That last change would push the validator count even higher and make the bundling problem harder still, which is partly why these pieces have to ship together. As of mid-2026 it's all still research-and-testnet: the people building it describe full production as years out, with the caveat that better solutions may emerge along the way.

What's striking is the destination. The algorithms for fast finality have existed for years, and CometBFT runs one in production today. It's hard for Ethereum specifically because Ethereum chose a million validators, and the physics of bundling that many votes in seconds is a bottleneck no amount of protocol elegance erases. The most-researched consensus roadmap in the industry is arriving, committee by committee, at the same compact-set constraints smaller BFT chains started from years ago. Two philosophies meeting in the middle, from opposite ends.

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!

Season 5 is wrapping up. Our 3-month staking pool expires at block 5,649,633 (around 3 PM UTC on June 10th), and with it, we're opening the door to Season 6.

THe upcoming season looks a little different as it will run a single 1-month pool rather than the usual three. That's deliberate since we're planning to launch a new mainnet on CometBFT architecture later this summer, so we wanted a shorter, cleaner bridge into it. Once the new mainnet is live, we'll consider our staking options and might return to our familiar three-pool structure with 1-, 2-, and 3-month options.

The short version for newcomers: staking lets you lock up REACT for a fixed period and earn rewards for helping secure the network. Each season is a fresh round with its own pools and reward budget.

How Season 5 Stacked Up

Season 5 ran three pools, and the turnout spoke for itself:

That's 477 stakers and over 150M REACT locked in across the season.

How to Join

If you staked in Season 5:

1. Open the Reactive Token Portal and confirm your REACT wallet is connected.
2. Select the pool you're currently in.
3. Hit Restake and confirm the transaction to roll into Season 6.

If you're new:

1. Open the Reactive Token Portal and connect your REACT wallet.
2. Select the 1-month pool (the only one this season).
3. Enter the amount of REACT you'd like to stake.
4. Hit Stake and confirm the transaction.

Once staked, your REACT stays locked for the full duration of the pool. Principal and rewards unlock only when the pool concludes.

Key Dates and Numbers

Season 5 closes at block 5,649,633 on Wednesday, June 10th. Rewards don't distribute automatically. Be sure to claim yours through Reactive Token Portal.

Season 6 launches the very next block, 5,649,634, with a fresh reward pool of 1,000,000 REACT, and closes at block 6,055,034, around midday UTC on Monday, July 13th. We've timed this deliberately: the close lands early in the week rather than heading into a weekend, clearing the way for what comes next. Launching the Omni fork is the goal we're working toward, and we'll share exact timing as we get closer.

For technical details on Reactive Network: Reactive Docs.

For more details on tokenomics: REACT Tokenomics & Staking.

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!

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!

Somewhere beneath the surface of over a hundred blockchain networks, from Cosmos Hub to Osmosis to Celestia, there's a consensus engine quietly doing the heavy lifting. It's called CometBFT, and unless you've spent time wandering the Cosmos ecosystem, you've probably never encountered it. 

That's about to change. Projects outside of Cosmos are starting to adopt it, and we're one of them: Reactive Network is swapping out its entire Ethereum-style consensus stack in favor of CometBFT. 

So what is this thing, why does it exist, and what makes it different from the consensus approach Ethereum uses? Let's take a walk through it.

What a Consensus Engine Actually Does

Before we get into mechanics, it helps to be clear about what we're even talking about. A consensus engine is the part of a blockchain that gets all the nodes (independently operated computers scattered around the world) to agree on what has happened and in what order. Which transactions are valid? What's the next block? Who gets to propose it?

Every blockchain needs answers to these questions, and the consensus engine is the system that produces them. Think of it as the parliamentary procedure of a decentralized network: not the legislation itself, but the rules for how votes happen and how decisions become official.

What makes consensus design interesting is that the participants don't trust each other. Some might be offline. Some might be actively trying to cheat. The engine has to produce reliable agreement anyway.

Tendermint Legacy

CometBFT is the direct descendant of Tendermint Core, a consensus algorithm that Jae Kwon began designing in 2014, before Ethereum even launched. The idea was to take decades of academic research on Byzantine fault tolerance (BFT) and turn it into a practical blockchain consensus protocol. "Byzantine fault" sounds intimidating, but the concept is simple: a participant that doesn't just crash, but actively misbehaves, sending contradictory messages, proposing invalid data, or trying to manipulate the outcome. CometBFT keeps the network safe as long as fewer than one-third of validators are acting this way.

In 2023, the project was forked from Tendermint Core and relaunched as CometBFT, maintained by Informal Systems. Along with the rename came meaningful protocol upgrades, including ABCI++ (more on this shortly) and improved developer tooling.

Reaching Agreement

Here's where it gets fun. CometBFT's consensus process for each new block follows a structured round with three phases: Propose, Prevote, and Precommit. The diagram above shows the flow, but a few details are worth mentioning.

The proposer for each round isn't random. It's selected through a deterministic rotation weighted by stake, so the network always knows whose turn it is. If a validator receives a block it considers invalid, or never receives one at all (maybe the proposer went offline), it can prevote "nil", signaling there's nothing worth committing this round. The protocol also includes a locking mechanism that prevents validators from flip-flopping between conflicting blocks across rounds, which is essential for blocking a subtle class of double-spend attacks.

The entire process typically completes in a matter of seconds. For our implementation, the target is roughly one-second block times.

Ethereum's Approach

To appreciate what CometBFT does differently, it helps to understand how Ethereum handles the same problem. Ethereum's post-Merge consensus protocol is called Gasper, a combination of two components: LMD-GHOST (a fork-choice rule that picks which chain tip to build on) and Casper FFG (a finality gadget that periodically locks in history as irreversible).

As the diagram shows, the structure revolves around slots and epochs. A block that appears in its slot is not final. It has probabilistic confirmation (more attestations make it more likely to stick), but true finality doesn't arrive until two full epochs have passed. That's roughly 12.8 minutes. During that window, chain reorganizations are possible: a block you thought was confirmed can get replaced by a competing fork.

For most everyday Ethereum usage, like sending tokens or interacting with a DeFi protocol, this delay is tolerable. Users typically treat a few confirmations as "good enough". But for certain use cases, probabilistic finality is structurally inadequate.

Reorg Problem in Cross-Chain Systems

This is where our own transition makes for a useful illustration. Reactive Network is built around reactive contracts, which are smart contracts that listen to events on other EVM chains (Ethereum, Base, Arbitrum, and so on) and automatically execute logic in response. Think of it as an automation layer: when something happens on chain A, a reactive contract can trigger an action on chain B. The diagram below shows what can go wrong under probabilistic finality, and how CometBFT changes the picture.

Under CometBFT, our blocks achieve instant finality. Once validated, a block can't be reorganized. The origin chains we listen to still have their own finality characteristics, but our layer no longer introduces additional uncertainty.

We describe this as the distinction between reactive finality, which CometBFT provides on our chain, and origin finality, which depends on whichever chain we're monitoring. The former is now deterministic. The latter remains whatever the origin chain provides.

ABCI

CometBFT separates the consensus engine from the application logic entirely. The consensus engine handles networking, peer discovery, block propagation, and the voting protocol. The application, whatever you want the blockchain to actually do, communicates with it through a clean, standardized interface called ABCI (Application Blockchain Interface). Teams can build their application in whatever language and framework suits them and just plug it into CometBFT for consensus, without thinking about peer-to-peer networking or vote counting.

This is the approach that allowed CometBFT to run under an incredibly diverse set of chains in the Cosmos ecosystem. For us, it's especially useful because ABCI's hook-based design lets us implement our event-listening primitives directly at the consensus layer, rather than bolting them onto infrastructure that wasn't designed for that purpose.

Instant Finality Isn't Free

Every consensus design involves trade-offs, and CometBFT is no exception as its finality guarantee depends on a known, relatively compact validator set. Every validator participates in every round of voting, which is what makes single-block finality possible. That model works well with dozens or even a few hundred validators.

Ethereum takes a different path: its Beacon Chain supports over a million validators, trading finality speed for a much broader participation base. CometBFT-based chains typically operate with 50 to 175 active validators.

The two approaches also handle network stress differently. In CometBFT, the chain prioritizes correctness: if participation drops below the required threshold, block production pauses until enough validators return. Ethereum's fork-choice rule keeps producing blocks under heavier participation drops, though those blocks won't be finalized until conditions stabilize.

These are genuinely different design priorities. Ethereum optimizes for large-scale decentralization and censorship resistance. CometBFT-based chains optimize for performance, finality speed, and architectural flexibility. Neither is universally better. They're built for different contexts, and choosing between them depends on what the application needs most.

Cosmos Ecosystem

CometBFT is the foundation of the Cosmos vision, sometimes called the "Internet of Blockchains": many specialized chains, each running its own instance of CometBFT with its own validator set and application rules, communicating through a shared protocol called IBC (Inter-Blockchain Communication). The result is a network of networks, each sovereign but interoperable.

Our adoption of CometBFT, while maintaining full EVM compatibility, is something of a hybrid. We take the developer experience and tooling of Ethereum (Solidity, Hardhat, Foundry, Remix) and pair it with the consensus performance of Cosmos. You write the same smart contracts you'd write for any EVM chain, but the engine underneath is playing by different rules.

Going Forward

The trend is worth watching. Ethereum itself has been actively researching "single-slot finality", an approach that would make its consensus behave more like CometBFT's, finalizing blocks within a single slot rather than waiting two epochs. It's one of those moments where two different design philosophies are converging toward similar conclusions from different starting points.

At Reactive Network, we're already there. Our Omni fork transition replaces the old Geth+Prysm stack with CometBFT while preserving all existing state, balances, and contracts. Lasna Testnet running the new architecture is live and open to the public, being put through its paces by both our team and the community. Mainnet follows, and we'll have more to share on that timeline soon.

Consensus design has historically been one of those topics that feels deeply esoteric until it suddenly isn't. The moment your cross-chain transaction gets caught in a reorg, or your callback fires based on an event that no longer exists, or you're waiting 13 minutes to know if your transaction is truly irreversible, that's when the consensus layer stops being an abstraction and starts being the thing that determines whether your system works or doesn't.

CometBFT is one answer to those problems. It's battle-tested across hundreds of chains, it's architecturally elegant in ways that reward curiosity, and it's increasingly showing up in places you wouldn't have expected it a few years ago. If you're interested in how blockchains actually work under the hood, not just what you can build on them, but how they reach agreement about reality, it's well worth your time to dig in.

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!

Today, May 25th, we're rolling out the Omni fork for Reactive Lasna. The first testnet built on Reactive Network's new CometBFT-based architecture is live and ready for developers to start building, testing, and experimenting with the changes we've been working toward over the past several months. 

If you've been following our technical roadmap, this is where the technical plans become something you can actually deploy contracts to.

Major Updates

CometBFT consensus with full EVM compatibility. The consensus layer has been replaced, but the execution environment remains standard EVM. Your Solidity contracts, your tooling, your workflows – all unchanged. CometBFT gives us instant block finality (no more reorgs) and block times of approximately 1 second, down from the previous ~7 seconds.

No more RVM. Reactive contracts no longer require dual deployments across RVM and Reactive Network. Everything deploys to a single environment, the way standard smart contracts do. If you've found writing reactive contracts cumbersome in the past, this is a significant simplification. The developer experience is now much closer to what you're used to on any other EVM chain.

Standard tooling works out of the box. With the RVM gone, there's no need for custom RPC methods or manual trace inspection. Hardhat, Foundry, Remix, Blockscout, Foundry's `cast` – everything works as expected.

Existing subscription and callback formats supported. Subscription call signatures remain the same. Callbacks in the old format will continue to work. New contracts can use the new system contract interface for a cleaner experience, but nothing is being broken.

Where to Dig in 

We're particularly interested in feedback on:

• Deploying existing contracts and verifying they behave as expected on the new architecture
• The new reactive contract development flow without RVM
• Interaction with the new system contracts for subscriptions and callbacks
• General tooling compatibility across your development setup

How to Connect

Head over to Reactive Docs to connect instantly, or plug in the network details manually:

• Network Name: Reactive Lasna
• RPC URL: https://lasna-omni-rpc.rnk.dev
• Chain ID: 5318007
• Currency Symbol: lREACT
• Block Explorer: https://lasna-omni.reactscan.net

Lasna testnet runs the exact architecture mainnet will use. Every piece of feedback you give directly shapes what ships to production. 

Key Personnel Update: Thank you to our departing CEO Rong Kai Wong

Today we announce that, by mutual agreement, Rong Kai Wong is stepping down from his role as CEO of Reactive Network.

Rong Kai has been with this team since the PARSIQ days, first as COO and then as CEO across three product iterations. Under his leadership, Reactive Network grew from two use cases at launch to more than sixty within a year, and the protocol helped establish reactive contracts as a category in their own right. Rong Kai pushed consistently for accountability, dedication and transparency in everything Reactive Network did, and the protocol is stronger for it.

This transition comes as Reactive Network moves into its next chapter of growth and leadership. Reactive Network has historically operated with a distributed leadership structure between executive leadership, the Board, and core contributors, and the network is fully prepared for its next operational phase.

As set out in our recent roadmap, the protocol is decentralising: open-sourcing the codebase, migrating to CometBFT, and shifting decision-making toward the Foundation, contributors, and community governance. Within this framework, the Foundation takes on day-to-day operational matters, while strategic governance previously held at the Board transitions to the DAO and community.

Going forward, Daniil Romazanov (CTO) will lead the delivery and operations of Reactive Network’s Omni fork through the Foundation. 

Rong Kai remains deeply supportive of the vision and technology being built at Reactive Network. The transformational technology, created by a team of brilliant engineers, will change the way blockchain operates at a fundamental level. He looks forward to seeing the next generation of capabilities reach mainnet, and wishes the colleagues he has worked alongside for the past five years every success in the chapters ahead.

The work continues.

Reactive Network & Rong Kai Wong

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!

Reactive Network is getting a new engine. We're calling this the Omni fork. The consensus layer, the developer experience, and the way reactive contracts work are all being rebuilt. This document covers the technical specifics: what's changing, what stays the same, and what it means if you're building on Reactive today or planning to.

The short version: Reactive remains a fully EVM-compatible chain. Your existing contracts keep working. But the infrastructure underneath is being replaced with something faster, simpler, and significantly easier to build on.

Geth+Prysm out, CometBFT in

Reactive Network's Legacy architecture runs on an Ethereum-style consensus stack (Geth+Prysm).  We're replacing the consensus layer with CometBFT, the engine behind most Cosmos ecosystem chains, while preserving full EVM compatibility. Solidity contracts, Ethereum tooling, familiar development workflows – all unchanged. CometBFT handles how the network reaches agreement on blocks; everything else stays the same.

Three things improve immediately.

Instant finality. On Geth+Prysm, reorganizations can happen: a confirmed block gets replaced by a competing one. For Reactive, that's a structural problem, not just a nuisance. A callback sent to a destination chain like Base could be triggered by a transaction that later gets reorged away, leaving an action on one chain caused by something that no longer exists on another. CometBFT eliminates this. Once a block is validated, it's final.

Faster blocks. Block time drops from roughly 7 seconds to approximately 1 second. Callbacks trigger sooner, cross-chain workflows complete faster, and overall network responsiveness improves significantly.

Architectural flexibility. CometBFT's hook-based design lets us implement Reactive's event-listening primitives directly at the consensus layer, rather than working around limitations in infrastructure that wasn't designed for this use case.

Finality in the New Architecture 

There are two kinds of finality that matter for Reactive, and they work differently.

Reactive finality is what CometBFT gives us. Once Reactive Network validates a block, that block is permanent. No reorgs, no competing forks. This is a direct upgrade from Geth+Prysm, where reorgs could and did happen.

Origin finality is about the chains Reactive listens to. When Reactive's Sequencer observes an event on, say, Ethereum mainnet, it treats that observation as canonical. If Ethereum later rolls back the block containing that event and replaces it with a different one, the sequencer doesn't retroactively invalidate its earlier observation. Its position is: "I witnessed both. Both are real from my perspective".

This model carries over unchanged from the current system. The sequencer has always worked this way, and it will continue to. In later phases we may explore decentralizing the sequencer, but the main principle remains: once the network agrees it has observed an event, that observation is final.

No More Dual Deployments

This is the change that developers will feel most directly, and it's a significant simplification.

Under the Legacy architecture, writing a reactive contract means deploying to two separate environments: the RVM (ReactVM) and the top-level Reactive Network (RNK). Your contract logic splits across both, with state living in two places and callbacks routing between them. If that sounds cumbersome, it is. It's been the single steepest barrier to entry for developers who want to build reactive applications.

Under the Omni fork, the RVM is gone. Reactive contracts deploy to a single environment: Reactive Network. There's no dual state to manage, no separate RVM-side initialization, no callbacks from RVM back to RNK. One contract, one deployment, one mental model.

For anyone who's written a standard Solidity contract, the new reactive contract experience should feel immediately familiar. You're writing a smart contract that happens to have event-listening superpowers, not learning a parallel deployment model on top of everything else.

Developer Tooling 

The RVM removal has a ripple effect across the entire developer toolchain, and it's almost entirely positive.

Previously, we provided custom RPC methods to emulate transactions inside the RVM and inspect traces. In practice, these were clunky. They didn't work with mainstream smart contract tooling and required everything to be done manually. That friction is eliminated. With reactive contracts living in standard EVM, every major development tool works out of the box: Hardhat, Foundry, Remix, whatever your team already uses.

The block explorer story gets simpler too. Reactscan no longer needs to reconcile separate transaction and block views across RVM and Reactive Network. Data on Reactscan will look the same as on any other EVM chain, and developers can use familiar tools like Blockscout and Foundry's `cast` to inspect on-chain state.

Subscriptions and Callbacks

If you have existing reactive contracts, here's what you need to know.

Subscriptions keep the same format. New contracts will register them through a new system contract, but the call signature is identical. If you know how to set up subscriptions today, you know how to set them up tomorrow.

Callbacks in the old format will be supported indefinitely. Your existing contracts won't break. The difference in the new model is that emitting a callback no longer routes through the RVM. It happens directly on Reactive Network. For new contracts, instead of emitting a raw event, you can simply call the appropriate method on the system contract. Under the hood it still emits an event, but the developer-facing experience is more intuitive: you call a contract, it handles the rest.

Callback delivery to destination chains works the same way it does today. Reactive Signer posts transactions to the destination network, where they pass through a callback proxy. No changes there.

Destination callback reverts are unchanged as well. If a callback reverts on the destination chain, handling that remains the recipient's responsibility, same as before.

Gas and Payment Models

At launch, the gas model is unchanged. Everything works the way it does now. But with the RVM removed and new system and proxy contracts in place, we can iterate on payment models in ways that weren't practical before.

We're working on new callback payment options. For example, a developer could tell the system contract: "I want to pay for the destination-chain callback upfront, query the oracle for the cost, and settle now". Alternatively, callbacks could be paid for using REACT directly. That second option introduces some complexity around price volatility between payment and execution, so we'll need to address the security implications before shipping it, likely through some form of pre-payment mechanism.

These new payment models will roll out gradually. The current gas model will remain available for the foreseeable future. Nothing is being taken away; options are being added.

EVM Compatibility

Reactive Network will be fully EVM-compatible, targeting Solidity 0.8.29. Contracts compiled with earlier Solidity versions should work as expected. All custom precompiles are being removed. From an opcode perspective, Reactive will be a standard EVM chain. The only precompiles that remain are internal to the system contracts, and developers won't encounter them under normal circumstances.

This is a deliberate move toward convention. Previously, contracts had to be written in somewhat counter-intuitive ways to function as reactive contracts. That's no longer the case. Standard Ethereum smart contracts without any reactive features deploy and run without modification. If you can deploy a Uniswap pool on Ethereum, you can deploy it on Reactive, no changes required.

State During the Transition

Everything carries over. All existing state, account balances, deployed contracts, contract storage, from Legacy to the Omni fork intact. There is no new token, no swap, no claim process.

During the transition itself, there will be a brief disruption on the order of minutes. Our goal is zero lost callbacks: any callbacks arriving during that window should not be lost, only delayed.

What Remains Unchanged 

It's worth being explicit about what stays the same, since not everything is being rebuilt.

Subscription formats remain identical. Callback delivery mechanics are unchanged. The gas model persists at launch. Old reactive contracts continue operating as expected. Destination callback revert handling stays the recipient's responsibility. There are no limits on subscriptions per contract. Payload size limits continue to be determined by the destination network.

The changes are significant, but they're concentrated in the consensus layer and the developer-facing architecture. If you're a user or a contract that just consumes Reactive's capabilities, the transition should be largely invisible.

Looking Ahead 

The immediate priority is completing the CometBFT integration with the EVM execution layer and finalizing the new system contracts that replace the RVM. Everything else depends on this.

From there, full testnet rehearsals using production state to verify that all existing contracts, balances, and storage carry over correctly. Once the testnet is stable and the tooling has been independently audited, we move to mainnet cutover: Legacy's state gets packaged into the genesis of the Omni fork chain, so Reactive continues from where it left off.

After mainnet, newer callback payment models, potential Sequencer decentralization, and expanded callback configuration options become active areas of development, rolled out incrementally as each component is ready.

If you're building on Reactive and have questions about how any of this affects your contracts, reach out. We'd rather address concerns early than have them surface during the transition.

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!

We spent 2025 building, shipping, and watching a growing cohort of developers push the network forward, stress testing its functionality. As we close out this inaugural year, we've taken stock: what's working, what needs improvement, and where this goes from here.

This roadmap is a story in three parts. What we built. What builders told us. And how we're improving to meet the needs of the market.

The Vision

Every action on a blockchain leaves a trace. Every swap, liquidation, cross-chain transfer, vote, and deposit is emitted as an event log. These logs are some of the richest data on-chain, but today most of that data is exhaust. Other smart contracts, even on the same chain let alone another, cannot act on it. Blockchains remain passive: contracts wait for someone, or something, to call them.

Our goal from the start is to turn event logs into valuable, actionable data that can automate smart contracts trustlessly and seamlessly across chains, without any off-chain infrastructure. Any contract on any supported chain can subscribe to any event on any other supported chain and respond to it automatically without offchain bots or centralised relay.

When event logs become first-class programmable primitives, a whole category of workloads that currently depends on fragile off-chain glue moves on-chain. Bots become smart contracts. Relayers become callbacks. Centralised infrastructure becomes trustless code.

That's the vision. Everything that follows remains in service of it.

Part 1: What we Built, What Builders Told us

Reactive was built entirely in-house. That setup made sense early on: it let us move fast and ship without waiting for a wider developer community consensus.

Over the past year, that changed. Teams started building real things on Reactive: trading infrastructure, cross-chain liquidity monitoring, yield vesting, prediction-market settlement, arbitrage defences. What they have in common is that they'd be much harder, or impossible, to do any other way.

After the latest UniChain builder cohort, we ran an anonymous survey and combined the results with detailed feedback from teams we work closely with. The concept is working. 

One builder: "I replaced what would have been a Gelato keeper bot + AWS Lambda + a monitoring dashboard with a single RSC file and a 0.01 ETH deployment. That's a real architectural win." 

Another framed it: "Event-driven smart contracts that span chains. That's a genuinely new programming model, not just another bridge or oracle." A third, more directly: "The core primitive is the most interesting thing in cross-chain infra right now." Yes, that's a direct quote.

Builders also pushed through real friction to use it. Several told us they'd use Reactive again, that the concept is "strong enough that developers will push through the rough edges." 

This last quote is maybe the most revealing. Reactive Network is unique and directionally game-changing, but we don't want adoption to depend on developers being willing to grind through rough edges.

Part 2: Where we Must Progress

The specific frictions clustered into three underlying problems. Each points at a structural limitation, and each is what the roadmap below is designed to fix.

The consensus layer doesn't fit the use case. Reactive's core job is sending callbacks to external chains based on events on other chains. That job demands two things above all else: finality (once a triggering transaction is confirmed, it stays confirmed) and speed. Our current Ethereum-style proof-of-stake setup delivers neither as strongly as the market requires. If our network reorganises, a callback we've already sent can end up caused by a transaction that no longer exists on the origin chain. Block times sit at roughly 7 seconds, with more added by relay latency. For cross-chain infrastructure, both of these are the wrong trade-offs.

A closed codebase has hit its ceiling. The most consistent strategic question from builders was some variant of "Can we see the code?" Critical infrastructure on top of a black box is a hard sell on blockchain, especially when the black box is the piece automating your (or your users’) transactions. The closed codebase is also why the developer experience gaps have persisted: local testing, debugging, deployment tooling, faucet flows, gas model docs. Each is fixable. The friction has been fixing them at scale when you're the only team who can touch the code. As one respondent put it: "The technology is ahead of the documentation."

A single-company network can't credibly claim decentralisation. Node operators told us repeatedly they'd run Reactive validators, but not for a network operated by one company. The same logic applies to governance: token holders need a path to real authority, not advisory input into decisions one team ultimately makes. Without that path, long-term credibility has a ceiling.

These problems reinforce each other. Which is why the fixes below have to come together.

Part 3: What we're going to do about it

Opening the Code

Every repository required to run, validate, or build on Reactive Network will be publicly available under a permissive open-source licence (Apache 2.0 or MIT). Full stack, no staged rollout, no "core stays private" caveats. You can't have independent validator teams without readable code. You can't have community governance over a protocol no one can inspect. And you can't fix the documentation cliffs and silent failure modes without letting the developers hitting them see the actual code.

The repositories will live under a GitHub organisation (reactive-network/) with contribution guidelines, tagged issues for newcomers, and funded bounties. We'll also establish a formal path from casual contributor to Core Contributor: people and teams with merge rights and eligibility for ongoing protocol funding.

Moving to CometBFT

This is a tech-stack upgrade, not a new chain. $REACT continues as the gas token with no action required for holders. Reactive remains fully EVM-compatible: same Solidity contracts, same tooling, same developer experience. What changes is the consensus layer underneath.

CometBFT, the consensus engine behind most Cosmos-ecosystem blockchains, gives us three things which make it the most suitable for our mission:

1. Instant finality. Once a block is confirmed, it's confirmed. No reorganisations, no rollbacks.
2. Faster blocks. From ~7 seconds today to approximately 1 second. Reducing blocktime by ~85%.
3. Architectural flexibility. Cleaner integration points to embed Reactive's event-listening logic closer to consensus.

Crucially, this isn't a new chain starting from zero. It's a continuation of the existing network with all its state (every account balance, every deployed contract, every piece of storage) carried over intact. No new token. No swap. No claim process. The transition will be announced well in advance, rehearsed on testnet with real production data, independently audited, with a verification period and rollback plan. We're designing the shift so that no callbacks are lost and all pending outcomes reach their destination chains throughout the swap.

Sequencer Upgrade

Readers following Reactive closely may be wondering where the previously described Sequencer fits in. When we wrote about it in October, the plan had two parts: a new sequence format (CustomSequence) to ingest non-EVM data, and a move toward permissionless data ingestion so external teams could bring their own chains to Reactive.

We have made the decision that a Sequencer upgrade is far more impactful when built upon a new techstack foundation. Right now, our network can occasionally “change its mind” about recent transactions, which makes it hard to clearly separate what’s final and what’s still in progress.

If you try to layer additional, less reliable external data on top of that it can create yet more uncertainty.

There’s also another challenge. If we want to let anyone bring in data from outside the network, we need a way to hold them accountable if that data is wrong. That requires a proper system of validators who put value at stake and can be penalised for bad behaviour. In other words, it requires a more mature and robust network setup than we have today.

CometBFT is a precondition which will make the functionality unlocked by the Sequencer upgrade even more powerful. Once CometBFT is stable on mainnet, the Sequencer becomes the next major milestone, and the path to a genuinely multi-ecosystem Reactive gets much shorter.

A New Organisational Structure

Reactive Foundation is a new non-profit entity serving as long-term steward of the protocol. It manages the treasury, owns the GitHub organisation, runs the grants programme, and handles operational matters. Its board will initially include Reactive leadership and independent members, with community-elected seats added as governance matures.

Reactive Governance uses a dual-track model. One track is open to all token stakers and handles ecosystem decisions (treasury, grants, community initiatives). The other, composed of recognised technical contributors, handles protocol-level decisions (upgrades, parameter changes, security-critical matters). Major changes require both tracks to agree. This prevents two failure modes we've seen elsewhere: technically unsound proposals passing because they're financially motivated, and expert decisions that bypass the broader community.

Under the new model, $REACT takes on two new roles alongside gas: validators bond it to participate (with slashing for misbehaviour), and staked $REACT confers voting rights in the community track. The token economy is being rethought accordingly, and we'll share more detail as it matures.

Validators and Safeguards

The new chain launches with 7–15 genesis validators. The Foundation operates one or two, explicitly not a majority; the rest are established ecosystem operators selected for reliability, geographic distribution, and willingness to participate in governance. The set expands over three to six months as the network demonstrates stability.

Early governance can be fragile, so a few time-limited guardrails are in place: Foundation veto authority on governance proposals for the first 18 months (each veto publicly justified), critical parameters locked for the first year, and Foundation-only upgrade proposals for the first 12 months. All sunset automatically. Large treasury disbursements require community approval from day one.

The Roadmap and Phased Timeline

• Months 1–2: Preparation. Codebase audit. Foundation setup begins. Transition tooling underway.
• Months 2–4: Public repositories go live.
• Months 3–5: Foundation operational. Treasury funded. Grants committee active.
• Months 5–7: Full transition rehearsals on testnet. External audit.
• Months 6–8: CometBFT testnet live with genesis validators.
• Months 7–9: Grants programme relaunch, weighted toward protocol development.
• Months 9–12: Mainnet cutover.
• Months 11–14: Dual-track governance activated on-chain.
• Months 14–18: Delegation layer introduced.
• Months 18–24: Foundation veto sunsets. Full community governance operational.

Conclusion

The thread running through all of this is a shift from trust Reactive to trust the protocol. Open code anyone can inspect. A consensus mechanism that provides the guarantees cross-chain infrastructure demands. Governance structures that give the community real authority, phased in at a pace that prioritises getting it right over getting it fast.

The sequencing is firm; the dates are estimates. The community should hold us to the outcomes, not the timeline.

The work is underway. The first commits hit GitHub in the coming weeks. See you there.

About Reactive Network

Reactive Network is an EVM automation layer built around Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation.

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding 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!

In DeFi Hack Postmortem Part 1, we looked at how Reactive Contracts address the root cause of bridge exploits: the gap between what a validator claims has happened and what actually has happened on-chain. That's the prevention side: stopping the hack before it starts.

But prevention only works if you control the infrastructure. Most DeFi users don't. They're downstream, holding positions on lending protocols like Aave, using tokens like rsETH as collateral, and trusting that the systems above them will hold.

On April 18th 2026, that trust broke. And for users with rsETH-collateralized positions on Aave, the question wasn't whether the bridge could have been built differently. It was: how do I get out before everything collapses?

This is where Reactive Contracts solve a different problem entirely. Not bridge security but automated, on-chain self-defense.

Aave's Collateral Damage

As covered in Part 1, the Kelp bridge exploit drained 116,500 rsETH in a single block. But the real story for Aave users wasn't the exploit itself. It was what happened next.

Aave froze rsETH markets within hours. That freeze didn't just contain the attacker's positions. It locked in every legitimate user who had rsETH exposure.

What followed was a liquidity cascade. Whales and large funds pulled billions from Aave's pools. WETH reserves hit 100% utilization across Ethereum, Arbitrum, Base, Linea, and Mantle, with idle balances below $20 on every chain. The remaining depositors couldn't withdraw. Some borrowed roughly $300M against their own trapped stablecoin deposits at steep losses, just to access liquidity.

For ordinary users with rsETH positions on Aave, the window to act was measured in minutes. If you weren't watching the chain at the exact moment the exploit happened, you were already too late.

Speed Gap

DeFi lending works on health factors. Your health factor is the ratio between the value of your collateral and what you've borrowed. Drop below 1.0 and you're liquidatable. Most users try to maintain a buffer, keeping their health factor at 1.5 or 2.0 to absorb normal price swings.

But bridge exploits aren't normal price swings. When the Kelp bridge was drained, the situation didn't unfold over hours or days. The adapter balance went from 116,723 rsETH to 223 rsETH in a single block. The attacker's positions on Aave settled with health factors between 1.01 and 1.03, razor-thin margins that any small price movement would trigger.

For legitimate users, the timeline was brutal. The exploit happened. News spread. Panic set in. Whales moved first, draining liquidity pools before smaller users could react. By the time most people understood what was happening, WETH utilization was at 100% and withdrawals were frozen.

This is the core failure mode that Reactive Contracts address on the user side: the assumption that human attention and reaction time are sufficient to manage DeFi risk.

They aren't. Markets move faster than people. Exploits move faster than markets.

Reactive Defense

For Aave position protection, a Reactive contract works like this:

It's the difference between a smoke alarm that activates the sprinkler system and one that just beeps.

Consider a user who held rsETH as collateral on Aave with a health factor of 1.5 before the exploit.

Without a Reactive Contract: The exploit drains the bridge. rsETH begins to depeg. The user's health factor drops. By the time they notice (if they notice at all) WETH pools are at 100% utilization. They can't withdraw, can't repay easily, and can't add collateral from external sources because the markets are frozen. They're trapped, watching their position deteriorate with no way to act.

With a Reactive Contract: The RC detects the health factor dropping toward the trigger threshold. Before WETH pools are fully drained, before markets are frozen, the RC executes the protective action: repaying debt, adding collateral, or both. The position is stabilized or unwound while liquidity still exists. The user doesn't need to be online, doesn't need to be watching, doesn't need to compete with whales for exit liquidity.

Timing is key. In the Kelp aftermath, the first movers (whales and large funds) pulled out billions before most users could react. Reactive Contracts level that playing field. An automated on-chain response doesn't sleep, doesn't panic, and doesn't wait in line. It executes at the speed of the chain.

Why Bots Fall Short

The obvious counter-argument: why not just use an off-chain bot to monitor your position and act when needed? Off-chain bots are better than nothing. But they have structural weaknesses that Reactive Contracts don't share.

Bigger Picture

The Kelp exploit exposed something the DeFi ecosystem has been slow to acknowledge: composability is also a liability.

When everything works, composability is DeFi's superpower. Tokens flow between protocols. Yield stacks on yield. Collateral moves across chains. But when one layer fails, the damage propagates through every protocol that touches it. A bridge exploit becomes a lending crisis becomes a liquidity crisis becomes a confidence crisis.

Reactive Contracts don't fix composability risk at the protocol level. That requires the kind of architectural changes discussed in Part 1. What they do is give individual users the ability to defend their own positions, automatically, at the speed of the chain, without depending on protocol governance to act fast enough, or whale liquidity to still be available, or their own attention to be perfectly timed.

In a system where a single forged message can cascade through the entire DeFi lending stack in hours, that kind of automated self-defense is must-have infrastructure.

About Reactive Network

Reactive Network is an EVM automation layer built around Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation.

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding 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!

On April 18th, 2026, someone sent a fake message to a cross-chain bridge and walked away with $293 million.

The target was Kelp DAO, a liquid restaking protocol on Ethereum. The bridge connecting it to other blockchains was configured with a single validator, one computer responsible for confirming whether incoming cross-chain messages were real. The attacker forged a message claiming tokens had arrived from another chain. The bridge believed it and released 116,500 rsETH, roughly 18% of the token's supply.

No encryption was broken. No smart contract bug was exploited. The system worked exactly as designed. It just wasn't designed to handle a lie.

DeFi's Recurring Disaster

Cross-chain bridges let users move tokens between blockchains. The basic flow is a bridge that locks tokens on one chain, sends a message to the other chain confirming the lock, and releases equivalent tokens on the other side.

The entire model depends on that middle step, the message being truthful. Most bridges delegate message verification to a set of validators or signers. If enough of them are compromised, tricked, or (as with Kelp) if there simply aren't enough of them, the bridge will release tokens against fabricated claims.

This isn't a new problem. Ronin lost $625M this way. Wormhole lost $320M. Nomad lost $190M. The pattern repeats because the underlying architecture hasn't changed: bridges still rely on small groups of external parties to attest that something happened on another chain, and attestation can be forged.

Root Cause

Every major bridge exploit shares the same structural flaw. The destination chain doesn't independently verify what has happened on the origin chain. Instead, it trusts a relayed message: a claim made by a third party that an event occurred.

The flow looks like this:

The security of the entire system sits in step 2. Compromise the validator (or, in Kelp's case, simply have only one), and the bridge can’t tell the difference between a real transfer and a fabricated one.

This is what makes bridge exploits so much larger than typical DeFi hacks. The bridge isn't checking whether tokens have actually been locked. It's checking whether a trusted party says they have.

Reactive Model

Reactive Contracts, built on Reactive Network, take a structurally different approach to cross-chain communication. Instead of relying on validators to relay messages between chains, they subscribe directly to on-chain event logs and execute logic when specific conditions are met.

Here's what that changes in practice:

In a traditional bridge, you trust validators to accurately report what has happened. With Reactive Contracts, the contract reads directly from the origin chain's own event logs.

Trust lives in the origin chain's own consensus, not in an external validator set. To fake an event, you'd need to compromise the origin chain itself.

Applied to Kelp

In the Kelp exploit, the attacker forged a LayerZero packet that appeared to confirm a token transfer. The single validator approved it, and the bridge released $293M in rsETH from its Ethereum-side adapter in a single block.

Under a Reactive Contract model, there's no packet to forge. The contract would be watching for a specific burn event on the origin chain. If no tokens have actually been burned, there's no event in the log. No event, no release. The attack vector simply doesn't exist.

Beyond eliminating the forged-message problem, Reactive Contracts can enforce additional conditions before releasing tokens: checking that burn amounts on the origin chain match the expected release on the destination, verifying that the originating contract is recognized, enforcing rate limits or volume caps, all within the same execution flow. These aren't bolted-on safety mechanisms. They're part of how the Reactive contract operates.

Architectural Comparison

That's a categorically different security boundary. It moves the trust anchor from a small external validator set to the consensus mechanism of the origin chain, which is exactly the security guarantee users believe they are getting when they use a bridge in the first place.

Going Forward

The Kelp incident has already triggered some recovery. Arbitrum's Security Council froze $71M in ETH linked to the attacker. Aave is stress-testing its Umbrella bad-debt backstop for the first time in production. Governance proposals are flying across every affected protocol.

But the pattern won't stop until the architecture changes. As long as bridges rely on attested messages (claims about what has happened on another chain rather than direct verification), they'll remain the highest-value target in DeFi. Every bridge holding significant liquidity is one compromised signer away from the same outcome.

Reactive Contracts don't eliminate all cross-chain risk. But they do eliminate the specific class of vulnerability behind Kelp and every major bridge exploit before it: the gap between what a validator says has happened and what has actually happened on-chain.

Part 2 will cover the other side of this incident: once the damage was done and rsETH began to depeg, how could individual users with Aave positions have protected themselves? We'll walk through how a Reactive Contract monitoring health factors could have automatically unwound positions before the liquidation cascade hit.

About Reactive Network

Reactive Network is an EVM automation layer built around Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation.

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding 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!

Liquidation feels like a shock to many users. Positions weaken gradually: health factor drops, buffers thin, and prices move against you. Then one transaction closes everything. Soft liquidation addresses that gap. Instead of enforcing at a single threshold, it responds to early warning signals and adjusts while the position can still recover.

With ReacDEFI now live on Ethereum and Base Mainnets, that protection is no longer theoretical. Reactive Network's DApp brings automated, rule-based liquidation protection to two of DeFi's most active chains.

How Soft Liquidation Works

ReacDEFI's Liquidation Protection is configured directly in the interface. Each element defines how and when your position is protected.

1. Protection Type You choose how the system should intervene: add more collateral when Health Factor drops (Collateral Deposit), repay part of the borrowed asset (Debt Repayment), or use both methods (Combined).

2. Trigger Health Factor This is the activation threshold. If your current Health Factor is 1.29 and you set the trigger at 1.2, nothing happens while HF stays above 1.2. The moment it drops below, protection activates automatically while the position is still solvent.

3. Target Health Factor This defines how far recovery goes. If the target is 1.5, ReacDEFI adjusts your position until HF reaches 1.5, then stops. It doesn't close the position. It restores a buffer and exits.

4. If you selected Collateral Deposit (or Combined), this is the asset that will be added to your position when protection activates. You decide in advance where additional collateral comes from.

5. If you selected Debt Repayment (or Combined), this is the asset that will be repaid when HF drops below your trigger. Again, the method is predefined. Nothing is improvised during market stress.

6. Check Frequency This controls how often the system checks your Health Factor: every block, every 10 blocks, every 100 blocks. every 1000 blocks, and every 10,000 blocks. More frequent checks mean faster reaction. Less frequent checks reduce activity.

7. Prefer Debt Repayment (Optional) In Combined Mode, this toggle lets you prioritize debt repayment before adding collateral, giving you control over which side of the position adjusts first.

8. Enable Protection Once everything is configured, you activate protection. From that point forward, ReacDEFI monitors your position automatically and executes according to the parameters you defined.

Recovery Options

ReacDEFI gives three protection modes:

• Collateral Deposit: adds more collateral when the Trigger Health Factor is breached, increasing your buffer without reducing debt.
• Debt Repayment: repays part of the borrowed asset, reducing leverage directly by lowering outstanding debt.
• Combined Mode: uses both methods, with optional priority for debt repayment.

Each mode changes what fields you configure and how the system restores your position. 

When you select Collateral Deposit, the system protects your position by adding more collateral once the Trigger Health Factor is breached.

When HF drops below your trigger, ReacDEFI automatically deposits the selected collateral asset until the position reaches your target HF. This increases your buffer without reducing your debt.

Alternatively, when you select Debt Repayment, protection works by repaying part of your borrowed asset.

Once HF falls below your trigger, ReacDEFI repays part of the selected debt asset until HF reaches your target. This reduces leverage directly by lowering outstanding debt.

Live on Ethereum and Base

ReacDEFI doesn't remove hard liquidation from the lending protocol underneath. If risk continues to rise and buffers are exhausted, liquidation can still happen.

What changes is the path leading there. Instead of waiting for a single irreversible moment, the system detects stress early, intervenes automatically, restores a defined buffer, and continues monitoring. Liquidation becomes less likely to feel sudden.

With the launch on Ethereum and Base Mainnets, ReacDEFI's soft liquidation is available where it matters most: on chains with deep liquidity and active lending markets. Users on both networks can now configure automated protection for their positions without relying on manual monitoring or third-party keepers racing for the same opportunity.

About Reactive Network

Reactive Network is an EVM automation layer built around Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation.

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding 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!

In Intent-Centric Protocols: A Simpler Way to Use Blockchains, we looked at how intent-centric protocols are changing the way people interact with blockchains. Instead of specifying every step of a transaction, you describe the outcome you want and let a network of solvers compete to deliver it. It's a cleaner, safer model. But it has a gap.

Intents are great at expressing what a user wants. What they don't do is watch the world and decide when to act. Someone, or something, still needs to monitor conditions, detect the right moment, and trigger execution. Today, that job falls mostly to off-chain bots and custom infrastructure. Reactive Contracts, built by Reactive Network, offer an on-chain alternative, and a natural complement to the intent-centric stack.

Missing Piece

Take a simple intent: “Sell my ETH if it drops below $1,500”. The intent is clear. Execution is solvable. But nothing activates it.

A system still needs to monitor the price and trigger execution at the right moment. In DeFi today, that’s done by off-chain keepers. It’s effective but dependent on private infrastructure, uptime, and coordination.

This is the gap: intents define outcomes, solvers handle execution, but the trigger layer remains mostly off-chain.

Reactive Contracts

Reactive Network approaches this problem by rethinking what smart contracts can do. Traditional smart contracts are passive. They contain logic, but they only execute when someone explicitly calls them, either a user signing a transaction or a bot poking them into action. They can't watch for events on their own.

Reactive Contracts invert this relationship. They subscribe to on-chain events across EVM chains and execute Solidity logic automatically when predefined conditions are met. No caller. No keeper. No cron job. The contract itself decides when to fire, based on what's happening on the blockchain.

In practice, a Reactive Contract might monitor a price feed on Ethereum, detect that a threshold has been crossed, and send a callback to a contract on Arbitrum or Base to execute a trade. It does this without relying on an off-chain server, a centralized API, or a human pressing a button.

Pairing with Intents

The connection between intents and Reactive Contracts becomes clear once you think about the lifecycle of an intent-based interaction:

The intent layer handles what. Reactive handles when. Together, they could cover the full lifecycle of a conditional, user-defined action without requiring any off-chain infrastructure.

The pairing gets more interesting as intents become more expressive. A few examples of what becomes possible:

What This Replaces

To understand why this pairing matters, it helps to see what it displaces. Today, most DeFi automation depends on a patchwork of off-chain components:

Keeper bots run on private servers, polling the blockchain for conditions and submitting transactions when thresholds are met. They work, but they're centralized, opaque, and require ongoing maintenance.

Custom relayer infrastructure connects chains and triggers cross-chain actions, but each protocol typically builds its own, leading to fragmentation and redundant effort.

Centralized automation services offer convenience but reintroduce trust assumptions that decentralized systems are supposed to eliminate.

Reactive lets subscribe to events on any supported EVM chain, react from one contract, and do it without callers or keepers. For intent-centric protocols, this means the entire pipeline from user wish to on-chain settlement can remain decentralized, automated, and verifiable.

Open Questions

Although this pairing is promising, it's still early and several questions remain.

Integration complexity. Intent protocols and Reactive Network are being built independently. There's no standardized interface yet between an intent format (like ERC-7683) and a Reactive Contract subscription.

Trust model. Moving monitoring on-chain reduces reliance on private infrastructure, but introduces a new network layer into the system. Reactive’s consensus and execution guarantees become part of the overall security model.

Cost and scalability. Continuous event monitoring across multiple chains isn't free. As the number of intents and conditions grows, the computational and economic costs of the Reactive layer will need to scale respectively.

Solver-trigger interplay. If a Reactive Contract triggers an intent at a specific moment, the solver network needs to respond quickly enough to capture the intended conditions. Latency between the trigger and settlement could introduce slippage or missed opportunities, especially in volatile markets.

These engineering and design challenges are not fundamental flaws and worth naming honestly, because the value of this pairing depends on how well these pieces are actually stitched together.

Two Halves of the Same Idea

Intent-centric protocols and Reactive Contracts come from different starting points, but they converge on the same vision: a decentralized system where users describe outcomes and the infrastructure handles everything else.

Intents abstract away how. Reactive Contracts abstract away when. Together, they sketch the outline of a system where a user can set a complex, conditional, cross-chain financial strategy and walk away, knowing that the monitoring, triggering, optimization, and settlement are all handled on-chain, without bots, without babysitting, without trusting a centralized service to stay online.

About Reactive Network

Reactive Network is an EVM automation layer built around Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation.

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding 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!

If you've ever tried to swap one cryptocurrency for another, you know the feeling. A screen full of options you didn't ask for: gas fees, slippage tolerance, liquidity routes. Each one seems like a small decision that could cost you money if you get it wrong. Something that should feel like a bank transfer ends up feeling like you're flying a plane with no training.

Intent-centric protocols exist to fix this. They represent a fundamental rethinking of how ordinary people interact with blockchains, and they're quietly reshaping the plumbing beneath decentralized finance. Here's what they are, how they work, and why they matter even if you've never touched a crypto wallet.

Problem

When you send money through Venmo or PayPal, you just say what you want: "Send $50 to Alex." You don't think about servers, payment rails, or network congestion. You describe the outcome, and the system handles the rest.

Crypto hasn't worked that way. Interacting with a blockchain has meant specifying not just what you want, but exactly how to get it, at the machine level. Choose an exchange. Set a gas price (a fee bid to get your transaction processed). Pick a slippage tolerance (how much price movement you'll accept before the trade cancels). Then hope the conditions you set are still valid by the time the transaction goes through.

This is imperative design: you give the computer explicit instructions, and it follows them to the letter, even if conditions have changed since you hit "submit." The result is brittle, intimidating, and expensive. Trades fail. Users overpay. And the complexity keeps most people on the sidelines entirely.

Idea

Intent-centric protocols flip this model. Instead of submitting machine-level instructions, you submit an intent: a signed statement expressing the outcome you're after. Something like: "I want to exchange my ETH for at least 2,000 USDC, any time in the next five minutes”. No route, no platform, no sequence of steps. Just the result you want and the boundaries you'll accept.

Think of it as the difference between giving someone turn-by-turn driving directions versus telling them the address. Same destination, very different burden on you. Once you've signed your intent, it's handed off to a network of specialized actors called solvers, who compete to find the best way to fulfill it.

Mechanics

First, you sign a cryptographically secure message describing the outcome you want, including any conditions: minimum amounts, fee caps, time windows, compound rules. This isn't a transaction yet. It's a verifiable wish.

Then, a decentralized network of solvers then competes to fill it. They route across exchanges, match you peer-to-peer, tap private liquidity, or batch your intent with others. The best solution wins a reward, so competition works in your favor.

Finally, the winning solution is checked against your original conditions. If anything fails, the whole thing reverts and you lose nothing. If everything checks out, it settles on-chain. The blockchain only sees the clean result.

Protocols

Several projects are building this paradigm, each from a different angle.

CoW Protocol (Coincidence of Wants) is the most mature. Before routing through an automated market maker, it looks for direct matches between users with compatible intents. No exchange fee, no price impact. When matches aren't available, solvers route through external liquidity. Batch settlement provides strong protection against front-running.

Anoma is the most ambitious, building an entirely new protocol from scratch with intents as the foundational building block. The vision extends beyond trading into coordination, resource allocation, and governance.

Essential takes a pragmatic, modular approach, building intent settlement as a standalone layer that existing blockchains can plug into without starting over.

In Practice

The user-facing difference is real. Solver competition consistently finds better prices than any single exchange. Batch settlement systems like CoW's make front-running structurally harder by settling trades at a uniform price. You don't need to understand liquidity pools, gas optimization, or routing logic. And because your intent only settles if every condition is met, you don't end up with transactions that went through but delivered a bad outcome because conditions shifted mid-execution.

Trade-Offs

Intent-centric protocols are promising, but they aren't a solved problem.

The solver layer introduces a new centralization risk. Competing as a solver requires serious infrastructure and capital, so a small number of sophisticated players tend to dominate. That quietly recreates some of the trust assumptions these systems are meant to eliminate. Most protocols are actively working on this, but it remains an open challenge.

Privacy is another concern. Broadcasting an intent before it's filled means revealing your preferences to the solver network before execution, creating an opening for solvers to exploit that information. It's a subtler version of the same front-running problem intents are designed to solve. Cryptographic countermeasures exist, but they're still maturing.

There's also a natural tension between expressiveness and execution: the more complex your intent, the harder it is for solvers to fill it efficiently.

Bigger Picture

Intent-centric design isn't just a UX improvement for crypto traders. It's a rethinking of the relationship between users and decentralized networks.

Today's blockchains (Ethereum, Solana, and others) were built around the assumption that users interact with the protocol directly, specifying every detail of every action. That worked for developers and enthusiasts building new infrastructure. It doesn't work for the billions of people who might one day use decentralized systems the way they use email, without knowing or caring how the pipes work.

Intents are the pipes. You describe what you want. The network figures out how. That shift has consequences well beyond any single protocol, consequences we'll explore in Part 2, where intents meet the automation layer that can bring them to life.

About Reactive Network

Reactive Network is an EVM automation layer built around Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation.

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding 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!

As season four of REACT staking draws to a close with the expiration of our 90 day staking pool we're announcing staking season five!

Season five will operate in the same way as season four with a 30, 60 and 90 day pool available to REACT stakers.

How to Join

For Season 4 stakers:

1. Open the Reactive Token Portal and check your REACT wallet is connected.
2. Select the pool you’re currently in.
3. Hit Restake and confirm the transaction to roll into Season 5.

For new participants:

1. Open the Reactive Token Portal and connect your REACT wallet.
2. Pick your pool (1 month, 2 months, 3 months).
3. Enter the amount of REACT you want to stake.
4. Select Stake and confirm the transaction.

Once staked, your REACT remains locked for the full duration of the chosen pool. Principal + rewards unlock only when the pool concludes.

Season 4 closes at block 4,503,578 today Monday March 9th. A quick reminder: rewards do not distribute automatically, be sure to claim them through the Reactive Token Portal.

Season 5 launches at block 4,503,579, bringing a fresh reward pool of 2,268,494 REACT spread across three durations:

• 1-month pool — 147,032 REACT
• 2-month pool — 546,119 REACT
• 3-month pool — 1,575,343 REACT

For technical details on Reactive Network, visit Reactive Docs.

For more details on tokenomics, explore REACT Tokenomics & Staking.

About Reactive Network

Reactive is an EVM-compatible execution layer for dApps built with Reactive Contracts (RCs): a different beast from traditional smart contracts. Instead of waiting for user-triggered transactions, RCs use inversion of control, responding automatically to data flowing across EVM chains.

They listen for event logs on multiple chains, react with Solidity logic, and decide when to transmit updates to destination chains. This enables conditional cross-chain state changes without direct user prompts. Reactive runs on a parallelized EVM implementation for fast, low-cost execution.

Website | Blog | Twitter | Telegram | Discord | Reactive Docs

Build once — react everywhere!