01 — Hack / Smart-Contract Exploit

Trigger: Funds have been moved out of contracts, hot wallets, custody, or user accounts without authorization. Includes flash-loan attacks, oracle manipulation, key compromise, signing-process compromise, bridge exploits.

First 30 minutes

The first 30 minutes determine whether this is a recoverable event or a wind-down event. Order matters:

1. Confirm the hack is real. Engineering team verifies on-chain movement. False alarms happen — confirm before public statement.
2. Open the hotline to Jukka. “Hack confirmed. Approximate scope: [€X]. Funds affected: [user / treasury / both]. Containment status: [in progress / done].”
3. Stop the bleed. Pause affected contracts if pausable. Pause withdrawals if user funds at risk. This is engineering’s call, not marketing’s — but marketing must know within 5 minutes of the action.
4. Time-stamp the on-chain event. First transaction hash, address, exact UTC timestamp. This anchors every later statement.
5. Convene the war room. Per the README order-of-operations.
6. Brief the support team. They will be flooded within 30 minutes once the on-chain movement is detected by community watchers. Give them a one-line script: “We are aware and investigating. We will update within X hours.” Nothing more.
7. Notify counsel. Counsel needs to be in the war room. If a regulator-letter follow-up is likely (almost always for licensed entities), counsel decides what is and isn’t disclosed externally.
8. Decide who the public spokesperson is. One person. Usually founder/CEO. Not the engineering lead.

Do not publish externally yet.

Holding statement template

Ship within 4 hours of trigger. Aim for 60–90 words.

[TIMESTAMP — UTC]
      
      [COMPANY] is aware of unauthorized activity affecting [SPECIFIC AFFECTED COMPONENT — e.g.,
      "the [PRODUCT] vault contract", "a hot wallet"] at approximately [APPROX UTC TIMESTAMP OF EVENT].
      
      We have [PAUSED / RESTRICTED / TAKEN OFFLINE] [SPECIFIC THING] as a precaution.
      [CUSTODIED USER FUNDS / TREASURY / OTHER] [ARE / ARE NOT] affected based on initial review.
      
      We are working with [SECURITY FIRM IF ENGAGED, e.g., "external security partners"] to
      [INVESTIGATE / CONTAIN / RECOVER]. We will publish a fuller update at [SPECIFIC TIME WITHIN 12-24h, NOT VAGUE "SHORTLY"].
      
      — [Name, Role]
      

What this template deliberately doesn’t say: - The total amount lost. You don’t know yet, and any number you publish in the first 4 hours will be wrong. - The cause. You don’t know yet. - Whether users will be made whole. You can’t promise this in hour 1. - An ETA for resolution. Vague timelines erode trust faster than no timeline.

Stakeholder cascade

In strict order. Each step starts when the previous step’s notification has been acknowledged, not when it has been sent.

If the press calls before step 6, you skipped a step. Apologize internally, not externally.

Do

• Stay narrow on facts. Only publish what’s verified.
• Time-stamp every public statement. Ambiguity about when you knew what is litigation fuel.
• Coordinate with counsel before every external comm. Every word becomes evidence.
• Update on a schedule. Hourly for the first 6 hours, every 4 hours for the next 24, daily thereafter. Predictability is reassuring; silence is panic-inducing.
• Keep the support team supplied with current talking points. If they’re improvising, you’ve lost the narrative.

Don’t

• Don’t speculate on cause publicly. “Our security partners are investigating” is enough.
• Don’t promise restitution in hour one. You cannot guarantee any specific outcome that early.
• Don’t blame third parties before forensics are complete. Even if you’re right, it reads as deflection.
• Don’t go silent. Every hour without an update doubles the speculation volume.
• Don’t let the founder tweet alone. Run every founder X post through comms first.

Variants

Funds recovered before public disclosure. Some hacks are reversed via white-hat negotiation, blockchain reorg, or successful contract pause. If recovery is complete before you’ve gone public, you can sometimes publish a single comprehensive statement instead of a holding statement. Counsel decides.

Hack on a partner, not directly on you. When a counterparty (bridge, custody provider, oracle) is the actual exploit target, your statement frames “funds bridged via [partner] are affected; our directly-held funds and contracts are not”. Cross-reference 06 — Partner Blow-Up.

Insider compromise suspected. Do not publicly indicate this until forensics confirms. Internally, halt all access, rotate credentials, separate the suspect-individual from the war room.

No funds lost, vulnerability disclosed by white-hat. Different playbook entirely — frame as “responsible disclosure,” credit the researcher, ship the patch. Often a brand-positive event.

24-hour follow-up

Once the immediate window is closed:

• Publish a fuller post-mortem within 7 days. Not 14. Not 30. Trust decays at half-life around day 5.
• The post-mortem is technical: timeline, root cause, on-chain evidence, remediation, what’s changed. Counsel reviews; comms reviews.
• If users were made whole, document it specifically. If not, document the path to making them whole or the reason that’s not happening.
• Brief the team on what was learned. Update internal incident-response runbooks.
• Submit any required regulatory follow-up disclosure (varies by jurisdiction).

Cross-references: 02 — Depeg, 06 — Partner Blow-Up, 08 — Withdrawal Pause.