Back to blogs
Written by
Patrick Collins
Published on
April 6, 2026

Why the Drift Protocol Hack Changes Everything About Web3 Security

The $285M Drift hack used in-person social engineering to compromise a multisig. Here's why transaction legibility standards like ERC-8213 are the fix.

Table of Contents

Why the Drift Protocol Hack Changes Everything About Web3 Security

The $285M Drift Protocol hack wasn't the largest hack in Web3 history — Bybit's $1.4B exploit holds that title. But it may be the most important one for the industry to understand. Here's why.

Video version of this post

TL;DR

  • Drift Protocol, a Solana-based perpetual futures DEX, was exploited for ~$285M on April 1, 2026
  • The hack was a multisig compromise via social engineering — not a smart contract vulnerability
  • The attackers met Drift contributors in person, worked with them for six months, and built genuine trust before striking
  • Hardware wallets were used but were irrelevant — the signers couldn't verify what they were signing
  • The systemic fix is transaction legibility: ERC-8213 (Ethereum) and a proposed SIMD (Solana) aim to make signing verifiable

What happened

Drift Protocol operated behind a 2-of-5 multisig using Squads, a standard multisig infrastructure on Solana. The team confirmed that all multisig signers used cold wallets.

The attacker needed just two approvals. From Drift's post-mortem:

The attack was enabled by a combination of pre-signed durable nonce transactions and compromise of multiple multisig signer's approvals, likely through targeted social engineering or transaction misrepresentation.

The exploit itself — compromising a multisig by manipulating what signers approve — is not new. We saw this exact pattern with Bybit ($1.4B), WazirX ($200M), and Radiant Capital ($50M). The playbook is consistent:

  1. Compromise the signer's device or environment
  2. Present transactions that appear legitimate but contain malicious data
  3. The signer approves without the ability to meaningfully verify
  4. Funds are drained

The exploit transaction executed in roughly 12 minutes.

Why this one is different

Every previous state-sponsored hack in crypto has relied on remote social engineering — fake job offers, Telegram messages, malicious links sent to strangers. Meeting in person was considered too risky for the attackers, which meant teams could use in-person verification as a mitigation.

The Drift attackers removed that assumption.

From Drift's disclosure:

Drift contributors were approached by a group of individuals at a major crypto conference who presented as a quantitative firm looking to engage on the protocol. They were technically fluent, had verifiable professional backgrounds, and were familiar with how Drift operated.

Over the following six months, the attackers onboarded an Ecosystem Vault on Drift, deposited over $1M of their own capital, participated in working sessions, and met contributors face-to-face at multiple conferences across several countries. By the time the attack executed, the relationship was nearly half a year old.

This is reminiscent of the XZ Utils backdoor — a multi-year infiltration of critical open-source infrastructure by a contributor who spent years building trust before inserting a backdoor.

Two things make this escalation significant for every team in Web3:

  1. In-person verification is no longer a sufficient filter. The attackers used intermediaries (not North Korean nationals themselves), but the result is the same — the Drift team believed they were working with a legitimate firm.
  2. Attack timelines are extending. Six months of relationship-building before execution. The industry's detection models are not calibrated for this kind of patience.

The individual remediations (and why they're insufficient)

There are specific steps that could have reduced the attack surface. We should acknowledge them honestly:

Transaction verification. Hardware wallets were used, but the signers could not verify what they were actually signing. Transaction data on hardware wallets — especially for complex Solana instructions — is rendered as raw hex. Verifying thousands of characters against expected values is impractical. This is the blind signing problem that exists across every chain.

Code execution hygiene. One contributor was likely compromised after cloning a code repository shared by the attackers. Tools like Docker containers, dev containers, and sandboxed environments exist for this. Pascal Caversaccio from SEAL recommends Qubes OS for full isolation.

Device separation. Signing devices should be physically and logically separated from working devices. A compromised laptop should not have any path to a signing key.

Each of these is valid. Each was available before the hack. But here's the problem — none of them are the default path for how teams operate today. And that's the systemic issue.

The default path must be the secure one

There's a concept in security called security fatigue — when the cognitive burden of doing the right thing is so high that people just stop doing it. Every hack where the response is "they should have known better" is a symptom of this problem.

Consider passwords. For decades, the "solution" to credential reuse was telling people to memorize unique passwords. The advice was technically correct. In practice, it was infeasible. The real fix came when we built infrastructure — password managers, passkeys — that made the secure path the easy path.

The same pattern applies here. We can tell every multisig signer to verify every character of every transaction on their hardware wallet. That advice is technically correct. In practice, no one does it — because it's 20 pages of hex data and a single wrong character means a catastrophic loss.

This is the fundamental attribution error applied to security: blaming individuals for situational failures. The fix isn't better education. The fix is better infrastructure.

What we're building to fix this

ERC-8213: Transaction Digest Display (Ethereum)

ERC-8213 is a standard we've proposed for the Ethereum ecosystem. Instead of displaying raw calldata on hardware wallets, the wallet displays a single 32-byte digest. The signer independently computes the expected digest on a separate device and compares. One hash to verify instead of thousands of characters.

This targets technical users and enterprise signers — anyone responsible for high-value multisig operations.

ERC-7730: Human-Readable Signing (Ethereum)

ERC-7730 is the longer-term companion. It establishes a registry where projects provide structured metadata that translates raw transaction data into plain-language descriptions. This targets non-technical and retail users.

SIMD Discussion: Bringing This to Solana

The Drift hack happened on Solana, where these standards don't exist yet. We've opened a discussion in the SIMD repository to bring both approaches to the Solana ecosystem — a transaction digest equivalent and a human-readable signing registry.

What you should do right now

If you operate a multisig, manage a treasury, or sign transactions on behalf of a protocol:

  1. Go bump the proposals. ERC-8213 and the Solana SIMD discussion need community support.
  2. Separate your signing and working devices. This is table stakes.
  3. Use containers for untrusted code. Docker, dev containers, Qubes OS — anything that isolates execution.
  4. Don't run software from people you haven't exhaustively vetted. Even people you've met in person.

These are the immediate individual steps. But the real fix — the systemic fix — is making wallets that don't let this happen in the first place.

The default path must be the secure one.

Secure your protocol today

Join some of the biggest protocols and companies in creating a better internet. Our security researchers will help you throughout the whole process.
Stay on the bleeding edge of security
Carefully crafted, short smart contract security tips and news freshly delivered every week.