Blog | Reactive

Reactive Staking: Season 10

Reactive Network — Tue, 13 Oct 2026 15:17:26 GMT

Reactive Staking Season 9 closes at block 7,196,129 on Wednesday, October 14th, and its one-month pool expires with it. Season 10 picks up on the very next block with a two-week pool that runs until the Omni upgrade goes live on Reactive mainnet on October 28th. It is the last staking season: after that, seasons give way to delegation and validation.

Short version for newcomers: staking locks up REACT for a fixed period and pays you for helping secure the network. Each season is a fresh round with its own pools and reward budget.

Season 9 ran a single pool against a budget of 1,000,000 REACT. By the close, it held 104,764,620 REACT from 200 unique stakers, with APY settling at 12.31% .

Token Portal Guide

Stake

Open the Reactive Token Portal and connect your REACT wallet.
Make sure the // STAKE tab is selected.
Pick the 2-week pool, the only option in Season 10.
Enter the amount of REACT you want to stake.
Hit Stake and confirm in your wallet.
Watch the current block and reward block tick along if you want to track the countdown.
Distribution stats sit below: total staked, total reward, current APY, your stake, your rewards.

Disclaimer: Staking locks your funds until the Reward Distribution Block. Unstaking is unavailable until then, so stake only what you can leave alone for the full month.

Restake & Withdraw

Open the Reactive Token Portal and connect your REACT wallet.
Make sure the // WITHDRAW tab is selected.
Pick the season you took part in.
Choose the pool holding your tokens. Seasons before 4 ran 30-day, 60-day and 90-day pools; from Season 4 onward, pools are counted in months.
Pick the pool you want to restake into.
Hit Restake and confirm in your wallet.
The Withdraw All button takes everything back to your address.
Distribution stats sit below, same as on the stake tab.

Disclaimer: A withdrawal sends your staked tokens back to your address and can’t be cancelled or reversed. Rewards stop accruing the moment you withdraw.

Swap

Token Portal's bridge moves REACT freely between Reactive Network Mainnet, Ethereum Mainnet and Base.

Open the Reactive Token Portal and connect your REACT wallet.
Make sure the // SWAP tab is selected.
Choose the network you're sending from.
Choose the network you're sending to.
Enter the REACT amount.
Hit Swap and confirm the transaction (requires wallet confirmation).

Blocks to Watch

Season 9 closes at block 7,196,129 on Wednesday, October 14th. Rewards aren't distributed automatically, so be sure to claim yours through the Reactive Token Portal.

Season 10 launches on the very next block, 7,196,130, with a fresh 500,000 REACT budget, and closes at block 7,371,294 , on Wednesday, October 28th.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain execution. Reactive contracts subscribe to event logs across EVM chains and run Solidity logic automatically when a matching event fires, issuing cross-chain callback transactions once their conditions are met. The upcoming Omni fork moves the network to CometBFT consensus, bringing instant finality and roughly one-second blocks while keeping full EVM compatibility.

Build once — react everywhere!

Reactive x Robinhood: Chain Integration

Reactive Network — Mon, 12 Oct 2026 14:58:11 GMT

Reactive integrates with Robinhood Chain, an Ethereum Layer-2 built for tokenized real-world assets, as both an origin and a destination chain within Reactive Network. Stock Tokens and the DeFi built around them already trade around the clock. With Reactive, the logic that manages them can run around the clock too, responding to on-chain conditions on Robinhood and on every other chain the position touches.

Automation Gap In Tokenized Markets

Tokenized equities break an assumption most financial plumbing was built on: that markets close. A share of NVIDIA stops trading at 4pm Eastern. A token that tracks NVIDIA does not.

That mismatch shows up downstream. Spreads widen after hours. Price feeds update less often than the token trades. A weekend headline can move a stock token long before the underlying market can reprice. Anything built on these tokens, collateral, index products, lending vaults, has to keep working through windows when nobody is watching.

The usual answer is a bot, a cron job, and someone on call. That works until it doesn't, and it puts a server in the middle of something that should settle on-chain.

Robinhood Chain In Detail

Robinhood Chain went live on July 1, 2026. It runs on the Arbitrum Orbit stack and posts data back to Ethereum, so it inherits Ethereum's settlement guarantees. Anyone can deploy to it without approval, and existing Solidity works as is.

Stock Tokens launched with the chain in 120+ countries. They track US equities and give holders economic exposure rather than share ownership. The important part for builders is that they are ordinary ERC-20s: they can be supplied as liquidity, borrowed against, or bundled into index products, all without waiting for the NYSE to open.

Uniswap came in as the main AMM on day one and now handles roughly 99% of tokenized-stock trading on the chain, with v4 holding about 73%. Cumulative volume in those stock tokens passed $1 billion by mid-August, peaking near $130 million a day.

