Doesn't a DeFi protocol just need the same DDoS protection as any website?

For the front end, yes — a DeFi protocol's marketing site and dApp interface are a conventional web app behind a conventional CDN, and standard DDoS mitigation applies the same way it would to any casino or fintech front end. The RPC/API layer is a different problem, because most protocols don't run that infrastructure themselves — they consume it from a managed provider like Infura, Alchemy, or QuickNode, and "DDoS protection" at that layer means understanding what the provider actually insures you against, not deploying your own mitigation stack.

If Infura or Alchemy already runs DDoS protection, what's left for a protocol team to worry about?

Network-layer floods aimed at the provider's edge, which the provider is genuinely built to absorb — Alchemy's own published figures cite mitigating surges up to 500,000 requests per second without customer-facing downtime. What that protection doesn't cover is your own account being rate-limited. Alchemy's documented throughput model caps compute units per second at the account level, shared across every app under that account, and returns a 429 error once you exceed it — a limit that authenticated, well-formed, expensive RPC calls against your own API key can trip without ever looking like an attack from the provider's side.

What's an example of a request that's expensive without being a flood?

Calls like eth_getLogs over a wide block range, or trace_* methods, cost dramatically more compute units than a simple eth_blockNumber call — providers publish per-method compute-unit tables specifically because the cost varies by orders of magnitude. A small number of expensive, authenticated calls against your account's own API key can exhaust its throughput allocation and trigger 429 rate-limiting on your legitimate traffic, without the request volume or pattern ever resembling the flood a provider's network-layer DDoS defenses are tuned to catch.

Was the 2020 Infura outage an example of a DDoS attack on RPC infrastructure?

No, and it's worth being precise about that. The November 11, 2020 Infura outage that froze MetaMask, delayed Uniswap price feeds, and led Binance to pause ETH and ERC-20 withdrawals was caused by a dormant consensus bug in an outdated Geth client version Infura hadn't yet patched, which caused Infura's nodes to briefly follow a minority chain after an unannounced network split — a software and operations failure, not an attack. It's relevant here for a narrower reason: it's a real, verified demonstration of what happens across the ecosystem when a large share of DeFi traffic depends on one infrastructure provider, which is the same structural condition that makes provider-level rate limiting and outages a genuine availability risk independent of whether the cause is malicious.

What should a DeFi protocol's DDoS protection strategy actually cover?

Three things most generic DDoS engagements don't scope by default: a written understanding of what your RPC provider's DDoS coverage actually insures against versus what it doesn't (network floods, not account-level rate limiting); a runbook for what happens when your account gets 429'd, including whether a second provider is already configured and ready to fail over to, not provisioned from scratch during an incident; and a review of which of your own front-end or backend code paths can trigger expensive RPC calls at attacker-controllable volume, since that's the leverage point that turns "send a lot of eth_getLogs calls" into a self-inflicted outage.

DDoS Protection for a DeFi Protocol: The Front End Is Solved, the RPC Layer Isn't

The short answer

Front-end DDoS protection for a DeFi protocol is a solved, conventional problem — a website behind a CDN, no different from any other business. The RPC/API layer most protocols depend on to read and write on-chain state is a different problem, because most protocols don't own that infrastructure: they consume it from a managed provider like Infura, Alchemy, or QuickNode. Those providers genuinely defend their own network edge against volumetric floods — Alchemy's own published figures cite absorbing surges up to 500,000 requests per second. What they don't insure is your specific account getting rate-limited by its own compute-unit budget, which a handful of expensive, authenticated calls against your own API key can trigger without the traffic pattern ever looking like an attack from the provider's side.

Who this is for

This is written for the Head of Infrastructure, protocol engineering lead, or CISO at a Web3 or DeFi platform scoping what "DDoS protection" should mean for a protocol whose availability depends on both a conventional front end and a managed RPC/API layer it doesn't operate. It assumes your team is deciding what a DDoS protection engagement should actually cover, not just buying a mitigation product because one exists.

