Blog | Reactive

Reactive Staking: Season 8

Reactive Network — Wed, 12 Aug 2026 14:44:39 GMT

Season 7 is wrapping up. Our 1-month staking pool expires at block 6,437,662 (Thursday, August 13th), and with it we're opening the door to Season 8.

Season 8 repeats Season 7 in structure: a single 1-month pool. We're finalizing the final matters of the Omni transition to Reactive mainnet, and once it’s live, we might revisit our staking structure, likely returning to the familiar three-pool setup 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 7 Stacked Up

Season 7 ran a single pool with a reward budget of 1,000,000 REACT. By the close, it had drawn 192 stakers and 101,802,464.85 REACT staked, at an APY of 12.69%.

How to Join

If you staked in Season 7:

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

If you're new:

Open the Reactive Token Portal and connect your REACT wallet.
Select the 1-month pool (the only one this season).
Enter the amount of REACT you'd like to stake.
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 7 closes at block 6,437,662 on Thursday, August 13th. Rewards aren't distributed automatically, so be sure to claim yours through the Reactive Token Portal.

Season 8 launches on the very next block, 6,437,663, with a fresh reward pool of 1,000,000 REACT, and closes at block 6,816,896, around 12 pm UTC on Sunday, September 13th.

The Omni transition is in its final stretch, with testing on track and the remaining work focused on polish. We’re not setting a firm date yet, but we’re close and will share timing as we get nearer.

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.

Build once — react everywhere!

Maestro: Keeping A Pool's Liquidity At The Live Price

Reactive Network — Mon, 10 Aug 2026 13:02:43 GMT

Maestro was the fifth of the six projects in our look at the UHI9 hookathon, and it points a reactive contract at something none of the others touched: the real market price, sitting on a different chain. The full project is open here.

Maestro is a Uniswap v4 hook whose pool has a manager. The manager's job is to keep the pool's liquidity concentrated around the live market price and to set the swap fee, and it pays rent to the liquidity providers (the people who deposit the two tokens so others can trade between them) for the privilege. The whole reason for Reactive to be involved is that this manager is not a person or a server. It is a reactive contract that watches a price feed on another chain and moves the pool's liquidity to match.

A pool that trades a step behind

A normal automated market maker is passive. Its price only changes when someone trades against it, so it is always a little behind wherever the real market has already moved to. Traders who watch both notice the gap and trade against the stale pool price until it catches up, and the small, repeated profit they take comes straight out of the liquidity providers' pockets. This has a name, loss-versus-rebalancing, and on a lively pair like ETH/USDC it is estimated to cost providers somewhere around 5 to 10 percent a year.

What would fix it is easy to say: keep the pool's liquidity sitting where the price actually is right now, instead of where it was at the last trade. But a hook can’t do that on its own. It only runs inside a swap, so between trades it has no idea where the market has gone, and it certainly has no way to read a price feed living on another chain.

A manager you rent, not a bot you run

Maestro's answer is to hand that job to a manager, and to sell the role in a continuous auction. Anyone can bid a per-block rent to become the manager. Each bid has to beat the last, and after a short delay the winner takes over and pays rent every block until someone outbids them or their deposit runs dry. That rent does not go to Maestro. It is shared out to the liquidity providers, who can claim their portion whenever they like. The party best placed to profit from steering the pool ends up paying the providers for the chance to do it.

While it holds the role, the manager does two things: it concentrates the pool's liquidity into a tight band around the live price, and it sets the fee. Doing that well is what makes the rent worth paying. And the manager doing it is a reactive contract.

What the reactive contract watches

Every earlier project in this series pointed its reactive contract at the pool's own activity: swaps, withdrawals, a clock. Maestro points it somewhere else entirely, at a price oracle. Pyth is a service that publishes real market prices on-chain, and Maestro's reactive contract, `MaestroManagerRC`, subscribes to Pyth's price-update event for the ETH/USD feed. It then does nothing at all until that price moves.

// Watch Pyth's PriceFeedUpdate event for one feed (ETH/USD) on the origin chain.
service.subscribe(
    originChainId, originPyth, PRICE_FEED_UPDATE_TOPIC_0,
    uint256(priceId),                  // filter: only this one price feed
    REACTIVE_IGNORE, REACTIVE_IGNORE
);

Laid out end to end, that is three chains in one line. Pyth publishes the ETH/USD price on Ethereum Sepolia and emits it as an event; `MaestroManagerRC` on Reactive Lasna testnet is subscribed to that event and forwards each new price across chains; and on Unichain the manager callback takes the delivered price and repositions the pool around it. Only the middle box is the reactive contract's own work, and it is worth looking at what that work amounts to when a price actually arrives.

Carrying the price across

When the Pyth price updates, `react()` runs. It pulls the new price out of the event and asks Reactive to deliver it to the pool's manager contract on the other chain. That is the whole of it. The reactive contract holds no state and makes no decision about where the band should go.

function react(LogRecord calldata log) external vmOnly {
    // PriceFeedUpdate carries (publishTime, price, conf); we only want the price.
    (, int64 price,) = abi.decode(log.data, (uint64, int64, uint64));

    // Deliver the live price to the manager callback on the destination chain.
    emit Callback(destinationChainId, managerCallback, CALLBACK_GAS_LIMIT,
        abi.encodeWithSignature("repositionToPrice(address,int64)", address(0), price));
}

The leading zero address is a placeholder that Reactive fills in with the caller's identity when the call lands, so the destination can check who sent it. The band math, turning that raw price into a tick range the pool can use, runs on the destination side where the Uniswap libraries live. The reactive contract's only job is to carry a price it observes on one chain over to another.

