The Smoke Detector Problem: What On-Chain Monitoring Can and Can't Stop in 2026

Detecting an attack is largely solved. Stopping it depends entirely on the attack's shape — and on whether a response was wired before the alarm fired.

In 2022, Forta's machine-learning model flagged the Team Finance exploit contract a full hour before the attacker sent the first malicious transaction. The detection was correct. The lead time was enormous. And the funds drained anyway, because nobody was subscribed to that alert and no action was wired to fire when it tripped.

Hold that case in your head, because it is the whole subject in miniature. A monitor that sees an attack does nothing on its own. It is useful only if there is a window to react and a mechanism (a pause, a block, an exit) that fires inside that window before the money leaves. Detection and prevention are two different problems, and in 2026 they are in very different states of health.

The single mental model to carry: monitoring is a smoke detector, not a sprinkler. It tells you the building is on fire. Whether anything puts the fire out is a separate question entirely, and the answer depends almost completely on the shape of the attack.

Detecting that an attack happened is, by 2026, largely a solved problem — confirmed-transaction detection lands close to complete, often within seconds. The harder question is the lead time that buys you room to act before funds leave. For multi-step attacks with a staging window, the good platforms often see it minutes ahead. Against an atomic single-transaction drain or an attack that originates off-chain, they have no meaningful pre-attack signal at all.

The paradox to resolve first

Here is the fact that confuses everyone who looks at the headline numbers. The defendable category, exploits of DeFi protocol code, has shrunk hard. DeFi-protocol exploit losses are down roughly 74% from the 2022 peak through 2025, from a $2.62B peak to about $680M in 2025. The 2024 trough was lower still, about $534M (roughly 80% below the peak), before losses partially rebounded to ~$680M in 2025 as activity picked back up after the Bybit theft.

And yet total dollars stolen keep breaking records. 2025 shattered the all-time dollar record at $3.4B. 2026 is now setting records by incident count: Q2 2026 logged the most individual hacks ever recorded in a single quarter, even though the dollar pace through the first half hadn't yet matched 2025's comparable period.

Those two facts aren't in tension. The attacks migrated. Stolen keys, poisoned signing UIs, social-engineered approvals, hijacked DNS: the dollars moved off-chain, to places where on-chain monitoring is structurally blind to the origin. The code-exploit category that monitoring can actually fight is the one that shrank.

So the real question isn't whether monitoring works. It's which attack shapes it can possibly work against, and that comes down to two properties of any exploit: is there a window to interrupt it, and is a response wired to fire inside that window?

Why attack shape decides everything

Start with the window, because some attacks don't have one.

An EVM transaction and its entire internal call tree execute as a single indivisible unit. It all succeeds or it all reverts, and nothing external can run "in the middle." A flash-loan attack borrows, manipulates a price, drains, and repays inside one transaction. There is no "during" to interrupt. bZx and the November 2025 Balancer drain both packed the full theft into a single atomic transaction; Euler's $197M took multiple flash-loan transactions, one per pool, though each individual pool drain was itself atomic. Against any of these, a pause() executed in a later block has nothing left to pause. The fire is already out.

Many large drains, though, are not atomic. The attacker stages a contract, runs failed test transactions, then drains over several transactions, blocks, or hours. That elapsed time, dwell time, is the window real-time monitoring lives in.

The Solv Protocol exploit (March 5, 2026) shows exactly what that window looks like. A reentrancy/double-mint bug in an onERC721Received callback amplified supply 4.2-million-fold over 22 cycles and drained about $2.7M — all atomically, in one transaction. That first transaction was already final before any monitor could act. But the exploit was multi-contract: roughly $10M was still reachable across other Solv contracts after the first drain. That open, multi-contract window, the gap between the first atomic transaction and everything else the attacker could still reach, is where post-block detection actually has leverage. (The $10M figure is vendor-attributed, per Hypernative.)

Then there's the surface the monitor can't see at all. On-chain monitoring watches blockchain state, transactions, and events. It is blind to the origin of an attack when that origin is a stolen private key, a poisoned signing UI, a phished approval, or a hijacked DNS record, even when it later sees the resulting outflow. Bybit's $1.5B drain looked, on-chain, like a perfectly legitimate signed multisig transaction. The compromise happened off-chain, in a tampered frontend. Nothing in the chain data was anomalous, because nothing in the chain data was wrong.

