Crypto Incident Response: A Protocol Team Playbook

Detection to war room

Crypto incident response is the coordinated work of containing an active security event, preserving evidence and restoring a service under an agreed authority. A monitoring alert starts that work. The cause still needs investigation. Treat an unexpected withdrawal, a changed signer and a redirected website as different observations until evidence connects them.

Choose an incident commander who can assign work while specialists investigate. Give the scribe a separate job: record observations, decisions, owners and the evidence available when each decision was made. Use UTC timestamps and retain the block number alongside wall-clock time. A block explorer screenshot helps communicate a finding, but it should accompany the transaction hash and raw receipt rather than replace them.

1. Capture the first alert with the chain, affected contract or hostname, observed behavior and reporter contact. State what is confirmed and what remains a hypothesis.
2. Page the named responders. Escalate unanswered pages.
3. Open an access-controlled war room. Verify participants using a channel whose integrity is still trusted, especially when the suspected incident involves organizational accounts.
4. Assign containment, evidence collection and communication in parallel. Keep a decision log that survives the loss of the primary chat platform.

The Security Alliance's incident response checklist calls for named leadership, alternate communication channels and prepared emergency execution. Translate those readiness controls into your actual roster.

An unanswered group message is not an escalation procedure.

Our smart contract monitoring guide separates a detected condition from an executable response. Record the alert's blind spots here too: an onchain balance rule may reveal losses while missing the compromised website that persuaded users to sign.

Pause decision

Before signing a containment transaction, name the behavior it stops. A frontend shutdown does not disable direct contract calls. A deposit pause may leave withdrawals open.

An upgrade can change execution but may itself depend on a compromised signer or an unexpired timelock. Read the deployed controls and current role assignments, then simulate the proposed action against the relevant state when time and tooling permit.

Consider a suspected signer compromise during a pending upgrade. First establish which transaction is queued and whether the remaining trusted authority can cancel it. Revoking a visible role may leave a different execution path intact. The response lead needs a state-based explanation of what the attacker can still do after the proposed change. Reconcile the nonce and signing requirements before collecting approvals, then check the receipt and resulting authority assignments after execution. A transaction that was signed but never included has not changed the deployment.

Containment has costs.

Pausing a lending market can interact with liquidation and repayment rules. An emergency transfer can change the balances investigators need to reconcile. Write down the expected benefit, the authority used and the residual exposure. Have a separate reviewer inspect the target chain, contract address and calldata. Never let a familiar transaction label substitute for reading its effect.

If no safe pause exists, acknowledge that limit immediately. Shift effort toward the controls that do exist, such as disabling a compromised application interface, notifying integrators or isolating infrastructure credentials. Avoid repeatedly proposing a transaction the deployed system cannot execute. Preserve the failed simulation and its state reference so later reviewers can understand the decision.

Record the remaining exposure.

SEAL 911 and whitehat negotiation

The official SEAL 911 repository identifies its Telegram bot as the contact route and describes a volunteer service. Open that route from the official repository. An unsolicited direct message from a familiar avatar is not proof that the sender belongs in the war room.

SEAL documents an authentication procedure involving an unguessable keyword and a ticket through the bot. Follow the current published instructions when verifying a claimed member. Identify the affected system and current exposure in the request. Attach observed transactions, describe actions already taken and name a reachable incident lead. Share sensitive exploit details through the verified private channel, with access limited to people doing the response work.

A whitehat rescue requires a clear authority boundary. The Safe Harbor FAQ describes intervention after a separate malicious actor has attempted an exploit, under a framework adopted by the protocol. A public framework is not evidence that your deployment adopted it. Check the actual agreement, covered chains and contracts, applicable version and any conditions attached to rescue or payment.

For a proposed rescue, record who authorized the action, which assets may move, where recovered assets should go and what evidence will confirm completion. Separate those approvals from discussions about compensation. Ask counsel to review the applicable agreement and any proposed negotiation; a technical responder cannot resolve every question about sanctions, ownership or authority by inspecting bytecode.

Use a single authorized negotiation lead. Preserve incoming messages and proposed terms, including their provenance, without spreading operational details across public chats. Treat a promise to return funds as an unverified statement until the transfer and control of the receiving address are confirmed.

Recovery accounting belongs in the incident log, with asset quantities retained in native units.

What 84 public SEAL 911 log entries show

Method

We counted every bullet in SEAL 911's public activity log at a pinned repository revision retrieved on September 5, 2026. The publisher explicitly calls the record incomplete. Our inventory asks what the labels and reference links expose to a reader, without treating them as independently verified incident reports.

Population

84 bullet entries in ACTIVITY.md; all 84 included.

Exclusions

None. Entries without a source URL remain in the denominator.

Signals

Literal domain-hijacking, DNS-takeover and X-account-takeover labels; whitehat-rescue labels; destination hosts.

Reproduction

seo/research/incident-log-survey.py and seo/research/incident-log-survey-2026-09-05.json retain the pinned commit, raw log, source statuses and per-entry evidence. These files stay in the repository and are not published as downloads.

Results

We manually read all 10 takeover-matching labels and retained all 10 under the stated label rule. The combined Ambient Finance website/X label counts once in the X group. This confirms the classification of the text, not the underlying root cause. Operationally, the inventory supports including domain and social-account response in a protocol exercise; it cannot rank those threats against contract exploits.

Limits

• The unit is a log entry, not a deduplicated incident. Multiple entries may concern related events.
• Inclusion does not prove recovery, response speed or the amount of loss prevented.
• We did not crawl the 79 linked destinations as part of this measurement. A social link or an absent link does not prove that fuller evidence is unavailable elsewhere.