On the destination the call arrives at `ManagerCallback` on Unichain, which is strict about who it will listen to: it takes the price only from Reactive's official callback proxy, and only when the call carries the identity of the exact reactive contract it expects. Then it repositions the pool's liquidity around the delivered price.

About Reactive Network

Build once — react everywhere!

Coinstancy x Reactive: Automating Portfolio Rebalancing On-Chain

Reactive Network — Wed, 05 Aug 2026 15:55:50 GMT

Coinstancy has taken on a practical challenge with Reactive Network: how to keep a portfolio aligned with its intended allocation when market prices are constantly moving.

Instead of relying on someone to continuously monitor positions and execute trades, the system responds automatically when a portfolio drifts too far from its target allocation. The reactive contract is now live on Reactive Mainnet, and the integration has reached its second milestone, moving from a testnet proof of concept to a working part of Coinstancy's production stack.

Coinstancy in Detail

Coinstancy allows users to deposit stablecoins, which are then allocated across a predefined basket of crypto assets. For example, a basket may include a combination of BTC, ETH, and other tokens.

That allocation does not remain fixed for long. As asset prices change, the weight of each position changes with them. A portfolio that starts out balanced can become noticeably skewed within a matter of days.

Traditionally, correcting this drift involves three steps: identifying that the portfolio has moved away from its target, calculating which positions need to be adjusted, and executing the necessary trades, sometimes across several networks.

This process is manageable at a small scale, but it quickly becomes time-consuming, repetitive, and prone to execution errors.

What Reactive Adds

Reactive provides a way for on-chain systems to respond directly to events rather than waiting for someone to intervene manually. A single reactive contract subscribes to Chainlink price feed updates for the assets held in active baskets. The baskets themselves currently live on Arbitrum, so that is the primary origin chain, but a few assets only have a feed on Ethereum mainnet.

Rather than standing up separate monitoring for each network, the reactive contract simply subscribes where the feed exists and aggregates the results in one place. Base and Ethereum are set to join as destination chains as new baskets are added.

When an update arrives and the basket has drifted past its target allocation, the contract emits a callback that records a rebalance request on the destination chain. Each request traces back to the price event that caused it, so when a user asks why their portfolio changed, there is an on-chain answer.

Where Execution Happens

One design decision here is worth calling out, because it runs against the assumption that reactive contracts have to do everything.

Coinstancy does not custody user funds on-chain directly; positions are held in managed wallets, and the trades themselves are routed through an external liquidity protocol. Rebalance execution therefore stays in Coinstancy's backend, which reads the rebalance requests recorded on the destination chain and acts on them.

The reactive contract handles what it is best suited for: watching several chains at once and deciding, on-chain and verifiably, that a rebalance is warranted. Pushing the swap logic and wallet operations on-chain as well would have meant rebuilding a large part of an existing, audited stack for little gain.

What Stops a Rebalance

Most price updates produce no action at all, and that is the intended behavior. A rebalance has to earn its way past a series of conditions first.

The contract discards feeds that look stale or implausible, ignores data from a Layer 2 for a grace period after a sequencer outage, and confirms that the basket has not been rebalanced too recently. Each request carries an identifier derived from the originating transaction, so one event can’t produce two rebalances. On the destination side, the receiver accepts calls only from the official Reactive callback proxy, and only from Coinstancy's own contract.

The backend is equally cautious: events count as final only once enough confirmations have passed to make a reorg unlikely, already-processed ones are discarded, and signing runs through a hardware-backed key management service. If a rebalance is interrupted partway through, the backend works from a snapshot taken beforehand to unwind the swaps that completed, records any difference in value, and alerts the team. The request itself stays on-chain throughout, so the reason it was issued never has to be reconstructed.

User Benefit

From the user's perspective, portfolio management becomes more consistent and requires less manual intervention.

Portfolios remain closer to their intended allocation without users having to continuously track prices or decide when trades should be executed. The system applies the same predefined rules each time, which helps avoid emotional or inconsistent decision-making.

The result is a smoother experience in which the portfolio strategy is maintained in the background.

Closing Thought

Thanks to the Coinstancy team for seeing this through from a testnet demo to a live mainnet deployment. They pushed back on parts of the design along the way rather than taking the first version of it: where the drift logic belongs, what the contract should and should not own, how much to trust a price feed. Those are the right questions to ask, and the integration is better for them being asked.

What stands out about the result is how ordinary it is. A contract watches price feeds on a few chains, and every so often it decides something needs to change. No scheduler, no monitoring service, nothing to keep running. That is roughly where we hope reactive contracts end up: not the interesting part of the system, just the part that quietly works.

Follow their socials: Website | X | Instagram | LinkedIn

About Reactive Network

Build once — react everywhere!

Lambda: Keeping A Hedge In Sync Across Chains

Reactive Network — Tue, 04 Aug 2026 12:33:09 GMT

Lambda was the fourth of the six projects in our look at the UHI9 hookathon, and it puts a reactive contract to the use Reactive Network is most literally built for: turning an event on one chain into a transaction on another, with no server in between. The full project, contracts and tests included, is open here.

Lambda is a Uniswap v4 hook that tries to cancel the price risk a liquidity provider (an LP, someone who deposits two assets into a pool so others can trade between them) carries. It does that by holding a matching short position on a perpetual futures exchange, and it keeps that short the right size automatically, even though the pool and the exchange live on different chains.

The loss that is also an income stream

An LP slowly loses value to arbitrage. When the price moves, the pool sells the asset that is rising and buys the one that is falling, and traders on the other side pocket the difference. Researchers named and measured this (they call it loss-versus-rebalancing, the precise cousin of "impermanent loss"), and for a volatile pair it is not small.