The second property, wired response, is where most teams quietly lose. The single biggest determinant of whether detection becomes prevention is whether a pre-authorized automated pause is wired to the alert, versus a human who has to wake up, assess, and act. Routing a pause through a multisig, as Hypernative put it, "would have introduced approval latency that could potentially cost hours." And humans drown in alerts: alert fatigue can mean the late-night page goes ignored. SparkDEX's alert fired at 3:56 AM; a separate Saturday-morning Olympus alert reached a human team only because someone happened to be watching. Two different incidents, same lesson — the signal that mattered nearly got lost in the noise.

That's the gap. Now the machinery that lives inside it.

What monitoring actually watches

Real-time monitoring ingests from several data layers at once, and each catches a different class of threat. You can think of what it watches as four layers:

Figure 1 — The four data layers of on-chain monitoring: mempool (predictive), confirmed transactions and events, per-block state snapshots, and off-chain signals.

The first layer, the public mempool, where pending transactions wait before they execute, is the only predictive one, and its window is tiny. The second and third layers (confirmed transactions plus events, and per-block state snapshots) are post-hoc by construction: they tell you what already happened, seconds late. The fourth layer is everything off-chain: DNS and frontend integrity, price feeds, governance forums, vulnerability disclosures. It's the only layer with any chance of catching the key-theft and UI-compromise attacks that now dominate the dollar losses.

How you pull from those layers matters as much as which ones you watch. Push beats poll. Polling on an interval adds roughly two seconds of block latency — "the difference between a warning and a post-mortem," in QuickNode's phrasing. Push and streaming (WebSocket subscriptions like eth_subscribe('newPendingTransactions'), or pipelines like Goldsky Mirror and QuickNode Streams) drop block latency below half a second and fire alerts in under a second. At protocol timescales, those two seconds are the whole game.

But the predictive layer has a catch that breaks naïve intuition: "mempool" means something different on every chain. The prediction window in layer one is chain-specific, and on several major chains it's effectively zero.

Chain	Pre-confirmation window	Implication for monitoring
Ethereum	~12 s public mempool	Best case for pre-crime alerting; simulation and whitehat front-running are feasible here
BSC	~0.45 s public mempool (Lorentz → Maxwell → Fermi hard-fork series; Fermi: Jan 14, 2026)	Still public but the window is ~27× shorter than Ethereum — reaction time is measured in fractions of a second, not human-readable seconds
Polygon	Public mempool; opt-in private mempool available since April 2026	Standard eth_subscribe works; attackers who opt into the private channel collapse your pre-confirmation visibility to zero
Avalanche	Validator-only gossip; public visibility severely limited vs Ethereum	Treat as effectively no usable prediction window for external monitors
Arbitrum	No public mempool; sequencer-feed WebSocket is the only signal	Subscribe to the sequencer feed — standard eth_subscribe('newPendingTransactions') sees nothing; ~250 ms blocks
Optimism / Base (OP Stack)	Private sequencer gossip — not an ETH-style mempool; sequencer-feed WebSocket subscription works	Standard Ethereum mempool subscriptions see nothing pre-confirmation; sequencer-feed subscription does work; ~2 s blocks
Solana	No mempool — transactions forwarded straight to validators (Gulf Stream)	Zero pre-confirmation window; all monitoring is post-slot; no "pending tx" concept exists

Ethereum's roughly 12-second public mempool window is the best case for pre-crime alerting — you can see a hostile transaction sitting there and maybe act before it's included. BSC now runs at about 0.45-second blocks following the Fermi hard fork on January 14, 2026 (the last of a series — Lorentz, then Maxwell, then Fermi), so its window is dramatically tighter than Ethereum's. Polygon still exposes a public mempool, though an opt-in private mempool option arrived in April 2026; Avalanche uses validator-only gossip that sharply limits public visibility. And then the window collapses entirely: Arbitrum has no public mempool (a sequencer-feed WebSocket is the only signal), Optimism and Base (OP Stack) use private sequencer gossip rather than an Ethereum-style mempool, and Solana has no mempool at all, forwarding transactions straight to validators.

