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!

DIA price oracles will be integrated with Reactive Network on March 2, 2026. The integration introduces an on-chain price feed for REACT/USD, available on Base Mainnet and accessible to Reactive Contracts and other smart contracts.

This integration provides a publicly accessible price reference for REACT that can be used by automated on-chain applications.

On-Chain Price Data

Blockchains can’t directly access external data such as market prices. Oracles provide this information on-chain. In this case, the oracle publishes the price of REACT in USD so that smart contracts can use it as an input for automated logic.

For example, a smart contract may:

• trigger an action when REACT reaches a target price
• compare REACT prices across chains
• track price movements over time
• use REACT price data in DeFi applications

DIA Oracle Architecture

The DIA system collects price data from centralized and decentralized exchanges. These trade prices are processed and combined into a single value. The final price is written on-chain where it can be read by smart contracts.

The process consists of several steps:

1. Sources – Market data is collected from exchanges where REACT is traded.
2. Feeders – Nodes submit price data to the DIA network.
3. Aggregation – Submitted prices are combined using a median calculation.
4. On-chain update – The resulting price is stored in an oracle contract.

The oracle updates when the price moves by more than 1%, or at least once every 24 hours.

Price Feed Details

Network: Base Mainnet

Oracle Contract: `0x5612599CF48032d7428399d5Fcb99eDcc75c06A7`

Feed: REACT/USD

The oracle provides:

• REACT price in USD
• Timestamp of the last update

This information is stored on-chain and can be accessed by any application.

With the DIA integration, price data becomes one of the conditions Reactive Contracts (RCs) can monitor. This allows RCs to react to price movements without relying on external bots or manual input. Typical uses include:

• price-triggered actions
• automated portfolio logic
• liquidation monitoring
• cross-chain automation

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!

For many users, liquidation doesn’t feel like a design flaw. It feels like a shock.

A position rarely collapses out of nowhere. It weakens first. Health factor drops. Buffers thin out. Prices move against you. Then one transaction closes everything. That disconnect or sudden enforcement is what soft liquidation is trying to fix.

Hard liquidation activates at a single number. Cross it, and the protocol acts. Everything resolves at once. But positions don’t deteriorate in a single block. They send signals along the way. Health factor compresses. Volatility eats into margins. Risk builds gradually.

Soft liquidation responds to those signals instead of waiting for collapse. The idea is simple: adjust while the position is still healthy enough to recover.

Automation Ahead of Liquidation

Many protection tools still revolve around speed. They monitor positions and react as liquidation approaches. In volatile markets, everyone tries to act at the same moment. Execution becomes competitive. Gas spikes. Outcomes depend on timing.

ReacDEFI, Reactive Network’s DApp, takes a different approach.

Instead of racing at the edge of liquidation, it activates earlier based on rules you define in advance. There is no scramble at the last second. Intervention happens before the position becomes critical.

Soft Liquidation

ReacDEFI’s soft liquidation is configured directly in the interface, to access simply connect a wallet with an open liquidity position.

Each element defines how and when your position is protected. Below is what each step does.

1. Protection Type

You choose how the system should intervene:

• Collateral Deposit: add more collateral when Health Factor drops
• Debt Repayment: repay part of the borrowed asset
• Both (Combined): use both methods

This determines how your position recovers once protection activates.

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 HF drops below 1.2, protection activates automatically. The position is still solvent. The system steps in early.

3. Target Health Factor

This defines how far recovery goes. For example, if the target is 1.5, ReacDEFI adjusts your position until HF reaches 1.5 and then stops. It doesn’t close the position. It restores a buffer and exits.

4. Collateral Asset

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. Debt Asset

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
• Every 10,000 blocks

More frequent checks mean faster reaction. Less frequent checks reduce activity. You choose the balance.

7. Prefer Debt Repayment (Optional)

If using Combined Mode, this toggle lets you prioritize debt repayment before adding collateral. It gives 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: add more collateral
• Debt Repayment: repay part of the borrowed asset
• Combined Mode: use both

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.

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.

What Changes

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
• Continues monitoring

Liquidation becomes less likely to feel sudden.

Closing Thought

Markets move continuously. Risk builds continuously. Traditional liquidation does not as it acts at a single point.

Soft liquidation introduces continuity into that structure. In ReacDEFI, you decide when protection activates, how recovery happens, and how much safety margin is restored. The system executes those rules automatically, before the position reaches the edge.

Risk doesn’t disappear. But surprise does. Liquidation shifts from a last-second event to a managed process, one shaped by parameters you control in advance.

About Reactive Network

Reactive is an EVM-compatible execution layer for dApps built with Reactive contracts. These contracts differ from traditional smart contracts by using inversion-of-control for the transaction lifecycle, triggered by data flows across blockchains rather than by direct user input.

Reactive contracts listen for event logs from multiple chains and execute Solidity logic in response. They can determine autonomously when to transmit data to destination chains, enabling conditional cross-chain state changes. The network delivers fast and cost-effective computation via a proprietary parallelized EVM implementation.

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

Build once — react everywhere!

