The Chain That Answers Itself: Inside Somnia Reactivity Build in Public , Part [2]. DeFi runs on an invisible night shift of bots that watch the chain and poke it back. Somnia Reactivity moves that job inside the protocol. On Ethereum and the chains built like it, a smart contract has never woken itself up. It cannot act until someone sends it a transaction, so DeFi relies on a night shift of bots and keepers to watch the chain and push responses back in. Somnia Reactivity removes that night shift: contracts subscribe to onchain events, and the protocol itself executes the response, with no external bot signing the reaction. On Somnia mainnet, those reactions land in the same block as the events that trigger them. Here is how we built it, and what it took to get every node on the network to agree. The last mile is still a bot The standard way to build an event-driven DeFi app is to run an observer. It listens for a log, checks the latest state, then submits a transaction in response. Every step after the event happens offchain, on infrastructure the team has to keep fast, funded and secure. Picture a copy-trading app following a top wallet. The wallet trades. The app's server spots the log, checks the price against its users' limits, signs a trade and broadcasts it. If that loop takes an extra second, the market has already moved. The chain can process the follow-up quickly, but it cannot win back the time spent noticing the event and sending the reply. And latency is the cheap part. The team also has to run a server, protect a hot key, top up a gas wallet and live with a single point of failure at exactly the moment markets get busy. DeFi learned the cost on Black Thursday in March 2020, when keepers struggled to bid in MakerDAO's liquidation auctions as gas spiked and some collateral cleared at close to zero. Yet every team building reactive logic still rebuilds this same plumbing from scratch. We started with a simple question. If the event happens onchain, and the logic for responding to it is already onchain, why does the response have to leave the chain and come back? Attempt one: better ears, same legs Our first answer was somnia_watch, an endpoint that combined eth_subscribe and eth_call. An app could observe a log and query the state it needed in a single step, instead of listening and then making a separate round trip. It made watching the chain easier, but something offchain still had to sign and submit the reaction transaction. We had given the night shift better ears. It still had to run to the door. To remove the run, the response itself had to move inside the protocol. Reactivity: building the thermostat into the chain Think about heating a house. One way is to hire someone to watch the thermometer and flip the boiler on when it drops. That works until they fall asleep, get stuck in traffic or check at the wrong moment. The better way is a thermostat: the sensing and the switching live inside the system. Reactivity is the thermostat. A smart contract creates a subscription that links an emitted log to a handler function and defines which events should trigger it. When a matching event occurs, the protocol executes the handler on behalf of the subscription owner. Nobody signs a separate reaction transaction. The application still owns the logic: which events matter, what conditions to check and what action to take. The chain now runs the response as part of normal execution, so teams no longer need their own observer-and-keeper stack. Before Reactivity A contract emits an event. An offchain observer picks it up. The observer queries state over RPC. A bot signs a new transaction with its own key and gas. The transaction waits to be included in a later block. With Reactivity A contract emits an event. The protocol matches it to a subscription and runs the handler, on mainnet in the same block as the event that triggered it. The hard part: thousands of thermostats, one shared answer Explaining Reactivity takes a paragraph. Making it deterministic was most of our testnet work. A blockchain is a machine where every node must reach the same result from the same inputs. Accounts, code and blocks already work that way. Subscriptions are a new kind of state, and they change while the network runs: contracts subscribe and unsubscribe block by block. If two nodes disagree by even one subscription about which handlers should fire, they compute different states and the chain splits. In early March 2026, we shipped the first testnet release under a tight deadline and missed tests. It went badly. We spent the next month fixing issues, many of them in state management. Smaller problems kept surfacing too. We got close to finishing cron jobs for recurring schedules, then cut them because they weren't stable enough and built a simple one-off scheduler instead. The address we first assigned to Reactivity, 0x0100, turned out to be taken. And some of our precompile interfaces caused compatibility problems for developers writing Solidity against them. These sound like implementation trivia. They also decide whether builders can trust the feature, because protocol execution, interfaces and developer tooling all have to work together before anyone ships on it. What a chain that responds makes possible When an app's logic and data already live onchain, Reactivity lets it respond to onchain activity without a separate service sending the reply. A few designs this opens up: Copy trading without the server. A followed wallet's trade triggers a handler that checks each user's limits and acts. Risk checks that run on the event. A price update emitted onchain prompts a position check or update, rather than waiting for a bot to notice. Markets that settle themselves. A market updates state or settles when its onchain conditions are met. Builders can pursue these designs now, though not every one is live yet. Each still depends on sound financial logic and reliable inputs. Somnia is building financial and information infrastructure for onchain finance. Instead of stitching together an offchain matching engine, a sequencer, an oracle network and a bridge, venues build on one decentralized platform where each layer is a smart contract and every action is a public transaction. Reactivity is what lets those layers respond to each other: when one contract's event triggers another's handler, the response happens inside the chain's public execution, where anyone can verify it. Live on mainnet: 6,771 subscriptions In our October snapshot, Somnia mainnet had 6,771 subscriptions, with recorded executions landing in the same block as the events that triggered them. It shows the feature working in production. It isn't a benchmark for every DeFi workload. Builders still define the financial logic, choose the inputs and set the conditions for acting. They just don't need to run a separate system whose only job is to watch the chain and talk back to it. For most of DeFi's history, blockchains have been excellent record keepers and poor listeners. A fast chain processes financial activity. A reactive chain responds to it. Building something that should react on its own? Start with the Somnia Reactivity docs: https://docs.somnia.network/developer/reactivity.(Historical earnings: For fiscal 2026Q3 (period ended 2026-02-28), Oracle reported basic EPS of 4.47, diluted EPS of 4.38, and net income of USD 12.783 billion, versus prior-year basic EPS of 3.24, diluted EPS of 3.15, and net income of USD 9.016 billion. For fiscal 2026Q2 (period ended 2025-11-30), basic EPS was 3.19, diluted EPS 3.11, and net income USD 9.062 billion, versus prior-year basic EPS of 2.19, diluted EPS of 2.13, and net income of USD 6.080 billion. Consensus expectations: For the upcoming 2027Q1 event, consensus EPS estimate is 1.7766 and revenue estimate is USD 19.527 billion.)