That difference is purely a function of where the code is deployed. The same monitor watching a protocol on Ethereum gets a ~12-second head start to maybe act before inclusion. Watching that exact protocol on Base or Arbitrum, it gets ~0 seconds of pre-confirmation warning, because the sequencer's mempool is private: it learns of the hostile transaction only once the block is essentially built. One nuance worth keeping straight: on Base, a standard eth_subscribe('newPendingTransactions') subscription won't see pending transactions, but a sequencer-feed WebSocket subscription will. The visibility isn't gone; it just doesn't come through the door you'd expect.

The six ways detection actually works

Underneath the plumbing, detection comes down to six techniques stacked from cheap-and-dumb to expensive-and-predictive.

Rules, signatures, and blocklists are the floor. Match against known-bad: malicious bytecode patterns, OFAC-sanctioned addresses, catalogs of phishing contracts and fake tokens, known drainer signatures. Deterministic, near-zero false positives on exact matches, and completely blind to anything novel.

Invariant monitoring defines properties that must always hold (total assets ≥ total liabilities, sum of shares = total supply, TVL deltas within bounds, oracle deviation under some percentage) and alerts off-chain or reverts the transaction on-chain when one breaks. The on-chain form is the strongest defense in this whole list, because it stops the transaction atomically. It also costs gas and risks bricking legitimate flows.

Anomaly and ML detection builds a baseline of "normal" (balance variance, gas profiles, call-tree shapes) and flags deviations, which is good for slow-burn attacks that don't use flash loans or fresh contracts. The canonical example is Forta's exploit-contract model: a logistic regression treating contract bytecode as text (TF-IDF over EVM opcode n-grams). Exploit contracts have a fingerprint: heavy PUSH20 (they touch many addresses), absent SHA3 (no access-control storage reads), absent PUSH32 (no event emission, deliberately staying quiet). ⚠ The sober academic counterweight: surveys find naïve unsupervised anomaly detectors (One-Class SVM, Isolation Forest) often underperform and produce high false-positive rates, because smart-contract threats are about execution semantics, not numerical outliers.

Transaction simulation takes a pending or unsigned transaction, forks chain state at the current block, executes it in a virtual replica, and reads what would happen (token transfers, USD balance deltas, storage changes, the full decoded call trace) without committing anything. Tenderly offers this across 100+ networks with bundled simulations. Blockaid does it at the wallet level: a stateful fork plus ABI-decoded calldata plus denylist/allowlist risk classification, returning safe/warning/critical at under 300ms P99, powering MetaMask, Coinbase, Ledger, and Uniswap across 500M+ transactions a month (per a May 2026 Blockaid announcement). Simulation is the direct antidote to blind signing — it reveals malicious logic even when the dApp UI lies.

Graph and fund-flow analysis builds a transaction graph of every hop, split, and merge, clusters addresses likely controlled by one entity, and attributes those clusters to real-world actors. Chainalysis Reactor (27+ chains, Daubert-admissible in U.S. courts) and TRM Labs (glass-box attribution, with a source and confidence score per label) lead here. Critically, this sits mostly post-incident: it's forensics, attribution, and recovery, rarely the thing that stops an exploit mid-attack.

Bytecode and deployment detection flags the attacker's staging contract the moment it's deployed, before the first malicious call, via opcode fingerprinting and similarity to known exploit contracts. This is the highest-value detection in the list because it can precede the attack. Real recorded lead times: DFX Finance 6 minutes, Olympus DAO 2 minutes, Team Finance a full hour — the same hour that opened this piece, and the same hour that saved nothing.

