Ido Ben-Natan, Co-Founder and CEO of Blockaid, on The Security Table

Most people picture a hack as a single moment. Someone finds a flaw, drains a contract, disappears. Ido Ben-Natan spent years in Unit 8200 before founding Blockaid, and the first thing he does on this episode is take that picture apart.

In the units he served in, a single operation could span years. One team hunts vulnerabilities. Another builds the malware that follows the vulnerability in. Another builds the tooling to pivot, escalate privilege, and move laterally once inside. All of that work compiles into one operation that unfolds over a very long period of time. The breach isn't the operation. It's the last step of it.

His argument is that crypto's largest incidents now look the same way. Looking at the two biggest hacks of the past six months, he describes them as sophisticated cyber operations rather than opportunistic finds, complicated efforts that span weeks and months. And AI compresses the timeline without simplifying the structure. What once needed a lot of people and a long calendar can now run with more agents than people, in a fraction of the time, with the same number of moving pieces underneath.

That leads him to a conclusion worth sitting with: <cite>"the thing that needs securing is the entire ecosystem or the entire stack and not just one point in piece in time."</cite>

The Incident Volume Nobody Sees

Blockaid's vantage point is unusual. They aren't only watching transactions their customers send. They're running every transaction across every chain they support through a set of traditional machine learning models, because agents don't run at that scale, and escalating to heavier models and agents only when a risk threshold gets crossed.

What that surfaces is a rate change. Over the past six months, Ido says incidents have gone from a few every month to a few every day. Their H1 report covers more than 200 incidents that crossed their severity threshold in that window, and he's explicit that this is only a fraction of what they actually see. In many cases they reach the team, get everyone into a Telegram group, stop the bleeding, and never publish anything. His summary of it: the reality is that the carnage is much worse than what gets reported.

The Ledger Connect Kit compromise on December 14th, 2023 shows the mechanics. A poisoned npm package spread to roughly a hundred dapp front ends at once. Blockaid's systems flagged malicious transactions on a front end that should have been safe, and the flag was automatic and unremarkable. What made it an incident was the pattern. A ping came in from Stani suggesting a false positive on Aave. It wasn't a false positive. Another message came in from someone else in the industry with the same theory about their own front end. Within minutes the shape resolved into a shared upstream dependency.

The recovery cases follow the same pattern of speed. With Huma Finance, Blockaid notified the team fast enough to stop the damage in progress and freeze the affected USDC inside 24 hours, and the funds were recovered.

Where the Money Actually Goes

Asked about the report's finding that compromised keys accounted for more than 98% of Solana's losses, Ido gives the broad version: operational security is the culprit of most of the damage across the ecosystem. Third-party dependencies with no crypto in them. Social engineering. Oracle compromises. Permissioned keys that can do more than anyone modeled. The operation starts outside the chain and ends on it.

He's careful not to let that become a case against contract security, and neither should anyone reading it. He calls smart contract security very, very important, and notes that DeFi's composability makes the contagion from any single failure worse than it would be anywhere else. These are two distinct failure surfaces, and the reason opsec dominates the loss tables isn't that the code layer is solved. It's that the code layer and the operational layer fail for different reasons and need different enforcement.

Olympix doesn't work on key management, and no tool from us would have changed the outcome at Bybit. That's the honest read on the split. What's worth pulling forward is the reasoning Ido applies to signing, because it transfers cleanly to code.

Signing Is an Intent Problem

His recommended audit of a bank's signing stack starts where you'd expect. Quorum-based infrastructure, MPC or multisig, so one compromised device or user doesn't compromise the network. Then he moves to the part most teams underweight, which is the application logic layer.

His example is Paxos accidentally minting $300 trillion in assets. The signing infrastructure wasn't compromised. Someone made a mistake, and every control in the stack faithfully executed it. Bybit is the adversarial version of the same thing, $1.5B lost while the keys sat safe in their various locations, because the content being signed was malicious.

The analogy he uses is that signing a transaction is like double-clicking an executable. You can build every permission layer you want around the approval to run it, and none of that tells you what the executable does.

Blockaid's answer is simulation, running the transaction against a forked chain to see what actually happens, and then a second step that matters more than the first. Simulation alone sits in the flow as information. It has to be enforced. Their cosigner joins the signing ceremony as a third party, simulates, evaluates the outcome against policy, and either continues the ceremony or doesn't. As Ido puts it, what you sign is what's going to happen. That also closes the time-of-check-to-time-of-use gap that Bybit exploited, where what got reviewed wasn't what got signed.

Strip the crypto specifics and the principle is this: stated intent and actual behavior diverge, humans can't see the divergence by reading, so you derive the intended property, execute against it, and block on the result rather than reporting it.

The Same Gap Exists Months Earlier

That's the problem Olympix works on, at the point in the lifecycle where the intent is still being written down.

A contract's state space looks infinite and isn't. Olympix ingests the code along with everything around it, the threat models, the whitepaper, past audits, design docs, and infers the invariants the system is supposed to hold. Then it maps the execution paths through the codebase, reads the signals that mark a path as dangerous, and attacks that path two ways at once. It symbolically executes the path until it can break an invariant, and it runs known attack strategies indicated by the signal until one lands. Two independent methods from different angles, so the known classes and the unknown ones both get pressure.

The deterministic output is the counterexample. Not an opinion that something looks risky, but a concrete execution that breaks a property the protocol says it holds. That's the same authority Blockaid's cosigner has at signing time, moved to before a PR merges.

Enforcement is the part that carries over most directly. Findings that arrive as a report get triaged, deprioritized, and shipped around. Findings that block a merge get fixed. Olympix runs automatically and asynchronously during development, and the result gates the release rather than annotating it.

Audits and the Boundary Problem

None of this displaces audits, and Olympix augments auditors rather than replacing them. Audits are necessary. They're also scoped, and scope is where the gap lives.

Protocols audit every time they ship meaningful code. What gets batched into each engagement is the delta, a new feature or an updated product, validated in isolation. The exploit rarely lives inside a scope that was reviewed. It lives at the boundary, where a cleanly audited component meets the rest of the system, or where two independently audited scopes interact and were never examined together. An audit tells you what one person found, in the time they had, inside the scope they were given. Neither of those limits is a security property, and no auditor claims otherwise.

Continuous, automated verification of invariants across the whole codebase is what covers the boundaries between engagements. It's the layer that keeps working while the auditors are between scopes.

The Stack, Not the Point

Ido's closing take is about tokenization, and it lands on defenders. Markets today are open roughly 20% of the week. Assets that trade around the clock don't make the defensive job 5x harder in his read, they make it disproportionately harder, because the 80% that used to be for building, patching, and sleeping goes away.

That's an argument for pushing security earlier. If the runtime window never closes, the work you can still do calmly is the work that happens before anything is live. The counterexample you find before a merge is the one incident that never needs a war room.

Blockaid holds the line at the moment of signing. Olympix holds it before the code ever gets there. Both are answers to the same observation Ido opened with, which is that the operation is long and the exploit is only its last step.

To see what verification looks like on your own codebase, book a technical walkthrough and benchmark the engine against your own audit history: https://olympix.security/get-started-enterprise