DeFi protocols lost $1.19 billion across 234 recorded incidents between January and October 2026, according to the public incident ledger. Two of those incidents account for just under half of it. Drift lost $295 million on April 1 and Kelp lost $293 million on April 18, and in both the contracts behaved as configured.

That split describes the year. Contract and economic logic bugs are still the most common failure. Token and share accounting, oracle manipulation and protocol logic cover 46.6% of the 234 entries and 22.3% of losses. Access control and bridge failures run the other way, at 26.5% of incidents and 57.8% of losses. The larger sums moved through signer approvals, key custody and deployment settings.

So when we review a system at Sherlock, we ask how much value can be exposed before a separate control takes effect. Three controls answer that. A code audit tests what the system enforces as deployed. Operational security (OpSec) governs who can change that behavior. Managed detection and response (MDR) determines how much is still exposed once something goes wrong.

Figure 1. January–October 2026 DeFi protocol entries from the public incident ledger. Shares are based on 234 incidents and $1.19 billion in recorded losses. Exchanges are outside this cut, including the $6.36 billion Binance entry from October 29, which we covered separately.

Code audits test the system as deployed

Code-level failures were the most frequent attack class in 2026 and usually the cheapest. The median recorded loss across DeFi protocol incidents was $410,000. Of the 221 incidents with a loss figure, 145 came in under $1 million.

The expensive failures sat at the edge of the usual audit scope. Tectonic lost $124.5 million on August 30 after an attacker inflated the price of its thinly traded governance token and borrowed against it across nine lending markets. Halborn's analysis traces the loss to an illiquid token accepted as collateral. Kelp's bridge released 116,500 rsETH on a forged message because its route required a single verifier to attest to it. Both exposures came from values set at deployment: a collateral listing and a verifier count.

The standard is to audit the deployment along with the repository. In our smart contract audit process, we pin the code version and define the behavior in scope. The review should also record the production settings and dependencies the result relies on. That means collateral parameters, price sources, rate limits and third-party verifiers, tested with the values the team intends to ship.

That record matters after launch. An upgrade, a new market or a configuration change can alter how much value the protocol exposes. The team should know which changes would invalidate the original results and require another review.

OpSec limits who can change the rules

The largest crypto theft on record was an OpSec failure. On October 29, attackers took about $6.3 billion from Binance hot wallets, and Binance says it found no evidence that a private key leaked. Its account starts with a fake job interview that put malware on an engineer's laptop. From there the attackers reached a service container that could submit withdrawals, and the signing service signed what it was sent. Most of the funds left within about 20 minutes of the first transfer.

Figure 2. The Binance breach of October 29, 2026, based on Binance's account of the incident. Times are UTC.

Binance is an exchange, so it sits outside the DeFi figures above, and we covered it in our write-up of the breach. The route is one DeFi teams should recognize: trusted access to a system that signs.

The largest DeFi loss of the year also came through legitimate signing authority. Drift's attackers got Security Council members to pre-sign transactions, then used them to take admin control of a 2-of-5 multisig with a zero-second timelock, according to Hypernative's reconstruction. In the same sequence they listed a worthless token as collateral and raised withdrawal limits by 20x or more across five assets. The limits worked as coded. The attacker had become the account allowed to change them.

Drift later tied the approach to an operation staged over roughly six months, beginning with people who posed as a trading firm at a conference. Signers were the target long before any transaction reached the chain.

Key compromise as its own category adds 23 incidents and $148 million. Step Finance lost $40 million through compromised executive devices. Humanity lost $32 million through one foundation member's key. Wasabi lost $5.5 million through a deployer account that held the sole admin role with no multisig or timelock.

Figure 3. The five largest recorded loss estimates among incidents classified as key compromise in the same dataset.

The standard starts with a map of every account that can raise a limit, list an asset, upgrade a contract or grant those powers to someone else. A multisig signing threshold tells you how many owners must approve a transaction. The strength of that approval depends on whether the signers share a device, administrator or recovery process. Those dependencies are part of the authority review we describe in our Web3 OpSec guide.

Then put an enforced delay on any change that increases exposure, so the team has time to investigate before it takes effect. Emergency containment has the opposite timing requirement. Give the emergency role a narrow set of actions, such as pausing or lowering limits, and make sure it stays reachable if the usual approval route is unavailable.

MDR measures time to verified containment

The large drains of 2026 ran in minutes. Tectonic's nine markets were emptied in roughly 11. Hypernative puts Drift's admin takeover, reconfiguration and first withdrawals inside about 12.

Kelp shows what a response is worth once the first transfer has landed. Its emergency multisig paused core contracts 46 minutes after the drain. Two follow-up attempts, each for 40,000 rsETH worth roughly $100 million, reverted against the pause. On Cronos, validators halted the chain about an hour and 44 minutes after the Tectonic exploit was detected, and the rollback reversed about $111 million. Most protocols have no chain halt to fall back on.

Where funds can leave before an operator can act, the protection for that first transfer has to be in the code or the approval policy. MDR covers what happens next. An alert that a limit changed is the start of a decision. The investigator needs to establish whether the change was expected, how much value is still exposed and who can act.

In our institutional monitoring and response work, we investigate alerts and coordinate approved action with the institution's incident lead. Containment counts once the intended restrictions are confirmed live on every affected deployment.

The Security Alliance incident response checklist calls for timed drills. Measure detection, authorization and containment separately. Then compare the total with how fast your largest pool can drain under its current limits.

Where to bolster first

Most teams reading this have had their code audited. Fewer have had the deployed configuration, the signer set and the response path tested to the same standard, and that is where the 2026 losses concentrated.

Before launch, rehearse a failure that could expose a large share of user funds. Use the configuration the team intends to ship and assume one of the usual response dependencies is unavailable. Ask reviewers to show where the limit still holds, operators to show who can change it and responders to show how they'd verify containment.

If the limit can be raised and used before anyone can intervene, constrain who can change it and how quickly it can take effect.

Contact our team to run a loss scenario and see how your deployed configuration, signer controls, and response plan hold up.

‍