The idea Lambda is built on is that this loss has a mirror. A short position on a perpetuals exchange collects a recurring fee, called funding, and over time that funding is roughly the same size as the loss the pool suffers, with the opposite sign. Both are paid by the same thing: people wanting exposure to a moving price. So Lambda holds the pool position and a matching short at once. The loss and the income meet in the middle, and the combined position barely cares which way the price goes. That last property has a name: delta-neutral.

The short is deliberately partial, sized at about 0.65 of the position's exposure rather than a full 1.0, because a full hedge is far more likely to get liquidated on a sharp move. Hedging most of the risk gives up little protection for a lot more safety.

The fix lives on another chain

A Uniswap hook only runs when someone trades. Between trades it is blind, and it can’t start anything on its own. Lambda's hook does what it can while a swap is passing through: it recomputes the position's exact exposure (its delta) and, if that has drifted too far from the last hedged level, emits a single event asking for the hedge to be resized.

// Every swap, recompute the live delta; if it has drifted past the band tau,
// emit one HedgeRequested carrying a strictly increasing per-pool nonce.
if (DeltaMath.shouldRehedge(ps.hedgedDelta, live, ps.tau)) {
    ps.hedgedDelta = live;
    uint64 nonce = ++ps.hedgeNonce;
    emit HedgeRequested(id, nonce, DeltaMath.hedgeSize(live, ps.hedgeRatioWad), live, sqrtPriceX96, block.timestamp);
}

But the thing that has to happen next, adjusting a real short, happens on a different chain and a different venue. The usual way to bridge that gap is an off-chain bot: a server watching for the event and signing the hedge transaction. That server is a trusted operator, a point of failure, and something that has to stay online. Lambda removes it. A reactive contract does the bridging instead, entirely on-chain.

What the reactive contract does

The whole loop fits on two chains. On Unichain, the hook follows each swap, tracks the position's exact delta, and when that drifts too far it emits a single `HedgeRequested` event. Over on Reactive's Lasna testnet, `LambdaReactive` is subscribed to that event: it checks if the event is new, then routes a callback back across chains. On testnet that callback lands on a stand-in receiver on Unichain, which re-checks the sender and the nonce and records the hedge at 0.65 of the position's delta. On mainnet, the same callback would drive a real perp instead, which is the honest gap the diagram's "testnet receiver" label is pointing at.

The reactive contract subscribes to the hook's event on the origin chain, and optionally to the network's periodic CRON tick for funding checkpoints:

// Watch the hook's HedgeRequested event over on the origin chain...
service.subscribe(originChainId, hook, HEDGE_TOPIC0, ...);

// ...and, optionally, the network's periodic CRON tick.
if (cronTopic != 0)
    service.subscribe(block.chainid, address(service), cronTopic, ...);

When the event arrives, `react()` runs. Its job is small and careful: check the event is genuinely newer than the last one it acted on, then ask Reactive to deliver a call to the hedger on the other chain.

function react(LogRecord calldata log) external vmOnly {
    bytes32 poolId = bytes32(log.topic_1);
    uint64  nonce  = uint64(log.topic_2);

    if (nonce <= lastNonce[poolId]) { emit HedgeDropped(poolId, nonce, lastNonce[poolId]); return; }
    lastNonce[poolId] = nonce;                       // drop replays and out-of-order events

    // Ask Reactive Network to deliver a call to the hedger on the destination chain.
    emit Callback(destinationChainId, hedger, callbackGasLimit,
        abi.encodeWithSignature("applyHedge(address,bytes32,uint64,uint256,uint160)",
            address(0), poolId, nonce, targetSize, sqrtPriceX96));
}

Emitting that `Callback` is the whole cross-chain step. Reactive Network's relayer picks it up and turns it into a real transaction on the destination chain, filling in the leading zero-address placeholder with the caller's identity as it goes. The reactive contract itself moves no money and trusts nothing in the event beyond what it can verify: it forwards, and it keeps a per-pool nonce so a repeated or stale signal goes nowhere.

Where the callback lands, and who is allowed to send it

The call arrives at a small contract on the destination chain, and that contract is strict about who it listens to. It accepts the call only from Reactive's official callback proxy, and it re-checks the nonce itself rather than trusting the payload it was handed.

function applyHedge(address, bytes32 poolId, uint64 nonce, uint256 targetSize, uint160 sqrtPriceX96)
    external
    authorizedSenderOnly // only the official Reactive callback proxy
{
    if (nonce <= lastNonce[poolId]) revert StaleNonce();  // re-check; never trust the payload
    lastNonce[poolId] = nonce;
    // ...size and place the short...
}

On mainnet that contract is the real hedger on HyperEVM, and the last step is a genuine order placed on Hyperliquid's perpetuals exchange through its on-chain `CoreWriter` system contract. The short is opened or resized to match `0.65 x delta`.

There is an honest wrinkle worth stating plainly. Reactive's testnet does not route callbacks to HyperEVM's testnet, so the live testnet demo can’t place a real perp there. Instead the callback is routed back to Unichain Sepolia, where a stand-in receiver applies the exact same two checks (authorized sender, then nonce) and records the hedge it was asked to make, without sending an order. The perp leg itself is written and tested against real HyperEVM state on a fork, but it is not running live. What is proven live is the part this article is about: the cross-chain automation, firing with no bot.

About Reactive Network

Build once — react everywhere!

TrancheShield: Managing A Pool's Risk From Another Chain

Reactive Network — Thu, 30 Jul 2026 13:11:59 GMT

TrancheShield was the third of the six projects in our look at the UHI9 hookathon, and it takes yet another angle on the same limit: a Uniswap hook only runs when someone trades, but a pool's risk does not sit still between trades. Here is how it deals with that. The full project is open here if you want to see how the pieces fit together.