Do any of these actually work against a real, informed attacker, or is it theater? The strongest non-vendor evidence comes from Trace2Inv, a peer-reviewed 2024 study that ran 23 invariants across 42 contracts hit by 27 real exploits. The single most effective invariant guard blocked 18 of 27 exploits on its own. The best combination tested (EOA∧GC∧DFU) blocked 23 of 27. A different, more conservative configuration achieved false-positive rates as low as 0.28–0.32%, but it covered only 20 of 27. Those are two distinct configurations, not one that does both at once. The part that matters most: the invariants stayed effective even when attackers knew about them. Bypass was infeasible or unprofitable in 84% of cases. Unlike a vendor's "$X saved" headline, this is controlled and reproducible. It's the best reason to believe a well-chosen on-chain check is real defense rather than marketing.

The platforms: who detects, who responds

The market splits into pure detection, pure response, and both. Here's the compact map as of mid-2026.

Platform	What it is	Detection / Response
Forta	Decentralized detection-bot network + Forta Firewall / FORTRESS neural net (pre-chain tx screening at the sequencer or RaaS layer)	Both — detection bots for post-block alerting; Firewall for pre-execution blocking
Hypernative	AI/ML + heuristics + simulation + graph analysis across 70+ chains; wires detection to automated pause/unwind/cold-storage via Safe/Fireblocks	Both — detection and automated response
Hexagate (acquired by Chainalysis, Dec 18 2024, ~$60 M est.)	ML real-time detection + GateSigner pre-signing screen	Both — pre-sign screen + real-time alert; now part of Chainalysis forensics stack
OpenZeppelin Defender	Classic Sentinel → Action → Relayer auto-pause stack. ⚠ Being sunset: signups closed Jun 30 2025, full shutdown Jul 1 2026; OZ pivoting to open-source Monitor/Relayer	Both (legacy — end of life; migrate now)
Tenderly	Transaction simulation on 100+ networks + Web3 Actions (programmable defensive txs); the simulation primitive others build on	Detection plumbing (infrastructure layer)
Blockaid	Wallet-level pre-signature screening at <300 ms P99; claims 90%+ of major Web3 wallets (vendor-reported figure, no independent market study)	Detection + user-side block (direct antidote to blind signing)
Chaos Labs	Risk oracles that auto-adjust DeFi parameters (supply caps, IR curves, LTV) within governance-approved bounds in real time	Detection + parameter response
Chainalysis / TRM Labs	On-chain forensics, entity attribution (27+ chains, Daubert-admissible / glass-box), address screening, KYT	Mostly detection / forensics / post-incident recovery
Cube3	On-chain RASP — a cube3Protected modifier reverts transactions that exceed an ML-derived risk threshold at execution time	Response / prevention (intra-block)

A few things are worth pulling out of that table. OpenZeppelin Defender, the classic Sentinel → Action → Relayer auto-pause stack that a generation of teams built on, is being sunset: signups closed June 30, 2025, full shutdown is July 1, 2026, with a pivot to open-source Monitor and Relayer tooling. Hexagate's real-time prevention layer was acquired by Chainalysis on December 18, 2024 for a reported ~$60M (officially undisclosed; that figure is a Calcalist estimate Chainalysis hasn't confirmed), folding live prevention into a company previously known for forensics. And Blockaid claims to screen transactions in 90%+ of major Web3 wallets, a vendor figure, with no independent market study confirming it.

The Hexagate acquisition paid off most visibly in the Venus Protocol incident (September 2, 2025). A whale was phished into granting delegate status, and roughly $13–13.5M was drained in one multi-step transaction ($13M per Hexagate/Chainalysis; $13.5M per PeckShield and CoinTelegraph). Venus had onboarded Hexagate monitoring a month earlier. The platform flagged suspicious activity 18 hours before and again at execution; the protocol paused within about 20 minutes, recovered fully within 12 hours, force-liquidated the attacker, and froze $3M via governance. ⚠ One caveat to file away for later: Hypernative also claims credit on Venus as a non-customer alert, so don't sum vendor tallies. The same save shows up on two scoreboards.

The latency reality — where on the timeline you catch it

There are exactly three places you can catch an attack, and they hand you wildly different powers.

Figure 2 — The three catch points: pre-transaction (mempool), intra-block (on-chain guard), and post-block (alert) — with the off-chain origin invisible to all of them.

