The "Drift Protocol" Case: Trust, But How Far?

A few months ago, I wrote about the Step Finance case in the newsletter. It was a situation where the security flaw wasn’t in the code but in a person, leading to millions being stolen when an employee’s credentials were compromised. It even started a chain of events that led to Step Finance shutting down.

This week, a similar pattern emerged, but on a much larger, more planned, and more organized scale.

April 1, 2026. Drift Protocol, one of the largest decentralized exchanges on the Solana blockchain, lost about $285 million.

This incident wasn’t due to a software bug or a gap in security measures. It was a well-planned, organized, and long-term intelligence operation that took six months.

To give a bit of background, Drift Protocol is an exchange where users entrust their crypto assets, operating without a central company. Like many crypto exchanges, centralized or not, it uses a security model called “multi-signature” to manage systems. You can think of it like a safe that requires multiple keys to open. Transactions can’t happen based on one person’s decision; they need approval from multiple authorized individuals.

In theory, this is a very secure system and infrastructure. But what happens if the device or signature mechanism of one of the authorized people is compromised?

That’s where the story begins.

In the fall, at a major crypto conference, a group introduced themselves as an “algorithmic trading” firm (using bots for automated trades). They met the Drift team, set up a joint Telegram group, and spent months asking technical questions and discussing strategies.

In December-January, they deposited over a million dollars of their own money into Drift, acting like genuine customers. Throughout February and March, they met with team members face-to-face at conferences in multiple countries.

So who was this team? They were intermediaries with entirely fabricated identities, complete with real work histories and professional networks. They were a local agent network used by North Korean state-backed groups for operations at this level, though they weren’t North Korean themselves.

After gaining the Drift team’s trust, they shared links, tools, and apps. They convinced one team member to download a wallet app still in beta via TestFlight. Another team member’s computer was quietly compromised the moment they cloned a shared code repository. Once they had device access, they gathered the necessary multi-signature approvals for transactions without the authorities even noticing, and on March 27, the protocol’s final security layer was silently disabled.

But the attack wasn’t just about people. During the same period, they created a completely fake token, the CarbonVote Token. With a few thousand dollars, they fabricated a price history and order book for this token. However, Drift’s pricing system accepted it as genuine collateral. On April 1, within a total of 12 minutes, $285 million was drained: approvals from compromised devices and “real” assets through “fake collateral.”

This isn’t the first time. Radiant Capital, Bybit, Step Finance, the same pattern: target human trust, then infiltrate the technical system. Since 2017, North Korea-linked groups have stolen approximately $7 billion from the crypto world.

The picture this paints is unsettling, and it highlights an important point.

Security is never just one layer, nor can it be. There are technical layers like firewalls, intrusion prevention systems, two-factor authentication, and multi-signature wallets. But alongside these, there’s the human layer: recognizing phishing attacks or social engineering attempts, not clicking suspicious links, maintaining device security. And for these two layers to work properly together, a third is needed: governance. Information security policies, access management, monitoring security risks at every step of business processes, training, audits, compliance with standards.

In the Drift case, all three layers were targeted. The technical system was fooled by a fake token. People were deceived through social engineering. The governance gap was created when the security council was quietly moved to a zero-delay new structure on March 27, and unfortunately, there was no process to catch this.

“Was the code audited?” is no longer enough on its own. Questions like “Who operates this system, who has access, how are these accesses managed, and who notices when something goes wrong?” come into play.

In this story/case I shared, the security flaw wasn’t in the code; it was in the trust relationship built over months with people you thought you knew, met face-to-face, and worked with. Your partner, supplier, customer, you can trust them, you should. But how much, and how far?