Why Do You Need Post-Deployment Smart Contract Monitoring?
We have seen too many projects that passed an audit but were hacked a month after deployment. An audit is a security snapshot at a specific point in time. It does not protect against new vulnerabilities that appear after dependency updates or changing market conditions.
Without continuous monitoring, you risk discovering a problem only when users start complaining, while hackers have already withdrawn the funds.
We develop a smart contract monitoring system that tracks on-chain activity in real time, identifies anomalies, and automatically alerts the team via Telegram, Slack, or PagerDuty.
Our experience (10+ years in blockchain development) allows us to set up monitoring for any protocol: from a simple ERC-20 to complex DeFi protocols with multiple contracts.
What threats does monitoring track?
Real-time reentrancy attacks
The classic Reentrancy attack remains one of the most common causes of exploits.
We monitor the sequence of calls to the contract and trigger when we detect suspicious patterns: an external contract call before the state update, multiple calls from a single address within a short interval.
Example: the attack on TheDAO (2016) resulted in losses calculated after audit — monitoring could have detected it within the first transactions.
Oracle manipulation
Chainlink is the de facto standard, but even it is susceptible to manipulation during sharp price movements. We track price changes on DEX and compare them with the oracle. If the divergence exceeds a threshold (typically 5%), an alert is generated. This makes it possible to stop liquidations or cancel transactions before damage is done.
TVL and volume anomalies
A sharp drop in TVL may indicate an exploit or mass panic. We monitor the balances of liquidity pools and staking contracts, as well as transaction volumes. For example, a sudden 500% increase in withdraw requests within an hour is a trigger for investigation.
How do we configure monitoring?
The setup process consists of six stages, each of which requires attention to detail.
| Stage | Actions | Duration |
|---|---|---|
| 1. Contract audit | We study the ABI and identify critical events (Transfer, Approval, FlashLoan, Liquidation). We identify dependencies (oracles, bridge). | 0.5–1 day |
| 2. Rule design | For each event, we write a condition: thresholds, suspicious patterns, address blacklists. | 1–2 days |
| 3. Node integration | We deploy a full node or use an archive node (Alchemy/Infura). We connect an event listening service. | 0.5–1 day |
| 4. Alert setup | We choose channels (Telegram, Slack, Email, PagerDuty). We define severity: Critical — immediately, High — within an hour, Medium — daily digest. | 0.5 day |
| 5. Testing | We launch a mainnet fork and simulate attacks (flood, reentrancy, oracle manipulation). We check that alerts arrive with the correct context. | 1–2 days |
| 6. Launch and calibration | After deployment, the system starts operating. The first 48 hours are manual log analysis to calibrate thresholds. | 2 days |
Case: We set up monitoring for a Lending protocol on Polygon. The main threat was flash loan attacks on reserve contracts.
We added a rule: if in a single transaction there are >10 calls to borrow with different collateral, and the total value exceeds a threshold defined during the audit — a critical alert. In the first two months, we recorded 3 attack attempts, all were blocked before damage was caused.
Comparison with free solutions
| Criterion | Etherscan Alerts | Our monitoring |
|---|---|---|
| Notification delay | 2–3 seconds | ~500 ms |
| Configurable logic | Only basic events | Conditional thresholds, combined rules, blacklists |
| Multi-chain support | Only individual networks per project | Single dashboard for all networks |
| False positive filtering | No | Automatic aggregation, deduplication |
| Historical data | Only recent transactions | TimescaleDB with trend charts |
Why is monitoring needed even after an audit?
An audit does not protect against errors in upgradeable contracts, against changing external conditions (a new version of OpenZeppelin with a bug), or against social engineering that led to key compromise.
Continuous monitoring is the second line of defense that can save millions in funds before a hacker manages to withdraw all the assets.
Common mistakes when setting up monitoring
- Skipping events that are rarely called — for example,
OwnershipTransferred. If an attacker changes the owner, you will only find out when they have already withdrawn the funds. Add all admin events to monitoring. - Thresholds set too high — people often set a large deviation (20%) to avoid noise, but this gives the attacker enough time. The optimal value is 5% for prices and 10% for volumes.
- Not accounting for cross-chain risks — if a protocol operates on 3 networks, monitoring must be in place on each network; otherwise, an attack via a bridge will go unnoticed.
What is included in the work (deliverables)
- Scripts/configs for monitoring (Ansible roles, Docker images)
- Grafana monitoring dashboard with charts of key metrics (TVL, number of transactions, gas price)
- Documentation: description of rules, instructions for adding new contracts
- Access to a Telegram bot with live notifications
- 7 days of post-launch support (threshold calibration, rule refinement)
- Optional: premium 24/7 support with a 30-minute response time guarantee
Contact us for a preliminary estimate of your project. We will help set up monitoring that truly protects your funds.