Reactive In Action

Reactive contracts subscribe to event logs on origin chains, run Solidity in response, and decide on their own whether to send a callback to a destination chain. No relayer, no keeper, no off-chain trigger.

Short version for newcomers: a normal smart contract waits for someone to call it. A reactive contract watches for something to happen and calls something else.

That fills a gap the current tooling leaves open. A Uniswap v4 hook, the main way to program custom logic into a pool, only runs when somebody trades, so it can’t act on a price move that arrives between trades. We have covered that limit from several angles in the previous articles: Maestro, Lambda, TrancheShield, and Veritas.

With Robinhood Chain on both sides of that relationship, the pool no longer has to wait for a trader to wake it up. An oracle update, a transfer, or an event on any other chain becomes the trigger, and the callback can land right back on Robinhood Chain.

Use Cases: Liquidity, Collateral, And Agents

Weekend feed gaps. Tokenized stocks keep trading after the equity market closes, while the price feed behind them updates less often. A reactive contract can tighten borrowing limits or pause a vault the moment the feed goes quiet, instead of at Monday's open.

Repositioning between trades. Pool logic only runs when somebody trades, so a range can sit at a stale price for hours. A reactive contract watching the reference price moves or retires that range when the price moves and no trade arrives.

Agent limits. Robinhood has positioned the chain as somewhere AI agents transact against tokenized assets. Exposure caps and cooldowns enforced by a reactive contract hold whether or not the agent is behaving.

Tokenized assets inherit the speed of crypto and the complexity of finance at once. Now we shall observe what happens when the settlement layer never sleeps but the reference market still does.

Developer Setup Guide

Connect to Robinhood Chain mainnet manually with this network information:

RPC URL — https://rpc.mainnet.chain.robinhood.com
Chain ID — 4663
Gas Token — ETH
Block Explorer — Robinhood Chain Blockscout

More details on connecting to Robinhood.

Testnet remains available for development, with faucet tokens that carry no value. For more details, see the Robinhood Chain Docs.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts — event-driven smart contracts for cross-chain execution. It runs on CometBFT consensus, providing deterministic finality with roughly one-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, issuing cross-chain callback transactions when their conditions are met.

Build once — react everywhere! Now on Robinhood Chain.

Lasna Testnet Completes Migration to Omni Fork

Reactive Network — Wed, 07 Oct 2026 14:56:10 GMT

Migration is complete. Lasna is now running on the Omni fork.

What's Different

The biggest change is that the RVM is gone. Reactive contracts now deploy once, to a single environment, as standard Solidity targeting version 0.8.29, and dual deployment is a thing of the past. Standard tooling works out of the box too: Hardhat, Foundry, and Remix all work without workarounds, and most of the custom RPC methods have been dropped.

Subscriptions keep the same signature, and a new system contract now handles them. Old-style callbacks still work, and new contracts can call a system contract method instead of emitting a raw event. Existing deployments keep working as before, since we support legacy functionality. Callback delivery, destination revert handling, and the gas model are unchanged too.

Time to Break Things

This is the best moment to put Lasna through its paces. Deploy contracts, set up subscriptions, fire callbacks, and push the faster blocks. Testnet is where surprises are cheap, and what you find now might shape what reaches the mainnet.

What’s Next?

As always, no promises can be made, however our current plans are to launch the full mainnet Omni-Fork by the end of the month, pending stress-testing of Lasna testnet. If plans change we’ll keep you updated.

About Reactive Network

Build once — react everywhere!

Lasna Testnet Pauses for Migration

Reactive Network — Mon, 05 Oct 2026 15:09:16 GMT

Heads up: Lasna goes offline for migration on Wednesday, October 7th, at 12:00 UTC.

Why Pause?

Back on May 26th, we announced the launch of a new version of Lasna testnet, running on our new CometBFT-based architecture. Now, in preparation for our mainnet migration, the original Lasna testnet, which was based on the legacy Geth and Prysm stack, is also moving to CometBFT.

This is the same upgrade we're preparing for mainnet, which brings instant finality: once a block is validated, it's permanent, with no reorgs on the Reactive side. Blocks also get faster, at roughly 1 second instead of about 7, and Reactive contracts become easier to deploy with the removal of RVMs, in line with standard Solidity contracts and bringing improved tooling with it.

Running the upgrade on Lasna first gives all of us a chance to shake it out before it reaches mainnet.

Before Wednesday

While the migration runs, Lasna won't process transactions, subscriptions, or callbacks. Anything sent its way during that window won't land, so wrap up or pause any tests that depend on it. We expect up to three hours of downtime.

Reactive Mainnet won’t be affected. We'll post again as soon as Lasna is back up, along with what's changed for your contracts and what’s next to come.