TrancheShield is a Uniswap v4 hook that protects the senior side of a pool against impermanent loss, the gap that opens up for liquidity providers when the price moves and they end up worse off than if they had simply held the two tokens. That protection is partial, capped at a coverage level, and paid for out of a reserve. To keep the whole thing solvent, the pool has a few settings it can turn: the swap fee, how much of the loss it currently promises to cover, and whether new money is allowed into the senior side at all.

The catch is that the right values for those settings depend on what is happening in and around the pool, and most of that has nothing to do with any single trade. Volatility climbs. The reserve gets thin. Holders start trying to pull their money out. A hook can’t keep up with any of this on its own, because it only wakes up inside a swap. It has no way to keep a running measure of volatility across many swaps, no way to notice the reserve draining or a wave of withdrawals building, and no way to calm back down during a quiet stretch when, by definition, nothing is calling it.

TrancheShield hands all of that to a reactive contract on Reactive Lasna testnet. It watches the pool from the outside, keeps its own running state, and adjusts those settings as conditions change. It is, in effect, a risk manager for the pool that never needs anyone to trade in order to do its job.

What it watches

The reactive contract subscribes to three kinds of event coming off Unichain Sepolia, plus one optional signal from Reactive Network itself:

// On Unichain Sepolia: every swap, every reserve-ratio update, every Senior withdrawal.
service.subscribe(UNICHAIN_SEPOLIA_CHAIN_ID, hook,    swapTopic0,     ...);
service.subscribe(UNICHAIN_SEPOLIA_CHAIN_ID, reserve, reserveTopic0,  ...);
service.subscribe(UNICHAIN_SEPOLIA_CHAIN_ID, hook,    withdrawTopic0, ...);

// Optional: a periodic tick on Reactive Network, used to let things settle down.
if (cronTopic0 != 0)
    service.subscribe(REACTIVE_CHAIN_ID, SERVICE_ADDR, cronTopic0, ...);

Each of the three tells it something different. Swaps say how sharply the price is moving and in which direction. Reserve-ratio updates say how healthy the backing is. Withdrawal events say how many senior holders are trying to leave. When any of them arrives, a single entry point sorts it by type and updates the pool it belongs to:

function react(LogRecord calldata log) external vmOnly {
    bytes32 poolId = bytes32(log.topic_1);
    if      (log.topic_0 == swapTopic0)     _onSwap(poolId, log);
    else if (log.topic_0 == reserveTopic0)  _onReserveRatio(poolId, log);
    else if (log.topic_0 == withdrawTopic0) _onSeniorWithdrawal(poolId, log);
    else if (log.topic_0 == cronTopic0)     _onCron(poolId);
}

Everything is tracked per pool. Each pool gets its own volatility history, its own risk level, its own counters. A volatility spike in one pool can’t pull another pool along with it, and a brand-new pool always starts calm.

Keeping a running read on volatility

Here is something a hook genuinely can’t do well: remember. The reactive contract holds state, so with every swap it folds the new price move into a running estimate of the pool's volatility. It does this without storing the full history. It keeps only a few running totals (a count, a sum, and a sum of squares) and derives a standard-deviation-style score from them, using a well-known online method for exactly this, Welford's algorithm. The cost of updating stays the same whether the pool has seen ten swaps or ten million.

That volatility score maps onto four risk levels, and each level sets the swap fee:

if      (score >= volCrisisThreshold) { mode = CRISIS; mult = 25_000; } // 2.50x fee
else if (score >= volHighThreshold)   { mode = HIGH;   mult = 17_500; } // 1.75x
else if (score >= volMediumThreshold) { mode = MEDIUM; mult = 12_500; } // 1.25x
else                                  { mode = LOW;    mult = 10_000; } // 1.00x

The more sharply the price is moving, the more it costs to trade against the pool's liquidity, so the fee goes up to compensate the people providing it. If several swaps in a row push the price the same way, that is a sign of one-directional flow that is especially costly to serve, so the contract adds a surcharge on top, capped at a hard ceiling of 3.00x:

// 3+ swaps pushing the same direction in a row: add a surcharge.
if (consecutiveDirectional[poolId] >= 3) mult += 2_500; // +0.25x, never above 3.00x

Reserve health, and a wave of withdrawals

The other two signals are about solvency rather than price. When a reserve-ratio update comes in, the contract compares the reserve against what it owes the senior side and sets coverage accordingly: a healthy reserve keeps coverage near its cap, a thin reserve steps it down, and a critically low reserve drops it to a floor, pushes the pool into its highest risk level, and switches off new senior deposits.

The withdrawal signal is the one with a story in it. The contract keeps a small ring buffer of the timestamps of recent senior-withdrawal requests. Each new request goes in, and it counts how many landed in the last hour. If that count crosses a threshold, it reads the situation as a run on the pool and acts at once:

function _onSeniorWithdrawal(bytes32 poolId, LogRecord calldata log) internal {
    // record this request's time, then count how many happened in the last hour
    uint256 inWindow = _countWithdrawalsInWindow(poolId, timestamp);
    if (inWindow >= bankRunThreshold) {                    // 5 within an hour
        _callback(setRiskMode(poolId, CRISIS));
        _callback(updateCoverageRatio(poolId, 1_500));     // pull coverage down to 15%
        _callback(setSeniorDepositStatus(poolId, false));  // stop new deposits
    }
}

Notice what it does and does not do. It does not try to stop people leaving. It tightens the pool's stance so the holders who remain are not left relying on a promise the reserve can no longer keep, and it stops new deposits from entering a pool that is visibly under stress.

