Signer compromise: why clean audits don't stop key hacks

Drift Protocol had two audits. Trail of Bits looked at it in 2022. Another firm reviewed it in February 2026, weeks before the incident. Both cleared the code. On 1 April 2026, an attacker drained roughly $285 million from it anyway, more than half the protocol's total value locked, in about twelve minutes.

No reentrancy. No integer overflow. No missing access modifier in a function nobody noticed. The Solana programs did exactly what they were written to do. The attacker just got the keys, and the keys were never in scope for either audit.

This is the uncomfortable part of the job that the industry has been slow to say out loud: a clean audit report covers the code, and the code is no longer where the money is being lost. We sell smart contract audits. We think they are necessary. We also think any auditor who lets a client walk away believing a passing report protects them from what happened to Drift is doing them a disservice. So this post is about the layer the report doesn't cover, what the data actually says about it, and what we would look at if you handed us a Security Council instead of a repository.

Start with the numbers, because the whole argument rests on them and they are easy to get wrong.

Three independent datasets covering 2025 and early 2026 disagree on the exact magnitude but agree completely on the direction. TRM Labs, in its 2026 Crypto Crime Report, attributes approximately $2.2 billion, or 76% of 2025 hack losses across 45 incidents, to infrastructure attacks: compromised private keys and seed phrases, wallet infrastructure, privileged access, and front-ends. Code exploits, by contrast, accounted for about $350 million, or 12.1%. Hacken's full-year 2025 report draws the category line differently and lands in a similar place: access control and broader operational failures accounted for around $2.12 billion, roughly 54% of all 2025 losses, against about $512 million from smart contract vulnerabilities. Hacken's TRUST report frames the same year as access control near 58%, phishing and social engineering at 21%, and smart contract bugs around 10%.

The framing TRM uses is the one worth internalizing: adversaries have moved up the stack, targeting operational infrastructure, keys, wallets, and control planes, rather than contract code. That is the whole thesis in one line. The high-return target is no longer a novel logic error. It is a signer.

Two honest caveats, because an auditor states them rather than hides them.

First, the category boundaries differ. TRM's "infrastructure" bucket is wider than Hacken's "access control," which is why one says 76% and the other says 54%. They are not in conflict. Both put operational vectors as the clear majority of dollars and code as the minority.

Second, these totals are heavily skewed by single events. The February 2025 Bybit breach alone was about $1.46 billion, roughly half of TRM's entire 2025 hack total. TRM notes that even excluding Bybit, 2025 losses would still have been around $1.4 billion, so the thesis does not depend on one outlier, but the exact headline percentage does move if you remove the largest incident. And by raw incident count, code exploits were actually the most frequent category. TRM counted 52 code-exploit incidents against 45 infrastructure incidents. The shift is in severity per incident, not in how often each happens. Code bugs are common and mostly small. Operational compromises are rarer and catastrophic.