About Reactive Network

Build once — react everywhere!

Finality Wars: Counting Validator Counts Wrong

Reactive Network — Fri, 18 Sep 2026 13:17:43 GMT

On August 12th, Solana came within four and a half percentage points of losing the ability to finalize blocks, and almost nobody noticed. The network kept producing blocks and processing transactions the entire time, the status page recorded nothing unusual, and for roughly half an hour the margin between business as usual and a network-wide stall was thinner than it has been in a long while.

It's curious that none of the consensus software misbehaved. The code responsible for deciding which blocks the network agrees on did exactly what it was designed to do, all the way through. The problem was that a hosting company sent out a misconfigured network route.

In Finality Wars: Why Reactive Network is building with CometBFT we argued that fast finality is hard for Ethereum because Ethereum has over a million validators, and squeezing a million votes through the network every few seconds is a physical bottleneck that no amount of protocol elegance can talk its way around. We still think that is right. But August 12th points at something the validator-count framing quietly misses, and on reflection we think it may be the more important number.

Short Version For Newcomers

Validators are the independent machines that run a proof-of-stake network, Solana and Ethereum included. Each one's say in decisions is weighted not by machine count but by how much of the network's token is staked behind it, so a hundred small validators can matter less than one large one.

Finality is the point at which a block is permanently settled and can’t be undone. Reaching it requires validators holding more than two thirds of the stake to vote for the block. Turn that rule around and you get its shadow: if more than a third of the stake stops answering, whoever is left can no longer clear the two-thirds bar, and the chain stops declaring anything final at all.

That behaviour is a design decision rather than a flaw. Refusing to finalize is the safe way to fail, whereas the dangerous way is to declare a block settled and then have it reversed afterwards, which is roughly how exchanges get tricked and bridges get drained. A chain that stalls has decided it would rather say nothing than say something it might have to take back.

Which makes one third of the stake a line worth watching. In August, Solana walked right up to it.

Four Points From Stopping

For Solana that line sits at 33.34% of stake. Marinade Finance, which published a detailed reconstruction of the incident, reported that the fault pushed 28.83% offline, leaving a margin of 4.51 percentage points, or roughly 19.9 million SOL.

The cause was thoroughly unglamorous. Routers across the internet spend their time telling each other which paths traffic should take, and one hosting provider sent out a malformed announcement that spread through its own network. Equipment at a dozen of its sites across Europe and Asia accepted the broken path in preference to the working one, leaving those sites with no usable route to the rest of the internet while the same provider's North American locations carried on unaffected. Connectivity returned after around 33 minutes.

Throughout all of it, 597 of the network's 699 staked validators kept voting. That figure is the one we want to dwell on.

Headcount Versus Stake

Count the validators that went offline and you get one number. Count the stake behind them and you get almost double. Stake is the number consensus actually measures.

Both figures are accurate, and the distance between them is not a rounding error. It is the difference between how decentralized a network looks on a dashboard and how it behaves when a router misfires somewhere in Amsterdam. Marinade reported that 27.34% of all network stake sat behind a single network operator, and that 94% of that stake went dark simultaneously.

So for the duration of the fault, the question that mattered was never "how many validators does Solana have?" It was "how many things here can fail independently of one another?" and the answer to the second question turned out to be a great deal smaller than the answer to the first.

None of this is a mark against Solana in particular. Validators pick hosting for latency and cost like everyone else, providers and jurisdictions cluster together for perfectly good engineering reasons, and we are not aware of any chain that is genuinely immune to this. Solana's own response has been unusually open about what happened and why. What the incident gives us is the cleanest real-world demonstration we have seen of a gap that most discussion of consensus papers over entirely.

Wrong Denominator

Here is where we have to complicate our own argument.

In Finality Wars: Why Reactive Network is building with CometBFT we treated validator count as the thing that buys a network its decentralization and costs it its speed. Ethereum has over a million validators and pays for them in the delay it takes to bundle all those votes together, while chains built on CometBFT, the consensus engine we run, operate with somewhere between 50 and 175 and finalize in a second or two. More validators, more decentralization, slower finality.

August 12th suggests that count measures participation rather than independence. A validator set is a list of signing keys, whereas a failure domain is a building, a router, a network operator, a jurisdiction. The first number is published everywhere and quoted in every comparison, while the second is rarely measured at all and is the one that decides whether a chain keeps finalizing when something breaks. A million validators spread across three cloud providers is not a million failure domains, it is closer to three. Whether that beats a hundred validators across sixty providers is genuinely open, and not a question you settle by comparing counts.

The implication cuts awkwardly toward compact validator sets, which is where we live. Small sets are obviously more concentrated and we have never pretended otherwise, but their concentration is at least legible: with a hundred validators you can enumerate the hosting and count the operators in an afternoon. With a million, nobody can hold that picture in their head, and the reassuring size of the number actively discourages anyone from trying. Which is the more honest position to be in, visible concentration or concentration hidden behind a big number?

