Smart Contract Monitoring: Where Protection Breaks
An audit checks the code at the moment of the snapshot, but not the contract's behavior in the field. An access vulnerability built into the role logic passes static analysis without issue — until someone calls a function with someone else's permissions.
Oracle manipulation is not visible in the source code: the price comes from outside, and the attack only manifests in the transaction stream. Smart contract monitoring closes exactly this gap — it looks at what the contract is doing right now, not at how it is written.
A flash loan is the most illustrative class of attack. An attacker takes out a huge sum without collateral in a single transaction, moves a pool or oracle, takes the profit, and repays the debt — all in one block.
In the code, not a single line is changed, so pre-launch checking is powerless here. This can only be caught through transaction anomalies: a sharp spike in loan volume, price deviation from the market, withdrawal of funds to a fresh address.
A separate category is quiet leaks. The owner or a compromised admin key gradually withdraws liquidity through legitimate functions, and each operation individually looks normal.
A rule on cumulative outflow over a time window reveals a picture that cannot be seen in isolated calls.
We break down how this is closed: which events and metrics we capture, how we tune thresholds for a specific protocol, and what happens at the moment of triggering.
What continuous contract monitoring provides
Continuous monitoring turns contract security from a one-time pre-launch check into an ongoing process.
We set up rules for the events that precede loss of funds: anomalous withdrawals from the pool, a sharp increase in admin privileges, calls to critical functions outside the usual activity window.
A rule triggers on a specific sequence of transactions, not on a single indicator, so incident detection time drops from hours and days to minutes — often before the attack even completes.
The main engineering challenge here is not the number of alerts, but their precision. We calibrate thresholds on the contract's historical data: how many false positives each rule produces, which events are duplicated, where the signal drowns in the noise of legitimate activity.
After tuning, the false positive rate drops to single-digit percentages, and the on-call team responds to real threats instead of sifting through routine.
This directly affects speed: when there are hundreds of alerts, they get ignored, while a single precise signal triggers a response.
A separate effect is the eliminated class of failures that an audit cannot close. An audit checks the logic at the moment of review, but does not see what happens to the contract in the field: parameter changes, compromise of an admin key, oracle manipulation.
Monitoring closes exactly this gap — it catches deviation from normal behavior even if the code is formally correct.
Automated response closes the loop: a critical signal triggers a contract pause, revocation of privileges, or withdrawal of liquidity into a protected mode.
We design such scenarios in advance and test them on a network copy so that the response does not block legitimate operations. The time from signal to stopping an attack is measured in seconds — that is the difference between an incident and a loss.
Observation methods: comparison of approaches
The choice of observation method determines how quickly the team learns about a problem and how much its maintenance costs. An external observer does not require changes to the contract, but sees only what has made it into the event log.
A built-in hook gives access to internal state, but increases gas consumption and the attack surface. A hybrid scheme with an event oracle covers both scenarios, but requires careful synchronization.
| Option | When it fits | Limitations |
|---|---|---|
| External observer | The contract is already on-chain, changing it is impossible or expensive; a quick start is needed | Sees only events and calls; internal invariants remain out of sight |
| Built-in hook | A new contract where checking state before and after an operation matters | Additional gas consumption per transaction; an error in the hook blocks the main logic |
| Hybrid scheme with an event oracle | A large protocol with multiple contracts and external data sources | Harder to set up: signal-matching rules and protection against false positives are needed |
In practice, a hybrid is most often chosen: an external observer catches anomalies from events, while a lightweight hook exposes critical invariants.
The event oracle in this combination acts as an arbiter — it confirms that the signal came from a trusted source and filters out noise. Such a scheme provides a reaction time within a single block and does not require rewriting the contract entirely.
We select a method for a specific contract: if it is already deployed, we start with external observation and gradually add hooks where justified. Describe your task — we will come back with an estimate and a plan.
How we build a monitoring system
Monitoring doesn't start with configuring alerts — it starts with analyzing the contract: which functions change state, where roles and limits are stored, which events the contract already emits. This determines what can be tracked at all without modifying the code.
If the contract doesn't emit the necessary events, we first discuss how to close the gap — add an event in the next version or read state from the network.
Next, we design the scheme: which conditions count as an incident, who receives the signal and where, and what counts as a false positive.
A rule that fires on every large transaction stops being read by engineers within a week — so we calibrate thresholds against the contract's real activity.
- Contract audit. We analyze the logic, admin rights, external calls, and existing events. We compile a list of actions that must not be missed: ownership transfer, fund withdrawal, limit changes, pause.
- Scheme design. We define data sources, the set of rules, notification routes, and severity levels. We separately describe which triggers require immediate response and which go into a daily digest.
- Rule configuration. We write detectors for specific contract conditions, set thresholds and aggregation windows, and connect notification channels. Every rule is tested against historical data — it must fire on a real incident and stay silent during normal activity.
- Testnet verification. We run scenarios: role changes, large withdrawals, abnormal call frequency. We make sure the signal arrives on time and contains enough context for a decision.
- Calibration. For the first few days, we monitor the flow of triggers and fine-tune thresholds, removing noise. The goal is for the signal to be acted upon, not for notifications to be turned off.
- Handover. We provide access, rule descriptions, and a response guide for each signal type. We show how to add a new rule during the next contract update.
- Ongoing support. After contract changes, the rules are revisited — otherwise monitoring quietly drifts away from the actual logic.
Describe your contract and objectives — we'll get back to you with an estimate and a work plan.
Detection Rules and Trigger Thresholds
A detection rule is a condition under which the system raises an alert, and a trigger threshold sets the sensitivity: how large a transfer must be, how many confirmations to wait for, what percentage change counts as significant.
We tune them to the economics of a specific protocol, not "by default": for a stablecoin and for a low-liquidity pool, the same numbers will produce either a stream of false positives or a missed real attack.
- Large transfers. A threshold by absolute amount and by share of the total token supply in circulation; a separate branch for transfers to addresses not associated with the protocol, and for withdrawals from the treasury.
- Administrative function calls. Contract ownership change, admin rights transfer, limit changes, contract pause or unpause, proxy implementation upgrade — each event goes to a separate high-priority channel.
- Changes in liquidity pools. A sharp drop in pool depth, abnormal liquidity withdrawal within a short window, price deviation from an external source by more than a specified percentage.
- Activity spikes. A rise in the number of method calls per minute above the baseline, a series of failed transactions from a single address, mass calls to the contract from new wallets.
- Changes in rights and roles. Granting of a minter or burner role, appearance of a new address in the allowlist, change in fee logic.
- Technical signals. Oracle errors, data discrepancy between sources, drop in the share of successful calls below the norm.
- Time-based thresholds. Observation window (minutes or blocks), number of confirmations before escalation, quiet period between repeated notifications for a single event.
We put thresholds into configuration rather than code: they are edited without rebuilding and re-auditing the logic.
After launch, the first days go into calibration — we look at how many triggers come in and what share of them are false, and adjust the numbers until the signal becomes clean.
Case: reducing damage from a protocol attack
A lending protocol on Ethereum with liquidity in pools — the client's team noticed the anomaly only forty minutes after the attack began: the attacker, through oracle price manipulation, withdrew funds from the pool, and by the time of the manual response, part of the liquidity had already been lost.
The investigation showed that alerts for contract events existed, but without automatic response: the on-duty engineer saw the notification while manually checking the transaction, and the attacker managed to make several more withdrawals.
What was changed
We deployed smart contract monitoring on Forta and OpenZeppelin Defender: detectors tracked anomalous withdrawals from the pool, sharp changes in the oracle price, and calls to administrative functions.
The key was linking the detectors to automatic blocking: when a rule triggered, the contract was switched to pause mode, and suspicious transactions were rejected pending manual review.
The trigger threshold was configured so that legitimate large operations would not be blocked — we tested it on historical data.
Result
When the attack was attempted again through the same vector, the automatic blocking triggered within seconds rather than minutes: suspicious transactions were rejected before funds were withdrawn, and the damage was limited to gas on failed calls.
Incident response time dropped from tens of minutes to seconds, and the share of attacks stopped without human involvement grew to the majority of scenarios.
Reviewing each trigger takes minutes — the engineer sees the transaction context and decides whether to lift the pause or not.
Such a circuit does not replace an audit, but it closes the window between detection and response — that is exactly where the bulk of funds is lost.
How does monitoring differ from a security audit?
A security audit is a one-time review of code before launch: the team reads the contract, looks for vulnerabilities, checks access logic and economic assumptions, and produces a report with the issues found and recommendations.
The report captures the state of the code at a specific point in time and answers the question "is there a hole here that can be closed before deployment".
After fixes based on the audit's findings, the contract is considered verified — but only in the version that was reviewed.
Smart contract monitoring solves a different problem: it does not look for errors in the source code, but continuously observes the behavior of an already deployed contract on the mainnet.
An audit answers "is the code written correctly", while monitoring answers "is the contract behaving as intended right now". These are fundamentally different questions, and they are addressed by different tools.
The difference becomes critical after deployment.
The code may have been clean at the time of the review, but since then external conditions have changed: the oracle contract was updated, the logic of a connected protocol changed, someone gained access to the admin key, liquidity in the pool grew and an economic incentive for an attack appeared. No audit can catch such changes — it looks at a snapshot, not a stream.
Continuous control catches precisely these scenarios: abnormal withdrawals of funds, calls to privileged functions, sharp changes in balances, interactions with suspicious addresses.
The rules are configured for the specific logic of the contract, and when triggered, the team receives an alert within minutes, rather than learning about the problem from the news.
That is why an audit and monitoring do not replace but complement each other: a one-time review reduces the likelihood of an error in the code, while continuous control shortens the reaction time if something goes wrong on the mainnet.
The practice is to pass an audit before launch and set up monitoring right away, so that no blind spot remains between the review and real operation.
Common technical concerns
Smart contract monitoring is an external observer, not code inside the contract. Agents and guard rules read events from blocks and the contract state from the outside, so not a single line is added to the contract itself.
Gas consumption for business logic does not change: transactions execute exactly as designed, while condition checks and alerts happen off-chain.
Compatibility with different virtual machines is handled at the observation layer. For EVM networks, agents subscribe to event logs and method calls; for non-EVM environments, they subscribe to native block formats and account state.
Our task is to bring the data models to a common form so that rules and alerts work the same way regardless of where the contract is deployed.
The network load is minimal: nodes are polled by subscribing to new blocks rather than constantly scanning the history. If necessary, an archive node is connected only for the initial synchronization; after that, observation runs in the stream.
Will monitoring slow down the contract or increase the cost of calls?
No. Observation is not embedded into transaction execution, so gas and response time remain the same. Agents read already confirmed data and react after the fact — in the worst case, one block passes between the event and the alert.
Will this work on a non-EVM network?
Yes, but through a separate adapter for the specific virtual machine. The rule logic and notification channels remain the same; only the data source changes. We verify compatibility on a test network before rolling out to the main one.
What happens if the node the agent is connected to goes down?
Observation switches to a backup node, and missed blocks are caught up by range. Critical rules are duplicated on an independent provider so that a single failure does not leave the contract unattended.
Let's discuss your monitoring task
To come back with an estimate and an implementation plan, rather than generalities, we need a minimum of inputs about your contract.
Smart contract monitoring is not about "setting an alert" — it's about defining which events count as an incident, who responds and how, and what is considered normal during quiet periods.
The more precisely you describe the contract and requirements, the fewer iterations it will take to align.
What to send so we can discuss the task concretely:
- contract addresses and the networks where they are deployed, including test environments;
- source code or verified code and a link to the audit, if one was done;
- a list of critical functions: withdrawal of funds, ownership transfer, logic upgrades, mint;
- roles and access: who the owner is, which wallets are administrative, whether there is a multisig;
- which events are already logged and where notifications currently go;
- response requirements: where to send the signal, how quickly the team must see an anomaly;
- the expected load profile and peak periods when activity spikes.
Based on this data, we assemble an implementation plan: which detection rules cover your risks, how to configure alerts without false positives, and how to verify that the system catches real deviations rather than noise. We separately define what we do during the launch phase and how we hand over control to you.
Describe your task — we'll come back with an estimate and an implementation plan.