Blog | Reactive

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

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 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

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!

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!

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!