Christian Vari

Pre-mortems are useful for identifying risks. Simulated attacks are how you find the specific decision point where your team defaults to chaos. Those are not the same exercise, and only one of them is honest preparation. oaksecurity.io/agent

I've seen teams with documented incident response plans completely lose coordination structure within 90 seconds of a simulated drain. The plan existed. The muscle memory didn't.

A pre-mortem asks what could go wrong. A wargame shows you exactly where your team breaks when it does.

If any answer is no, the protocol carries operational risk that no smart contract audit will catch. The code can be perfect. The signing ceremony is where the attack surface lives. That scope doesn't exist in most audit engagements yet.

Three questions I now ask in every operational security review: Do you use durable nonces? Do your signers understand what they're authorizing when they sign one? Can a single compromised key escalate to admin privileges without a time delay or second factor?

The Drift attacker spent six months building trust before sending the signing request. The smart contract audit was clean. The protocol still got drained.

If you're auditing MEV infrastructure, the scope has to include bot-side execution validation. Does the bot confirm its tx landed in the expected block position? Does it verify state post-execution before acting on the result? These are auditable. Most audits never touch them.

The bot assumed its sandwich would land in a specific sequence. When the mempool didn't cooperate, the execution state diverged from what the bot expected. No check caught it. The bot acted on a world that no longer existed.

JaredFromSubway's vulnerability wasn't a contract bug. The contract logic was correct. The failure lived at the operational layer: the bot never validated that its transaction actually executed as expected.

That's not carelessness, it's just never been written down. Wallet OPSEC for a protocol team is a set of auditable controls. Most teams haven't audited that surface once. oaksecurity.io/agent

What I see in practice: one developer holds a hot key used for both testing and production signing, seed phrase lives in a password manager, and there's no documented procedure for rotating keys after a team member leaves.

Telling your team to watch out for phishing is not an OPSEC policy. It's a hope.

The gap isn't soft. It's architectural. If you've never rehearsed who calls the pause, who contacts the exchange, and who owns external comms, you have an incident response plan with no execution layer. oaksecurity.io/agent

The SEAL 911 war-room model names this explicitly: you need a designated incident commander, pre-assigned roles, and a single channel before an exploit happens, not after. Improvised hierarchy under pressure doesn't form fast enough.

An active exploit is unfolding. Your team is in four different Telegram threads, two people are sending conflicting pause instructions, and nobody has clear authority. The attacker has already drained 60%.