Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A useful blockchain incident response plan is a rehearsed operating system for making safe decisions when contracts, keys, infrastructure, governance, or users are under attack. Build it around the lifecycle in NIST SP 800-61 Rev. 3 (published April 2025), then adapt every step to your on-chain permissions, immutable code, transaction evidence, front end, wallets, bridges, and governance. Name decision-makers, prepare scenario playbooks, preserve evidence before changing state, separate containment from remediation, and practice the procedures at least twice a year.
What a blockchain incident response plan must accomplish
NIST SP 800-61 Rev. 3 is the current revision of NIST’s incident-response guidance. It is intended to improve preparation, reduce the number and impact of incidents, and make detection, response, and recovery more efficient and effective. For a blockchain project, that general lifecycle must be extended to systems that traditional enterprise plans often miss: deployed contracts and proxies, privileged roles, signing devices, timelocks, governance, bridges, RPC providers, indexers, deployment pipelines, domains, official social accounts, and user wallets.
The plan is not a document you write once and file away. It is a maintained capability with named owners, reachable copies, tested procedures, and a record of decisions. The operational objective is to make the first hour less improvised while preserving the ability to investigate, protect users, and recover without creating a second incident.
Define the systems and threat scenarios before writing procedures
Start with an inventory that shows what can be attacked, what depends on it, and who can authorize a response. NIST IR 8475 describes Web3 attacks against contracts, protocols, infrastructure, and software, while also treating phishing, fraud, and malicious application approvals as user-facing risks. The OWASP Smart Contract Security Handbook adds wallet drainers, compromised endpoints, insider threats, and incidents involving decentralized ownership.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Build a dependency and authority inventory
- On-chain code: list every contract, proxy, implementation, upgrade administrator, pause mechanism, role administrator, oracle, fee switch, mint or burn authority, and deployed chain address.
- Cross-chain components: document bridges, message relayers, wrapped assets, canonical-versus-minted token assumptions, and emergency contacts.
- Governance: record governors, delegates, quorum rules, voting delays, timelocks, cancellation rights, emergency councils, and the exact transactions each role can execute.
- Treasury and signing: identify multisig owners, backup signers, custodians, hardware devices, recovery procedures, spending limits, and geographic or organizational separation.
- Infrastructure: map RPC endpoints, nodes, indexers, monitoring, cloud accounts, CI/CD, package registries, secrets stores, databases, analytics, and alert delivery.
- User-facing services: include the web application, APIs, mobile clients, DNS, certificates, domains, documentation, support queues, email, and official social accounts.
- Evidence sources: specify where chain data, full transaction traces, application logs, endpoint telemetry, cloud audit logs, and governance events can be retrieved.
For every item, assign a primary owner and a backup. Record dependencies and the action that owner can authorize. A person who can investigate a contract may not be able to pause it, cancel a timelock, move treasury funds, or publish an announcement.
Prepare a playbook for each material incident class
| Scenario | Typical trigger | Initial playbook focus |
|---|---|---|
| Live smart-contract or protocol exploit | Unauthorized fund movement, abnormal state changes, or a confirmed exploit trace | Independent confirmation, evidence capture, pause or other containment, fund-flow tracing |
| Compromised signer, administrator, or governance key | Unexpected privileged transaction, leaked key, or suspicious queued action | Revoke or rotate authority, cancel timelock actions, review signer devices and approvals |
| Malicious front end, domain compromise, or wallet drainer | Users report altered URLs, malicious approvals, or drained wallets | Take the affected interface offline, publish verified warnings, provide a reviewed revocation path |
| Compromised employee or contributor endpoint | Malware, token theft, suspicious sessions, or endpoint detection | Isolate the device, invalidate credentials, preserve forensic images and logs |
| Infrastructure or supply-chain compromise | Unexpected build artifact, dependency change, cloud activity, or altered monitoring | Freeze releases, compare known-good artifacts, rotate secrets, validate every dependency |
| Insider or decentralized-governance incident | Abuse of legitimate access, collusion, or a disputed emergency decision | Use independent approvers, preserve governance records, follow conflict and escalation rules |
OWASP’s playbook selection guidance maps confirmed unauthorized contract fund movement to a contract or protocol hack response, multiple drained-wallet reports to a wallet-drainer or phishing response, employee-device indicators to endpoint compromise, and distributed ownership to a decentralized response. Your plan should make those routing decisions explicit rather than leaving responders to debate which procedure applies.
Assign decision authority before an emergency
Publish a roster with primary and backup contacts, secure contact methods, time-zone coverage, and the authority attached to each role. The incident commander coordinates the response and resolves conflicting recommendations. That person should be empowered to activate the plan and make the pause-or-no-pause decision, but should not silently acquire powers that belong to governance, a multisig, a custodian, or legal counsel.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Core response roles
- Incident commander: sets priorities, assigns owners, records decisions, and escalates unresolved conflicts.
- Smart-contract or protocol engineer: reproduces the suspected exploit in a controlled environment, assesses affected code and permissions, and prepares authorized mitigation transactions.
- On-chain forensics lead: captures transaction context, traces fund flows, identifies related addresses, and preserves reproducible analysis.
- Infrastructure and security lead: handles cloud, endpoint, deployment, identity, monitoring, and secret-management containment.
- Communications lead: prepares user, partner, governance, and media updates through verified channels.
- Legal counsel: advises on privilege, law-enforcement contact, contracts, sanctions, privacy, and jurisdiction-specific notification duties.
- Governance, multisig, custodian, exchange, bridge, issuer, and platform contacts: supply the approvals or operational assistance that the project itself cannot provide.
- Scribe: maintains a contemporaneous timeline, including wall-clock time, block number, action, decision, owner, and supporting evidence.
Write down who may pause a contract, revoke a role, cancel a queued timelock, rotate a key, move funds, migrate users, take a domain offline, or speak publicly. Include the required number of approvals and the backup route if a signer is unavailable. Never assume that one responder can safely perform every function.
Make the runbooks short, reachable, and testable
Each playbook should be action-first and usable by a stressed responder who has not opened it for months. Keep an offline or out-of-band copy that does not depend on the primary identity provider, cloud account, domain, or communications platform that may be compromised. Protect that copy from unauthorized edits, but ensure the incident team can retrieve it without the normal production systems.
Required fields for every playbook
- Trigger, confidence threshold, and examples of false positives.
- Incident commander and immediately paged roles.
- First safe actions and actions that must not be taken yet.
- Decision authority, approval count, and emergency contact path.
- Evidence to preserve, including chain and block context.
- Containment options, expected effects, reversibility, and risks.
- User, partner, governance, and regulator or law-enforcement communication paths.
- Recovery criteria, staged reopening steps, and enhanced monitoring.
- Escalation contacts and a place to record the live timeline.
- Post-incident review tasks, owners, and deadlines.
Assign an owner, version number, and review date to each runbook. Exercise the procedures at least twice a year and after a material architecture, chain, bridge, governance, or signing change. A tabletop should test not only technical choices but also whether the right people can be reached and whether the required approvals are actually possible under time pressure.
Rank #2
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
Detect and triage without overreacting
Connect every important alert to a person who can act. OWASP describes a detection chain of sources, collection, analysis, and alerting. In a blockchain project, sources include chain state and event subscriptions, application and contract logs, infrastructure metrics, deployment records, governance activity, endpoint telemetry, and human reports from users or partners.
Use a triage gate
- Classify the signal: suspected exploit, key compromise, front-end or phishing event, endpoint event, infrastructure event, insider event, or benign anomaly.
- Check whether the observation is reproducible and whether it affects real assets, permissions, users, or availability.
- Confirm a suspected exploit against a second independent source before taking disruptive action. Examples include an independent node or explorer view, a controlled simulation, a separate monitoring system, or corroborating user reports.
- Set a confidence level and assign an owner for the next decision. Do not let noisy alerts automatically trigger a pause that could itself cause harm.
- Open the full playbook when the threshold is met, preserving the initial alert and the reasoning behind the decision.
Record what was known at each decision point. This prevents hindsight from rewriting why a pause was or was not taken and gives engineers, counsel, and governance a common factual record.
How do you respond to a smart contract exploit?
Adapt the following sequence to the chain and architecture. The order is a practical playbook pattern, not a universal service-level guarantee. OWASP’s sample time markers are sequence aids rather than validated response-performance statistics.
- Verify independently. Reproduce the behavior in a safe environment or confirm it through an independent chain, trace, monitoring source, or trusted analyst. Separate an actual exploit from an indexing error, delayed finality, or expected arbitrage.
- Activate the response. Page the incident commander, contract engineer, forensic lead, infrastructure lead, communications lead, and counsel. Open the incident record and assign the scribe.
- Preserve volatile context. Capture the exploit transaction, block, full trace, affected contract state, relevant events, pending or mempool activity where available, code and configuration versions, and the alert that triggered the response. Do this before state-changing actions remove useful context.
- Assess containment authority and safety. Determine whether a pause, role revocation, timelock cancellation, front-end shutdown, bridge restriction, or other control exists, is authorized, and will reduce net harm. A pause can strand users, interfere with liquidations, or create a wider outage.
- Model the blast radius. Identify affected functions, assets, chains, pools, oracles, proxy implementations, privileged accounts, and users. Check whether the attacker can upgrade code, mint assets, drain approvals, or pivot through a dependency.
- Trace assets and coordinate externally. Follow stolen or at-risk funds and, when facts and counsel support it, contact exchanges, bridges, issuers, custodians, and other platforms. Preserve addresses and transaction relationships without claiming that recovery is certain.
- Communicate through verified channels. Publish only confirmed facts, immediate user actions, links that have been checked, and the location of future updates. Warn users about impersonators, fake support, and recovery offers.
- Maintain the timeline. Log wall-clock and block references, observations, decisions, transaction hashes, approvers, communications, and unresolved questions as the incident evolves.
How do we pause a protocol safely during an exploit?
First establish whether the deployed design permits a pause and who can invoke it. Possible controls include a contract pause, revocation of a compromised role, cancellation of a queued timelock action, disabling a front end or bridge route, or an authorized rescue transaction. The correct choice depends on permissions, governance, immutability, attacker access, chain behavior, and the users who could be harmed by stopping activity.
| Control decision | Questions to answer before execution |
|---|---|
| Pause or freeze | Will it stop the exploit, what functions remain available, who is authorized, and can users still exit safely? |
| Revoke or rotate a role | Is the attacker still able to act, are other roles dependent on it, and have replacement credentials been independently verified? |
| Cancel a timelock action | Is cancellation permitted before execution, who can call it, and could the cancellation transaction itself reveal a new attack path? |
| Route a private transaction | Would reducing public exposure help, and has the chain-specific route been assessed for reliability, authorization, and evidence impact? |
| Take a front end offline | Can a static warning page replace it, and are DNS, certificates, deployment credentials, and official update channels also secure? |
| Migrate or apply a compensating control | Is the code immutable or otherwise unpatchable, how will balances be reconciled, and what prevents the same flaw from returning? |
Have the engineer simulate the proposed transaction, verify calldata and destination addresses through an independent reviewer, and document expected state changes. Do not treat a pause as remediation. It may stop immediate activity while the vulnerable code, compromised key, or malicious interface remains unresolved.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhat evidence should we preserve during a crypto hack?
Evidence collection must be coordinated with containment so the response does not overwrite the facts needed to understand it. Preserve originals where possible, record acquisition time and source, and hash exported files when your forensic process supports it.
Rank #3
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
- Block number, timestamp, transaction hash, raw transaction, logs, internal calls, traces, and affected contract state.
- Pending or mempool transactions and nonce information, when the chain and infrastructure make them available.
- Deployed bytecode, verified source, compiler settings, proxy and implementation addresses, roles, owners, and configuration at the time of the event.
- Node, RPC, indexer, application, web-server, cloud, CI/CD, identity, and endpoint logs.
- Monitoring alerts, screenshots, user reports, support tickets, and the exact URLs or messages users received.
- Governance proposals, votes, timelock records, multisig approvals, signer attestations, and communications that authorized actions.
- Every response transaction, including who prepared, reviewed, signed, broadcast, and confirmed it.
Use a separate scribe or evidence custodian so engineers can work without losing the timeline. Record chain reorganizations, finality assumptions, time-zone conversions, and any missing data. If a state-changing action must happen immediately, capture the best available context first and note exactly what could not be preserved.
Containment, eradication, and recovery are separate decisions
Containment limits ongoing harm. Eradication removes the vulnerability, compromised authority, malicious artifact, or unsafe dependency. Recovery restores service under conditions that reduce recurrence. Treating these as one decision leads teams to reopen after a temporary pause or to delay an urgent containment action while waiting for a complete fix.
When code is immutable
An immutable contract cannot receive a conventional patch. The project may need a migration, a new deployment with a carefully reconciled state, a compensating control in dependent systems, a front-end restriction, or a governance-approved change in surrounding components. Explain which balances, permissions, and user actions are covered by the replacement and how users can verify the official destination.
Validate before reopening
- Reproduce the exploit and demonstrate that the mitigation blocks it.
- Review the change independently, including permissions, calldata, upgrade paths, and accounting.
- Confirm that signers, administrators, domains, build systems, dependencies, and monitoring are clean.
- Define recovery criteria and a rollback or stop condition before execution.
- Reopen in stages where feasible, with enhanced alerts and a named person watching each critical function.
- Continue monitoring for recurrence, copycat activity, delayed fund movement, and user-side phishing.
Do not promise that stolen assets will be recovered. Voluntary returns have occurred in some incidents, but they are exceptional and not a dependable recovery method.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should a Web3 project notify users after a wallet drainer or phishing incident?
Use a verified domain and official accounts whose credentials have been checked. State what is confirmed, which products or addresses are affected, what users should do immediately, which actions and links to avoid, and where the next update will appear. Warn that attackers may impersonate the project, offer fake recovery services, or send direct messages pretending to be support.
For malicious approvals or drainer reports, provide only a reviewed and trusted revocation path. Do not ask users to paste seed phrases, export private keys, install unverified software, or execute unfamiliar raw transactions during an active incident. If users must move assets, publish the destination and procedure through a channel that has been independently verified and protected from the same compromise.
Rank #4
- FIDO2 & Passkey Ready: Business-ready and FIDO2 L1 certified. This key is supported by major management suites and is ideal for both individual and enterprise deployment. Works seamlessly with Gmail, Facebook, GitHub, Dropbox, Coinbase, and more.
- Dedicated Manager App: Use the Thetis Manager App for the initial hardware PIN setup. Setting the PIN on the device first ensures a smooth registration process. Once the PIN is configured, you can begin registering the key across your favorite FIDO2-compatible online services.
- USB TYPE C Connectivity & DONGLE Design: Designed for PCs, Macs, laptops, iPhones, and Android devices that utilize a USB-C port. Plug and stay, or carry it on a keychain. (Item Size: 0.73 x 0.60 x 0.30 inches)
- Enhanced MFA (FIDO2 & TOTP/HOTP): Strengthen your security with flexible options. Use the Manager App to access TOTP/HOTP features for accounts that do not yet support FIDO2.
- Check FIDO2 compatibility before purchase - Known limitations: ID Austria is not supported (requires FIDO2 Level 2). Windows Hello login only works with Windows Enterprise editions that support Entra ID. NFC functionality is not supported.
Maintain separate messages for users, governance participants, partners, employees, and service providers. Communications should not disclose unverified attacker claims, expose investigation-sensitive addresses prematurely, or imply that a pause guarantees safety. Update the incident page when facts change, and preserve each version for the timeline.
Recommended Free Tools
Legal, regulatory, and external escalation
Notification duties depend on jurisdiction, organizational structure, affected users, data involved, contractual commitments, and the nature of the incident. There is no universal deadline established for every blockchain project. Counsel should maintain a jurisdiction-specific decision tree and contact list covering regulators, law enforcement, insurers, custodians, exchanges, bridges, and major infrastructure providers.
Route legal questions through counsel, preserve privilege where appropriate, and distinguish confirmed facts from working hypotheses. Communications, governance votes, and emergency transactions may later be examined by users, counterparties, auditors, or authorities, so keep approvals and rationale complete without speculating about liability.
Protect the accounts that control the response
Use hardware-backed multifactor authentication, including a FIDO2 security key where practical, for official accounts and administrative systems. This reduces account-takeover risk but does not solve a contract exploit, compromised signing authority, or poor incident coordination.
- Separate daily-use identities from deployment, treasury, governance, and emergency identities.
- Require independent approval for high-impact transactions and verify signer devices regularly.
- Keep emergency contacts and recovery codes out of the same account or password vault that an attacker could disable.
- Rotate credentials after endpoint, identity, cloud, CI/CD, or session compromise, and investigate how the original access was obtained.
- Review domain, DNS, certificate, social-account, and support-channel permissions as part of the incident, not only the contract state.
Close the loop and improve the plan
After containment and recovery, hold a structured lessons-learned review while evidence and decisions are still fresh. Identify the initiating condition, missed signals, authority bottlenecks, unsafe assumptions, user harm, communication gaps, and controls that worked. Convert findings into owners and due dates rather than a narrative that sits unused.
- Update detections, thresholds, dashboards, and independent confirmation sources.
- Revise contract, key, governance, infrastructure, and front-end controls.
- Change the playbook where responders hesitated, lacked authority, or could not retrieve evidence.
- Reconcile balances, affected addresses, user support cases, and partner actions.
- Rehearse the changed procedure and record whether the new control actually works.
A mature plan makes the next incident less dependent on heroics. It tells people who decides, what to preserve, which action is safe enough to take now, how to protect users from follow-on scams, and what evidence is required before service returns.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