Same Threshold, Different Bets

Three ecosystems are answering the same question right now in three different ways.

Solana is raising the tolerance. Its largest consensus overhaul since launch rebuilds how the network orders blocks and collects votes on them, targeting finality of around 150 milliseconds against today's roughly 12.8 seconds. Mainnet activation is scheduled to begin on September 28th, 2026, though two official sources give different timings, so the precise day is best treated as provisional. Asked about the August incident, one of the network's co-founders said the new design should keep finalizing with up to 40% of stake offline rather than a third. That was a remark on social media rather than a specification, but the direction of travel is unmistakable: the upgrade widens the very margin that a routing fault came close to consuming.

Ethereum is rehearsing the failure. Its next major upgrade has been running since August 20th on a test network built for it, and the plan is to stand up a second one designed specifically to simulate what happens when consensus struggles, before the code reaches the public testnets everyone uses. Deliberately building somewhere to practise not finalizing is a quietly impressive piece of engineering culture, and it follows from a design that would rather let finality lag behind than stop the chain.

CometBFT accepts the halt. There is no third option and no graceful degradation: once more than a third of the voting power is offline, block production stops. We wrote in June that this is the opposite call from Ethereum's, and it is. What August 12th adds is that the threshold is not an abstraction in a paper, but a real line that a real network walked up to this year, for reasons that had nothing whatsoever to do with consensus.

Three Ways to Stop

Which brings us to our own exposure, because it would be a bit rich to write all this and not turn the lens around. Reactive Network will soon run on CometBFT, and we’ve chosen it with our eyes open. Reactive finality is permanent the moment a block is validated, with no reorganizations, no probabilistic waiting and roughly one second of latency. The bill for that is precisely the one-third line Solana brushed against in August.

We also have more than one surface on which things can stop, and this is the part that rarely shows up in discussions of finality:

Reactive finality depends on our own validator set staying above the two-thirds mark. Below it, we stop finalizing.
Origin finality depends on chains we do not control. Our sequencer treats an event it has observed on an origin chain as canonical even if that chain later reorganizes, which is a deliberate choice and the thing that makes reactive contracts responsive, but it does mean another network's liveness becomes partly our concern.
Callback delivery depends on destination chains being available to accept a transaction, since a callback that cannot land is a callback that has not happened.

Any one of the three can stop without the other two noticing, and a user watching a cross-chain workflow stall has no way of telling which it was and little reason to care. This is the same borrowed-certainty problem we wrote about in Intents, Solvers, and Borrowed Certainty, approached from the opposite side: solvers absorb origin-chain reorganization risk on behalf of users, and we absorb it on behalf of contracts.

What August 12th changes for us is not the architecture but the measurement. Counting our validators tells us remarkably little about whether all three of those surfaces could fail at the same moment, and neither we nor anybody else routinely publishes the number that would.

Question Pointed Back

The obvious response to an article like this is to ask the author how concentrated their own infrastructure is, and that is a fair question to ask us. Sequencer decentralization sits in a later phase of our roadmap, which means today the honest answer involves a shorter list of failure domains than we would like. Saying so is not a confession. It is the thing we are arguing everyone should be able to say precisely, including about themselves.

What would it take for chains to publish failure-domain counts next to validator counts? Not a standard, not a committee, just the habit of treating "how many separate things can break?" as a number worth knowing. Marinade produced it for Solana in a few hours because an incident forced the question. It would be better to have it before.

About Reactive Network

Build once, react everywhere!

Reactive Staking: Season 9

Reactive Network — Fri, 11 Sep 2026 11:23:08 GMT

Reactive Staking Season 8 closes at block 6,816,896 on Sunday, September 13th, and its one-month pool expires with it. Season 9 picks up on the very next block, so stakers can roll straight into the next round with no gap in between.

The new round keeps the shape recent seasons settled into: one pool, one month, one reward budget. In the background, the new Reactive consensus is in final testing ahead of the move to Reactive Omni. Once that lands, the staking structure may change with it.

Short version for newcomers: staking locks up REACT for a fixed period and pays you for helping secure the network. Each season is a fresh round with its own pools and reward budget.

Season 8 ran a single pool against a budget of 1,000,000 REACT. By the close, it held 108,308,917.99 REACT from 194 stakers, with APY settling at 11.88%.

Token Portal Guide

Stake

Open the Reactive Token Portal and connect your REACT wallet.
Make sure the // STAKE tab is selected.
Pick the 1-month pool, the only option in Season 9.
Enter the amount of REACT you want to stake.
Hit Stake and confirm in your wallet.
Watch the current block and reward block tick along if you want to track the countdown.
Distribution stats sit below: total staked, total reward, current APY, your stake, your rewards.

