Quicknode

April 21, 2026 — 7 min read

By Arseniy Reutov, CTO and Co-founder, Decurity Published on the Quicknode Blog

I've spent over a decade building attack detection systems; first in Web2, where I worked on traffic analysis and WAFs, then in Web3, where the same adversarial problems play out faster and with more money at stake. I co-founded Decurity in 2022. We audit DeFi protocols and we build the tools to monitor them in production. Defimon is the monitoring side: a real-time exploit detection system trusted by protocol teams, security companies, and risk curators across the chains where DeFi actually runs. It fires alerts before hacks make the news. Or it's not doing its job. Building something that operates at that speed, across that many chains, turned out to be a harder infrastructure problem than a security one. This is what building it taught us.

Why Detection Speed Is a Security Primitive

In DeFi, a protocol can be drained in a single atomic transaction. However, very often there is often a window between the first signs of an exploit and the protocol being fully drained. The Balancer incident. The Yearn hack. In each case the question was not whether someone was watching. It was whether they detected these first signs and reacted in time.

For automated incident response to work, the alert has to arrive in time for something to be done: pausing contracts, notifying multisig holders, moving funds. A two-second delay in block processing does not sound like much. At the protocol level, it is the difference between a warning and a post-mortem.

Detection speed is not a feature. It is the product.

The Problem with Polling

When we started building Defimon, we pulled onchain data the standard way: polling via RPC, repeatedly asking the blockchain for fresh blocks, transactions, logs, and traces.

It worked until it did not.

With millions of wallet addresses and contract interactions to monitor, polling created two problems we could not engineer around.

Latency. Each polling cycle added around two seconds of block latency. For a product where detection timing determines whether a protocol team gets warned in time, two seconds is a structural problem, not a performance tuning issue.

Scale. Our watchlist of monitored addresses kept growing. We pushed blockchain data into Apache Flink SQL pipelines running on AWS, with dynamic address lists stored in memory. As coverage expanded, out-of-memory errors became routine. The system could not scale with what we needed to monitor. And any change to the SQL pipeline required a full restart of Apache Flink, up to 20 minutes of downtime each time.

At its worst, we were spending $4,000 a month on AWS to cover three chains, with three to four engineers keeping the pipelines alive. Our team's expertise is in detection logic. We were spending it on infrastructure.

Why We Moved to Push Data

The core shift was replacing polling with a push model using Quicknode Streams.

Instead of asking the blockchain for data, the data arrives the moment a block lands onchain. Block latency dropped from around two seconds to under 0.5 seconds. Telegram alerts now fire in under one second from detection. That is not an incremental improvement. It is a different category of product.

But latency was only part of the problem. The bigger win was upstream filtering.

Our old Apache Flink pipeline ran on SQL. Detection logic lived in one large query assembled from many subqueries, declarative to write initially, but painful to maintain as it grew. When we migrated to Streams, we also moved our detection logic from SQL to JavaScript, filters running directly inside the blockchain node. That change gave us three things:

Flexibility. Any change to detection logic goes live without downtime. We have a full test suite built from past DeFi incidents that verifies our logic stays intact across modifications. Quicknode's JS filter testing tools let us run the entire suite before deploying.

Economy. We no longer process all blockchain data. Streams handles the filtering at the node level and delivers only the data we need. Bandwidth dropped significantly.

Speed. Data is pushed as soon as a new block appears. No polling interval. No round-trip delay.

The Detection Architecture

Here is what our pipeline looks like today.

A block lands onchain across any of the eight chains we monitor. Streams filters it at the node level using JavaScript, passing only relevant data downstream. The Key-Value Store built into Quicknode Streams holds our watchlist, millions of tracked addresses that the JS filters can reference directly. Exploit detection logic runs against the filtered data in our upstream service. If a pattern matches, an alert fires.

The entire sequence completes in under one second.

One concrete example: by processing transaction traces with Streams, we can detect attempts to backdoor uninitialized proxy smart contracts. This attack pattern, which we call CPIMP (Clandestine Proxy In the Middle of Proxy), happens when a proxy is deployed but not initialized atomically in the same transaction. That gap lets a malicious actor take over the proxy and set a malicious implementation contract. Catching it requires seeing the trace data early and fast. Streams makes that possible.

Scaling to Eight Chains Without an Ops Team

We started Defimon on three chains. We now monitor eight: Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Avalanche, Optimism, and HyperEVM.

Under the old setup, adding a chain meant new infrastructure, new servers, new pipelines, more headcount. Each addition competed directly with detection work for engineering time.

With Streams, adding a chain is a configuration change. Integrating HyperEVM took less than a day. We adapted some constants and relevant addresses, and that was the majority of the work.

Today the entire pipeline runs with one engineer. Everyone else focuses on detection logic. Under the old setup, three to four people were needed just to keep the infrastructure running.

What Happens After the Alert

Defimon subscribers are not just watching for exploits. They are building automated incident response on top of our alerts. The faster the alert, the more time there is to act.

One hedge fund client, managing a nine-figure DeFi position, integrated with our system via WebSockets to automatically exit positions the moment we detect the first steps of an attack targeting their configured protocols. Individuals and traders use our alerts to adjust positions when an ongoing incident is identified.

The most significant use case, though, is active whitehat intervention. We run a whitehat bot that has already rescued more than $2 million in total. Recently it recovered $512K for a user who had accidentally misconfigured their token allowances. We were fast enough to move before malicious actors noticed. The speed of the underlying pipeline is what made that intervention possible.

Closing

Every DeFi protocol should know what is happening with their contracts in real time. In an era where AI is accelerating the volume and sophistication of exploits, catching the early signs of an attack is not optional. It is the baseline.

Defimon's job is to fire the alert with enough time for teams to act. The data pipeline is either what makes that possible or what gets in the way.

If your team is still on polling, the question is not whether the latency will matter. It is when. Rebuilding from the source is uncomfortable. But patching a fundamentally slow architecture is not a path to sub-second detection. For us, moving to a push model was not a technical preference. It was the only way the product could actually work.

Arseniy Reutov is CTO and Co-founder of Decurity, a Web3 security firm trusted by 1inch, Gearbox, and the Arbitrum Foundation. Defimon is Decurity's real-time exploit detection platform, monitoring eight EVM chains for 3,500+ subscribers.