Monitoring
🔑 Key Takeaway: Monitoring only improves security when every alert has an owner and a documented response. Detection without action is noise.
On-chain monitoring watches blockchain state and events so teams can detect anomalies and attacks close to real time. For smart contract protocols, that means tracking the behaviors that matter to safety and solvency — large transfers, mint and burn activity, admin changes, upgrades, oracle deviations, and similar signals — and routing those signals to people prepared to act.
This framework focuses on on-chain security monitoring. Off-chain infrastructure metrics (hosts, CI, cloud control planes) belong in DevSecOps and infrastructure guidance; linking monitored on-chain signals to incident management remains essential.
First principles
Before deploying any monitoring tool, establish the fundamentals that make monitoring effective.
Know what is monitored and why
Define which on-chain events are meaningful to the project and which response each alert must trigger. A monitoring setup without defined responses is noise: it consumes attention without producing safety. For every alert configured, answer: who receives this, and what do they do when it fires?
Act on alerts
Organizations fail at monitoring in two ways: not observing at all, or observing without acting. Both leave teams blind to preventable loss.
Every alert must map to a concrete, documented response. For smart contract protocols, that typically means a pause mechanism or circuit breaker and, in higher-maturity setups, carefully designed automation that may fire on critical alerts only when trigger conditions and failure modes have been explicitly reviewed. Without this, monitoring reports what happened after the fact rather than enabling prevention or fast containment.
Monitor with redundancy (higher maturity)
No monitoring provider has perfect uptime or perfect detection. For critical systems, run two independent providers monitoring the same invariants in parallel (for example one self-hosted and one managed). If one has downtime or misses an event, the other still provides coverage. See Tools for combining self-hosted and managed options.
What this framework covers
- Guidelines: objectives, coverage tracks, alerting design, reviews, and linkage to incident response and forensic readiness.
- Tools: open-source and commercial on-chain monitoring options with reliability criteria.
- Thresholds: baseline metrics, multi-layered alerts, adaptive thresholds, and anomaly detection.
Related frameworks
- Incident Management: response plans, communications, and forensic readiness tied to alerts
- Infrastructure: broader infrastructure and network monitoring context
- DevSecOps: CI/CD and pipeline telemetry complementary to on-chain signals
- Treasury Operations: high-value transfer monitoring and controls
Further Reading
- OpenZeppelin Monitor: open-source monitoring stack often used as a self-hosted baseline
- Forta Network: decentralized detection bots and community-shared threat signals