Letting a pool re-evaluate when it is quiet

The optional periodic tick fills a real gap. Risk levels rise during active trading, but if trading simply stops, a hook never runs again, and the pool could stay pinned in a high-fee, low-coverage stance long after the pressure has eased. The tick gives the reactive contract a scheduled chance to recompute a quiet pool's risk and, if the numbers no longer support a cautious stance, step it back down, without waiting for a trade that may never come.

Crossing the chain, within limits

When any of this changes a setting, the reactive contract does what the others in this series do: it emits a callback, and Reactive Network delivers it as a real transaction on Unichain Sepolia, to a receiver contract that applies the update to the pool.

The receiver is deliberately strict. Every value it accepts is clamped to a safe range before it touches the pool. The fee multiplier is held between 1.00x and 3.00x, coverage can never exceed 50%, and the risk level has to be one of the four valid values:

function updateFeeMultiplier(address rvmId, bytes32 poolId, uint256 newBps)
    external rvmIdOnly(rvmId)
{
    if (newBps < 10_000 || newBps > 30_000) revert FeeMultiplierOutOfBounds(newBps);
    hook.updateFeeMultiplier(PoolId.wrap(poolId), newBps);
}

This matters. The reactive contract is doing real work and pushing real changes, but it is not trusted with unbounded power over the pool. The worst it could do, even if something went badly wrong, is move a handful of settings within ranges fixed in advance, on one pool at a time. Coverage tops out at half by design, so the protection is always partial and the pool never promises more than it can plausibly back. The receiver also checks that each callback carries the identity of the exact reactive contract it expects, so a stray call from anywhere else goes nowhere.

There is a small engineering story worth sharing, because it is the kind of thing you only learn by running the system. The callback travels through two hops before it reaches the pool, the delivery proxy and then the receiver, and Ethereum passes on only part of the remaining gas at each hop. A gas budget that looked generous kept running out partway through, and the fix was to send far more than seemed necessary. It is a reminder that a cross-chain call is not one call but a short chain of them, each consuming part of what is left.

About Reactive Network

Build once — react everywhere!

Unistrata: When Settlement Can’t Wait For The Next Trade

Reactive Network — Mon, 27 Jul 2026 13:35:22 GMT

Unistrata was the second of the six projects in our look at the UHI9 hookathon, and it draws a different lesson from the same limit: a Uniswap hook only runs when someone trades, but some decisions can’t wait for the next trade. Here is how it handles that. The full project, contracts and tests included, is open here.

Unistrata treats a single liquidity pool the way finance treats a bond. It splits the pool into two tranches, senior and junior. The senior tranche (called Bedrock) has protected principal and earns a fixed return priced from the pool's own volatility. The junior tranche (Sediment) absorbs losses first and is paid only from what remains after the senior's protected amount, and in exchange it keeps the extra trading fees. At the end of each epoch (a fixed settlement period), the pool settles: it works out what everything is worth and pays the senior tranche its protected amount first, then the junior gets the remainder. That ordering is called the waterfall.

Two things are worth noting. First, it uses no price oracle: the pool measures its own volatility directly from its trading activity and prices the senior return from that. Second, settlement has to happen at the right moment, and the hook can’t start it on its own. It only runs when someone trades.

There are two moments when settlement matters, and they are very different. One is routine: the epoch ends, and it is time to settle. The other is urgent: the price is falling right now, and you want to settle immediately, while the pool still holds enough to cover the senior tranche's protected amount. Settle in time and the loss falls on the junior tranche, which signed up to absorb it; wait too long and the shortfall starts eating into senior principal. That urgent moment is the one you can’t afford to wait on, and the one a fixed schedule would miss. Unistrata's reactive contract handles both.

Two things to watch

The reactive contract lives on Reactive Lasna testnet and does nothing but watch and act. It subscribes to two very different signals:

a periodic CRON event on Reactive, so it can settle on a regular schedule, and
the pool's volatility reading, published on the origin chain whenever trading moves the price, so it can settle as soon as volatility jumps.

That second subscription is the useful part. The pool already measures its own volatility (it needs to, in order to price the senior return) and emits that number on-chain, and the reactive contract listens for it.

// The network's cron event, on the Reactive chain...
service.subscribe(block.chainid, address(service), cronTopic, ...);

// ...and the pool's own volatility readings, over on the origin chain.
service.subscribe(originChainId, unistrataHook, UNISTRATA_OBSERVATION_TOPIC, ...);

One subscription is a timer; the other reads the pool's volatility.

Settling on schedule

After a set number of CRON ticks, the contract treats an epoch as elapsed and asks the pool to settle:

function _onHeartbeat() internal {
    if (++cronTicks >= ticksPerEpoch) {   // a full epoch's worth of ticks
        cronTicks = 0;
        _emitCallback("settleEpoch(address)");
    }
}

Even in a quiet market where nobody trades for a long stretch, the books still close on time.

Settling early on a volatility spike

This is the more interesting case. Every time the pool emits a new volatility reading, the contract checks how much volatility has built up since the last settlement. If that increase crosses a threshold, the contract does not wait for the epoch to end; it settles immediately:

function _onObservation(bytes memory data) internal {
    (, uint256 varAcc) = abi.decode(data, (int24, uint256));
    latestVarAcc = varAcc;
    if (varAcc - lastSpikeVarAcc >= spikeThreshold) {   // volatility just spiked
        lastSpikeVarAcc = varAcc;
        _emitCallback("emergencySettle(address)");        // settle now, do not wait
    }
}

Settling early matters because of what a fall does to the two tranches. Settle while the pool still holds enough to cover the senior tranche's protected amount, and the loss falls on the junior. Wait too long, and there may not be enough left, so the senior principal, the part meant to be protected, starts taking losses instead. The threshold triggers an early settlement precisely to avoid that.

