Skip to content

DeFi Incident Response & Protocol Recovery

In short

DeFi incident response is the work of containing a live exploit, freeing stuck funds, and recovering a protocol after something goes wrong on-chain, from engineers who have built and operated the same DeFi architectures that get attacked.

Trusted by teams building on-chain

DeFi incident response is the work of containing a live smart contract exploit, freeing stuck funds, and recovering a protocol after something goes wrong on-chain: confirming the attack is real, identifying the vulnerable contract and function, executing emergency mitigations, and communicating to users without making it worse. Protocol Rescue is Protofire's emergency response service for exactly that moment. It is engineering-led: the people in your incident channel have built and operated the same DeFi architectures that get attacked, so smart contract incident response starts from pattern recognition, not from a generic runbook.

Most security vendors hand you a report and disappear. An audit tells you what was known on the day it was signed; it does not pause the contract at 3am on a Saturday. Blockchain emergency response is a different discipline: the speed and correctness of the first mitigation, under pressure, with money leaving the protocol in real time.

For a 2-5 person founding team that is simultaneously the developer, the operator, and the community manager, the first hour decides the outcome, so we engage on two models: on-demand exploit response when an incident is already live, and a standby retainer with monitoring and pre-built runbooks so the response is rehearsed before it is needed.

From first alert to hardened recovery

A blockchain emergency response follows the same staged sequence whether the trigger is an active exploit, a critical vulnerability in live code, a governance attack, or funds stuck behind a bug.

01

Triage

Confirm the attack is real, isolate the vulnerable contract and function, and determine whether it is ongoing - no irreversible action taken blind.
02

Contain

Execute the emergency mitigation: pause calls, Safe multisig transactions assembled correctly the first time, and a holding statement that acknowledges the incident without revealing the vector.
03

Diagnose

Establish the root cause: which function, which interaction class (flash-loan, oracle manipulation, reentrancy), and whether the vector remains open in other contracts.
04

Remediate

Coordinate on-chain fund recovery where viable, draft the public statement, and deliver root-cause analysis, post-mortem, and remediation specification.
05

Post-mortem & Hardening

Verify the fix, coordinate or provide a re-audit, support redeployment, and stand up monitoring and protocol-specific runbooks before the engagement closes.
01

What Protocol Rescue covers

When an exploit fires, the first question is what is actually happening. We confirm the incident is real, isolate the vulnerable contract and function, and determine whether the attack is ongoing, using on-chain triage tooling: Tenderly transaction simulation, block explorers, and Dune Analytics.

Because we have worked inside lending and CDP systems, ERC-4626 vaults, Uniswap-style DEXs, staking modules, and Safe governance, the attack vector (flash-loan interaction, oracle manipulation, share-price manipulation, reentrancy) is usually a known pattern, not a novel puzzle. Benefits: the vector named in minutes, not hours · no guesswork on which function to touch · a clear picture before any irreversible action.

02

How an exploit response runs: triage, contain, recover, harden

1

Triage

Establishes ground truth (is this real, is it ongoing, which contract, which function) using transaction simulation, explorers, and analytics so no irreversible action is taken blind.
2

Contain

Executes the mitigation: pausing in the correct order and assembling the Safe multisig transactions that actually stop the bleeding, plus a holding statement that acknowledges the incident without publishing a roadmap for further exploitation.
3

Recover

Turns the acute phase into structured output: root-cause analysis, post-mortem, remediation spec, and coordination of any fund recovery.
4

Harden

Verifies the fix, coordinates a re-audit, supports redeployment, and leaves monitoring and runbooks behind. The first 60 minutes carry the most weight, because a delayed or incorrect first mitigation is what turns a contained loss into a total one.
03

Incidents we respond to

Active exploit containment (funds being drained now)
Critical vulnerability discovered in live code
Governance / multisig attack response
Emergency pause and emergency admin execution
Stuck or frozen funds from a contract bug
Post-incident root-cause analysis and post-mortem
Remediation specification and re-audit coordination
Redeployment and post-incident hardening
Standby retainer: monitoring, runbooks, on-call coverage
04

Our 24/7 incident response model

Engaged when an incident is already live: we join your incident channel, triage, and coordinate containment, with no prior relationship required (a deposit applies for first-time crisis clients, standard for emergency work).

05

Who Protocol Rescue is for

