DEV Community: Aleksei Nazarov

Smart contract monitoring in 5 minutes: what to watch and how to set it up

Aleksei Nazarov — Sun, 25 Oct 2026 20:22:04 +0000

A contract goes live after an audit. The audit checked the code on one day. From then on, the contract changes owner, gets upgraded, moves money and talks to bots, and somebody has to notice when one of those things is not supposed to happen.

Most small teams notice from users, from a block explorer tab left open, or from a post on X. SmartAlert is a monitor for that gap: you paste a contract address, and it tells your team in Telegram, Slack or Discord when something on the contract is off.

This post covers what it watches, and then takes a contract from "nobody is watching" to working alerts in about five minutes.

What it watches

SmartAlert reads public chain data on Ethereum, BNB Chain, Base and Arbitrum. It does not touch your contract and needs no code change.

Admin changes. Ownership transferred, a role granted or revoked, a proxy upgraded, the proxy admin changed, Safe owners or threshold changed, the contract paused. These are the first on-chain signs of most takeovers.
Money, in dollars. A transfer above $X, priced at the block and optionally filtered by sender. The total value of a treasury below a floor, including when a price drop crosses it. Prices come from Chainlink, with CoinGecko as a fallback.
Operations. A keeper or relayer wallet with gas for fewer than N days. A balance that is low and got no top-up in an hour. Failed transactions from your bots.
Activity. Any event count or value per hour: transfers, swaps, deposits, claims. Spikes, and a contract that suddenly goes quiet.
State. Values read through view functions, such as paused() returning true.

Two things keep the alerts useful:

A norm for each hour. Activity on most contracts is low at night and high during the day. One fixed threshold is either noisy at peak hours or silent at night. SmartAlert can compare each hour with the same hour on previous days instead, so a burst at 3 a.m. is caught and a busy afternoon is not an alert.
A check on history before a rule runs. Every rule shows, on a chart of the contract's real past, where it would have fired. If it would have fired forty times last month, you see that before it wakes anyone up.

Setup

You need a contract address on one of the four networks and a Telegram account. The free plan is enough; the first 14 days of a project work with Pro limits.

Step 1. Add the contract (1 minute)

Sign up and create a project.
Choose Add contract, pick the network and paste the address.
For a verified contract, the ABI is loaded for you. For an unverified one, paste the ABI.

If SmartAlert has not seen the contract before, it first collects its history. The contract shows a "backfilling" status, and rules wait until it is done. If the contract is already tracked, its history is there at once.

Step 2. Turn on the first rules (2 minutes)

Open the contract. SmartAlert suggests rules from its ABI: ERC-20, ERC-721 and ERC-1967 proxies get matching templates. Select the ones that fit and choose Enable selected.

If you are not sure what to start with, these six cover the most common ways a contract gets taken over or drained:

Rule	Why	Setting
Ownership transferred	A new owner can call every admin function	Any event, Critical
Role granted	A new admin on an `AccessControl` contract	Any event, Critical
Proxy upgraded	The code behind the address changed	Any event, Critical
Transfer above $X	The drain itself, priced at the block	`from` = your contract, a threshold above normal flow
Unusual transfer activity	Bursts that a fixed number misses at night	Against the norm for each hour
Contract went quiet	A broken integration or a stuck bot	Against the norm for each hour

If you run keepers or relayers, add their wallets and a gas runway rule. For a treasury, add its address and a total below $X rule.

Step 3. Check each rule on history (1 minute)

Open a rule and look at the chart. It shows the metric, the norm or your threshold, and marks where the rule would have fired.

Admin rules should show zero or a few marks, each one a change you remember making.
For value and activity rules, too many marks means the threshold is too low. Raise it, or set a target such as "no more than 2 a week" and let SmartAlert pick the threshold.

Use against the norm for each hour (the default) for activity, and own threshold for amounts in dollars and admin events.

Step 4. Connect Telegram (1 minute)

Open Channels, enter a name and press Add.
Open the link SmartAlert gives you and press Start in the bot. For a team chat, add the bot to the group and run the command there.
The bot replies with the project name. The channel is active.

The link works for 15 minutes. On Pro you can also add Slack, Discord, email, PagerDuty or a webhook.

What an alert looks like

The message has the value, the threshold or this hour's norm, the time and a link to the transaction. When the condition clears, a "Back to normal" message follows, and PagerDuty incidents close on their own.

What it does not do

