If your business holds crypto, runs a trading product, accepts digital-asset payments or builds on smart contracts, a written blockchain security checklist is not paperwork — it is the difference between an incident you absorb and one that ends the company. The case for discipline is in the numbers: Chainalysis estimates $3.4 billion was stolen from crypto services in 2025 alone, with a single event — the $1.5 billion Bybit theft — accounting for nearly half of it. Read the post-mortems and a pattern jumps out: almost none of the big losses required breaking a blockchain. They required one hot wallet with too much in it, one signing screen nobody verified independently, one unaudited contract, one engineer who trusted a fake recruiter. Every item on the checklist below maps to a real, named failure. Work through it in order, assign an owner to each control, and re-run it after every material change to your system.
Why this checklist matters now
Three facts should frame your priorities. First, bridges are the most-exploited component in the industry: Chainalysis estimated roughly $2 billion stolen from cross-chain bridges across 13 hacks in 2022, about 69% of all crypto stolen that year — including $625 million from Ronin and $611 million from Poly Network. Second, the biggest single theft, Bybit in February 2025, defeated a multisignature cold wallet not by stealing keys but by compromising the signing interface, so controls that only protect keys are no longer sufficient. Third, the survivors of major incidents — Binance in 2019, Bybit in 2025 — survived because custody limits and reserve funds were in place before the attack. If you want the full breakdown of how these attacks work, read our companion analysis of how crypto exchanges get hacked first, then come back and implement the defences.
The blockchain security checklist: custody and key management
Everything else on this checklist is secondary to how you store keys and how much value a single compromise can reach.
- Keep at least 90% of funds in cold storage. Hot wallets should hold only what daily withdrawals require. When Binance was breached in 2019, its hot wallet held about 2% of its BTC — the loss was $40 million, painful but absorbable.
- Cap hot-wallet balances automatically. Set hard limits per wallet and per asset, with automatic sweeps back to cold storage and alerts when a balance drifts above its cap.
- Generate and store keys on hardware. Keys for custody wallets should be created on hardware security modules or hardware wallets, never typed into a cloud note, a spreadsheet or a developer’s laptop.
- Split keys with MPC or multisig. No single person or server should be able to move funds. Multi-party computation (MPC) splits one key into shares held in separate environments; multisig requires multiple independent signatures on-chain.
- Back up key material offline and geographically separated. Seed backups belong in tamper-evident storage in at least two locations, with a rehearsed recovery procedure — an untested backup is a hope, not a control.
- Allowlist withdrawal addresses. Custody systems should only send to pre-approved addresses, with any change to the list requiring a cooling-off period and a second approver.
Signing and approvals: the post-Bybit rules
Bybit’s signers did nothing careless by the standards of 2024 — they approved a transaction their trusted interface presented as routine. The interface was the compromised component. These controls exist so a lying screen cannot move money:
- Require independent payload verification. Every signer must confirm the destination address and amount on a second, independent device or tool that parses the raw transaction — never from the same web interface that created it.
- Ban blind signing by policy. If a signer cannot see exactly what a signature authorises, the signature does not happen. No exceptions for “routine” transfers; the Bybit transfer looked routine too.
- Use meaningful multisig thresholds with genuinely independent signers. Ronin’s five-of-nine failed because several keys sat inside one organisation’s reach. Signers should span teams, devices and locations.
- Add time delays to large movements. Transfers above a set value should queue for hours, not seconds, with an independent reviewer able to veto. Attackers optimise for speed; delay is a defence.
- Treat signing vendors as critical infrastructure. Audit the tools in your signing path, pin and verify their code where possible, and have a fallback signing method that does not depend on a single third-party front end.
Smart contracts and bridges
- Audit before launch and after every material change. Use an established audit firm, fix findings before deployment, and re-audit upgrades — Poly Network’s $611 million exploit was an access-control flaw in contract logic, exactly what audits exist to catch.
- Run a public bug bounty from day one. A standing bounty priced against the value the contract holds turns the research community into an early-warning system instead of a threat.
- Put upgrades behind timelocks and multisig. No single deployer key should be able to change contract logic instantly. A 24–72 hour timelock gives monitors time to spot a malicious or mistaken upgrade.
- Minimise bridge dependence. If you must use bridges, prefer designs with large, independent validator sets, set per-transaction and daily value limits, and add circuit breakers that pause transfers on abnormal volume. The BSC Token Hub exploit minted $570 million of BNB through one proof-verification bug; limits and breakers decide whether a bug is an incident or a catastrophe.
- Separate admin keys from operational keys. The key that can pause a contract should not be the key that can upgrade it, and neither should live on a hot system.
Monitoring, detection and people
Ronin’s theft went unnoticed for six days. Detection speed is a control, and so is the human layer attackers now target first — state-sponsored groups such as the Lazarus Group have repeatedly entered through fake job offers and recruiter impersonation aimed at engineers, including in the Ronin compromise. In our trading automation work, the same monitoring patterns apply to bots and APIs as to custody wallets.
- Alert on-chain, in real time. Monitor every custody address for unexpected transactions, balance anomalies and interactions with flagged or sanctioned addresses, with alerts that reach a human 24/7.
- Set withdrawal anomaly rules. Unusual size, unusual hour, new destination, rapid sequences — any of these should pause and escalate automatically.
- Train staff against social engineering specifically. Generic phishing training is not enough. Engineers and finance staff need to know the fake-recruiter playbook: unsolicited job offers, “coding tests” that install malware, and requests to run files outside the normal hiring process.
- Enforce hardware-key two-factor authentication everywhere. No SMS codes, no authenticator apps on personal phones for production access; phishing-resistant hardware keys for admin, cloud and signing-adjacent accounts.
- Segregate duties. The person who prepares a transaction should never be the only person who can approve it, and developers should not hold production withdrawal rights.
- Screen vendors like you screen code. Any third party in your transaction path — signing interfaces, wallet SDKs, price oracles — gets a security review, because the Bybit attackers entered through exactly such a vendor.
Incident response: decide before it happens
- Write the playbook now. Who can freeze withdrawals, who calls the lawyers, who drafts the public statement, which partner exchanges and bridge operators get address-flagging requests in the first hour.
- Rehearse it. Run a tabletop exercise at least twice a year, including the scenario where the signing interface itself is lying to you.
- Hold a recovery reserve or insurance. Binance’s SAFU fund and Bybit’s reserves are why their users were made whole. Decide in advance how your customers or treasury would be covered.
- Preserve evidence and publish a post-mortem. Logs, device images and a transparent timeline protect you legally and are the industry’s main way of learning; both Binance and Bybit published detailed accounts.
Common mistakes we see
The failures we are most often hired to untangle are mundane: one admin key that can do everything, kept in a password manager shared by the whole team; a contract upgraded without a re-audit because the change “looked small”; signers approving from the same screen that built the transaction; a hot wallet quietly growing to 30% of funds because nobody owned the cap; and monitoring that sends alerts to an inbox nobody reads at night. None of these require an attacker of state-sponsored skill to exploit — they require only patience. That is precisely why a checklist with named owners beats a policy document: each line above either has someone’s name next to it, or it does not exist.
From our experience
Nine years and 300+ projects have taught us that security work fails when it is treated as a launch milestone instead of an operating habit. The clients who stay safe re-run this checklist quarterly, after every vendor change and after every incident anywhere in the industry — the Bybit post-mortem alone should have triggered a signing-policy review in every treasury team in crypto. Start where the money is: custody limits and independent signing verification close the two paths behind the largest losses in history, and both can be implemented in weeks, not quarters. If you are building or buying systems that move value — exchanges, payment products, trading bots, token platforms — get the architecture reviewed while it is still cheap to change. That is most of what our platform engineering security reviews cover, and it is far less expensive than a post-mortem.
Frequently asked questions
What percentage of funds should a business keep in cold storage?
Serious exchanges typically keep 90% or more of assets offline; Binance’s hot wallet held about 2% of its BTC when it was breached in 2019, which is why a $40 million theft was absorbable. Set your hot balance to genuine operational need — and to a loss figure you have consciously agreed you can survive.
Is multisig enough to protect a treasury on its own?
No. Bybit’s wallet was multisignature; the attack compromised what signers saw, not their keys. Multisig must be paired with independent verification of the raw transaction on a separate device, genuinely independent signers, and time delays on large transfers.
How often should smart contracts be audited?
Before launch, after every material code change or upgrade, and continuously through a public bug bounty. An audit is a snapshot of one version of the code; the moment the code changes, the snapshot expires.
What is MPC and how does it differ from multisig?
With multisig, several separate keys each sign a transaction and the signatures are checked on-chain. With multi-party computation (MPC), one private key is split into mathematical shares held in different environments; no complete key ever exists in one place, and the shares jointly produce a single signature. Both remove single points of failure; MPC is chain-agnostic and keeps the arrangement private, multisig is transparent and natively enforced by the protocol.
What should a business do in the first hour after detecting a hack?
Freeze withdrawals and pause affected contracts, revoke compromised keys and sessions, preserve logs and device evidence, alert partner exchanges and bridge operators with the attacker’s addresses so funds can be flagged, and communicate honestly with users. Every one of those steps is faster and calmer if it was written into a playbook beforehand.
Want this checklist applied to your own platform, treasury or product before an attacker tests it for you? Book a security review with our team and we will work through it line by line against your architecture.