Protocol Rescue is built for DeFi protocols live on EVM mainnet with real value locked, run by small founding teams (typically 2-5 people) without a dedicated in-house security engineer or incident response plan. It fits protocols on common, well-understood architectures (Aave/Compound-style lending and CDP systems, ERC-4626 yield vaults, Uniswap v2/v3/v4-style DEXs, Safe multisig governance, and staking) where the attack surface is known and pattern recognition pays off immediately.

It also fits teams that have just crossed a meaningful TVL milestone and realized they have no plan for the day something goes wrong. Scope is EVM-only; non-EVM chains (Solana, Near, Cosmos CosmWasm) and centralized or custodial infrastructure are out of scope, because the tooling and attack patterns are different.

06

An engineering-led security team, not a generic SOC

Protofire is an engineering-led blockchain development and security company that has shipped 250+ projects since 2016 across 60+ networks and 95+ protocols. We maintain Solhint, the open-source Solidity linter used by 1M+ developers and built with Ethereum Foundation grants, and we are an official Safe Guardian with deployments across 120+ EVM networks securing $2B+ in assets, the exact emergency multisig execution capability an incident demands.

We are a core contributor to Chainlink and a top-3 indexer in The Graph ecosystem, and we have built and operated production DeFi systems (DEXs, staking, lending, and vaults) for protocols including Balancer, CowSwap, and Swarm Markets. Across those builds we have worked directly inside the architectures incidents target: Aave/Compound-style lending and CDP systems, ERC-4626 vaults, Uniswap-style DEXs, staking modules, and Safe governance, so the attack surface in a given contract is usually a pattern we already know. Incident response is pattern recognition and execution under pressure; ours is grounded in code we have shipped, not a playbook we bought.

“The first 60 minutes carry the most weight, because a delayed or incorrect first mitigation is what turns a contained loss into a total one.”

Incident response model

No incident plan / ad-hoc responseProtocol Rescue standby retainer
Response timeAssembled during the incident, 3am SaturdayPre-built runbooks, on-call rotation, defined SLA
Incident phasesTriage + damage control onlyTriage, contain, recover, harden fully scoped
Security expertiseGeneric security vendors or audit reportsPattern recognition from shipping the DeFi architectures under attack
Monitoring & runbooksSet up after an incident happensActive monitoring via Tenderly/Defender, tested scripts before anything fires
Team accountabilityOne-off crisis responseDedicated on-call rotation with quarterly reviews

FAQ