The first phase of DeFi lending broke under speed: systems that assumed human attention and reaction time were overtaken by markets that moved faster than users could respond. The second broke under incentives: liquidation began rewarding those who could trigger and capture it, not those who reduced risk.

As liquidation became fast, deterministic, and frequent, it stopped being just a safety mechanism. When value appears at a known moment, behavior organizes around capture. It became a point where value reliably appeared — and where competition naturally followed.

That competition has a name: MEV. Understanding liquidation protection without understanding MEV is like studying traffic accidents without looking at road design. The collisions aren’t random. They happen where the system concentrates pressure.

Pressure Points

MEV, or Maximal Extractable Value, is the profit captured through execution ordering and timing. A simpler way to think about it is traffic. Imagine an intersection with no traffic lights. Cars arrive from every direction. There are rules, but no enforced order. Whoever moves first gets through.

Now imagine that, at certain moments, the intersection must open because something valuable is passing through. Everyone can see when it’s about to happen. Everyone knows there’s an advantage to being first. Soon, drivers don’t just pass through. They wait nearby. They accelerate early. They compete for position. 

Visibility turns opportunity into coordination. That behavior isn’t reckless driving. It’s the predictable outcome of the intersection’s design. MEV works the same way. Whenever a system releases value at a known moment, competition concentrates around execution and ordering. Liquidations are one of the clearest places where this happens.

MEV Funnel

Liquidation doesn’t attract MEV by accident, it collapses value into a single executable moment. Hard thresholds, forced actions, known rewards, and permissionless execution don’t operate independently. They collapse into a single moment: the liquidation event. When that moment arrives, value is released predictably and mechanically.

At that point, uncertainty disappears. What remains is timing. Once a position becomes liquidatable, the system no longer asks what should happen. It asks who gets there first. Execution turns competitive by design.

This isn’t exploitation. It’s incentive alignment. When value is funneled into a single, deterministic event, speed becomes strategy. Liquidation stops being about resolving risk and starts being about winning the narrowest part of the funnel.

Designed Outcomes

It’s tempting to treat liquidation MEV as an unfortunate side effect of open blockchains. But the dynamics are not accidental. Hard liquidation encodes a specific philosophy:

• Risk is tolerated until a line is crossed
• Enforcement happens all at once
• Resolution is externalized to whoever executes fastest

Those choices collapse resolution into a single moment. MEV simply flows toward that concentration. In other words: liquidation MEV is not a bug in the execution layer but rather a consequence of the liquidation model itself.

Feedback Loop

Once MEV enters the picture, liquidation stops being a single event and starts behaving like a system.

Volatility pushes positions toward their limits. As more positions cross liquidation thresholds, each liquidation releases value at a predictable moment, drawing in competition. That competition raises execution pressure: higher gas, tighter timing, more aggressive strategies. Forced sales accelerate, slippage increases, and price moves intensify. The result feeds back into volatility.

What emerges is a closed loop: volatility creates risk, risk triggers liquidations, liquidations intensify competition, and competition feeds volatility.

At this point, liquidation is no longer primarily about resolving insolvency. It becomes a mechanism for extracting value under stress, precisely when the system is least able to absorb it.

Protection, then, isn’t just about saving individual positions. It’s about introducing friction into a loop that otherwise accelerates itself.

Existing Protection Approaches

These approaches differ in where they operate: outside the protocol, at the user level, or inside the system itself. What they share is more important than what separates them.

All of them still depend on the same moment: the liquidation trigger.

Some try to react faster. Others try to stay farther away. Some soften what happens after the line is crossed. None change the fact that risk accumulates until a hard boundary is reached and that value is released all at once.

As long as liquidation remains a single, competitive event, protection can only reduce damage at the margins. The underlying incentive stays intact: a predictable moment where speed decides the outcome.

That’s the ceiling every existing approach eventually hits.

Rethinking Liquidation

By this point, the issue is no longer whether liquidation protection is needed. The real question is whether liquidation should remain a single, adversarial event at all.

Hard liquidation treats every failure the same way, regardless of speed, context, or recoverability, assuming enforcement must be immediate and absolute. But systems that operate at machine speed don’t fail cleanly. They drift. They oscillate. They recover if given time.

MEV didn’t corrupt DeFi liquidations. It revealed their incentives.

What looked like adversarial behavior was simply the system responding to rigid thresholds and hard defaults. Liquidation protection evolved to reduce losses, but it hasn’t changed the shape of liquidation itself. As long as liquidation remains a cliff, competition will continue to cluster at the edge.

That leaves a design question, not about speed or incentives, but about structure: what happens if liquidation stops being an event, and starts becoming a process?

About Reactive Network

Reactive is an EVM-compatible execution layer for dApps built with Reactive contracts. These contracts differ from traditional smart contracts by using inversion-of-control for the transaction lifecycle, triggered by data flows across blockchains rather than by direct user input.

Reactive contracts listen for event logs from multiple chains and execute Solidity logic in response. They can determine autonomously when to transmit data to destination chains, enabling conditional cross-chain state changes. The network delivers fast and cost-effective computation via a proprietary parallelized EVM implementation.

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

Build once — react everywhere!