It is not for a protocol that self-hosts its own RPC nodes end-to-end with no managed-provider dependency — that architecture faces a more conventional infrastructure-DDoS problem, closer to what DDoS Protection for a Crypto Exchange already covers for a single-operator platform. If the concern is a routing-layer hijack redirecting users to a fraudulent front end rather than an availability problem, see Private Anycast for Web3 Infrastructure, which covers BGP hijacking and RPKI — a different attack surface entirely. If you're scoping an authorized stress test against a verifier or relayer network's failover logic specifically, DDoS Stress Testing for Web3 Infrastructure covers that testing question, not the protection-architecture question this post covers.

Why the front end and the RPC layer are different problems

A DeFi protocol's marketing site and dApp front end are a conventional web application: a domain, a CDN, and standard L3/L4/L7 DDoS mitigation apply exactly as they would to any other business's website. That part of the architecture has one operator — you, or whoever you've contracted to run it — and one trust boundary, the same shape a crypto exchange's or a casino's front-end DDoS problem already has.

The RPC/API layer breaks that shape. Most DeFi protocols don't run their own Ethereum or other-chain nodes at scale — they consume read and write access to on-chain state from a managed provider, because running enough geographically distributed, fully-synced nodes to match a managed provider's reliability is a specialized operational burden most protocol teams don't want to own. That means the infrastructure your dApp's core functionality depends on — quoting a price, checking a balance, submitting a transaction — sits behind an account with a third party, not behind your own mitigation stack, and "DDoS protection" for that layer means something different from deploying a scrubbing service in front of a server you control.

What your RPC provider's DDoS protection actually covers — and what it doesn't

Alchemy's own documentation describes network-layer protection built on Cloudflare, "reinforced by custom-built defenses at both L4 and L7 network layers," and states the platform has mitigated hundreds of high-intensity DDoS attacks, including surges up to 500,000 requests per second, without customer-facing downtime or degradation. That's real coverage, and it's the reason most protocol teams reasonably assume "DDoS protection" is already handled by the provider they're paying for RPC access.

What that network-layer defense doesn't cover is your own account's throughput ceiling. Alchemy's throughput documentation describes rate limiting measured in compute units per second (CU/s), evaluated over a rolling window, and — critically — configured at the account level rather than per individual app: "the combined usage of all your Alchemy apps counts toward your overall throughput limit." Exceed that account-wide allocation and every app under the account gets an HTTP 429 response, regardless of whether the traffic that caused it came from a real attacker, a runaway internal job, or simply more legitimate users than the account's tier was sized for.

This is a materially different failure mode from a flood:

	Network-layer DDoS	Account-level rate exhaustion
What triggers it	High-volume traffic aimed at the provider's infrastructure	Normal-looking, authenticated calls against your own API key that individually cost more compute units than expected
Who sees it first	The provider's own network-edge defenses	Your app, as 429 responses — the provider's DDoS layer never engages because nothing about the traffic looks like an attack
What stops it	The provider's Cloudflare/custom L4-L7 mitigation, which you don't configure	Your own request budget, rate-limiting, and provider failover — none of which the provider's DDoS protection manages for you
Blast radius	Typically scoped to the specific endpoint or app under attack	Every app sharing the account, per Alchemy's documented account-level pooling

The specific mechanism that makes this exploitable without a flood: RPC methods are not priced equally. Provider-published compute-unit tables show calls like eth_getLogs over a wide block range or trace_* methods costing dramatically more than a simple eth_blockNumber call — by design, because they genuinely require more backend work. A small number of expensive calls against your own account can exhaust a compute-unit budget that a much larger number of cheap calls wouldn't touch, and from the provider's side, every one of those calls is legitimate, authenticated traffic — there's nothing for a DDoS defense to flag.

What the 2020 Infura outage does and doesn't demonstrate