One detail is worth noting. The threshold measures volatility since the last settlement, not since the pool launched. After every settlement, routine or early, the baseline resets, so the trigger responds to a fresh jump in volatility rather than to volatility that accumulated over the pool's whole history.

Crossing the chain, and who is allowed to settle

A reactive contract can’t reach the origin chain on its own. As with the other projects in this series, it emits a `Callback`, and Reactive Network's callback proxy delivers it as a real transaction on the origin chain, paying the gas and calling the pool as an authorized sender.

The pool does not accept that call from just anyone. Both settlement entry points are gated two ways: the caller must be the official callback proxy, and the request must carry the identity of the exact reactive contract registered at setup.

function emergencySettle(address rvm_id)
    external
    nonReentrant
    authorizedSenderOnly      // must come through the official proxy
    rvmIdOnly(rvm_id)         // and carry our registered controller's identity
{ ... }

And because an automated system that fails silently is worse than none at all, there is a manual fallback: a permissionless settlement that anyone can call, but only after the epoch has ended and a grace period has passed. If a callback is ever missed, the pool can’t get stuck; someone can always settle it directly.

About Reactive Network

Build once — react everywhere!

EvenFlow: The Problem With Waiting For A Swap

Reactive Network — Mon, 20 Jul 2026 14:55:25 GMT

EvenFlow was the first of the six projects in our look at the UHI9 hookathon, and the one we singled out as the clearest case of something a Uniswap hook simply can’t do on its own. Here is a closer look at how it gets around that. The full project, contracts and tests included, is open here.

Essentially it is a Uniswap v4 hook that tries to make a liquidity provider's income less lumpy. When trading turns against the people who supply the pool's capital (LPs, for short), EvenFlow charges a little extra and sets that money aside in a reserve. When the market calms down again, it drips the reserve back to the LPs who stuck around, so their income ends up smoother without ending up smaller.

There is one catch, and it is the whole story. The drip is meant to happen "when the market goes quiet". But almost everything inside a pool is set in motion by a trade: someone swaps, and code runs. If the market goes genuinely quiet, with no swaps at all, there is nothing to set the drip in motion. The reserve sits there stranded, at exactly the moment it is supposed to be paid out.

Give the pool a clock

The fix is to give the pool a sense of time that does not depend on anyone trading. That is what a reactive contract provides. A reactive contract is a small program that watches for events and acts on its own when it sees one it cares about, and it can watch events on other chains too.

Reactive Network happens to emit a built-in periodic signal, called a CRON event, on a fixed cadence. Anyone can listen for it. EvenFlow's controller (a reactive contract living on Reactive's Lasna testnet) listens for two things:

the pool's own "the mood just changed" signal, so it can react the instant a swap tips the pool into a quiet spell, and
the network's CRON event, so idle pools that emit no events at all still get checked on a schedule.

The second one is the interesting half. It means the pool no longer has to wait for a swap to realize it has gone quiet. The network's clock realizes it on the pool's behalf.

In code, those two subscriptions are the base of the whole thing:

// Watch the hook's own "regime changed" event over on the origin chain...
service.subscribe(originChainId, shieldHook, RISK_REGIME_CHANGED_TOPIC0, ...);

// ...and listen for the network's periodic CRON event.
service.subscribe(block.chainid, cronSystem, cronTopic0, ...);

Two lines. One says "tell me when the pool's mood changes". The other says "and tap me on the shoulder every so often, no matter what". Everything else follows from those.

What happens when the clock ticks

When either signal arrives, the contract's `react()` function runs. Its job is small: decide whether this is a drip-worthy moment, and if so, ask for a drip on the other chain.

function react(LogRecord calldata log) external vmOnly {
    if (/* the pool just went quiet */) {
        _requestDrip(pool, REASON_REGIME_QUIET);
    } else if (/* the CRON event ticked */) {
        _requestDrip(targetPool, REASON_CRON);   // sweep the idle pool
    }
}

A reactive contract can’t reach across to another chain by itself, though. What it can do is ask:

```solidity
// Ask Reactive Network to deliver a call to the executor on the other chain.
emit Callback(destinationChainId, executor, CALLBACK_GAS_LIMIT, payload);
```

Emitting that `Callback` event is the request. Reactive Network's Signer picks it up and delivers it as a real transaction on the destination chain (here, Base), where a small contract called the executor is waiting. The full hop looks like this:

Who is allowed to press the button?

This is the part worth slowing down for. The executor's one useful power is to tell the hook "release the reserve now". You would not want just anyone able to trigger that. So before it does anything, the executor checks two things, and both have to pass:

// 1. The message must arrive through the chain's official callback proxy.
if (!senders[msg.sender]) revert UntrustedProxy(msg.sender);

// 2. It must carry the identity of the controller we locked in earlier.
if (sender != controllerRvmId) revert UnauthorizedReactive(...);

The first check confirms the message came in through Reactive Network's official delivery channel, and not from some random address that fancied a go. The second is a kind of return address that can’t be forged: when the controller was set up, the identity of the account behind it was recorded once, and from then on the executor only accepts messages stamped with that same identity. Locked in once, verified on every single delivery.

It can ask, but it can’t force

Even after both checks pass, the executor does not touch any funds itself. It just forwards the request to the hook:

shield.triggerQuietDrip(_poolKeys[poolId]);

The hook then re-checks everything from scratch: is the pool actually quiet, has the cooldown elapsed, is there anything in the reserve to pay out? If any answer is no, nothing happens and no harm is done. A callback that turns up at the wrong moment is simply a harmless no-op. The clock can tick as often as it likes; the money only moves when the pool itself agrees it should.

