Smart Contract Monitoring After Defender: What to Watch, Thresholds and the Alert-to-Pause Path

Events worth monitoring

Everyone means roughly the same thing by smart contract monitoring: watching a deployed contract's own logs and storage slots for changes a human would want to know about, then routing each change to someone or something that can act on it. It is not a scanner and it is not a simulator. The subject is code that already holds money.

Five families of signal carry most of the value, and they differ in how cheaply a node can filter them. A parameter marked indexed becomes a log topic, which an RPC provider matches server side. A parameter that is not indexed sits in the data blob, so the watcher pulls every log of that type and decodes it before deciding whether it cares.

1. Admin roles and ownership. OpenZeppelin's AccessControl declares RoleGranted(bytes32 indexed role, address indexed account, address indexed sender), RoleRevoked with the same three parameters, and RoleAdminChanged(bytes32 indexed role, bytes32 indexed previousAdminRole, bytes32 indexed newAdminRole). Every parameter of all three is indexed, so a filter can name one role hash or one account. Ownable adds OwnershipTransferred(address indexed previousOwner, address indexed newOwner), also fully indexed. Grants deserve more attention than revocations, since a revocation usually follows a plan somebody wrote down.
2. Proxy upgrades. Under EIP-1967, Upgraded(address indexed implementation) and BeaconUpgraded(address indexed beacon) index their single address. Its third event does not: AdminChanged(address previousAdmin, address newAdmin) indexes neither parameter, so both addresses live in the data blob and the only filter available is the contract address plus the topic hash of the signature. All three share a deeper problem. The standard says a proxy SHOULD emit them when the slot changes, not MUST, so a proxy written without them upgrades in silence. Reading the slots is the signal that cannot be suppressed. Each is defined as bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1) and the matching label.

   Implementation

   0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc

   Admin

   0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103

   Beacon

   0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50

3. Pause calls. Pausable emits Paused(address account) and Unpaused(address account), and account is not indexed in either, so the watcher filters on contract address plus event signature and decodes the caller afterward. An unpause nobody scheduled is as interesting as a pause nobody ordered.
4. Price feed behavior. The Security Alliance names price feed deviations as a monitoring track, alongside bridge volumes, governance proposals and node health. What counts as a deviation is a property of the feed and of the position it prices, so that number belongs to your deployment. Our note on oracle manipulation covers the attack this signal is meant to catch.
5. Value movement. Same source, quoted: Large fund transfers from protocol or treasury wallets, Token minting and burning events and Unusual gas usage patterns that may indicate griefing or exploitation.

One family belongs on the list and is rarely on it: your own emergency machinery firing when nobody pushed the button. If a guardian role can pause, then that role being granted, moved or exercised is itself a top tier alert, because whoever holds it can also stop the thing that would have stopped an attacker.

Alerting thresholds

The Security Alliance publishes a page on monitoring alert thresholds, the most authoritative free document on the question, and it contains no percentage, no dollar amount and no time window. What it gives is a method: Establish baseline metrics for normal activity, threshold transfers on both absolute amounts and relative percentages, threshold minting on volume minted and mint frequency, split alerts into primary and secondary tiers and Combine metrics where single-signal rules produce too many false positives.

That silence is deliberate and it is correct. A threshold copied from someone else's protocol has no relationship to your traffic, so anything you read that opens with "alert on withdrawals above 5 percent" is quoting a figure from nowhere. Deriving your own is a morning of work rather than a project.

1. Pull 30 days of your own history, one query per event family, through an archive node or a hosted log endpoint. Bucket by day and by transaction.
2. Read four numbers off each bucket: median, 95th percentile, observed maximum and count of distinct callers. Anything occurring fewer than ten times in 30 days is rare enough that every occurrence can page someone, which saves you a threshold entirely. Role grants and upgrades usually land here.
3. Set the warn tier at the observed 30 day maximum.
4. Set the page tier at a multiple of that maximum, chosen so the rule would have fired zero times in the sample. Twice the maximum is a starting point rather than a recommendation; the property you want is a clean historical record, and you get it by testing the rule against the sample you already pulled.
5. Express fund movement in both units the framework asks for, an absolute amount and a share of the pool it leaves, since a fixed dollar figure ages badly against a moving TVL.
6. Write a name next to each rule. Not a team, a person, plus a backup.

