Tool selection guide
Web3 incident response tools: evidence and containment preparation
An incident workflow needs evidence that survives the next action. Preserve the initial observation and assign decision authority before preparing containment. An explorer can help reconstruct a transaction; it does not establish every address attribution or authorize a multisig action.
Sources checked . Workflow design from public documentation; no alerts, signatures or transactions were sent.
Decide what your review needs
- Start an incident log with timestamps, chain IDs, transaction hashes and raw observations. Keep hypotheses separate from confirmed facts.
- Preserve a copy of relevant source, bytecode and configuration before changes. Record which artifact each conclusion used.
- Assign an authorized decision-maker for pause, upgrade or revocation actions. Investigators and signing authorities may have different roles.
- Track containment, notification and recovered assets as separate outcomes. Do not label funds recovered merely because an attacker address was identified.
Use the post-mortem guide to document recovery and remediation.
Compare inputs, results and limits
| Tool & access | Input → output | When it fits | Limits & source |
|---|---|---|---|
| Phalcon Explorer EVM | Input: Observed EVM transaction hash and chain Output: Trace and asset-flow evidence for investigation | You need to inspect calls and transfers before writing an incident hypothesis. | Decoded labels and traces need interpretation against the underlying transaction and contract state. Documentation reviewed. Official source |
| OpenZeppelin Monitor EVM | Input: Recorded detections and notification configuration Output: Alert and delivery context around the incident window | You need to relate an initial signal to the monitoring rule and notification path. | A monitor needs suitable RPC access, tested rules and a maintained notification path. Documentation reviewed. Official source |
| Safe Transaction Builder EVM | Input: Proposed calls and the intended Safe context Output: A transaction batch for review before execution | An authorized team needs to inspect exact calls and ordering; this does not grant signing permission. | Review each target, value, operation and calldata item. Batching can conceal an unwanted permission change. Documentation reviewed. Official source |
Public artifact walkthrough
Keep an alert record separate from a proposed response batch
The monitor can send a notification when a configured condition matches. That output belongs in the incident evidence log. A proposed response belongs in a separate review packet identifying the authority, affected contracts and exact calls. Link the two records by incident ID, without treating the alert as approval to execute the batch.
- Preserve the original alert and transaction trace, including their retrieval time and network context. Mark address labels as attributed when they come from a third party.
- Prepare an action proposal with preconditions, expected effects and a failure/rollback plan that is possible for the deployed system.
- Have the authorized operators review and simulate the proposal. Record execution separately from the evidence and never infer recovery from a simulation.