About Reactive Network

Build once — react everywhere!

Reactive Contracts & Uniswap Hooks: The First Wave from the UHI9 Hookathon

Reactive Network — Wed, 15 Jul 2026 14:05:28 GMT

Plenty of teams came through the UHI9 hookathon, and a good share of them used Reactive Network. The judges did something more useful than count claims: they checked whether each project's reactive contract actually fired a callback on-chain. Six passed that test. This is a look at those six: what they made, and why a hook alone could not get them there.

First, the short version. A Uniswap hook is code that runs at specific moments during a swap. It is quite functional, but it has one hard limit: it only wakes up when someone trades. No swap, no hook. Fine for anything that happens during a trade, and a problem for everything that needs to happen when the pool is quiet.

A reactive contract is the other half of the story. It watches for events, including events on other chains, and when it sees one it cares about, it acts on its own by firing a callback. No human, no off-chain bot, no scheduled job on a server. When a builder says their reactive contract "emitted callbacks", they mean the watch-and-act loop actually ran. That loop is the thread through all six projects below.

EvenFlow: The Problem With Waiting for a Swap

EvenFlow is the cleanest illustration of why any of this matters. When trading turns against liquidity providers (the people who supply the pool's capital, usually shortened to LPs), EvenFlow collects a small surcharge and holds it aside in a reserve. Once the market calms down, that reserve is meant to drip back to the LPs who stayed in range.

Here is the catch the team spotted: the payback needs something to trigger it, and the natural trigger would be a swap. But the whole point is that things have gone quiet. If nobody trades, nothing fires, and the reserve just sits there stranded. Their fix was a reactive cron, a time-based reactive contract that releases the funds cross-chain whether or not anyone shows up to trade. It is a small idea with a big implication, and EvenFlow states it more plainly than anyone else in the cohort: a hook can’t rescue capital during a quiet spell, because it is exactly when a hook is asleep.

Unistrata: Settling the Books With No One at the Desk

Unistrata treats a liquidity pool the way finance treats a bond structure. There is a senior tranche with protected principal and a coupon priced off volatility, sitting on top of a junior tranche that takes the first loss in exchange for more upside. First in line to get paid, versus first to absorb the hit.

At the end of each epoch (a fixed settlement period), someone has to work through that waterfall and decide who gets what. Unistrata does it with a reactive contract and nothing else. No keeper, no bot, and, notably, no external price oracle. The volatility figure that prices the coupon is read straight from the pool's own price movements, the path its ticks actually took. The settlement then fires cross-chain on its own. It is the same lesson as EvenFlow wearing a different suit: the moment that matters is a moment of stillness, and stillness is where reactive contracts do their best work.

TrancheShield: A Risk Dial That Turns Itself

TrancheShield takes the watching loop and points it at the pool's own health. A reactive contract prices the pool's risk continuously and adjusts three levers cross-chain as conditions shift: the swap fee, the level of impermanent-loss coverage (protection against the pool losing value compared to simply holding the two tokens), and whether new deposits are allowed in at all.

What is curious here is the framing. The reactive contract does not live inside the pool; it sits outside it and holds the authority to reconfigure it. When volatility spikes, or reserves start to look thin, or everyone heads for the exit at once, the dial turns without anyone touching it. It is less a trigger and more a control plane, quietly keeping the settings honest while the pool goes about its business.

lambda: Hedging on a Market Your Hook Has Never Visited

lambda tackles a problem LPs know well. Provide liquidity, watch the price move, and you can end up worse off than if you had simply held the two tokens. The field has a name for that drift: loss-versus-rebalancing, or LVR. The usual answer is to hedge on a derivatives market, and the usual trouble is that the market you would hedge on lives somewhere your pool does not.

lambda's positions sit on Unichain, and each one is automatically hedged on Hyperliquid, a separate perpetuals venue (a market for no-expiry futures). A reactive contract is the bridge that lets a hook on one chain act on a market on another, with no off-chain bot in between. The result is an LP position that stays close to delta-neutral (gains on one side roughly cancelling losses on the other) instead of bleeding value on every price swing. This is Reactive doing the one thing a hook fundamentally can’t: reaching past the edge of its own chain.

Maestro: Letting a Contract Run the Pool

Most of these projects use a reactive contract to assist a pool. Maestro hands it the keys.

Here the reactive contract is the pool manager. It subscribes to a live Pyth ETH/USD feed (an on-chain source of the current price) on one chain and fires callbacks to Unichain to keep the pool's liquidity concentrated around the real market price. The right to be that manager is sold through a continuous, self-assessed auction (a Harberger auction, if you want the term), and the rent flows back to LP shareholders block by block. The manager is not a person, and it is not a bot idling on a server. It is a contract that watches a price and acts. Maestro's team makes a fair claim to a first here: a concentrated-liquidity, auction-managed AMM whose manager is fully autonomous and lives across chains.

Veritas: What the Chain has Already Seen

Veritas is the most quietly interesting of the six, because its real subject is trust. A reactive contract on Lasna testnet watches for attestation events (on-chain records vouching that some content is authentic) over on Unichain Sepolia. When a near-duplicate of previously attested content appears on-chain, the contract fires a callback that raises that asset's "dilution score", which in turn feeds into how much fee protection LPs receive on the next swap.

The team's reasoning is the sharpest line to come out of the whole hookathon, and it is worth sitting with. An off-chain oracle has to sign its data, and anything that can be signed can, in principle, be bribed. A dilution floor built from what the chain has already witnessed can’t be pushed below the record, because you can’t ‘un-happen’ an on-chain event. So instead of trusting a signer, Veritas trusts the ledger's memory, and the reactive contract is what turns that memory into a live signal the pool can use.

Common Thread

Line them up and a pattern appears. EvenFlow releases capital during a quiet spell. Unistrata settles when the epoch closes. TrancheShield adjusts when conditions move. lambda hedges on a venue elsewhere. Maestro re-centers when the price drifts. Veritas reacts to what another chain has recorded. Almost every one of them acts at a moment when nothing else is prompting anything to happen, and reaches across chains to do it. That is not a coincidence of theme. It is the shape of the space where a hook runs out of road and a reactive contract keeps going.

Quite a few teams at UHI9 chose Reactive for exactly this kind of job, and these six carried the idea all the way to a callback that fired on-chain. Their repositories are open if you would like to see how they did it. And since this is only the first wave, there are others still working their way toward the same finish line.

About Reactive Network

Build once — react everywhere!

Reactive Staking: Season Seven

Reactive Network — Mon, 13 Jul 2026 10:03:31 GMT

Season 6 is wrapping up. Our 1-month staking pool expires at block 6,055,034 (Monday, July 13th), and with it we're opening the door to Season 7.

Season 7 repeats Season 6 in structure: a single 1-month pool. We're finalizing the last details of the transition to Reactive mainnet Omni, and once the new mainnet is live, we'll revisit our staking structure, likely returning to the familiar three-pool setup with 1-, 2-, and 3-month options.

How Season 6 Stacked Up

Season 6 ran a single pool with a reward budget of 1,000,000 REACT. By the close, it had drawn 216 stakers and 98,450,512.18 REACT staked, at an APY of 13.27%.

How to Join

If you staked in Season 6:

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

If you're new:

Open the Reactive Token Portal and connect your REACT wallet.
Select the 1-month pool (the only one this season).
Enter the amount of REACT you'd like to stake.
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 6 closes at block 6,055,034 on Monday, July 13th. Rewards aren't distributed automatically, so be sure to claim yours through the Reactive Token Portal.

Season 7 launches on the very next block, 6,055,035, with a fresh reward pool of 1,000,000 REACT, and closes at block 6,437,662, around 6 pm UTC on Thursday, August 13th.

Launching the Omni fork is the goal we're working toward, and the transition is now in its final stretch. Testing is tracking to plan, and the work that remains is polish rather than open questions. We're not fixing a hard date yet, but we're close and we'll share exact timing as we get nearer.

For technical details on Reactive Network: Reactive Docs.

For more details on tokenomics: REACT Tokenomics & Staking.

About Reactive Network

Build once — react everywhere!

Fiet's Settlement Automation Goes Live on Reactive Network

Reactive Network — Thu, 02 Jul 2026 15:38:14 GMT

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

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

Problem revisited

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

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

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

Reactive’s role

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

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

Settlement flow

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

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

Why this matters

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

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

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

About Reactive Network

Build once — react everywhere!

REACT Tokenomics: Network Stability & Longevity

Reactive Network — Tue, 30 Jun 2026 12:55:10 GMT

Reactive Network is entering a new era.

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

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

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

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

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

This is not a cosmetic change. It removes discretion.

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

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

Why the number is changing

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

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

That is the trade.

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

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

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

What does not change

The fee burn stays.

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

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

Usage will reduce total supply.

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

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

Where the tokens go

The fixed maximum supply is 2.4 billion REACT.

Locked Supply Wallets and Contract Addresses:

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

Ecosystem Development and Grants: 0xA07d990c2cA0e26D0239cCcc92279a8f02b1901C

Core Contributors: 0x40d589db8c135602b836cbc14563f5a5b75ccbb1

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

Validator rewards

Validators receive 500 million REACT from a fixed allocation.

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

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

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

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

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

Core contributors

Core contributors receive 420 million REACT.

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

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

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

Ecosystem development and grants

The ecosystem allocation is 280 million REACT.

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

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

The dashboard

The tokenomics only matter if people can verify them.

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

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

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

Why this matters now

This change fits the wider Reactive roadmap.

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

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

Tokenomics has to move with it.

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

The answer should be visible.

The only variable left

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

The same standard now applies to REACT.

No mint path. No future issuance. No spreadsheets.

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

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

About Reactive Network

Build once — react everywhere!

Finality Wars: Why Reactive Network is building with CometBFT

Reactive Network — Tue, 16 Jun 2026 15:55:47 GMT

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

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

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

A Quick Recap on the Problem

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

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

Finalize in One Round

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

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

A Million Validators

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

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

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

Cost of Aggregation

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

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

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

Pipelining Trick

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

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

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

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

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

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

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

The Catch That Sounds Familiar

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

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

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

Bigger Picture

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

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

About Reactive Network

Build once — react everywhere!

Reactive Staking: Season 6 with Boosted Pool

Reactive Network — Wed, 10 Jun 2026 11:01:34 GMT

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.

How Season 5 Stacked Up

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

Pool	Stakers	Total REACT Staked
1 month	41	16,794,988.65
2 months	139	39,145,554.35
3 months	297	94,404,072.89

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

How to Join

If you staked in Season 5:

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

If you're new:

Open the Reactive Token Portal and connect your REACT wallet.
Select the 1-month pool (the only one this season).
Enter the amount of REACT you'd like to stake.
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

Build once — react everywhere!

The Future of Ethereum Consensus Is Already Running on Reactive Network

Reactive Network — Fri, 05 Jun 2026 12:59:56 GMT

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

Build once — react everywhere!

How CometBFT Consensus Works and What It Means For Reactive

Reactive Network — Thu, 28 May 2026 13:55:32 GMT

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

Build once — react everywhere!