Is a DeFi protocol's RPC and relayer infrastructure a valid DDoS stress-testing target?

Yes, for the off-chain components — RPC endpoints, bridge relayers, oracle nodes, and message verifiers — because they're conventional servers with conventional availability limits. What's different from a normal web app is that some of these components exist in sets of three or more for redundancy, and a stress test that only checks whether the set as a whole stays reachable misses what happens to trust when individual members of that set go down one at a time.

What actually happened in the KelpDAO hack that makes this relevant to DDoS stress testing?

On 2026-04-18, an attacker who had already compromised a LayerZero Labs developer's session keys on 2026-03-06 used that access to poison RPC infrastructure ahead of time. When the attack ran, legitimate external RPC nodes feeding LayerZero's verifier network were DDoS'd into silence, and the network fell back to the remaining — already compromised — nodes, which signed off on a forged cross-chain message. That forged message let the attacker mint 116,500 unbacked rsETH tokens, roughly $292M.

Doesn't the exchange or protocol's cloud provider (AWS, Cloudflare) already protect against this?

It protects the origin from going offline, which is a different question from what the origin trusts once part of its verification set is offline. A CDN or scrubbing provider can keep an RPC endpoint reachable during a flood; it has no visibility into whether the application-layer logic behind that endpoint silently promotes a lower-trust node to decision-maker when its usual peers stop responding. That's an application/protocol-design question, not an infrastructure-uptime one, and it's outside what DDoS mitigation vendors are scoped to test.

How is this different from an authorized DDoS test against a crypto exchange's trading platform?

A centralized exchange's trading platform has one operator and one trust boundary — the exchange itself controls all the infrastructure a stress test would exercise. A DeFi protocol with cross-chain messaging typically depends on a verifier or relayer network run by a mix of the protocol team, a messaging provider, and sometimes independent node operators — so the question a stress test has to answer isn't just "does it stay up" but "who's actually making the trust decision when part of that network is down, and did that change under load."

What should be in scope when a DeFi protocol authorizes a DDoS stress test?

At minimum: flood each RPC/verifier node individually (not just the whole set at once) and confirm the failover path enforces the same identity and quorum checks as the primary path; confirm a flooded node can't be silently excluded from a quorum count in a way that lowers the effective signature threshold; and confirm alerting fires on "primary source degraded, fell back to secondary" as its own event, separate from a generic uptime alert, so a human sees the trust-boundary change in real time rather than after the forged message has already been accepted.

DDoS Stress Testing for Web3 Infrastructure: The Failover Path Most Scopes Never Touch

The short answer

A DDoS stress test that only proves your RPC endpoints and relayers stay reachable under load answers the wrong question for a DeFi protocol with cross-chain messaging. The question that matters is what the system trusts once part of its verification set goes quiet — because on 2026-04-18, an attacker DDoS'd LayerZero's external RPC nodes into silence, forcing a failover to nodes the attacker had already compromised, and used the resulting forged cross-chain message to mint $292M in unbacked tokens from KelpDAO. The DDoS wasn't the exploit. It was the switch that turned on the exploit.

Who this is for

This is written for the Head of Infrastructure, protocol engineering lead, or CISO at a Web3 or DeFi platform that depends on off-chain infrastructure to move information about on-chain state — an RPC node set, a bridge relayer, an oracle feed, or a cross-chain messaging verifier network like LayerZero, Wormhole, or a custom multi-sig attestation service. It assumes you already run, or are considering, an authorized DDoS stress test against that infrastructure, and you're scoping what "passing" should actually mean.

It is not for a protocol whose only public surface is a smart contract with no off-chain relayer, oracle, or verifier dependency — there's no failover path to test if there's nothing off-chain making trust decisions. If the concern is a routing-layer hijack redirecting users to a fraudulent frontend rather than a verifier network being starved into a bad decision, see private Anycast for Web3 infrastructure, which covers BGP hijacking and RPKI, a different attack surface entirely. If the question is whether a DDoS stress test is the right engagement at all versus a load test, load testing vs DDoS stress testing covers that decision generically.

What KelpDAO shows about the threat model

Two independent accounts of the 2026-04-18 KelpDAO incident agree on the sequence: on 2026-03-06, an attacker social-engineered a LayerZero Labs developer and obtained session keys, then used that access to poison RPC infrastructure ahead of time — planting compromised nodes into the pool the verifier network could fall back to. Weeks later, the attacker DDoS'd the legitimate external RPC nodes offline. With the primary path silenced, LayerZero's verifier network fell back to the remaining nodes — the ones already under attacker control — which signed off on a forged cross-chain message. That message let the attacker mint 116,500 unbacked rsETH tokens, worth approximately $292M, and triggered roughly $13B in DeFi outflows as Aave froze rsETH markets on V3 and V4 in response.

