Tool selection guide
On-chain monitoring tools: detection rules and delivery checks
Monitoring begins with an event or state change that someone owns. Define what should trigger, how quickly the observation must arrive and who can decide what happens next. Detection, notification delivery and authorized response are separate results that need separate checks.
Sources checked . Configuration documentation reviewed; no alert was sent.
Plan the monitoring rules, thresholds and escalation.
Decide what your review needs
- Specify watched contracts, events or state conditions and the network context. A product's broad coverage statement does not configure your rule.
- Decide how to handle reorgs, missed blocks and RPC failures. Retain the last processed position and evidence of recovery.
- Test the notification destination and escalation owner with an explicitly labeled exercise. A matched rule does not prove that a person received it.
- Review permissions before enabling an automated response. Bound the actions and provide an owner-controlled disable path.
Compare inputs, results and limits
| Tool & access | Input → output | When it fits | Limits & source |
|---|---|---|---|
| OpenZeppelin Monitor EVM | Input: Network/RPC settings, watched conditions and notification configuration Output: Matched observations and notifications with persisted progress | You want configurable monitoring you can operate and inspect. | A monitor needs suitable RPC access, tested rules and a maintained notification path. Documentation reviewed. Official source |
| Forta EVM | Input: Detection bots or selected data feeds with monitored activity Output: Alerts produced by the selected detection coverage | You need bot-based signals and can evaluate their evidence and delivery path. | Bot coverage and alert quality vary. Connect alerts to an owned response procedure. Documentation reviewed. Official source |
| Hypernative Multichain | Input: Hosted monitoring integrations and response configuration Output: Threat signals and configured operational responses | You need a managed platform and can verify coverage, permissions and service terms. | Confirm supported assets, integration requirements and response controls for your environment. Documentation reviewed. Official source |
Public artifact walkthrough
Follow a monitor observation through notification and recovery
OpenZeppelin Monitor documents configurable conditions, several notification channels and checkpoint-based progress. It also describes retrying blocks missed during RPC failures. Treat those as separate acceptance checks: the condition must match, the notification destination must work and a restart must resume from the intended position. A successful startup message establishes none of these by itself.
- Define one event or condition and a harmless test observation with a known expected outcome.
- Record the observation ID, notification outcome and the responsible owner's exercise acknowledgment.
- Exercise an RPC interruption and restart in a test environment. Verify the recovery position and check for missed or duplicate notifications.