Disclaimer: Staking locks your funds until the Reward Distribution Block. Unstaking is unavailable until then, so stake only what you can leave alone for the full month.

Restake & Withdraw

Open the Reactive Token Portal and connect your REACT wallet.
Make sure the // WITHDRAW tab is selected.
Pick the season you took part in.
Choose the pool holding your tokens. Seasons before 4 ran 30-day, 60-day and 90-day pools; from Season 4 onward, pools are counted in months.
Pick the pool you want to restake into.
Hit Restake and confirm in your wallet.
The Withdraw All button takes everything back to your address.
Distribution stats sit below, same as on the stake tab.

Disclaimer: A withdrawal sends your staked tokens back to your address and can’t be cancelled or reversed. Rewards stop accruing the moment you withdraw.

Swap

Token Portal's bridge moves REACT freely between Reactive Network Mainnet, Ethereum Mainnet and Base.

Open the Reactive Token Portal and connect your REACT wallet.
Make sure the // SWAP tab is selected.
Choose the network you're sending from.
Choose the network you're sending to.
Enter the REACT amount.
Hit Swap and confirm the transaction (requires wallet confirmation).

Blocks to Watch

Season 8 closes at block 6,816,896 on Sunday, September 13th. Rewards aren't distributed automatically, so be sure to claim yours through the Reactive Token Portal.

Season 9 launches on the very next block, 6,816,897, with a fresh 1,000,000 REACT budget, and closes at block 7,196,129, on Wednesday, October 14th.

About Reactive Network

Build once — react everywhere!

Intents, Solvers, and Borrowed Certainty

Reactive Network — Thu, 03 Sep 2026 13:00:37 GMT

A wallet that wanted to support five bridges used to integrate five SDKs. Five fee oracles, five sets of error codes, five ideas about what "the transfer went through" means. Multiply that by every wallet and every app, and you get the state of cross-chain UX for most of the last five years: enormous duplicated effort spent on plumbing nobody wanted to think about.

Intents were the fix, and ERC-7683 is the standard that grew out of them. It is worth understanding what it did and did not solve, because the part it deliberately left alone is the part that decides whether your money arrives.

Short Version For Newcomers

An intent is a signed statement of what you want rather than how to get it. "I have 10,000 USDC on Arbitrum, I want USDC on Base, expire in five minutes". You sign that sentence. You do not pick a bridge, a route, or a relayer.

A solver is whoever reads that statement and makes it true. Solvers are off-chain actors, usually market makers running bots, who deliver the assets on the destination chain out of their own inventory and then claim payment from the origin chain. Competition between them is what gets you a good price.

The important structural detail: the solver fronts the capital and gets paid afterwards. Every risk that used to sit with the user, waiting to see whether a bridge delivered, now sits with the solver. That relocation is what makes the UX feel instant, and it is also where all the interesting problems went.

Five Bridges, Five Integrations

The fragmentation was never only a wallet problem. It hit solvers harder.

The standard's motivation section is blunt about the cost. Every solver has to integrate separately with each protocol's payload format, execution flow and payment semantics, and new protocols then struggle to attract competitive execution, because no existing solver can serve them without engineering work first.

So you get a market that looks competitive from the outside and is actually a set of walled gardens, each with its own small set of solvers, each quoting worse prices than it would if it could aggregate demand across all of them.

Standardizing Consumption, Not Settlement

ERC-7683 is still marked Draft, so what follows is where the specification stands rather than a description of any one deployment.

A protocol keeps its own order encoding, whatever that is, and publishes a resolver contract on-chain. A solver calls `resolve` on that resolver off-chain, through `eth_call`, and gets back a general-purpose description of the order: a list of steps to execute, variables it gets to choose (where it wants to be paid, on which chain), the payments it will receive, and a list of named assumptions the resolver can’t verify on its own.

Resolution happens off-chain, so the translation is not constrained by gas costs. A resolver can do rich, complicated decoding work that would be unaffordable inside a transaction.

The resolver is explicitly the point of trust. Solvers whitelist resolver addresses they have vetted through audits and time, and once vetted, they follow its instructions without needing to understand the protocol behind it. The standard's phrase for the goal is programmable solvers: add support for a new protocol by reviewing its resolver, not by writing an integration.

Whose Finality Are You Trusting

How does the origin chain learn that a fill happened on the destination chain? ERC-7683 does not say. Across uses an optimistic oracle. UniswapX uses off-chain attestations. You could use a validity proof. The standard is agnostic, which means the trust assumption behind any given transfer belongs to the settlement contract and the messaging layer underneath it, not to the standard. Two transfers can be equally ERC-7683-compliant and have nothing in common in terms of what could go wrong.