Pre-transaction, in the mempool, is the only point where true prevention is possible (simulation and signature screening can stop a transaction before inclusion), and the point most often blinded by private orderflow. Intra-block, the on-chain guard (invariant revert, circuit breaker, RASP modifier) is the only thing that beats a single-transaction atomic drain, because it acts during execution. Post-block, the alert tier helps only if a window remains — a multi-step attack, a staging phase, a cross-chain leg. Underneath all three sits the off-chain origin, feeding straight into block inclusion while staying invisible to on-chain monitoring the whole way.

The detect-decide-act loop has to fit inside the chain's prediction window. The 2026 mempool latency budget looks like this: WSS arrival under 50ms, filtering under 1ms, state fetch under 20ms, simulation under 50ms, signing under 5ms, submission under 100ms. All of that has to land inside ~12 seconds on Ethereum, or sub-second on some L2s: Arbitrum runs ~250ms blocks; Optimism and Base (OP Stack) run ~2-second blocks. Push versus poll is the make-or-break, again: the two seconds polling adds is the gap between the window and the post-mortem.

As the Solv incident showed in practice, the atomic first transaction was simply beyond reach, already final by the time the monitor fired. No additional losses occurred beyond that initial ~$2.7M drain; Hypernative credits its post-block alert with enabling the remaining funds to be protected, though both the causal claim and the $10M figure are vendor-stated. What post-block detection bought wasn't a save on the core drain. It was time on the multi-contract window that followed, which is exactly the most the post-block tier can ever do, and exactly nothing on the part that already happened.

---

That distinction is the hinge of the whole subject. Detection in 2026 is genuinely good at seeing that an attack happened: the smoke detector works. Whether you can stop it is the harder question, and it splits cleanly along attack shape: atomic versus multi-step, on-chain versus off-chain origin, automated response versus a human in the loop. Part 2 takes that question head-on — the response ladder from auto-pause to asset freezing, the atomic ceiling that no alert pipeline can beat, the effectiveness scoreboard with its vendor-marketing traps, and the 2026 frontier where AI is arming both sides at once.

---

Sources & further reading

• Immunefi — DeFi Ecosystem Vulnerability Scoreboard (6 years) — the ~74–80% DeFi-protocol loss decline; best "is code security working?" evidence.

• Trace2Inv (arXiv 2404.14580) — peer-reviewed proof that invariant guards block 18–23 of 27 real exploits at FP rates as low as 0.28%, robust to informed attackers. The strongest controlled evidence that on-chain checks work.

• "After the Audit" — post-deployment monitoring stack (Ethernal) — best single explainer: three-layer detection timeline, Forta opcode-ML internals, why Team Finance's 1-hour lead time saved nothing.

• QuickNode — Real-time DeFi exploit detection — push vs. poll, sub-1s detection pipelines, why latency is the product.

• Hypernative — "Security Theater vs Real Detection" — the best vendor-skepticism framework and grading criteria for claimed saves. ⚠ Vendor metrics.

• Hypernative — Why on-chain monitoring fails most teams — detection-without-automated-response, alert fatigue, the human handoff problem. ⚠ Vendor metrics.

• Chainalysis — Crypto hacking & stolen funds 2026 — best overview of the 2025 landscape; Venus case anatomy; DeFi vs. CeFi divergence thesis. ⚠ COI: Chainalysis acquired Hexagate (Dec 2024).

• Trail of Bits — Maturing your smart contracts beyond private-key risk — vendor-neutral: access-control maturity levels, why pause is "not a golden bullet," timelocks and cancel-guardian patterns.

• Blockaid — Transaction security — wallet-level simulation internals: stateful fork, calldata decoding, <300ms P99 response, blind-signing defense.

• FlashGuard (arXiv 2503.01944) — the atomicity problem formalized; mempool disruption as the only pre-confirmation stop for atomic exploits. ⚠ Research-stage; counterfactual.

• ACM Computing Surveys — ML for smart contract security — the sober academic counterweight to vendor ML claims: unsupervised anomaly detection often underperforms; high false-positive rates in practice.

• altfins — DeFi hacks 2026 YTD — 2026 incident list with attack-vector composition; 72% of incidents attributed to credential/key theft.