Posts tagged validator security.
Which chains fail the same way
Twenty-eight of the 118 techniques we have reproduced appear on more than one chain. The registry could always report that number but never draw the line between the chains. The chain graph draws it, and most of the lines it draws are arithmetic rather than evidence, which is the part worth publishing.
Beyond Zero answers what the machine decides. It does not answer who said it could.
Google's Beyond Zero moves the trust boundary from the application to the individual action and puts a reasoning layer in the access path. The objection that landed on Hacker News, that a non-deterministic evaluator does not belong there, is aimed one layer too low. The gap is not determinism. It is legitimacy: nothing establishes that a given system has the standing to act in your environment, against your traffic, under your conditions. Vendor-asserted accuracy is not evidence.
NRDAX: browsable by chain and family, readable by machines
NRDAX now holds 623 techniques across 64 chains, 103 reproduced with bundles. New per-chain and per-family landing pages, a pretty Atom feed, JSON and STIX 2.1 and knowledge-pack distributions surfaced for machines, and a fix for the first_seen date bug.
NRDAX now includes known-but-not-reproduced techniques
NRDAX v0.1-import now contains 368 techniques across 21 chains: 140 with reproduced instances and bundles, and 228 known from public disclosures (CVEs, GHSAs, vendor advisories) but not yet reproduced in the lab. A CVE maps to its technique even when no bundle exists yet.
NRDAX: the canonical technique registry for decentralized infrastructure attacks
We have published NRDAX, the NullRabbit Decentralised Attack indeX, at nrdax.com. It is the reference registry for attack techniques against decentralized infrastructure: 135 chain-agnostic techniques, grouped into mechanism families, with a coverage matrix across 21 chains.
Eighteen advisories, ten node implementations, one attack class
Since NR-2026-001, eighteen advisories across ten independent node implementations. Not unrelated bugs: one recurring attack class, unauthenticated ingress surfaces where a cheap request forces disproportionate cost. Egress and memory amplification, pre-auth CPU exhaustion, connection exhaustion, and crashes.
How close can an attacker get to your validator? We built a tool to find out
Most validator threat models assume an attacker can't co-locate with your node. We built a tool to measure the real number. It walked a cloud instance from 90ms to 40 microseconds for under a cent.
Anyone can knock a validator over once. The skill is designing an attack you can learn from
Making a node fall over is easy and proves nothing. The craft is building a reproducer that isolates the mechanism, measures it against an honest baseline, bounds the cost, and runs on one command, so the number actually means something.
Expensive work before authentication: the RPC pattern we keep finding
The DoS class that scales against validators isn't volumetric. It's small requests that cost the node real work before it authenticates the caller. The pattern we keep finding across clients, and the fix.
We're securing validators at the wrong layer
Blockchain security money goes to smart-contract audits. The validators those contracts run on are defended for volume and almost nothing else. The attacks that actually scale live at the transport and RPC layer, and they're a class, not a list.
Open data for blockchain validator security: the first multi-modal dataset for infrastructure attacks
We've published nr-bundles-public on Hugging Face: the first open, multi-modal dataset for blockchain validator security. 31 schema-pinned observations across Sui and Solana, seven attack families, CC-BY-4.0. Open bundle format, open ten-family taxonomy, closed corpus. The substrate for cross-chain ML detection of infrastructure attacks.
