What Crypto Gets Wrong About Security (According to Someone Who's Seen Every Hack)

‍

Julia has seen more crypto hacks than most people know exist.

As Co-Founder, Investigations at zeroShadow, she spent years at Chainalysis tracking stolen funds and responding to incidents before the rest of the industry even knew something had gone wrong. Her vantage point is rare: she sits at the exact moment things fall apart, which means she has an unusually clear picture of everything that led there.

Her conclusion is not flattering for the industry.

The Same Mistakes, Over and Over

The pattern Julia kept seeing at Chainalysis was not random. Protocols were falling to the same attack vectors, repeatedly, because the lessons from one incident were not making their way to the teams that needed them. Someone would get exploited, a post-mortem would go out, and two months later a different protocol would be drained by the same class of vulnerability.

The second pattern was timing. Teams were often finding out their funds were gone not from their own monitoring systems, but from a tweet. Days could pass between an exploit and the moment someone on the team realized what had happened.

Both of these are fixable problems. Neither requires inventing new technology. They require treating security as an ongoing operational function rather than a pre-launch checkbox.

The Human Element Is Still the Weakest Link

A lot of the conversation in Web3 security focuses on smart contract vulnerabilities. That focus is understandable, but it is incomplete.

According to Julia, the attack vector that continues to be underestimated is the human one. The person holding the keys, the team member who clicks a link in a fake Zoom invite, the insider with privileged access who becomes a target. These are not exotic threats. They are the entry point for some of the largest hacks the industry has ever seen.

The North Korean group known as Dangerous Password has made this its operating model. They compromise one person, extract credentials, use those credentials to reach new victims, and automate the laundering on the other end. The windows for recovery are not just small. They are sometimes nonexistent by the time anyone realizes what happened.

The technical security stack is maturing. The operational security stack, the culture, the access controls, the awareness training, is still lagging badly.

What the First 24 Hours Actually Look Like

When an exploit happens, the instinct is to move fast and tell everyone everything. Both of those instincts are wrong.

The first 24 hours are about containment and coordination, not speed and transparency. The response team needs to stay small. The on-chain addresses need to be flagged as stolen immediately because time is everything on the laundering side. The technical analysis needs room to run without pressure to produce conclusions before the threads have been followed.

Communication with the community is genuinely hard. Teams want to show they are responding, but revealing too much too early can compromise negotiations, tip off the attacker, or close off options that might otherwise lead to a recovery. Striking that balance is one of the least discussed and most consequential decisions in the immediate aftermath of a hack.

The two biggest mistakes Julia sees teams make: demanding answers before the investigation has had time to produce them, and not thinking about law enforcement early enough. Recovery of funds, when it happens, almost always has a law enforcement component. Teams that have not thought about jurisdiction and contacts in advance are starting from zero at the worst possible moment.

What Proactive Security Actually Looks Like

Julia's recommendation for protocols building their security posture from scratch is not complicated, but it does require commitment.

The first piece is operational security infrastructure: least privilege access, comprehensive logging, environment separation, and the kind of governance documentation that traditional finance and cybersecurity teams treat as table stakes but that Web3 teams often skip. This is not glamorous work. It is also the work that makes every exploit investigation faster, cheaper, and more likely to end in some kind of resolution.

The second piece is automated monitoring with real response mechanisms. Not just alerts. Actual automated responses that can pause a protocol, contain a situation, and give a team time to evaluate before more funds move. The teams that have built this have avoided losses that would otherwise have been catastrophic.

These two things together do not eliminate risk. Nothing does. But they are the difference between a team that finds out about an exploit from a tweet and a team that finds out from their own systems, with options still on the table.

The Hot Take Worth Taking Seriously

Julia's provocative take is one the industry has been slow to engage with honestly: many decentralized protocols are not as decentralized as they present themselves, and that gap creates both responsibility and opportunity.

When a bridge's volume increases 90x in a month, that is not organic community growth. That is a laundering pipeline. The protocol knows it. The industry knows it. And in many cases, the protocol has more technical ability to disrupt that activity than it has been willing to exercise.

The argument against intervention is usually framed around decentralization ethos. But decentralization ethos was never meant to be a shield for money laundering infrastructure. The protocols that are willing to think seriously about what they can do here, short of full KYC, using threat intelligence, flagging illicit addresses, building friction into known laundering pathways, are the ones that will be better positioned as regulatory pressure increases and institutional adoption continues.

The choice is not between being decentralized and being responsible. It is between choosing to engage with this problem now, or being forced to engage with it later under far less favorable conditions.