Smart Contract Monitoring: What Ours Actually Does

Smart contract monitoring used to be the thing teams bolted on after the audit, if they got round to it at all. That has changed. In our experience, more protocols are running monitoring as a standing function with a budget and an owner, the way an infrastructure team runs alerting.

So it is worth being precise about what a monitoring product actually gives you, and about the fact that there are now two ways to get one running. Given access to a good-quality onchain dataset, you can choose to hire a security team to build for you, or build it yourself with an AI assistant doing the SQL.

This post covers what Dedaub Custom Monitoring watches, how the rules get written either way, how often they run, where the alerts land, and what it deliberately does not do.

What smart contract monitoring actually watches

An audit is a judgment about code at a point in time. Smart contract monitoring is a judgment about behavior, continuously, while the protocol is live. The two answer different questions. An audit asks whether the code can go wrong. Monitoring asks whether something is going wrong right now.

In practice, that means running queries over decoded onchain data and raising an alert when a result comes back that should not be there. The three worked examples on our Custom Monitoring page give a fair picture of the shape this takes: detecting whale movements, catching protocol drains early, and flagging unknown governance activity. More broadly, the layer is built to track governance proposals, transaction integrity, contract state changes, and known attack vectors in one place.

The word doing the work there is “decoded”. Agents operate on decoded block, transaction, log, and token ledger data, so a rule can be written in terms of what a transaction meant rather than what it looked like in raw form.

Managed: Dedaub writes the rules for you

This is the part that separates products in this category. A tailored rule can catch not just that a large transfer happened, but that it happened in a sequence that breaks an assumption specific to your design.

Dedaub engineers write and maintain the monitoring queries around your actual contracts, your risk model and your operational logic. The product page is blunt about it: these are tailored queries, “not generic templates”. The companion Web3 security monitoring page makes the same commitment twice over, promising “Custom queries developed specifically for your protocol’s logic and assumptions” and “Continuous expert review and adjustment based on evolving threats”. The second half matters as much as the first. Rules that are written once and never revisited decay.

Self-service: an AI assistant drafts the query, you refine it

The managed path above is Dedaub writing the rules for you. There is also a self-service path, for teams that would rather move first and talk to us second, and it is where things have changed the most recently.

The queries themselves are written in DedaubQL, a query language that extends SQL with a handful of blockchain-specific building blocks, the same language Dedaub’s own engineers use on the managed side. That is a deliberate choice: people who already know how to ask questions of a database can ask questions of a blockchain. What it used to mean, though, is that shipping a new rule yourself depended on knowing both your protocol and the query language.

Dedaub’s AI Query Builder is addressing that directly. You do not need to know DedaubQL, or SQL. You just need to say what you want to monitor, where, and when. Describe it in plain English and it drafts the DedaubQL agent for you, correct gadgets, joins and thresholds included, ready to refine and deploy. The output is good enough to trust as a starting point: review it the way you would review any query before it goes live, and you do not need to loop in a Dedaub engineer to do that. The goal is to lower the barrier from “knows SQL” to “knows your protocol”, which is the right ambition, because the scarce input in this category was never query syntax. Monitoring has been free for registered users since Dedaub first shipped it, so trying this costs you an afternoon, not a sales call: open app.dedaub.com/tx-monitor, describe what you want watched, and see what comes back.

How often it runs, and what it costs to keep running

Three unglamorous details decide whether monitoring survives contact with a real team, on either path.

First, scheduling. Agents can be set to run every few minutes or at longer intervals, and each run processes only the blocks that are new since the last one.

Second, cost behavior over time. The underlying views update incrementally as new blocks arrive, with no full rescans, so processing stays constant per block instead of growing with chain history. Monitoring that gets slower and more expensive every month quietly gets switched off.

Third, alert hygiene. Alerts are configured per agent with unique-key deduplication, so each result triggers at most one notification per key. A system that pages you eleven times for one event trains your team to ignore it.

It detects and alerts. It does not block.

Worth stating plainly, because the category blurs this. Custom Monitoring detects and it alerts. Notifications arrive by email or webhook when a rule fires. It does not stop a transaction by itself. Nothing stops your own team from reacting to that webhook the moment a rule fires and pausing the protocol on your side, but that pause is something you build, not something Monitoring does for you. Conflating the two, expecting the alert itself to block anything, is how buyers end up disappointed.

Coverage is Ethereum Virtual Machine (EVM) only, across the chains Dedaub indexes, including Ethereum, Arbitrum, Optimism, Base, Binance, Polygon, Avalanche, and Robinhood Chain. If your protocol lives somewhere else, that is a real limit and you should know it before the first call rather than after.

Why smart contract monitoring is now its own category

The market has caught up with the idea. In 2025, at least one project delivering an onchain monitoring solution raised a $40 million round, and the category has seen a handful of mergers and acquisitions since, the kind of consolidation that only happens once a market has decided a category is real. Whatever you make of any individual raise, investors do not write cheques that size, or make acquisitions, for a feature. They do it for categories. Continuous monitoring is now being funded and consolidated as a security layer in its own right rather than as something bolted onto a point-in-time review.

Where to start

Try the self-service path first. Open app.dedaub.com/tx-monitor, describe what you want watched, and let the AI Query Builder draft the first version. That costs you an afternoon and tells you more than any datasheet.

If you get to the point where you want engineers who know your protocol writing and maintaining the rules, that is the Custom Monitoring engagement. Bring your worst case. The useful conversation is never about features. It is about the specific sequence of events that would ruin your quarter, and whether a rule can be written to catch it.