What is DeFi incident response?
DeFi incident response is the structured handling of a smart contract emergency: a live exploit, a governance attack, a critical bug found in deployed code, or funds stuck on-chain. It covers triage (confirming the attack is real and identifying the vulnerable contract and function), containment (pausing in the correct order and executing emergency multisig actions via Safe), communication to users and investors, and recovery (root-cause analysis, post-mortem, and a remediation specification). A fourth stage, hardening, verifies the fix, coordinates a re-audit, and leaves monitoring and runbooks behind so the next anomaly is caught early. At Protofire it is engineering-led: the responders have built and operated the same DeFi architectures under attack, so the work starts from pattern recognition rather than a generic runbook. The first 60 minutes carry the most weight, because a delayed or incorrect first mitigation is what turns a contained loss into a total one.
What should we do during a live exploit?
First, do not act blind. Confirm the exploit is real and identify which contract and function are being abused before touching anything. A wrong or out-of-order pause can make the loss worse. Use transaction simulation (Tenderly), block explorers, and analytics to establish ground truth: is it real, is it ongoing, which function. If you have a pause or emergency admin function, prepare to use it, but verify it will execute and not revert: the nonce, gas, and threshold details are what derail a panicked team. Post a brief holding statement that acknowledges the incident without revealing the vector or publishing a roadmap for further exploitation. Then get experienced help into your incident channel immediately. The first 60 minutes carry the most weight, because the correctness of the first mitigation decides whether a contained loss becomes a total one. We are reachable for on-demand exploit response with no prior relationship required.
How fast can you respond?
On-demand exploit response can be engaged immediately when an incident is already live: we join your incident channel, triage, and coordinate containment, with no prior relationship required. Standby-retainer clients get a defined SLA for rapid, 24/7 response to Critical alerts, with acknowledgment and active-triage commitments scoped per engagement, plus pre-built runbooks so the response is rehearsed rather than improvised. The retainer is for protocols that would rather rehearse than improvise: an on-call rotation, active monitoring via Tenderly and OpenZeppelin Defender, protocol-specific pause scripts and incident runbooks, and a quarterly review and tooling test. The point is that the response is pre-built: the plan exists, the pause script is tested, and the on-call chain is known before the incident, not assembled during it. Speed only matters if the first mitigation is also correct, so both models pair fast engagement with the pattern recognition to act without making the loss worse.
Which chains and protocol types do you cover?
EVM-compatible chains and Solidity smart contracts. We focus on common, well-understood DeFi architectures (Aave/Compound-style lending and CDP systems, ERC-4626 yield vaults, Uniswap v2/v3/v4-style DEXs, Safe multisig governance, and staking) where the attack surface is known and pattern recognition pays off immediately. Because we have built and operated these systems ourselves, an attack vector like a flash-loan interaction, oracle manipulation, share-price manipulation, or reentrancy is usually a known pattern rather than a novel puzzle. The service fits protocols live on EVM mainnet with real value locked, typically run by small founding teams without a dedicated in-house security engineer. Non-EVM chains (Solana, Near, and Cosmos CosmWasm) and centralized or custodial infrastructure are out of scope, because the tooling and attack patterns are different and pattern recognition is what makes the first hour fast. Keeping scope EVM-only is deliberate, not a limitation we are working around.
We already have an audit. Do we still need incident response?
Yes. An audit is a point-in-time assessment of what was known on the day it was signed; it does not pause the contract at 3am on a Saturday, execute the multisig, or write the holding statement when something fires. Blockchain emergency response is a different discipline: the speed and correctness of the first mitigation, under pressure, with money leaving the protocol in real time. Many protocols that suffered large losses had audit reports on file. The two are complementary: an audit reduces known risk before deployment, while incident response is what you do when the unknown happens. In fact they connect at the end of an incident: our hardening stage verifies the fix and coordinates or provides a re-audit before redeployment, then stands up monitoring and runbooks so the same class of bug is closed for good and the next anomaly is caught early.
Can you help recover stolen or stuck funds?
For stuck or frozen funds caused by a contract bug, we work to construct the on-chain actions needed to free them. For an active theft, we coordinate containment first and, where it is viable, run whitehat and negotiation outreach to recover what we can. On-chain recovery is never guaranteed, and we are explicit about that, but the response is run as a product with deliverables, not as a favor. Alongside any recovery effort we draft the first public statement, then deliver structured artifacts: a root-cause analysis, a community- and investor-facing post-mortem, and a remediation specification. Those matter because contained value, a clean post-mortem, and a credible remediation plan are what let a protocol retain investors and restart TVL even when not every dollar comes back. Communication is half the incident, so we treat the statement and the post-mortem with the same rigor as the on-chain mitigation.
We're a small DeFi team with no security engineer. Can you help?
That is exactly who Protocol Rescue is for. It is built for DeFi protocols live on EVM mainnet with real value locked, run by founding teams of typically two to five people who are simultaneously the developer, the operator, and the community manager, without a dedicated in-house security engineer. Knowing your own code is necessary but not sufficient in an incident: the hard part is execution under pressure: pausing in the right order, assembling and signing the Safe multisig correctly, and posting a statement that does not reveal the vector, all at once, in the first hour. As an official Safe Guardian with deployments across 120+ EVM networks securing $2B+ in assets, emergency multisig actions that would take a small team hours are routine for us. We bring that execution capability and the DeFi pattern recognition behind it, either on demand or on a standby retainer.
Do you offer ongoing coverage, or only emergency response?
Both. On-demand exploit response is engaged per incident: we join your incident channel, triage, and coordinate containment, with no prior relationship required (a deposit applies for first-time crisis clients, which is standard for emergency work). The standby retainer is the proactive model: an on-call rotation with a defined SLA, active monitoring via Tenderly and OpenZeppelin Defender, protocol-specific pause scripts and incident runbooks, and a quarterly review and tooling test. The difference is rehearsal: with a retainer the plan already exists, the pause script is already tested, and the on-call chain is already known, so the response is pre-built rather than assembled mid-incident. Many teams start with on-demand response during a live event and move to a retainer afterward, once they have seen how much the first hour depends on having the plan ready before anything fires. For the full standing watch, continuous monitoring, incident response, and lifecycle operations for a live product, see managed on-chain operations.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: June 2026.

Book a call with Alejandro Losa

Schedule a call with our Web3 Solution Architect to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved

Message us on Telegram