The security considerations are refreshingly direct about where that lands.

Notice where the window starts. Not when the order appears, but when the solver spends its own money on the strength of it. The solver looks at an event on the origin chain, decides it is real, and delivers on the destination chain. If the origin chain reorgs that event away, the solver has handed over goods against a payment instruction that no longer exists. Nobody at the standards layer can fix this, because it is not a formatting problem. It is a question about which chain's version of history you are willing to act on before that history is settled.

The standard handles it the only honest way available: it makes the assumption explicit. Conditions a resolver cannot verify get surfaced as named assumptions that the solver must validate before filling. Payments carry an `estimatedDelaySeconds` field, so the expected wait until money is actually spendable is part of the order rather than folklore. That does not remove the risk. It writes it down, which is a real improvement over five SDKs with five undocumented opinions.

Same Trade, Made Once

Reactive contracts react to events on other chains, which means our sequencer faces the solver's question on every single event it observes: act now on something that looks true, or wait for the origin chain to be certain. Our answer is a distinction we call origin finality. An event observed on an origin chain is treated as canonical for the purpose of triggering reactive logic, even if that origin chain later reorganises and unwinds it. That is a deliberate trade, made once at the protocol level and documented, rather than left to each application to rediscover.

A solver makes the same bet per order, priced into its spread and managed by its own risk model. We make it once, in the open, as a property of the network. Neither approach is obviously right.

The vocabulary is converging too. ERC-7683 gives solvers a way to read origin-chain logs, returning each one as a struct of emitter, topics, data, block number, transaction hash and log index. Anyone who has written a reactive contract will recognise that shape immediately, because it is nearly our own log record. When two designs converge on the same data structure without coordinating, it is usually because the underlying problem has only one sensible decomposition. Which raises the question worth sitting with: if everyone building across chains eventually needs a name for "true enough to act on", should that be a per-protocol choice, or the next thing somebody tries to standardize?

About Reactive Network

Build once — react everywhere!

Glamsterdam Gives Ethereum a Second Gas Meter

Reactive Network — Thu, 27 Aug 2026 15:10:32 GMT

For as long as Ethereum has existed, sending ETH from one address to another has cost 21,000 gas. It is one of the very few numbers that survived every fork, every roadmap rewrite, and every philosophical argument the ecosystem has had since 2015. Wallets hardcode it. Fee estimators assume it. "Send max" buttons are built on it.

Glamsterdam, Ethereum's next major upgrade, puts an asterisk on it. And the Ethereum Foundation has been unusually blunt about what that means: any tool that relies on a hardcapped maximum gas limit will break and needs updating. That is worth understanding even if you never touch Ethereum L1 directly, because the reasoning behind the change tells you something about where every high-throughput chain is heading.

Short Version For Newcomers

Gas is Ethereum's unit for "how much work did this transaction cause". Every operation has a price tag in gas, you pay for the total, and each block has a gas limit that caps how much work fits inside it. Think of it as a metered utility bill.

State is the chain's permanent memory: every account balance, every deployed contract, every storage slot. The important thing about state is that it does not go away. A transaction takes a second to execute and then it's done, but the state it creates has to be stored by every node, forever, including nodes that sync ten years from now.

Ethereum has always priced those two things with one number. Glamsterdam splits them apart.

Paying For Permanence

The change lives in EIP-8037, and it comes down to one split: operations that create new permanent state get charged to a separate meter called state gas, while everything else stays on the familiar meter, now called execution gas.

Every new state byte gets a fixed price, `CPSB` (cost per state byte), currently set at 1,530 gas. Multiply that by how many bytes an operation actually writes to disk and you get its state-gas charge. A fresh account is 120 bytes on disk, so creating one costs 183,600. A storage slot, the 32-byte box that contracts use to remember things between transactions, takes 64 bytes once you count its key, so filling a fresh one costs 97,920. Slots are the most common way applications create permanent state, which is why that second number matters more than it looks.

And the headline case: sending ETH to an address that already exists still costs 21,000, but sending it to an address that has never appeared on-chain adds that 183,600 charge at runtime. Roughly 204,600 total, close to ten times the number your wallet has been quietly assuming for a decade.

This is a correction as much as an increase. Deploying bytecode currently costs about 200 gas per byte of new state, while filling a storage slot costs about 313. Same disk, same permanence, different price, purely for historical reasons. EIP-8037 picks one number and applies it everywhere.

Bigger Blocks, Bigger Database

The motivation is not revenue. Ethereum wants bigger blocks, and bigger blocks fill up the database faster.

Every full node keeps its own copy of the state, and Ethereum's security rests on ordinary people being able to run one on ordinary hardware. Once that database outgrows a consumer drive, running a node becomes a data-centre job, and the property that makes the chain worth trusting quietly erodes.