It does not pause or block anything. It alerts. Send Critical alerts to people who hold a pause key; an alert that reaches nobody who can act is a log entry.
It does not read the mempool. It reads confirmed blocks. On Ethereum that is 12 confirmations, about 144 seconds, then a rule check: every 5 minutes on Free, every minute on Pro, every 30 seconds on Business. If an attacker drains a contract within two minutes of the first sign, the first loss is gone before any confirmed-block monitor can speak. Later steps of the same attack are not.
It does not replace an audit. It is the part that notices.

Two more habits:

Repeat on every chain you are deployed on. Attackers often go chain by chain, and the first chain's alert is the warning for the others.
Watch contracts you depend on, not only your own. A locker, a bridge or a vault that holds your tokens is public, and you can watch it without anyone's permission.

Price

$0 gets 2 contracts, 3 rules and a Telegram channel, checked every 5 minutes. Pro is $30 a month, Business $99.

I build SmartAlert. Questions about a specific contract are welcome in the comments.

Ronin Bridge, August 2024: the vote threshold was 0 for 48 minutes before the first withdrawal, and no event said so

Aleksei Nazarov — Fri, 23 Oct 2026 22:15:49 +0000

On August 6, 2024 the Ronin team upgraded its bridge on Ethereum. 48 minutes later an MEV bot withdrew about 4,000 ETH from it, and half an hour after that another address took 2M USDC. In total about $12M left. The bot belonged to a whitehat, and the funds came back the same day^[1]^[2]^[3].

Most bridge hacks start with a stolen key. This one did not. Nobody broke in, and nothing unusual was emitted. The upgrade was the team's own, and the Upgraded event was expected. What broke was a number inside the contract, and only a question to the contract could show it.

How the Ronin bridge approves a withdrawal

Ronin is the blockchain behind Axie Infinity. Its bridge to Ethereum has two parts that matter here^[2]^[3]:

The gateway 0x6419…AF08 on Ethereum holds the bridged ETH, USDC and other tokens. It is a proxy: the address stays, the code behind it can be replaced.
Bridge operators watch Ronin. When a user withdraws to Ethereum, operators sign the withdrawal. Each operator has a vote weight.

The gateway pays out only when the signers' total weight reaches a threshold. The view function minimumVoteWeight() returns it. Before August 6 it returned 1540, 70% of the operators' total weight^[3]^[7].

The gateway also limits how much one withdrawal may take, about 4,000 ETH or 2M USDC^[2]. Keep that in mind. It capped the size of each withdrawal.

Changes to the gateway go through MainchainBridgeManager 0xa714…fab0: a proposal needs operator signatures, then anyone can relay it on-chain. For emergencies there is a separate PauseEnforcer 0xe514…bcd4 that can stop the gateway in one call.

What went wrong in the upgrade

An upgradeable contract keeps its state in the proxy. New code often needs new state, so it ships with an initializer that fills it. The gateway had several, numbered by version. Version 3 set _totalOperatorWeight, the total weight the threshold is computed from. Version 4 set a new helper contract for WETH^[2]^[3].

The upgrade on August 6 jumped straight to version 4. The proxy had never run version 3. So _totalOperatorWeight stayed 0, and 70% of 0 is 0^[3].

The upgrade logs show this. They contain Upgraded and Initialized(4), but no Initialized(3)^[7].

The attack, step by step

All times UTC, block times from Ethereum. We read every transaction below on-chain ourselves^[7].

08:48:47 — the planned upgrade

Address 0xe880…f059 relayed proposal round 5 to MainchainBridgeManager with 16 operator signatures (0x855d…767e, block 20468438). The proposal made six calls to the gateway. Among them: add WBTC, switch the code to 0xfc27…20Ee and run initializeV4, then change the proxy admin. The last two calls failed, the first four succeeded^[7].

We read minimumVoteWeight() with eth_call on archive blocks^[7]:

Block	When	`minimumVoteWeight()`
20468437	the block before the upgrade	1540
20468438	08:48:47, the upgrade	0
20468678	the block before the first withdrawal	0

From this block, a withdrawal from the gateway needed no operator signatures at all. Anyone who noticed could take up to the per-withdrawal limit, as many times as they liked.

🔔 SmartAlert

Rule: "Contract state" on the gateway: call minimumVoteWeight() every minute, fire when the answer is below 1. It is the same rule as the paused() recipe, with a number instead of true/false.

Alert: about 08:51–08:53. The rule reads the block 12 confirmations behind the head (about 144 seconds), so the first call that sees 0 lands 2.5–4 minutes after the upgrade^[8].

Time left: about 45 minutes before the first withdrawal (09:37:23) and 79 minutes before the second (10:11:47).

What the team could do: the PauseEnforcer was there. One triggerPause() stops the gateway. The team made exactly that call later, at 10:15:23.

⚠️ What it misses

