How close can an attacker get to your validator? We built a tool to find out

There's an assumption buried in most validator threat models, usually unstated: an attacker can't get physically close to your node, so anything that needs sub-millisecond round-trip time is out of scope. Timing side-channels, latency-sensitive amplification, all quietly excluded.

We wanted the real number, so we built a tool to measure it.

High-frequency trading firms solved the underlying problem years ago. You don't negotiate a cage; you churn cloud instances, measure RTT to the target, discard the far placements and keep the near ones, until the scheduler drops you into the same zone, the same rack, sometimes the same host. Placement is a lottery you replay for pennies a draw. Our tool, nearwalk, adapts that to validators and answers one question: how close, how fast, how cheap.

A representative run walked a cloud instance from 90ms cross-region down to the ~40 microsecond tier, same-rack proximity, in three iterations across six instances for $0.0077. The lowest we observed was 40.8 microseconds. That isn't "near." That's effectively loopback, bought by a stranger in minutes for less than a cent.

So when we model a validator, network distance isn't a barrier and availability-zone placement isn't a security boundary. We assume an adversary can reach the node at near-loopback latency, and we judge every DoS and timing mitigation on whether it holds against a co-located attacker. A defence that only works because the attacker is far away doesn't work, because being far away is now a choice the attacker makes, not a constraint they're under.

nearwalk measures distance and nothing else: TCP connects shaped like curl, no payload, scoped credentials, a teardown that cleans up after itself. It's a ruler, built so we can point it at infrastructure safely and report the number. The number is the contribution.

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