Today it sits around 390 GiB, most of a typical laptop SSD. When Ethereum last doubled block capacity, raising the gas limit from 30 million to 60 million, daily new state more than tripled, from roughly 105 MiB to 326 MiB. People did not simply use the extra room, they used it disproportionately for things that leave permanent data behind. Project that onto the 200 million gas limit Ethereum is aiming for and the EIP arrives at roughly 387 GiB per year, which crosses the 650 GiB mark where nodes noticeably slow down in under a year.

There is the trap: raise the limit in order to scale, and you price ordinary people out of running a node, which defeats the point of scaling. So the authors worked backwards. Decide how much state growth is tolerable, in this case 120 GiB per year, work out how much state a year of blocks could produce, and divide one by the other. Out falls 1,530 gas per byte, the number behind every figure in the table above.

Two Counters, One Block

A block used to have one counter. Now it has two, one per dimension, and the block's reported `gas_used` is whichever counter is higher.

Two things follow from that. A block can be declared full while most of its execution capacity sits unused, as in the storage-heavy case above. And whichever dimension turns out to be the bottleneck is what drives the base fee, the price per unit of gas that everyone competing for that block has to pay.

Transactions get the same treatment. A transaction still carries one gas limit, but the protocol splits it into a normal budget and a reserve for state charges, which drain the reserve first and fall back to the budget once it runs dry. The useful consequence is that Ethereum's per-transaction gas cap now applies to execution gas only. Without that carve-out the new prices would have capped deployable contracts at around 7.4 KiB; instead Glamsterdam raises the contract size limit from 24 KiB to 64 KiB.

What Actually Breaks

If you maintain anything that touches Ethereum transactions, here is the checklist. Everyone else can skip to the last two sections without missing the argument.

Anything hardcoding 21,000. Especially "send max" flows, which subtract an assumed fee from the balance. Send to a fresh address and the real cost is ten times that, so the transaction fails.
Single-dimension gas estimation. `eth_estimateGas` has to return a limit covering both dimensions. One-number models will underprice anything that writes new state.
Hardcoded maximum gas limits. Indexers and validators that reject blocks above a fixed ceiling will choke as the limit climbs.
Metering with `gasleft()` deltas. The `GAS` opcode reports the normal budget only, so a before-and-after difference misses state gas entirely. ERC-4337 bundlers work exactly this way.
Pre-signed deployment transactions. The deterministic deployer factories were signed with fixed limits, often 100,000, which no longer cover the cost. Existing chains are fine, but new networks starting from genesis need them regenerated.
Contracts that write storage for users. Creating a struct, minting to a new holder, initialising a mapping entry: all new state, all now ~5× more.

About That 200 Million

The other number in the headlines is the 200M gas limit floor, up from roughly 60M today, and it is worth being precise about what that is. The fork does not set the gas limit. Validators do, through gas-vote signaling, and they will only step it up as nodes prove they can handle bigger blocks without falling behind on propagation. 200M is the design target the repricing unblocks, not a switch that flips on fork day. Expect a climb, not a jump.

Mainnet timing remains unconfirmed. Q4 2026 is the window most of the ecosystem is working toward, but the Foundation has consistently declined to name a date, and the honest read is that Sepolia and Hoodi activation are the signals to watch. EIP-8037 is also still in Review, so 1,530 is the current parameter rather than a promise.

Reactive Callbacks On Ethereum

Reactive Network is its own chain with its own gas model, so none of this changes how reactive contracts are metered. What it changes is the far end of the pipe. When one of our callbacks lands on Ethereum it executes as an ordinary Ethereum transaction under Ethereum's rules, with a gas limit the developer chose when requesting it, usually set once as a constant and then forgotten about. That is exactly the kind of assumption this upgrade is designed to expose.

So if you run a reactive contract with an Ethereum destination, ask whether your callback ever writes state that did not exist before: minting to a first-time recipient, initialising a slot, deploying through a factory. If it does, the `CALLBACK_GAS_LIMIT` that worked comfortably last year may not cover it after Glamsterdam, and a callback that runs out of gas is a callback that does not do its job.

About Reactive Network

Build once — react everywhere!

Veritas: Keeping A Risk Score True As Copies Appear

Reactive Network — Tue, 25 Aug 2026 13:06:23 GMT

Veritas was the sixth and last of the projects in our look at the UHI9 hookathon, and it puts a reactive contract to a use none of the others needed: keeping a stored number true after the thing it measures has quietly changed. The full project lives on GitHub, though the repository is private, so you may need to request access from the owner. The project's website is here.