An Upgraded rule would fire here too, and it would not help. The team was waiting for this event. An alert that says "the gateway was upgraded" reads as "yes, that is ours". Nothing in the event stream says the threshold is now 0. Only the contract knows that, and only if someone asks it.

09:37:23 — 3,996 ETH

Address 0x1a56…3cc1 called its MEV contract 0x4Ab1…3c0B, which called submitWithdrawal on the gateway. The gateway paid out 3,996.09 ETH (0x2619…a6cb, block 20468679)^[7]. This was 48 minutes after the upgrade.

🔔 SmartAlert

Rule: "Total address balance in $ below threshold" on the gateway, with a floor a little under the normal total. Native ETH does not emit Transfer, so a balance rule is how you see it leave.

Alert: about 09:40–09:41.

Time left: about 31 minutes before the 2M USDC.

The honest part: this is the alert that confirms the first one. On its own it comes after $10M has left. With the state alert in front of it, it says "it is happening now".

10:11:47 — 2M USDC

Address 0xFDe0…455A withdrew 1,998,046.88 USDC to 0x6980…BDD0 (0xbce5…0ad8, block 20468848)^[7].

🔔 SmartAlert

Rule: Transfer above an amount in $ on USDC, from = the gateway, threshold $1,000,000.

Alert: about 10:14–10:15:30, about when the team paused the bridge. This one tells you the size of the loss, not the time left.

10:15:23 — the pause

Address 0x8B35…8f57 called triggerPause() on the PauseEnforcer (0x90a1…c090, block 20468866)^[7]. That is 38 minutes after the first withdrawal and 86 minutes after the upgrade. Ronin said it paused the bridge about 40 minutes after the first withdrawal^[1].

After — the money came back

The whitehat behind the MEV bot returned the ETH, then the USDC about two hours later. Ronin paid a $500K bounty. According to The Block, the bridge held more than $850M at the time^[1]^[4]. The per-withdrawal limit capped each transaction at about 4,000 ETH or 2M USDC^[2]. SEAL 911 helped with the response^[3].

What no rule would have changed

⚠️ What it misses

A rule created after the upgrade. A contract-state rule starts recording answers when you create it. It does not read past blocks, so you cannot check it on history the way you can an event rule. To show the moment of the change, it had to exist before 08:48:47 for Ronin. A "below 1" rule created later would still fire, on its first call.

⚠️ What it misses

Knowing which number matters. Here it is minimumVoteWeight(). For a lending market it may be a price from an oracle, for a token paused() or owner(). A monitor checks the numbers you point it at. It does not guess your invariants.

⚠️ What it misses

Attacks in one transaction. If the bad value and the withdrawal land in the same transaction, a state check sees the result, not the warning. At Bybit in February 2025, a signed Safe transaction emptied about $1.46B two and a half minutes after the first sign^[5]. At KiloEx in April 2025, pools were drained in the same second^[6]. Ronin had 48 minutes. Not every incident does.

How to set up this rule in SmartAlert

Add the contract and open it. Contract-state rules are on Pro and above.
Create a "Contract state" rule. Pick the function, for example minimumVoteWeight(), and press "Check function" to see the current answer.
Choose the condition "Below threshold" with a threshold under the normal value, for example 1. For a bridge, call every minute.
Create it before your next upgrade. Then the first call after the upgrade shows whether the number survived.
Add the event rules too. Upgraded tells you when the code changed, the state rule tells you what it changed. For native ETH, add the gateway in "Addresses" and create a "Total address balance in $ below threshold" rule.
Choose where alerts go. Telegram is free.

See all alert recipes.

Sources

Ronin Network on X, incident statement: pause, about 40 minutes, the whitehat.
Rekt, Ronin Network — Rekt II: the skipped initializer, the per-withdrawal limit, the amounts.
Three Sigma, analysis of the Ronin Network exploit: initializeV3 and _totalOperatorWeight, the 70% threshold, SEAL 911.
The Block, report on the Ronin bridge pause: returned funds, the $500K bounty, more than $850M in the bridge.
CertiK, Bybit incident technical analysis.
KiloEx, Security incident root cause analysis.
Checked by SmartAlert on-chain: minimumVoteWeight() with archive eth_call at blocks 20468437, 20468438 and 20468678; the upgrade transaction, its six calls, their results and its logs (Upgraded, Initialized(4), no Initialized(3)); the two withdrawals and the pause, with block times, senders and amounts, through the Blockscout API.
SmartAlert, alert delay on Ethereum: 12 confirmations (about 144 s), head polling up to 12 s, storage up to 15 s (P95), rule check every 60 s on Pro.

Originally published on the SmartAlert blog.