The November 11, 2020 Infura outage is frequently cited in Web3 infrastructure discussions, and it's worth being precise about what it actually shows. The root cause, per contemporaneous reporting, was a dormant consensus bug in an outdated Geth client version that Infura's nodes hadn't yet been patched against; when the Ethereum network split into two temporary chains following an unannounced network change, Infura's unpatched nodes followed the minority chain. MetaMask users couldn't transact, Uniswap's price feeds lagged, DappRadar ran at reduced capacity, and Binance paused ETH and ERC-20 withdrawals as a precaution. It was not a DDoS attack, and it wasn't an attack of any kind — it was a software and operations failure.

What it does demonstrate, independent of the specific cause: when a large share of an ecosystem's applications depend on a single infrastructure provider for RPC access, that provider's problem — whatever caused it — becomes every dependent app's problem simultaneously, with no failover unless one was already configured in advance. That's the same structural condition that makes account-level rate limiting a real availability risk regardless of whether the trigger is malicious. A DDoS protection strategy that only asks "can an attacker flood us offline" and never asks "what happens when our own provider account gets rate-limited, for any reason" is scoped to half the actual risk.

What a DDoS protection engagement should cover for this architecture

Document what your RPC provider's DDoS coverage actually insures against. Get the specifics — network-layer flood mitigation, request-per-second figures, what's excluded — rather than assuming "they have DDoS protection" means your account-level availability is covered.
Identify which of your own front-end or backend code paths can trigger expensive RPC calls at attacker-influenced volume. A public-facing feature that lets a user (or a bot) trigger repeated wide-range eth_getLogs calls, directly or indirectly, is a lever an attacker can pull without ever sending a packet your provider's DDoS defenses would notice.
Have a second RPC provider configured and tested before you need it, not provisioned during an incident. A runbook that says "switch providers" without a pre-configured, pre-tested fallback endpoint is a plan to spend the first hour of an outage doing setup work.
Write the 429 runbook. Define what your application does when the primary provider starts rate-limiting: degrade gracefully, queue and retry, or fail over — and decide that in advance, not while users are already seeing errors.
Size your provider tier and account structure to your actual traffic profile, including whether pooling multiple apps under one account (which most providers default to) creates a shared blast radius you didn't intend.

Limitations

This does not cover front-end DDoS protection specifically — that's a conventional CDN/mitigation problem covered by the same architecture as DDoS Protection for a Crypto Exchange or any standard web app. It does not cover BGP-level routing attacks against your own Anycast infrastructure, which is a different threat model addressed in Private Anycast for Web3 Infrastructure. It does not cover the verifier/relayer trust-logic testing addressed in DDoS Stress Testing for Web3 Infrastructure. It does not make claims about any specific RPC provider's actual uptime, pricing, or SLA terms beyond what each provider's own published documentation states, and it does not recommend a specific provider.

Decision and next step

If your protocol depends on a managed RPC provider — which most do — your DDoS protection strategy has to cover two separate risk surfaces: the front end, which is a solved problem, and the RPC/API layer, where your provider's network-layer defenses don't extend to your own account's rate limits. Review your DDoS architecture with us; the DDoS Protection engagement scopes the provider strategy, runbooks, and failover design for exactly this dependency, not just the front-end mitigation stack most generic engagements default to.

Sources and review

Alchemy's network-layer DDoS mitigation description and the 500,000 requests-per-second figure are drawn directly from Alchemy's own Firewall product page. The account-level compute-units-per-second throughput model, the 10-second rolling window, and the 429 rate-limiting behavior are drawn directly from Alchemy's own throughput documentation. The relative cost of RPC methods such as eth_getLogs and trace_* calls versus simple calls is corroborated by independent RPC-infrastructure analysis at OnFinality's rate-limits explainer. The November 11, 2020 Infura outage's root cause, duration-relevant timeline, and customer impact (MetaMask, Uniswap, DappRadar, Binance) are cross-checked against two independent accounts: CryptoSlate's contemporaneous reporting and Decrypt's contemporaneous reporting, both explicit that the cause was a consensus/software bug, not an attack. AnySec's DDoS Protection service scope and methodology are drawn from our own published service terms; no new AnySec-original statistic is introduced in this post. Author: AnySec Engineering. Published 2026-09-28.