Veritas is a Uniswap v4 hook for pools of tokenized content, a photo or some other piece of media that someone has registered on-chain and opened a pool around. It prices a risk that ordinary pools ignore. As copies and near-duplicates of that content spread, the original loses the scarcity its value rests on, and the liquidity providers in its pool (the people who deposit the two tokens so others can trade between them) are the ones left holding that loss. Veritas attaches a risk score to each asset and feeds it into the pool's swap fee, so a riskier asset charges more and its providers are paid more to hold it. The interesting part, and the reason Reactive is involved, is when that risk actually changes.

A risk that arrives from somewhere else

To an ordinary automated market maker, a pool holding a one-of-a-kind photo looks exactly like a pool holding one of ten thousand identical copies. It can’t see scarcity, so it can’t price the loss that comes when scarcity fades. As duplicates multiply, the content's price drifts, and providers eat the difference as impermanent loss, the gap that opens up for a liquidity provider when the price moves and they end up worse off than if they had simply held the two tokens. Veritas measures how diluted a piece of content is and folds that into a single risk score, which the pool's fee then tracks.

Here is the part a hook can’t handle on its own. A piece of content's dilution does not change because of anything that content or its pool does. It changes when someone, somewhere else, registers a near-duplicate. Attest an original photo today (register it on-chain along with a fingerprint of the image) and its duplicate count is zero. Next week a near-copy of it gets attested, and the original is suddenly less unique than it was, through no event of its own. Nothing in its pool has traded, so its hook has not run, and no one has any reason to send a transaction that goes back and updates the original's record. The number that is supposed to stand for its risk is now quietly wrong.

What the reactive contract watches

Every new piece of content is recorded in a contract on Unichain, the registry, which emits a `NewAttestation` event when it happens. Veritas's reactive contract, `DilutionMonitorRC`, lives on Reactive's Lasna testnet and subscribes to that event, every one of them, because any new attestation might turn out to be a duplicate of something already on file.

// Watch every NewAttestation the registry emits on the origin chain.
service.subscribe(
    originChainId, originRegistry, NEW_ATTESTATION_TOPIC_0,
    REACTIVE_IGNORE, REACTIVE_IGNORE, REACTIVE_IGNORE
);

Where the earlier projects in this series subscribed to events about a single pool, this one subscribes to the arrival of new content across the whole registry, because that is where the risk to the existing assets comes from.

The score the diagram calls DRS is the pool's dilution risk score: a single number between 0 and 1 for how exposed a piece of content is to being copied, and the value the pool's fee tracks. The on-chain duplicate count is one of its inputs, so the more near-duplicates a piece of content picks up, the higher its count, the higher its DRS, and the more its pool charges to compensate the providers. Keeping that count current as new duplicates appear is the whole purpose of the loop: the registry emits an attestation event, the reactive contract on Lasna hears it and forwards the new attestation's id, and a callback back on Unichain finds the existing near-duplicates and raises their counts.

From a new attestation to a repriced pool

When an attestation arrives, `react()` runs, and it does something deliberately small: it forwards the new attestation's id to a callback on the other chain, and nothing more. It does not go hunting for duplicates itself. A reactive contract runs in a constrained environment that can’t cheaply read the destination chain's stored fingerprints, so the comparison is left to the side that can do it well.

function react(LogRecord calldata log) external vmOnly {
    bytes32 attestationId = bytes32(log.topic_2);   // the new attestation's id

    // Hand the id to the callback on the destination chain; let it run the search.
    emit Callback(destinationChainId, callbackReceiver, CALLBACK_GAS_LIMIT,
        abi.encodeWithSignature("onDilution(address,bytes32)", address(0), attestationId));
}

On the destination the callback does the real work. It reads the new content's fingerprint, asks the registry for everything already on file that looks close enough to count as a near-duplicate, and raises the dilution count on each of those existing records.

function onDilution(address /* rvmId */, bytes32 triggerAttestationId) external authorizedSenderOnly {

    // read the new content's fingerprint, then find the near-duplicates already on-chain...
    AttestationRecord memory rec = registry.getRecord(triggerAttestationId);
    bytes32[] memory affected =
        registry.getNearDuplicates(rec.pHashFingerprint, rec.blockhashFingerprint, HAMMING_TAU);

    // ...and raise each affected asset's dilution count.
    for (uint256 i = 0; i < affected.length; i++) _tryIncrement(affected[i]);
}

It listens only to Reactive's official callback proxy, and the registry in turn accepts these increments only from this callback, so the single contract allowed to raise an asset's risk is the one at the end of this exact chain of custody. Raising the count is what moves the score: a higher dilution count lifts the risk score, and the pool reads that new score and charges a higher fee on its very next swap. The provider who was quietly exposed to a copy that showed up last week is now, without anyone lifting a finger, paid more to carry it. Each increment is wrapped so that one frozen or disputed record can’t block the rest of the batch.

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!

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

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!