Two habits keep the result honest. Re-run the baseline after every launch, migration or incentive program, since each moves the distribution the numbers came from. Then record the date of the sample behind each threshold. A threshold with no provenance is indistinguishable from an invented one.

Escalation from alert to pause

The Security Alliance is direct about ownership: Every alert must have a designated owner and a documented response, and Document who gets paged for each alert category and what the first response steps are. This should be decided before an incident, not during one. Then the guidance stops. Nothing on that page addresses pausing a protocol in response to an alert, so the hop from a firing rule to a stopped contract is where the free corpus runs out.

Begin with the stage at which an alert can fire, because it caps everything downstream.

Pre signature

A wallet simulates the transaction and shows the signer what it does. The control is refusal.

Mempool

The transaction is public but not included, so a watcher that sees it can still act in the same block window, which in practice means outbidding it.

Sequencer

On a chain with a single sequencer, including most L2 deployments, screening can happen at the point of inclusion. That is refusal rather than a race.

Confirmed on chain

The log exists because it already happened.

Tiers map onto those stages. Log means the monitor records it and nobody is woken. Warn means somebody reads it within the working day. Page wakes a named person now. Auto pause sends the transaction without asking, which is defensible only for a rule proven never to fire on legitimate traffic.

Who can actually call pause is the other half, and it is a governance question. Four shapes are common. A single EOA guardian is fastest and most dangerous, because one compromised key both stops the protocol and becomes a denial of service against it. Multisig spreads that risk and adds quorum latency, measured in how long it takes to wake three people at four in the morning. A role held by a relayer address lets a script sign, at the price of a hot key with the power to halt the system. Timelocked pause is a contradiction: a delay long enough to be a governance control is long enough for the attacker to finish, which is why teams usually exempt pause from the delay and keep unpause inside it.

If the contract is immutable and has no pause at all, monitoring still buys the response that lives off chain: pulling the front end down, publishing revocation guidance for the approvals users have already granted and putting out a warning before the attacker reaches the next victim. Where the protocol holds liquidity of its own, moving it is the single on chain action still available, and hearing about the problem early is what makes that possible.

The monitor is a component that can fail too, and it fails quietly. Give it a heartbeat or a dead man's switch, so a watcher that has stopped reading blocks pages someone the way a firing rule would. Two causes account for most silent stalls: an RPC provider rate limiting the poller, and a log query window narrower than the block range being asked for, which returns an error the monitor may swallow or a truncated result it cannot tell from an empty one. A reorg runs the other way, because an alert that already fired can describe a transaction that is no longer on the canonical chain, so treat a fired alert as provisional until the block holding it is deep enough to argue about.

Rehearse the path on a fork and time each hop, from the log appearing to the pause confirming. Surprises tend to sit in the middle rather than at the ends: alerts fire and transactions confirm in seconds, while assembling a multisig quorum out of hours is the hop measured in tens of minutes. Time it on your own rehearsal, because that number is a property of your signer set, not of the tooling. Our note on incident response covers what follows the pause, and the mechanics of the pause itself belong to circuit breaker design.

Migrating off Defender

OpenZeppelin Defender was the default answer to this whole problem for years, and it is going away on a published schedule. From the docs:

New sign-ups were disabled on June 30, 2025. Until the final shutdown on July 1, 2026, Defender will remain fully operational while we focus on the open source versions of tools like Relayers and Monitor.

The sunset FAQ, published the day sign-ups closed, adds that the service keeps critical patches and support through that date.

Replacements are two self hosted repositories rather than one managed service. openzeppelin-monitor watches for specific on-chain activities and triggers notifications based on configurable conditions and notifies through Slack, Discord, email, Telegram, webhooks or a custom script in Python, JavaScript or Bash. openzeppelin-relayer enables interaction with blockchain networks through transaction submissions, which is the half that sends a pause. Both ship under the AGPL-3.0, and neither README states a release version, so pin a commit. Neither repository calls itself a Defender replacement either, so a reader starting from GitHub will not find the connection.

Three migration costs deserve budgeting, and only one of them is obvious.

• Configuration exports as a zip with the secrets stripped, so refilling it means re-entering API keys, RPC URLs and endpoint addresses, webhook URLs and integration credentials by hand.
• Custom Actions attached to Defender monitors will not be automatically migrated. If your alert to pause path runs through an Action, that logic is rewritten rather than moved.
• Relayer private keys cannot leave. They sit in AWS KMS, the documentation states that You cannot export existing Defender Relayer private keys, and the consequence is that you must create new relayers with new addresses. New addresses mean every allowlist entry, every on chain role grant and every off chain reference has to be found and re-pointed. Across several deployments that is a governance calendar, not an afternoon.

