What to Do in the First 24 Hours After a Protocol Exploit

Right Now

If you are reading this mid-incident:

• Pause the protocol through whatever mechanism you have: multisig, timelock, emergency DAO, proxy admin. Every block you wait is another block the attacker can drain.
• Contact centralized exchanges with the attacker's wallet addresses. A freeze is not guaranteed, but it is the closest thing to a stop button once funds leave your protocol.
• Move all internal communication off Discord, Telegram, and Slack. Assume the attacker is in your channels. Your community is already watching. Your team needs a clean space to coordinate.
• Issue a single public statement. One tweet. "We are aware of an incident affecting [protocol] and are investigating. We will share more information as soon as it is available." Nothing more.
• Engage a security firm for on-chain forensics and asset tracing. The attacker is already bridging, swapping, and mixing. You need someone who can follow the money across chains.

In this guide

• Why the First 24 Hours Are Different in Web3
• Hour 0–1: Pause the Bleed
• Hour 1–4: Assemble the War Room
• Hour 4–8: Trace the Funds and Scope the Root Cause
• Hour 8–24: Communicate, Recover, and Plan
• Beyond 24 Hours: Rebuilding Trust
• When You Need Help Right Now
• Frequently Asked Questions

The monitoring alert fires at 4:05 PM UTC. A transaction your team did not authorize is draining funds from the vault. Your token is down 40% in four minutes. The attacker's wallet is on Etherscan and your community is already posting the transaction hashes in Discord.

This is the playbook. On-chain attacks resolve in blocks. Every move you make is visible to an audience of thousands.

Why the First 24 Hours Are Different in Web3

On April 1, 2026, Drift Protocol was drained of $285 million in 12 minutes. The largest DeFi hack of 2026. Drift's contracts had been audited twice. Once in 2022 and again in early 2026, weeks before the attack. Neither review caught the vulnerability because the vulnerability was not in the code. DPRK-linked actors spent six months socially engineering two of five multisig signers.

In February 2025, Bybit lost $1.5 billion. Same pattern. The FBI attributed it to North Korean TraderTraitor actors. No code bug. UI poisoning of the multisig interface. Signers approved a transaction that looked legitimate. The underlying logic had been modified to transfer ownership.

Two of the largest exploits in crypto history, and neither was a code bug. Smart contract exploit losses dropped roughly 89% year over year in Q1 2026. The code is getting better, but the attackers are getting smarter too. They have moved up the stack to governance, to multisig, to infrastructure, and to the people building the protocols.

Most incident response playbooks were written for Web2. They assume that the attacker moves over days or weeks and that you can contain the breach before anyone outside knows what is happening. IBM's 2025 report found the average Web2 breach lifecycle is 241 days: 181 days to detect, 60 days to contain.

But in web3, the attack is public the moment the first transaction hits the chain, and the consequences are irreversible. You do not have 60 days to contain the incident. You only have a few blocks, and your incident response plan needs to account for this.

Hour 0–1: Pause the Bleed

Step 1: Verify it is real, but do not wait

Treat every credible signal as an exploit until proven otherwise. You are looking for:

• Unusual transaction volume from known protocol wallets
• Unexpected admin function calls or ownership transfers
• Anomalous token movements from vaults, treasuries, or liquidity pools
• Community reports of unexpected behavior
• Third-party monitoring alerts from your security partner or real-time monitoring tools

If you are on the fence, escalate. The Drift attacker drained $285 million in 12 minutes. Bybit lost $1.5 billion in a single transaction. You do not have the luxury of waiting to be sure.

Step 2: Pause the protocol

The mechanism depends on your architecture:

• If you have a multisig, coordinate your signers immediately. Call the pause function. If signers are unreachable, keep trying. Every minute matters.
• If you have a timelock, the clock is your enemy. The attacker may have already queued a malicious transaction days ago. Check the timelock queue immediately and cancel anything suspicious.
• If you have an emergency DAO or security council, activate it. Drift's Security Council was the target of the attack. Verify your emergency mechanism has not been compromised before you rely on it.
• If you have a proxy admin, use it to upgrade the implementation to a paused state. Verify the attacker has not already taken ownership of the proxy.
• If the contract is immutable, you have no pause button. Skip to the next step. Your only leverage is speed and exchange coordination.

Step 3: Contact centralized exchanges

The attacker will try to off-ramp. Send the attacker's wallet addresses to every major exchange with a clear, urgent request to freeze. Include attribution data from blockchain analytics firms if you have it.

Step 4: Hard rules

