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

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

The Vision

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

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

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

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

Part 1: What we Built, What Builders Told us

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

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

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

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

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

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

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

Part 2: Where we Must Progress

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

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

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

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

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

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

Opening the Code

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

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

Moving to CometBFT

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

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

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

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

Sequencer Upgrade

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

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

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

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

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

A New Organisational Structure

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

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

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

Validators and Safeguards

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

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

The Roadmap and Phased Timeline

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

Conclusion

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

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

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

About Reactive Network

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

Reactive Contracts monitor event logs across EVM chains and execute Solidity logic when subscribed events occur, autonomously deciding when to send cross-chain callback transactions. This model supports conditional cross-chain state changes and continuous cross-chain workflows.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!