DDoS Protection for a Crypto Exchange: When the Trading Surge Looks Like the Attack

The short answer

A crypto exchange's DDoS protection has to solve a problem a casino and a bank don't share: its own legitimate traffic can spike to attack-like multiples without warning, and the traffic doing the spiking — retail and algorithmic orders hitting the same trading-API paths an attacker would target — has no separate identity a rate limiter can key off of. Tune the anomaly thresholds too tight and you throttle real traders during the exact window your platform is worth the most. Tune them too loose and a genuine attack rides in behind the noise of a volatile market.

Who this is for

This is written for a CTO or Head of Infrastructure at a crypto exchange who already has DDoS protection in place — Cloudflare, AWS Shield, Akamai, or a comparable provider — and has confirmed it handles routine attack volume. It's not for the earlier decision of whether to own a private Anycast edge instead of leasing shared protection; that's a separate, already-published question covered in private Anycast for a crypto exchange, which this post doesn't repeat. This post is about a narrower, specific failure mode: what happens to your DDoS rules the day trading volume itself does what an attack usually does.

Why this is a different traffic-shape problem than a casino or a bank has

DDoS protection for any platform starts from the same question: how do you tell attack traffic from legitimate traffic when both can produce a request-rate spike? The answer depends entirely on what "legitimate" looks like for that platform, and it looks different in each of the three verticals this architecture gets built for.

• A casino's legitimate traffic is uniform. Players hitting login, odds feeds, and cashier endpoints produce a request pattern that's predictable in shape even when it spikes during a major sporting event — the four-layer architecture built for that rate-limits per session and per endpoint class because the traffic itself doesn't change character during a surge, just its volume.
• A bank's legitimate third-party traffic is identity-verified before it arrives. Open-banking regulation already requires third-party providers to authenticate with qualified certificates before their calls reach the API, so a digital bank's DDoS layer can key rate budgets to that registered identity instead of guessing from request shape alone.
• A crypto exchange's legitimate traffic has neither property. Retail and algorithmic clients place real orders through the same trading-API and WebSocket paths an attacker would probe, using the same unauthenticated-looking connection patterns, and the volume of that traffic can multiply by several times in the space of minutes — driven by nothing more than a price move that has nothing to do with an attacker.

That third case is the one without a clean structural fix. There's no registered-TPP identity to key limits to and no uniform traffic shape to rate-limit against, because the surge and the baseline are made of the same kind of request.

How large a legitimate surge actually gets

The scale of that ambiguity isn't hypothetical. Kraken's own engineering team published a detailed account of what a real volatility event did to their platform's load. When Bitcoin broke through $120,000 for the first time in mid-July 2025 and then rallied above $123,000 within days, the surge in trading activity was enough that, in the exchange's own words, "some clients hit errors" during that window — a legitimate-demand event large enough to degrade service on its own, with no attacker involved.

Kraken's response afterward is the useful part for a DDoS-protection conversation: they didn't just add capacity, they changed their standard. Every load test since has had to prove the platform "has to survive at least twice the heaviest load it has ever handled in production" before it ships — full-scale "war games" that throw a manufactured flood of trading activity at production systems to find the breaking point before clients do. That discipline paid off on February 5, 2026, during what the team called one of the sharpest selloffs of the past twelve months: every major service held with no incidents, across a platform now sustaining more than 230,000 successful requests per second in production. Kraken estimated that a full outage on that specific day — a forced-liquidation cascade, the kind of event where staying online matters most — would have cost $719,000 an hour.

None of that is a DDoS statistic; Kraken's account doesn't attribute the July 2025 errors to an attack, and this guide isn't claiming it was one. It's cited here for a narrower, verifiable point: a real exchange's legitimate, price-driven traffic surge reached a magnitude large enough to cause errors on its own, and the fix that mattered was rebuilding around a headroom standard, not a fixed threshold. A DDoS anomaly rule sized to "normal" traffic has to survive exactly that same kind of surge without either failing to catch a real attack riding in in parallel, or blocking the legitimate spike it was never designed to expect.

Why the standard anomaly-detection model struggles here

This isn't a gap unique to any one vendor — it follows from how Layer 7 DDoS detection is designed to work everywhere. AWS's own Shield Advanced documentation is explicit about the mechanism: Shield Advanced "monitors application traffic and compares it to historic baselines looking for anomalies," covering both total volume and traffic composition, and requires "a statistically significant deviation in both" before it declares an event. That baseline-comparison approach is exactly why the documentation also recommends associating protection "at least 24 hours before any planned event that might cause unusual patterns in your web traffic," and notes detection "is most accurate when it has observed 30 days of normal traffic."

That guidance works well for a sale that runs on a schedule. It assumes the operator knows the surge is coming and can tell the provider in advance. A market crash or a listing-driven rally doesn't send a 24-hour notice — the surge and the detection window arrive at the same moment, which is precisely when a baseline-driven system is least equipped to tell "this is 8x normal volume because the market moved" from "this is 8x normal volume because someone is attacking us."