The structural point, independent of LayerZero specifically: the DDoS attack did not need to break anything. It needed to remove enough of the trusted path that a lower-trust path became the effective source of truth, and it needed that substitution to happen without anyone — human or automated — treating "we fell back to secondary nodes" as an event worth a distinct alert. Both prerequisites are things a DDoS stress test can actually check for, if the scope is written to check for them.

This is a different failure mode from the ones AnySec's other DDoS and Web3 content already covers:

Private Anycast for Web3 Infrastructure covers a BGP hijack redirecting a frontend to a fraudulent server with a fraudulently obtained TLS certificate — an attack on routing, aimed at users. KelpDAO's failure was an attack on verification quorum, aimed at the protocol's own trust logic, with no user-facing redirect at all.
DDoS Protection for a Crypto Exchange covers a centralized exchange's anomaly-detection systems mistaking a legitimate trading surge for an attack — a false-positive problem on a single operator's infrastructure. A cross-chain verifier network spans multiple operators and node types by design, so the question isn't "is this traffic real" but "which node's answer do we trust right now."
DDoS Testing Sign-Off: AWS vs Cloudflare covers the sign-off chain for testing a single provider's mitigation stack. A verifier network's failover path often crosses provider boundaries — the primary RPC set on one host, the fallback set on another — so a single provider's sign-off doesn't cover the whole test surface.

Scope: what a stress test has to include that a generic one doesn't

	Generic uptime-focused DDoS stress test	Failover-trust DDoS stress test for a verifier/relayer network
What's flooded	The service as a whole, or one endpoint, to see if it goes down	Individual nodes in the verification set, one and then several at a time, to see what the remaining nodes do
Pass condition	The service stays reachable, or degrades gracefully	The service stays reachable and the failover path enforces the same identity/quorum checks the primary path does
What's checked after the flood	Response time, error rate, mitigation trigger logs	Whether the effective trust threshold (e.g., signatures required for quorum) silently changed when nodes dropped out
Alerting requirement	"Service degraded" or "mitigation triggered"	A distinct "fell back to secondary verification path" alert, separate from generic uptime alerting, fired to a human
Provider coordination	One DDoS mitigation or hosting provider	Potentially several — primary and fallback nodes are often on different infrastructure by design

The middle row is the one most scopes skip, because it isn't an infrastructure question — it's an application-logic question about how the verifier code responds when its input sources shrink. A DDoS mitigation vendor testing whether your Cloudflare or AWS Shield configuration absorbs a flood has no way to answer it, because the answer lives in code the mitigation provider never sees.

Deliverables

A stress test scoped this way produces, beyond the standard mitigation-effectiveness report: a node-by-node breakdown of what the verifier/relayer logic did as each node in the set was taken offline in sequence; confirmation of whether the effective quorum threshold changed as nodes dropped, and if so, by how much; and a review of whether "operating on a reduced verification set" generates its own alert or is invisible inside normal uptime dashboards. None of this requires access to the counterparties' infrastructure — a stress test against your own RPC/relayer nodes, with the fallback logic instrumented to log what it decided and why, is enough to answer the question.

Limitations

This does not test the on-chain smart-contract logic itself, the initial-access vector (the KelpDAO root cause was a social-engineered developer, not a DDoS-reachable system), or the specific behavior of a third-party messaging provider's infrastructure you don't operate — if your protocol depends on a provider like LayerZero or Wormhole's relayer network for cross-chain messages, the provider's own internal failover logic is a question for their security team, not something an external stress test against your infrastructure can validate. What this scope does validate is your own nodes' and your own integration code's behavior when part of the verification set you depend on goes quiet, whether that quiet is caused by a DDoS attack, a routine outage, or a provider-side incident.

Decision and next step

If your protocol's off-chain infrastructure includes any component that can fail over from a primary source to a secondary one — an RPC node set, a relayer, an oracle feed, a custom verifier — the DDoS stress test that matters is the one that floods individual members of that set and checks what the remaining members trust, not just whether the set as a whole stays reachable. Scope an authorized DDoS stress test built around your specific verification topology; the DDoS Stress Testing engagement runs under the same signed RoE and abort-condition discipline as any other authorized test, applied to the failover paths most scopes never ask about.

Sources and review

KelpDAO incident facts (date, dollar amount, mechanism) cross-checked against two independent secondary accounts: Bitcoin Foundation's incident writeup and crypto.news's 2026 DeFi-hacks analysis, both published 2026. Neither this post nor those sources describe the specific technical steps used to poison the RPC infrastructure or forge the cross-chain message; the mechanism is described here only at the level needed to understand the DDoS-to-failover-to-forged-trust chain, consistent with AnySec's policy against publishing exploit steps. Scope and deliverables reflect AnySec's DDoS Stress Testing engagement methodology. Author: AnySec Engineering. Published 2026-09-12.