Summary: This piece describes how to build incident response and threat monitoring programs for DeFi and web3, including onchain detection, containment, and how Spearbit evaluates readiness.
Incidents in DeFi and web3 are visible by design. Attacks and mistakes leave traces onchain. That transparency can be an asset for defenders, but only if teams prepare. Good incident response is the difference between a contained issue and a drawn out failure.
The incident lifecycle in a web3 stack
The classical phases of incident response still apply, but they look slightly different in an onchain environment.
Preparation
Preparation means:
- Defining incident roles and responsibilities across engineering, operations, security, governance, communications, and legal
- Ensuring that logging is configured and retained for infrastructure, applications, and onchain events
- Documenting access to critical systems such as governance contracts, multisignatures, and cloud consoles
- Establishing contact paths with key partners, including custodians, exchanges, and integrators
For DeFi, one additional element is essential: understanding which protocol controls can be used during an incident and under what conditions.
Detection and triage
Detection sources include:
- Automated onchain monitors that track unusual contract interactions, balance changes, or deviations in invariants
- Alerts from infrastructure monitoring on API errors, latency, or unexpected patterns
- Identity monitoring that catches unusual logins or role changes
- External reports from whitehats, users, or third party watchers
Triage has to answer quickly:
- Are funds at risk right now
- Which contracts, markets, or chains are affected
- Is this a configuration issue, an integration problem, or an exploit
That assessment informs containment actions.
Containment options for DeFi protocols
Containment can include:
- Pausing parts of a protocol through functions designed for that purpose
- Freezing new deposits or certain operations while allowing repayments or unwinds
- Temporarily adjusting parameters such as loan to value ratios or rate caps
- Turning off front ends or adding banners and warnings, while coordinating with integrators
Each of these actions has side effects, so they need to be considered and tested in advance.
Eradication and recovery
Eradication involves:
- Removing malicious components from infrastructure
- Fixing configuration errors or patching exploited software outside the chain
- Rotating keys and secrets that may have been exposed
Onchain recovery is more constrained. Depending on the architecture:
- Upgrades can be used to correct vulnerable logic, assuming the upgrade mechanism itself is safe
- Migrations can move users into new contracts, with careful handling of accounting
- Parameter changes can tighten risk until a more robust structural change is ready
Recovery ends when services and protocols operate under known, monitored conditions with reduced residual risk.
Learning and improvement
After any incident or large scale exercise:
- Reconstruct the full timeline using logs, onchain data, and communication records
- Identify missed or delayed signals and gaps in response
- Update runbooks, monitoring rules, and control designs
- Share learnings with affected users and, where appropriate, the broader community
Threat monitoring for DeFi and web3 systems
Threat monitoring is the continuous layer that supports incident response.
Onchain monitoring
- Track protocol specific metrics such as utilisation, collateralisation, pool balances, and deviations from expected invariants
- Monitor for unusual contract calls, especially to admin functions or governance actions that change important parameters
- Watch for large or structured flows that indicate potential draining or preparation for manipulation
Infrastructure monitoring
- Monitor API error rates, latency, and traffic patterns for your front ends and backend services
- Collect logs from servers, containers, and cloud systems and centralise them for correlation
- Integrate identity and access logs to spot unusual patterns in admin actions
Intelligence and dependency monitoring
- Track vulnerabilities in dependencies used in smart contracts, backend services, and libraries
- Watch for public exploit scripts or proof of concepts that target components present in your stack
- Keep an eye on third party incidents in providers on which your system depends
Action plan for incident response and monitoring
- Write focused runbooks for a handful of high impact scenarios: contract exploit, bridge issue, key compromise, and infrastructure breach.
- Ensure that logging and monitoring cover core components: contracts, markets, bridges, API endpoints, build systems, and identity providers.
- Implement onchain monitoring with clear thresholds for alerts, tuned to your protocol rather than generic values.
- Rehearse containment actions in non production environments, including pausing contracts, adjusting parameters, and migrating users.
- Define communication procedures for internal coordination and external updates, including who approves public statements.
- After incidents or simulations, update runbooks, refine alerts, and adjust technical controls.
How Spearbit audits incident readiness and threat monitoring
In incident readiness focused audits, Spearbit:
- Reviews existing detection mechanisms for both onchain and offchain threats and identifies blind spots
- Examines governance and admin controls to see which actions are possible during a crisis and how they are protected
- Assesses logging and monitoring, including whether incidents can be reconstructed with available data
- Suggests improvements to runbooks, containment tools, and monitoring so that incidents can be handled systematically
For DeFi and web3 infrastructure teams, strong incident response and threat monitoring are part of earning and maintaining trust.
See how MDR fits your response workflow
Our Managed Detection and Response connects onchain detection with governed execution. It routes protocol-specific alerts to named owners, embeds playbooks and pause authority in the incident view, and captures an audit-ready timeline as you act.
Ready to pressure test your first thirty minutes? Book a demo here.