Maintain your own durable evidence packet. A link to a public announcement is useful for communication, but it is an insufficient substitute for the observations and decisions your team made during containment.

Exchange freeze requests

An exchange freeze request needs a traceable reason to connect a deposit with the incident. Prepare the receiving address, chain, asset contract, transaction hash, amount and timestamp, then explain the path from the affected system. Distinguish a directly observed transfer from a provider's attribution label or an analyst's hypothesis. Do not present an address association as ownership proof.

Request owner

A named contact authorized to represent the affected organization, with a verified return channel.

Evidence packet

A short chronology, original transaction identifiers, supporting records and an explanation of the requested preservation or review.

Case linkage

The law-enforcement case reference and investigator contact when available, kept current as the investigation develops.

Status

Receipt, review, restraint and recovery recorded separately, with the source of each confirmation.

Coinbase's legal contact page separates customer support from official criminal requests through its law-enforcement route. Kraken's legal inquiry page directs compliance and legal matters to its designated form. Use the applicable published channel and identify your role accurately. A protocol team should not impersonate an investigator to enter a restricted process.

Notification is not confirmation that assets are frozen or recoverable. The receiving service evaluates the request under its procedures and applicable authority. Continue tracing and containment while recording acknowledgments. Announce recovery only after confirming the relevant transfer and control. Avoid sending the same incomplete claim through unrelated support routes when a verified incident contact can maintain a coherent record.

Law-enforcement filing

Prepare a factual incident summary for the appropriate jurisdiction and have the organization's legal lead coordinate the filing. For US complaints, the Internet Crime Complaint Center's cryptocurrency guidance requests addresses, transaction hashes, asset types, amounts and transaction dates and times. It also makes clear that investigation is at the receiving agency's discretion. A complaint reference is not a recovery commitment.

Keep that distinction in stakeholder updates.

Preserve originals. Keep exported logs and deployment records with their collection time. Identify the source and collector for communication archives too. Record any transformations used to produce a readable timeline. A spreadsheet of amounts is easier to review when each row points back to a transaction and the valuation method is stated separately from the native asset amount.

1. Describe the affected entity and system, the first confirmed observation and the current operational status.
2. Attach a transaction chronology that identifies the chain and token contract wherever an asset symbol could be ambiguous.
3. Provide a contact who can answer technical questions and a representative who can confirm organizational authority.
4. Retain every submitted version.

Do not fill evidentiary gaps with an attacker's claimed identity. Mark uncertain attribution explicitly and separate observed behavior from suspected motive. Where the incident spans jurisdictions, coordinate the submission strategy with counsel and the assigned investigators rather than assuming a form in one country covers every affected party.

Preserve submission acknowledgments.

Disclosure

A useful first statement names the affected service, explains the action users should take and identifies the trusted update channel. It can acknowledge an investigation without publishing a reproducible exploit while exposure remains open. Include a timestamp and the next planned update, then correct inaccurate statements visibly rather than silently replacing the record.

Yearn's yETH incident disclosure dated December 1, 2025 illustrates the value of boundaries: it identifies yETH and direct integrators as affected while distinguishing other Yearn products. Its timeline separately records the internal war room, SEAL 911 engagement and recovery execution. That is evidence of distinct response stages, not a response-time promise for another protocol.

Before reopening, prepare a release decision that links the fix to the failure evidence. Identify the new deployment artifact, the changed configuration and the tests that address the incident path. Reconcile outstanding user balances and explain any operations that remain restricted. Have an authorized owner accept the residual uncertainty in writing. If an investigation remains open, distinguish that status from the narrower decision that a particular service can resume. Keep the ability to roll back or contain a failed restart within the same documented authority model. Define which observation would trigger that fallback and who watches for it after reopening. An unexplained balance change or a recurring alert should have an assigned responder even while the rest of the team completes the postmortem. Record the restart decision as part of the incident timeline.

Alert

An observation requiring triage.

Assessed scope

Affected systems and remaining uncertainty.

Containment

An executed action with a checked effect.

Recovery record

Confirmed asset control and a reconciliation trail.

The later postmortem should connect the failure mechanism, response decisions and corrective work without exposing unnecessary personal data. Give unresolved questions owners. Link the correction or verification that closes each material issue; a published explanation alone does not demonstrate that the deployed system changed.

Free responders vs retainers

Volunteer assistance and a commercial retainer answer different capacity questions. SEAL 911 states that it does not offer paid services and that volunteer availability limits support. Its repository identifies separate commercial providers for needs that can extend beyond a volunteer engagement. Verify the current scope directly rather than assuming a public contact guarantees sustained tracing or a staffed response window.

Chainalysis described a tracing retainer and liaison with law enforcement and recovery counsel in its 2023 incident-response announcement. That establishes the service model, not a current price or contractual response commitment. Request the actual engagement terms before treating a marketing page as an operational dependency.

Use the security provider directory to assemble candidates and the ChainSecurity profile as a starting point for reviewing public audit evidence. Then verify incident-response availability separately. An audit relationship can help explain the codebase, but its existence does not establish an emergency service obligation.

Pre-incident readiness checklist

Practice the handoffs.

Exercise the response with a realistic failure, including a missing signer or an unavailable communication platform. Record where the team could not proceed and assign corrective work. The goal is an executable sequence whose authority and evidence survive pressure.

1. Maintain the deployment inventory, role map and dependency contacts alongside the security disclosure policy.
2. Test paging.
3. Prepare containment transactions and verify their effects on deposits and withdrawals. Notify affected integrators.
4. Keep evidence exports and a transaction chronology template available outside the primary production account.
5. Agree who can approve public statements, external engagement and reopening the affected service.
6. Close exercise findings with a repeatable check and a named owner. Revisit the plan when deployment authority or dependencies change.