April 2026 was the worst month on record for crypto. Almost none of it was clever.
Roughly 600 to 650 million dollars walked out the door in April. The worst month the industry has ever logged.
Here is the part that should keep you up at night. It was not math. It was not some unstoppable zero-day buried deep in the contract. Two incidents accounted for something like 93 to 95 percent of the total, and neither one was a smart contract exploit.
They were opsec failures. You know, people problems. Process problems. The exact kind of thing that never shows up in an audit report, because the code was never the weak point.
Let’s walk through two of the incidents, because the details are the lesson.
On April 1, Drift Protocol on Solana lost around 285 million dollars. No bugs in the contract. Instead, a North Korea-linked group (Lazarus, tracked as UNC4736) ran a six-month campaign. Fake profiles. Job offers. Slow, patient trust-building with the people who held the keys. Eventually they compromised devices and got multisig signers to pre-sign malicious transactions. The signers thought they were approving something routine. They were signing away the treasury.
Six months. Sit with that. While the team shipped features and watched their dashboards, someone was building a relationship with the single goal of draining them.
Then around April 18, Kelp DAO lost roughly 292 to 293 million through its rsETH bridge on LayerZero. Again, not a clean code bug. This was an infrastructure compromise. RPC poisoning, set up by social-engineering a developer, tainted nodes feeding the system bad data. Same playbook, same suspected crew.
Two protocols. Nearly 580 million dollars. Zero clever code exploits.
Here is the uncomfortable conclusion for any founder reading this. The contracts held. The humans around them did not.
Given that the breaches were people and processes, then security is not a thing you buy once and file away. It is not your audit firm’s job. It is the way you and your team think about security. Or, more importantly, the way you fail to.
That way of thinking has a name. Adversarial thinking. And it is the most underrated skill a Web3 founder can build.
Your assumptions are the attack surface
Most founders picture the threat as code. A reentrancy bug. An overflow. Something you can scan for. They know to keep their keys safe, but what does that mean?
The honest threat is bigger and quieter. It is every assumption you have never tested.
Who can sign a transaction, and what happens when their laptop is owned. The integration you trust because the team behind it has a good reputation. The deploy process you have run fifty times without incident, which is exactly why nobody questions it anymore.
Adversarial thinking is the habit of assuming you are already wrong. Already compromised. And working backwards to find out how.
It is not paranoia. Paranoia is fear without direction. This is the opposite: structured, specific, useful. You stop asking “does this work?” and start asking “how would I break this if I wanted the money?”
Defenders write checklists. Attackers ask questions. You have to be both, and most founders are only the first.
It does not just protect your ideas. It sharpens them.
Here is what surprised me. The same thinking that finds an exploit in your code finds a weak premise in your processes.
An idea nobody has attacked is not a strong idea. It is an untested one. Those two have a similar set of properties right up until the moment they don’t, and that moment almost always has a price tag.
Take any BAU process in your company and put it on trial. Who does this hurt? Who abuses it? What does it cost us when volume is a hundred times higher? Most ideas that die in that conversation deserved to die. The ones that survive come out sharper, with their soft spots already mapped.
This is the part many founders miss. Adversarial thinking is not a security tax you pay once in a while. It is how good ideas and processes get separated from comfortable ones.
Treat your own best ideas as suspects, not trophies.
April, up close: opsec is a founder problem
Going back to Drift and Kelp for a second, because the shape of those failures is the whole point.
Both teams almost certainly had audits. Both had competent engineers. Neither was breached through the thing they were watching.
The pattern is consistent:
- Signing flows nobody ever attacked from the inside.
- Key custody nobody stress-tested against a realistic threat.
- Teams that practiced the happy path and never once rehearsed the breach.
And the founder-level failures sitting underneath those:
- Trusting a process because it has not failed yet.
- Treating security review as a launch gate instead of a daily habit.
- Assuming the person in the DM, the recruiter, the helpful contributor, is who they say they are. Lazarus spent six months proving that assumption wrong.
I will say it the way I always say it: a protocol that was safe ninety days ago tells you nothing about today.
Make your AI adversarial, or it will just agree with you
Most founders now have an AI tool somewhere in the loop. Here is the trap few warn you about. These tools default to agreeable.
Ask “is this contract safe?” and you get reassurance. Reassurance is the most dangerous answer you can receive, because it feels like an answer when it is actually just politeness.
The fix is in how you ask. Watch the difference.
Weak prompt:
“Does this code block look secure?”
You get a one-sided rant. Confident, shallow, useless.
Adversarial prompt:
“You are a cyber security researcher. Give me a list of possible ways to attack this section of code. From this code are there external factors to be aware of that could affect the security. Use deep research to see if this type of code has ever been successfully attacked in the past.”
Now you have handed it a role, forced it to argue both sides, demanded evidence, and asked for specifics. The output is sharper because you made it work against itself.
Apply the same move to security. “You are an attacker trying to drain this contract. Walk me through the path.” “Argue in the strongest possible case that this design is broken.” “Where would a Lazarus-style campaign get a foothold in our signing process?” You will learn more from those answers than from a hundred “looks good to me” replies.
Now the honest boundary, because I have to be straight with you here. An adversarial prompt makes AI more useful. It does not make it sufficient. Fully autonomous AI auditing still misses things, and it still hallucinates findings that are not there. The model that actually works is human judgment, plus deterministic scanning, plus AI used as a sparring partner rather than an oracle. Use it to pressure-test your thinking. Do not turn your thinking and thought processes over to an AI and walk away.
The only real defense is testing, then testing again
Premises rot.
The thing you verified last quarter is now running against new code, new integrations, and attackers who have had three more months to study you. Drift’s attackers had six.
Safety is not a state you arrive at. It is a thing you keep re-earning. Which means the point-in-time audit, valuable as it is, was never going to be enough on its own. You need reviews that repeat.
So attack your own house, on a schedule:
- Use the tools and AI skills you already have, but point them at your assumptions, not only your code.
- Run your process against a real security framework instead of a gut feeling. If you are pursuing SOC 2, treat it as a live discipline rather than a certificate to frame. That operational rigor is exactly the kind of thing we help teams stand up at Fidesium.
- Practice incident response before you need it. The first time you run the breach drill should not be during the breach.
- Re-question the assumption you are most confident about. Confidence is where the next April lives.
It is the only way forward
Here is the thing about the teams that lost almost 580 million dollars last month. Not one of them thought they were the careless ones.
That is the entire point. Confidence was the vulnerability. The code was fine. The mindset was not.
Adversarial thinking is not glamorous and it does not end. You attack your own ideas, your own contracts, your own assumptions, on a loop, for as long as you run the company. It is tiring. It is also the only thing that will work.
The question is never whether you are secure. It is whether you are still asking.
