We're securing validators at the wrong layer

Almost all the money in blockchain security goes to one place: smart-contract audits. The application on top gets read line by line. The validator it runs on gets a volumetric DDoS plan and not much else.

We've spent the last several months proving that's the wrong allocation. The attacks that actually scale against a validator don't live in the contract and aren't volumetric. They live at the transport and RPC layer, they're cheap, and the same handful of shapes recur across chains that have never shared a line of code.

There are two we keep finding. One is expensive cryptographic work performed before the node has checked whether the caller is even on the allowlist: you make a validator burn CPU authenticating you before it's decided it should talk to you at all. The other is a small, unsigned "what would happen if" request that runs attacker-supplied work on a synchronous executor, so a tiny packet costs the node a whole core. Neither is a clever zero-day. Both are architectural, and both recur because chains inherit the same transport libraries, the same framework code, and, above all, the same audit assumptions.

That last part is why the class sits unowned. The contract-audit industry doesn't look here because it isn't contract code. The infra and SRE world doesn't look here because resource-exhaustion at the RPC layer isn't in their threat model. The bounty programmes rate it Low because they file it under "just DoS." So a real, portable, consensus-adjacent attack class falls into the gap between three groups who each assume someone else has it. Nobody does.

The reason we can say "class, not list" with a straight face is that the fix is identical wherever the shape appears: a wall-clock budget on per-request work that the caller can't set, and an allowlist check before the expensive crypto, not after. And there are clients that already do this correctly, which is the proof the whole thing is preventable rather than inherent to running a public endpoint.

We're deliberately not naming the affected networks or the numbers here. Those are in coordinated disclosure and publish as the embargoes lift. The thesis doesn't need them: if you operate a validator, run a foundation, or invest in this space, and the idea that your real exposure is at the transport layer is news to you, that is precisely the point we're making.

This is the layer we work. It's the one nobody else is standing on.

Simon Morley researches validator infrastructure security and is the founder of NullRabbit. About / contact.