Vertical	What makes legitimate traffic identifiable	What the DDoS layer keys rate limits to
Online casino	Uniform first-party shape; spikes in volume, not character	Per-session and per-endpoint limits
Digital bank	Third-party callers pre-authenticated via QWAC/QSeal certificates	Per-registered-TPP identity
Crypto exchange	Neither — surge and baseline are the same population of orders	Volatility-aware thresholds, not a flat rate

What a DDoS Protection engagement actually tunes for this

The architecture doesn't change from the four layers used everywhere else — network absorption, application-layer filtering, origin isolation, a rehearsed runbook. What changes for an exchange is how Layer 2 gets configured:

1. Baseline the anomaly thresholds against your own volatility range, not a generic default. A rule sized for a "normal" e-commerce site's traffic pattern will trip on a routine crypto trading day; the threat-modeling step in a DDoS Protection engagement has to use your platform's own historical request-volume range across quiet and volatile periods as the baseline, not a provider's out-of-the-box setting.
2. Separate volumetric absorption from order-path rate limiting. Network-layer absorption (Layer 1) can and should stay aggressive regardless of cause — there's no downside to soaking a volumetric flood whether it's an attack or a legitimate spike. The judgment call belongs entirely at Layer 2, on the specific endpoints (order placement, order-book queries, WebSocket subscriptions) where throttling a real trader is its own outage.
3. Give the on-call engineer a triage decision, not just an alert. The runbook needs a named owner and a fast decision path for "is this an attack or a volume event," because guessing wrong in either direction is costly — under-mitigating a real attack, or rate-limiting your own highest-volume trading window.
4. Validate with a stress test shaped like your own volatility, not a generic ramp. An authorized DDoS stress test that only ramps volumetric load in one direction doesn't test whether your Layer 2 rules survive a traffic pattern shaped like an actual price-driven surge — order bursts, WebSocket reconnect storms, uneven endpoint distribution.

That's what a DDoS Protection Strategy engagement reviews for an exchange specifically: architecture, provider tuning, and SOC runbooks built against your own trading-volume history, not a template built for a platform whose traffic doesn't move the way yours does.

Limitations

This isn't a claim that anomaly-based DDoS detection is broken or that any specific provider handles crypto exchange traffic poorly — Shield Advanced's documented baseline approach is a reasonable design for the traffic patterns most of its customers have. The gap is specific to platforms where legitimate demand can multiply by several times with no advance notice, which describes a crypto exchange more than most other verticals this architecture gets built for. It's also not an argument against private Anycast or any specific vendor — the queue-priority question covered in private Anycast for a crypto exchange is a separate decision from the rate-limiting tuning covered here, and the two don't substitute for each other. No customer-specific outage data or attack statistics are cited for AnySec's own engagements.

Decision: is your rate-limiting rule tuned to your traffic, or a template?

If your current DDoS provider has never been tested against a genuine volatility spike — not a scheduled load test, an actual price-driven surge — the honest way to find out is to check whether your Layer 2 thresholds were set against your own trading-volume history or copied from the provider's default. If you don't know the answer, review your DDoS architecture and we'll map your anomaly rules against your actual traffic range before the next volatile day makes the gap visible for you.

Sources and review

Kraken's account of the mid-July 2025 Bitcoin $120K/$123K trading surge, the resulting "some clients hit errors" outcome, the subsequent 2x-headroom load-testing standard, the February 5, 2026 selloff performance, the 230,000 requests-per-second sustained capacity figure, and the $719,000-per-hour estimated outage cost are drawn directly from Kraken's own engineering blog post, "War games: how we built Kraken to handle 10x the load" — third-party public data, not an AnySec claim, and Kraken's post does not attribute the July 2025 errors to a DDoS attack. AWS Shield Advanced's Layer 7 baseline-detection mechanism, the 24-hour pre-announcement recommendation, and the 30-day baseline-accuracy note are drawn directly from AWS's own Shield Advanced documentation. 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-06; last reviewed 2026-09-06.

---

Related reading

• Private Anycast for a Crypto Exchange: When Shared DDoS Protection Isn't Enough — the separate decision of who controls mitigation priority during a shared-edge attack wave, distinct from the rate-limiting tuning covered here.
• DDoS Protection for Digital Banks: The Uptime-Budget Problem — how a bank solves its own version of this ambiguity using pre-authenticated third-party identity, which an exchange's trading traffic doesn't have.
• How to protect an online casino from DDoS attacks — the four-layer architecture this guide adapts for a traffic population that isn't uniform.
• DDoS testing sign-off: AWS vs Cloudflare — the authorization chain for validating an exchange's edge under an authorized stress test.