That distinction matters for how you spend a security budget. If you only audit code, you are buying down the frequent-but-small risk and leaving the rare-but-fatal one untouched. The numbers say the rare-but-fatal one is where the money goes. (We walk through the year's biggest incidents in our 2025 DeFi hacks lessons breakdown.)

Drift is the cleanest recent demonstration, so it is worth walking through properly. None of the following is a smart contract finding.

The setup was social, and it was patient. According to Drift's own post-incident account, corroborated by TRM and Chainalysis, attackers spent months posing as a quantitative trading firm. They built trust with Drift contributors through Telegram, working sessions, and in-person meetings, onboarding a vault to look like a real counterparty. This is the part no Slither rule catches. The attack surface was a relationship.

The mechanism was a legitimate Solana feature. On a normal Solana transaction, a recent blockhash acts as a freshness stamp and expires after about 60 to 90 seconds; if the transaction is not submitted in that window it becomes invalid. Durable nonces exist to override that: they replace the expiring blockhash with a fixed on-chain nonce that keeps a signed transaction valid indefinitely until someone uses it. Useful for legitimate offline or scheduled signing. Also a way to decouple the moment of signing from the moment of execution. On 23 March 2026 several durable-nonce accounts were created, some tied to legitimate Security Council members and some attacker-controlled. The signers approved transactions that looked routine. The malicious payload sat dormant, pre-signed, waiting.

Then the configuration change that turned a compromise into a catastrophe. On 26 March, Drift migrated its Security Council to a new 2-of-5 threshold with zero timelock, eliminating the delay that would have allowed detection and intervention. The attacker adapted to the migration and by 30 March had re-obtained the required two-of-five approvals under the new configuration.

The drain itself was almost an afterthought. The attacker had already manufactured a fake asset. CarbonVote Token: 750 million units minted, a few thousand dollars of seeded Raydium liquidity, wash-traded to a price near $1, and a controlled oracle feeding that artificial price so Drift's oracles treated it as real. (Worth noting because secondary summaries got this wrong: the seeded liquidity was on the order of $500, not a million-dollar deposit.) On 1 April, after a legitimate test withdrawal, the attacker submitted the pre-signed durable-nonce transactions, two transactions four slots apart, enough to create and approve a malicious admin transfer and then execute it, taking full control of protocol-level permissions in minutes. With control, they listed CVT as collateral, raised withdrawal limits, deposited inflated CVT, and ran 31 withdrawals in roughly 12 minutes, draining real assets including USDC and JLP, then bridged to Ethereum through Circle's CCTP.

Take the multisig apart and every one of the "multi" guarantees had quietly failed. The threshold was reachable with two deceived signers. Pre-signing meant the signature and the execution were separated in time, so review at signing time told you nothing about what would execute. The zero timelock removed the only window in which anyone could have noticed and intervened. And the social engineering defeated the human layer that the whole scheme depends on. The contract enforced exactly the rule it was asked to enforce: two of five approved, so execute. The rule was the problem.

It would be convenient to file Drift under "durable nonces, a Solana thing." It is not. The same shape recurs across chains and across years, and in nearly all of it the contract code was sound.

Bybit, February 2025, about $1.46 billion, the largest on record. Worth being precise about what failed. According to NCC Group's analysis, calling it a "Bybit hack" is slightly misleading: the compromise was upstream, in the signing interface, not inside Bybit's own systems. The cold wallet used a 2-of-3 Safe multisig; the UI showed a legitimate destination, the URL tied back to Safe, but a blind-signing flaw meant the hardware wallets displayed only a hash, masking a change that handed the attackers control of the wallet's contract. Safe's contracts are formally verified and were not the failure. The keys were not stolen. The signers were misled.

Ronin, 2022, $620 million: five of nine validator keys obtained through social engineering and device compromise of Sky Mavis staff. A high threshold did not help, because the attacker simply reached it. WazirX, 2024, around $230 million: multiple signers compromised plus a fake UI to trick the remaining co-signer, blind signing again at the center. Radiant Capital, 2024: malware delivered through a spoofed PDF infected signer hardware wallets, and legitimate-looking approvals followed. Trail of Bits groups Bybit, WazirX, and Radiant together for exactly this reason. In each, attackers compromised the single critical control point, the multisig, despite the risk being nominally spread across multiple signers.

The common thread for an auditor: in almost every high-value "multisig hack," nobody exploited the contract. They compromised or deceived enough signers, or their devices, or their UI, to meet the on-chain threshold. The recurring enablers are a short list, and it is the same list every time. Blind signing. Pre-signing. Low effective thresholds. Missing or removed timelocks. No independent simulation of what the transaction actually does. Bridges concentrate this risk further — we cover it in our cross-chain bridge security checklist.

Here is the reframe that changes how you review one of these setups. A multisig threshold is not a security boundary you can lean on. It is a number you should assume the attacker can reach, and then ask what happens next.

QuillAudits, which has productized this kind of review, calls it the "k-signers-compromised" attacker scenario, and it is the right starting question. Given that some number of signers will eventually be phished, maimed by malware, or socially engineered over six months by people who flew to a conference to meet them, what is the blast radius? If the answer is "total and immediate," as it was at Drift, the architecture has no depth. If the answer is "bounded, delayed, and observable," you have something worth calling a control.

That question is not IT hygiene. It is an architecture and code review, which is precisely where an auditing discipline has an edge over a generic security-awareness vendor. The controls that bound the blast radius live partly in process and partly in the contracts, and they reinforce each other.

Timelocks, and they are not optional. SEAL's multisig guidance is blunt about this: enforce a mandatory delay between approval and execution, which provides the window for the team or community to detect and react to a malicious proposal, with a separate veto quorum to bypass the delay only in a genuine emergency. On Safe this is the Zodiac Delay Modifier. The Drift lesson reduces to a single sentence: removing the timelock on a multisig that controls an oracle is disabling the smoke detector. But a delay you do not watch is worthless. Trail of Bits points to Beanstalk, where a one-day timelock went unmonitored and led to a preventable hack. Timelock and monitoring are one control, not two.

Least privilege, enforced in the contracts. Trail of Bits lays out a maturity model that is a good spine for any governance review: progress from a single externally-owned account toward a design that can tolerate key compromise. The mature version separates roles: a core upgrade role behind a high threshold and long timelock used rarely, an operations role with medium settings for day-to-day work, a pause guardian with no timelock and a low threshold so it can act fast, and a cancel guardian that can kill a malicious transaction while it sits in the timelock. That last role is the one that would have saved Drift, if the timelock it depends on had still existed. The same role-separation logic shows up in DAO governance attacks.

Contract-level guardrails on the things admin keys touch. Whitelisting new collateral behind a higher quorum. On-chain invariants that revert state changes no honest upgrade would make. Minimum-liquidity and time-weighted-price checks before any asset is accepted as collateral, which is exactly the guard that would have rejected a token with $500 of wash-traded liquidity — the same class of defense we describe in our guide to oracle manipulation. Rate limits and circuit breakers on sensitive functions. These are auditable in the same pass as the rest of the code, and they are usually out of scope only because nobody asked.

Never blind-sign, and make that mechanical. SEAL and every serious post-mortem converge here. Require signers to validate transaction details through simulated execution before approving, use dedicated air-gapped signing devices that never touch email or browsing, and implement delays for high-value transactions. Independent hash verification with a tool like safe-tx-hashes-util, transaction decoding through something like Tenderly, typed-data signing over raw eth_sign, and hardware wallets with screens large enough to actually render the transaction. The point is to make "I signed what I thought I was signing" a verifiable claim rather than a hope.

Diversity and out-of-band verification on the human layer. SEAL recommends diverse hardware models to avoid systemic firmware risk, a mix of roles among signers, at least one external signer such as a security partner for high-value multisigs, and verifying any signer change through multiple independent channels like a video call plus a signed message. Drift's attackers spent months making themselves trusted. Out-of-band verification is the cheap control that makes that investment fail at the last step.

If the weakest link is a signer's key sitting on a device, an obvious move is to stop letting the whole key sit anywhere. That is the pitch for multi-party computation and threshold signatures, scaled by Fireblocks and others. The key is split into shares; a threshold of shares collaborates to produce a signature; the full private key never exists in one place. The advantages over a traditional multisig are real. There is no single device whose compromise yields a usable key. Signing policies, whitelists, velocity and amount limits, required approvers, can be enforced cryptographically inside secure enclaves and cannot be bypassed even by whoever runs the infrastructure. Shares rotate off-chain without changing the on-chain address, which removes the migration risk that makes Safe signer rotation painful. And it works consistently across many chains without chain-specific contract logic.

Our own bridge security checklist already recommends moving in this direction for high-TVL setups: consider threshold signatures rather than a thin multisig, harden key management with HSMs, air-gapped signing, and MPC for key generation, and ensure compromised signers can be rotated out without halting the system.

The honest qualification, the one a vendor selling MPC will not lead with: MPC removes the key-existence single point of failure and adds enforceable policy. It does not remove social engineering. A signer who is tricked into approving a transaction that happens to satisfy the policy still loses the funds. MPC raises the floor; it does not replace timelocks, simulation, and intent verification. For transparent on-chain governance where the point is public, auditable approvals, a Safe-style multisig with strong opsec and real timelocks is still the right tool. For a high-value treasury or admin key where speed and enforced policy matter more than on-chain transparency, MPC or an MPC-backed hybrid earns its complexity. The decision is per-key, not per-protocol.

Underneath all of this is one distinction worth making explicit, because it sorts every defense into one of two buckets.

General social-engineering defense tries to stop the compromise from happening: training, phishing simulations, endpoint detection, hardware MFA, basic hygiene. This is necessary and you should do it. It is also insufficient on its own against a patient, well-resourced adversary who will spend six months and a plane ticket on a single target. Humans are the fallible component, and against that class of attacker they will eventually fail.

Protocol-focused operational security assumes the compromise happens anyway and ensures the system survives it. Higher effective thresholds, least-privilege role separation, mandatory timelocks with monitoring, enforceable policy engines, on-chain invariants, circuit breakers. The first bucket tries to prevent the breach. The second assumes it and contains the damage. For a high-value target, only the second is a control you can rely on, because the first is a coin flip against someone who only has to win once. This is the same defense-in-depth workflow we apply to code.

Drift had no second bucket at the moment it mattered. The timelock that was its survivability mechanism had been removed four days earlier.

It is tempting to describe all of this as wide-open white space and tell you no one audits the operational layer. That would be a sales pitch, not the truth.

The truth is that the standard exists. SEAL's Secure Multisig Best Practices is the closest thing the industry has to a reference, and it is good. QuillAudits already sells an OPSEC and Multisig Audit with a thirty-item checklist, device assessment, blind-signing tests, and the k-signers-compromised model. OpenZeppelin has moved toward operational-security work. The category is not empty.

So the gap is sharper than "nobody does this." It is that the standards and tooling for governance and signer security are fragmented and not yet default, and most protocols still treat multisig setup as an internal IT task rather than something to be reviewed with the same rigor as the contracts. "Use a Safe and be careful" is still the median posture. That is the gap. Closing it does not require inventing a category. It requires treating the operational layer with the seriousness the loss data has already earned it, and tying it to the code review rather than selling it as a separate checklist: every admin function inventoried and mapped to its on-chain blast radius, the policy engine reviewed with an auditor's invariant mindset, the timelock and the monitoring assessed as the single control they actually are. This belongs in your post-audit security lifecycle, not a one-time gate.

The code being fine is the easy part now, and the part the industry already knows how to verify. The signers being fine is the part that keeps draining protocols. Both belong in scope.

Zealynx audits smart contracts and the operational layer around them, on EVM and Solana. If you want the governance and signer workflow reviewed alongside the code — every admin function mapped to its blast radius, the timelock and monitoring assessed as one control, the multisig stress-tested under a k-signers-compromised model — we can scope it.