Communicate these to everyone on your team:

• Do not tweet through the exploit. A single acknowledgment is enough. Everything else comes later.
• Do not promise compensation to users. You do not yet know the scope of the loss, the root cause, or whether you can recover funds. A promise you cannot keep is worse than silence.
• Do not message the attacker publicly. On-chain messages and public negotiation attempts create a second front you cannot control. If you decide to negotiate, do it through counsel and a security partner.
• Do not delete Discord messages, GitHub commits, or any public record. The community will find the deleted messages. They always do. The chain is immutable. Your reputation should be too.
• Do not make unilateral decisions about recovery, compensation, or governance without the full war room. Adrenaline produces bad decisions.

Hour 1–4: Assemble the War Room

Assign these roles now.

• Incident Commander: One person owns decisions, priorities, and the timeline. Not the CEO or founder. The person best equipped to run the technical response.
• Protocol Lead: Runs the contract pause, coordinates developers, and owns the technical investigation. This person knows the codebase and the governance architecture cold.
• On-Chain Forensics Lead: Traces the funds across chains, bridges, and mixers. Works with analytics firms. Every transaction hash is evidence.
• Community Lead: Owns the single public statement, monitors Discord and Twitter/X, and coordinates the communications strategy. This person should not be the one investigating the exploit. They need to be fully focused on the community.
• External Security Liaison: Manages your security auditor, forensics firm, exchange contacts, and legal counsel. This is the person who knows who to call. If you do not have a security partner on retainer, engage one now. Look for a firm that covers smart contract auditing, on-chain forensics, and cross-chain asset tracing. A firm that only audits Solidity is not enough. Ask about their experience with governance attacks, multisig compromise, and operational security failures. The Drift and Bybit exploits were not code bugs. They were governance failures. Your security partner needs to understand both.

Move off Discord

Assume the attacker is reading your Discord, Telegram, and Slack. Move all incident communication to a clean channel: a Signal group, a fresh phone bridge, or a secure out-of-band platform. The joint #StopRansomware Guide from CISA, MS-ISAC, NSA and the FBI warns that attackers monitor victim communications. In web3, the attacker is likely in your Discord. Using compromised channels to coordinate your response tells the attacker exactly what you know.

Hour 4–8: Trace the Funds and Scope the Root Cause

What to preserve

On-chain evidence is permanent, but context is not. Prioritize:

• Every transaction hash associated with the exploit, from the initial attack to the most recent transfer
• Discord logs, Telegram messages, and GitHub commit history from the days leading up to the exploit
• Deployer key audit trails. Who had access? From where? When?
• Multisig transaction history. Who signed what, and did they know what they were signing?
• Any off-chain artifacts: email threads, calendar invites, conference schedules

The On-Chain Forensics Lead logs every action with timestamps. If you contacted an exchange, note when and who. If you traced funds through a bridge, note the destination chain and address. This log becomes the backbone of your post-mortem, your governance proposal, and any legal action.

The eight-hour checkpoint

• What was the initial access vector? Smart contract vulnerability? Governance compromise? Multisig key theft? Social engineering? Supply chain insertion?
• Which contracts and chains were affected? Was the attack isolated to one contract or did it span multiple protocols?
• How much was stolen and where is it now? Has it been bridged, swapped, mixed, or deposited to an exchange?
• Does the incident involve user data, KYC information, or material non-public information? Web3 exploits usually involve on-chain assets, but off-chain data breaches are possible.
• Is the attacker still active? Are there additional transactions queued in the timelock? Are there compromised signers who have not been identified?

Cross-chain forensics

Web3 forensics follows the money across chains. The attacker will not sit on the stolen funds. They will bridge to another chain, swap through a DEX, use a mixer, or deposit to an exchange. Your forensics scope needs to cover every chain your protocol touches and every bridge the attacker might use.

Pull data from every surface. On-chain monitoring tools. Discord and Telegram logs. GitHub activity. Multisig signers' device security. Look for correlation. A single anomalous transaction might look like a bug. That same transaction paired with a suspicious conference interaction and a compromised signer device is an exploit. Assume the attacker has a post-exploit plan. Your forensics team needs to move faster than that plan.

Hour 8–24: Communicate, Recover, and Plan

Public communication

Your community is watching. They have been watching since the first block. By hour 8, you should have enough information to issue a substantive update.

The template:

• What you know. What you are still investigating. What you are doing about it.
• No speculation. No blame. No promises you cannot keep.
• A clear timeline for the next update.

