What is BGP hijacking, and how is it different from a DDoS attack against Web3 infrastructure?

DDoS attacks flood a target with traffic until legitimate requests can't get through — it's a capacity problem, and it's what Anycast, rate limiting, and scrubbing are built to absorb. BGP hijacking is a routing-integrity problem: an attacker announces a false claim to someone else's IP address block, and networks that don't validate the claim start sending that traffic to the attacker instead of the real destination. No flood is involved — from the target's own dashboards, nothing looks wrong, because the target's own legitimate traffic volume hasn't changed. The attacker is intercepting a slice of users before they ever reach the real infrastructure, typically to serve a malicious version of a frontend script or a wallet-connect payload.

What actually happened in the KLAYswap and Celer Bridge incidents?

On February 3, 2022, a rogue autonomous system (AS9457) hijacked BGP routes for developers.kakao.com and served a tampered version of a Kakao SDK JavaScript file that KLAYswap's frontend loaded. The altered script intercepted transaction approvals; over roughly two hours, attackers redirected 407 transactions across 325 wallets, taking approximately $1.9 million. On August 17, 2022, Celer Bridge users were hit by a similar pattern — malicious contracts deployed across multiple chains, then a BGP hijack used to obtain a valid TLS certificate and redirect users to a compromised frontend with altered contract addresses, for a loss of roughly $235,000 over about three hours. Neither incident required breaking the underlying smart contracts; both relied entirely on redirecting users at the network layer before their transaction requests reached the real frontend.

Does owning a private Anycast network with your own ASN actually stop this from happening?

It doesn't stop a hijack from being announced — anyone can announce a false route for any prefix; that's the underlying gap in BGP that RPKI exists to close. What owning your own ASN and IP blocks changes is who's allowed to author a Route Origin Authorization (ROA) for your prefixes in the first place: only the entity registered as the holder of an IP block with the Regional Internet Registry can create a valid ROA for it. If your frontend or RPC endpoint runs on IP space leased or shared through a hyperscaler, you have no standing to publish a ROA for it — the hyperscaler does, if it chooses to. Own the ASN and the prefix, and your team (or ours, under an operations retainer) can publish and maintain ROAs, so that any network performing Route Origin Validation rejects an unauthorized announcement for your addresses outright.

If RPKI depends on other networks validating routes, doesn't that mean it might not work anyway?

That's a real limitation, not a technicality to wave away. Route Origin Validation only rejects an invalid announcement on networks that have actually turned ROV enforcement on — an unenforced ROA doesn't stop anything by itself. Adoption has grown substantially among tier-1 and major transit networks, but it isn't universal, and a hijack that only needs to fool one non-enforcing network somewhere on the path can still get through in places. What a ROA does unconditionally is remove any ambiguity about which announcement is legitimate — every network that does check gets a definitive answer instead of having to guess. It raises the bar and shrinks the attack surface; it doesn't make a hijack attempt impossible everywhere on the internet.

Is this the same service as the DDoS-focused private Anycast case for a crypto exchange?

No — different failure mode, same underlying ownership decision. Private Anycast for a crypto exchange is about mitigation-priority contention on a shared edge during a volumetric attack: you're waiting in a queue behind other tenants. This is about route-level integrity: whether anyone, including an attacker with no relationship to your business, can successfully claim your IP addresses as their own on the internet's routing table. Both risks point toward the same architectural answer — own your ASN and IP blocks — but they're evaluated and defended against differently, and a platform can be well-protected against one while still exposed to the other.

Private Anycast for Web3 Infrastructure: The BGP Hijack DDoS Protection Misses

The short answer

BGP hijacking is a routing-layer attack, not a traffic-volume attack: someone falsely announces ownership of your IP address block, and any network that doesn't validate the claim starts sending your users' traffic to them instead of you. It's how attackers redirected KLAYswap and Celer Bridge users to malicious infrastructure in 2022, taking a combined $2.1M+ without touching a single smart contract. DDoS protection doesn't see this coming — nothing about a hijack looks like a flood of traffic. The one real defense, publishing a Route Origin Authorization (ROA) under RPKI, is only legally available to whoever is registered as holding the IP prefix — and on a hyperscaler's shared or leased address space, that's never the tenant.

Who this is for

Head of Infrastructure, CISO, or protocol engineering lead at a Web3 or DeFi platform running its own frontend hosting, RPC endpoints, bridge relayers, or wallet-integration servers — anywhere a user's browser or wallet has to reach an off-chain server before a transaction gets signed. It doesn't apply to a project whose only public surface is a smart contract with no centralized delivery path for a frontend or SDK; there's nothing for a hijack to redirect a user toward in that case. If the concern is DDoS mitigation-priority contention on a crypto exchange's trading platform rather than routing integrity, see private Anycast for a crypto exchange. If the question is whether private Anycast makes sense at all, independent of either risk, building a private Anycast edge from scratch covers the account-ban, cost, and ownership case generally.

The threat model: what a BGP hijack actually does

BGP, the protocol that decides how traffic finds its way across the internet, was built without any way to verify that a network announcing a route to an IP address block is actually authorized to do so. Any autonomous system can announce "send me traffic for this prefix," and by default, other networks have no built-in way to tell a legitimate announcement from a false one. Most of the time nobody bothers to lie, so the system works. When someone does lie — deliberately or through misconfiguration — some fraction of the internet's routers can start sending real traffic to the wrong place, for as long as the false announcement stays live and unchallenged.

Two incidents in 2022 show what that looks like against Web3 infrastructure specifically:

Incident	Date	Duration	Mechanism	Loss
KLAYswap	2022-02-03	~2 hours	Rogue AS9457 hijacked routes for developers.kakao.com, serving a tampered Kakao SDK script that KLAYswap's frontend loaded	~$1.9M (407 transactions, 325 wallets)
Celer Bridge	2022-08-17	~3 hours	Malicious contracts deployed cross-chain, then a BGP hijack used to obtain a valid TLS certificate and redirect users to a compromised frontend	~$235K

Neither hijack required breaking a smart contract, guessing a private key, or exploiting a wallet bug. Both required exactly one thing: convincing enough of the internet's routers, for long enough, that the attacker's network was the legitimate origin for a block of IP addresses it didn't own. That's a gap no amount of smart-contract auditing, wallet security review, or DDoS mitigation tuning closes, because none of those controls sit at the routing layer where the attack actually happens.

Why ownership — not DDoS protection — is the control that matters here

The fix the internet standards bodies converged on is RPKI (Resource Public Key Infrastructure): a system where the holder of an IP address block can cryptographically sign a Route Origin Authorization stating which autonomous system is allowed to originate routes for that prefix. Networks that perform Route Origin Validation (ROV) check incoming route announcements against published ROAs and can reject ones that don't match — an unauthorized announcement for a validated prefix simply gets dropped instead of propagated.

The part that matters for a buy-vs-build decision: only the registered holder of an IP block can create a valid ROA for it. That's not a policy choice AnySec or any other vendor can override — it's how the Regional Internet Registries (RIPE, ARIN, APNIC, and the others) are structured. Which means the question "can we protect ourselves against a KLAYswap-style hijack" collapses into a much narrower one: who actually holds the registration for the IP addresses our frontend, RPC endpoint, or bridge relayer runs on?

	Shared or leased hyperscaler IP space	Private Anycast — your own ASN + prefix
Who can publish a ROA for the prefix	The hyperscaler, if and when it chooses to	You
Who decides ROV enforcement policy on your traffic	The hyperscaler's routing configuration	Your own BGP announcements and peering relationships
Visibility into route announcements for your own addresses	Whatever the hyperscaler's dashboard exposes	Full visibility — it's your ASN
Recourse if a hijack goes unaddressed	A support ticket into someone else's priority queue	Your own network team acts directly

This is the same ownership argument made generally in building a private Anycast edge from scratch — account-ban exposure, jurisdictional choke points, opaque routing — applied to a risk that's specific to any platform with an off-chain component a user has to reach: on shared infrastructure, you're not just dependent on someone else's account-standing decisions, you have no legal standing to author the one cryptographic control that stops this specific attack.

What's delivered, and what it doesn't include

A private Anycast engagement follows the same methodology regardless of the reason a buyer is pursuing it:

PoP location selection based on the platform's actual traffic profile
ASN registration and IP-block (IPv4/IPv6) coordination
Anycast announcement and BGP setup across the selected PoPs
Failover and health-check configuration
Fault-injection and throughput validation before sign-off

That's the Global Private Anycast Network Setup engagement. It gets you to the point where your team — or AnySec's, under a separate operations retainer — has legal standing to publish and maintain ROAs for your own prefixes. Publishing and monitoring those ROAs on an ongoing basis isn't a line item inside the base Setup deliverables; it's an operational responsibility that only becomes possible once ownership transfers to you, the same way ongoing BGP monitoring is scoped separately from initial deployment.

Limitations

RPKI and ROV raise the bar; they don't make a hijack attempt impossible everywhere. Route Origin Validation only protects you on networks that have actually enabled it — adoption has grown but is uneven, and a hijack that fools even one non-enforcing network somewhere along the path can still reach some users. RPKI also doesn't address every way an attacker can redirect a user to fake infrastructure: DNS-level attacks that don't touch BGP at all, phishing unrelated to routing, and compromised frontend build pipelines are all separate problems this control doesn't touch. It's not a substitute for standard frontend hardening — TLS pinning, subresource integrity, and (per CertiK's own recommendation after the incidents above) considering content-addressed hosting like IPFS as a defense layer that doesn't depend on location-based routing at all. Owning your ASN and prefix is a necessary precondition for defending against this specific attack class; it isn't a complete answer to it on its own.

Decision: do you actually hold the registration for your own IP addresses?

Before this becomes an Anycast-architecture decision at all, it's worth answering a narrower question first: for the IP addresses your dApp's frontend, RPC endpoint, or bridge relayer actually run on, who is registered with the Regional Internet Registry as the holder — your team, or your hosting provider? If it's the provider, the RPKI defense against a KLAYswap-style hijack isn't something more DDoS spend or a better CDN plan can buy you; it's entirely out of your hands until the addresses are yours. If that's the situation and it's not one your team is comfortable with, request a network design review and we'll scope PoP locations, ASN and IP-block coordination, and BGP setup against your actual traffic profile.

Sources and review

The KLAYswap and Celer Bridge incident details — dates, mechanisms, and loss figures — are drawn from CertiK's analysis of BGP hijacking incidents, which also states CertiK's own recommended mitigations (RPKI/ROA/ROV/BGPSec coordination with network providers, IRR filtering, and IPFS-based content addressing as a complementary defense). The KLAYswap facts — the AS9457 rogue-announcement mechanism, the $1.9 million figure, the two-hour window, and the 407-transaction/325-wallet count — are independently corroborated by The Record's coverage of the incident. RPKI, ROA, and Route Origin Validation mechanics are described per RIPE NCC's official documentation. Anycast methodology, deliverables, and pricing reflect AnySec's own published service terms; no AnySec-original attack, cost, or performance statistic is cited in this post. Author: AnySec Engineering. Published 2026-09-08; last reviewed 2026-09-08.