OpenZeppelin's advice for the cutover is to overlap rather than switch: spin up self-hosted instances, run them in parallel and confirm the new stack behaves as expected first. Overlapping also gives you the only honest test of a new alerting stack, whether it fires on the same events as the one you trust.

Tool landscape without vendor ranking

Ranking these products by quality is not possible from outside, since almost every headline figure is self reported and none is audited. Sorting them by detection stage is possible, and that turns out to be the distinction that decides which one fits you: the stage a product observes determines what it can ever do about a threat.

Read the last column first. Five of the nine products above publish no price at all and a sixth, Phalcon, is invite only. The three that say anything define the market: OpenZeppelin's monitor and relayer are free and self hosted, while Tenderly states that alerts are available on the paid plan with no figure attached.

Vendor claims are worth repeating with attribution, since they describe capability even when nobody can check them. Hypernative publishes a 99.8 percent detection rate and case studies in which it alerted two minutes into a phishing campaign and seven minutes before an exploit executed. Blockaid states $13.1B in theft prevented, Phalcon states $20,000,000 saved in whitehat rescues. This is a market where the vendor is the only measurement instrument.

Two corrections to older articles that still rank for these queries. Forta today sells Risk and Firewall, the second described as "Transaction screening at the sequencer", and the public detection bot network that fills 2022 era listicles is not what the vendor puts forward now. Hexagate is no longer independent. Chainalysis announced the acquisition on December 18, 2024. No deal size appears in that announcement.

For a small team the choice collapses to one question. If your response is a pause you send yourself, a self hosted monitor plus a relayer covers it for the cost of two containers. If it has to happen before the attacker's transaction lands, you are buying mempool or sequencer access, which nobody sells self serve.

How members of the directory fit in

Sites approached

23

Sites reachable

20

Monitoring language

8

On a page selling it

6

Incident response language

10

Both

7

Neither

9

Surveyed

September 4, 2026

Audit firms increasingly say they also watch the code after it ships. To find out how many say so in public, on September 4, 2026 we surveyed the websites of all 23 firms in the alliance directory with a script. That script, member-monitoring-survey.py, and its dated JSON output are kept in the site repository and are not published, so the method is stated in full below and every count can be argued on the method rather than taken on trust.

Method, stated so the number can be argued with. The script fetches each firm's home page, reads the sitemap where one exists, selects at most six candidate pages per firm whose URLs hint at services or products, and matches two families of phrase: monitoring terms such as on-chain monitoring, real-time monitoring and monitoring service, and incident response terms such as incident response, emergency response and war room. Every match is recorded with its page and surrounding text, and we classified each one by hand rather than trusting the count.

Classification is where the count stops being mechanical. Language on a product page is a service you can buy; the same words in a blog post may describe work done once for one client.

Read conservatively, six of the eight firms with monitoring language put it on something they sell and two have it only in editorial. Hacken's phrase appears in an insight post describing a product called CORE3 Intelligence, which is real, but the survey found no page selling it. HYDN's appears in two case study posts. CyStack deserves a note in the other direction, since its home page phrase "24/7 Monitoring and Response" is generic security marketing while a separate service page names on chain monitoring explicitly, and that page is what earns the classification.

Limits are real. A firm can run a monitoring practice without those words appearing on a page the script chose, six candidate pages per firm is a shallow crawl, and a JavaScript rendered navigation can hide a product line from a stdlib fetcher. Absence here means absence of published evidence in this sample, and a match proves only that the words exist.

What the survey supports is a purchasing question rather than a ranking. Fewer than half the reachable member sites publish anything about watching a contract after the audit, so continuous coverage is a separate procurement from the review and worth naming in the request. Firms that publish both are at least stating a scope you can hold them to. BlockSec ships Phalcon, and Cyberscope sells a real time monitoring product. Browse the rest of the alliance member directory and ask each firm the same three questions: which events you watch, who is paged when a rule fires and whether anyone on your side can send the pause transaction.

Two habits are worth building alongside: publish a way to be told about a problem, covered in our note on security disclosure policy, and learn to read what an auditor committed to, the subject of our guide to the audit report.