"We have confirmed unauthorized access to [protocol] through [initial access vector, if known]. Approximately [amount] in user funds was affected. We have paused the protocol, are working with on-chain forensics partners to trace the funds, and have contacted centralized exchanges. The attacker's wallet addresses are [addresses]. We will publish a full post-mortem by [date]."

The community will demand more. Do not give it to them until you know it is true.

Law enforcement and regulatory considerations

The web3 regulatory landscape is fragmented, but the direction is clear. Public companies and regulated entities have disclosure obligations. GDPR applies if user data was compromised. State laws vary. Engage legal counsel to determine your obligations.

Law enforcement is a resource. The FBI's IC3, CISA, and international agencies track DPRK-linked crypto theft as a national security priority. Both the Drift and Bybit attacks were attributed to North Korean actors. Engaging law enforcement early can help with attribution, exchange freezes, and eventual asset recovery. It also signals to your community that you are taking the incident seriously.

Recovery planning

By hour 24, document the plan for:

• Restoring the protocol from the exploit
• Patching the vulnerability
• Re-auditing the contracts
• A governance proposal for compensation if applicable
• A schedule for public updates and decision deadlines

Start a lessons-learned log now. Memory fades faster than you think. The decisions you make in the first 24 hours will be scrutinized for months. Document them.

Beyond 24 Hours: Rebuilding Trust

The first day is survival. The weeks that follow are about rebuilding trust. TVL is trust denominated in dollars. When trust breaks, TVL leaves.

First week: Complete the forensic investigation. Patch the vulnerability. Re-audit the contracts. Publish the post-mortem. Notify affected users. The Drift team published their post-mortem on April 5, four days after the exploit. It named the root cause, the attack vector, the timeline, and the remediation steps without deflection.

First month: Update your incident response plan or build one if you did not have one. Launch or expand a bug bounty program. Run war game exercises against governance attack scenarios: multisig compromise, social engineering, timelock manipulation. The Drift and Bybit attacks were operational failures. Your security program needs to cover operations, not just code.

First quarter: Harden your governance. Split authority across independent signers, not co-located team members. Implement transaction simulation for all multisig approvals. Audit your deployer key management and signing infrastructure. Run another war game. Vet your security partner before you need them. The middle of an exploit is not the time to compare audits.

Frequently Asked Questions

What if the contract is immutable?

You cannot pause it. Your immediate priorities shift to contacting centralized exchanges with the attacker's addresses, tracing the funds on-chain, and communicating transparently with your community. If your protocol lacks circuit breakers, make that the first governance proposal after the incident.

Should I negotiate with the hacker on-chain?

Not publicly. On-chain messages are visible to everyone and create a second front you cannot control. Negotiate through counsel and a security partner with experience in crypto extortion. The Drift team reached out to the attacker via blockscan chat. A private channel is better than a public one.

Do I need to report a web3 exploit to regulators?

It depends on your jurisdiction, your incorporation structure, and the data involved. If user PII or KYC data was compromised, GDPR and state data breach laws may apply. Public companies and regulated entities have disclosure obligations. Engage legal counsel to determine your obligations.

How do I handle the token price crash?

You cannot control the market. You can control your response. A clear, honest, and timely post-mortem does more for token price recovery than any coordinated messaging strategy. The community will price in your response.

Should I compensate users?

That is a governance decision. You do not have enough information on day one. Some protocols have made users whole through treasury funds or protocol revenue. Others have negotiated partial returns. The answer depends on the size of the loss, your treasury, and your community's expectations.

How do I prepare before an exploit happens?

Build an incident response plan and test it with war game exercises. Have a security partner on retainer. Implement real-time on-chain monitoring. Harden your multisig governance. Require transaction simulation for all approvals. Maintain a list of exchange contacts for emergency freezes. The protocols that survive are the ones that ran the war game six months ago, not the ones scrambling to find a security firm on Telegram.

When You Need Help Right Now

This guide was published by Quantstamp, a web3 security and incident response firm. It draws from public frameworks, real incident response work, and publicly available post-mortems.

Quantstamp is a global leader in blockchain security. Since 2017, the team has secured over $500 billion in digital assets and conducted more than 1,300 audits. We specialize in smart contract auditing, on-chain forensics, penetration testing, and economic exploit analysis. Whether you need an audit before you deploy or forensic help tracing an active exploit, engage a partner who understands the attack surface is bigger than your code.

Schedule an audit before you deploy or reach out immediately if you are in an active incident.

Get active monitoring for your communication channels through Common Defense to prevent social engineering attacks and phishing scams.