Picture the entrance to a crowded venue.
Most people belong there. A few do not, and the difficult ones have watched the regulars closely enough to imitate them. The person at the door cannot stop the line to investigate every arrival, and sometimes the decision depends on what someone did thirty seconds ago rather than what they are doing now.
Admit too many of the wrong people and the venue becomes unusable. Become too aggressive and you create the disruption yourself by turning away the people you were meant to protect.
Now replace the queue with network traffic and accelerate it until arrivals are measured in hundreds of millions of packets per second.
That is the problem Wirescope is built to solve.
Today we are launching Wirescope, a network combining IP transit with inline DDoS mitigation for infrastructure where being technically online is not enough.
At its simplest, Wirescope behaves like an ISP. Customers connect to our network, bring their own address space or use ours, establish BGP where appropriate, and exchange traffic normally. The difference is that mitigation is built into the network path rather than bolted on beside it.
That model comes out of a specific history. Wirescope was founded by Erik Buckingham, who spent years building mitigation for Minecraft servers and other latency-sensitive infrastructure at ProxyPipe, and the people around him come from the same part of the industry: game hosting, network operations, and mitigation platforms.
ProxyPipe protected game servers during the period when Mirai changed what a botnet could do, and it was targeted by that botnet directly. Defending the most-attacked corner of the internet teaches both halves of this problem quickly. The first is technical: attack traffic aimed at a game is deliberately shaped to look like players, so filtering has to understand the application rather than simply count packets. The second is commercial, and we return to it near the end of this article, because the cost of defending customers is how a mitigation provider usually loses.
Wirescope is the network we wanted to exist during those years: transit we control, filtering built into the forwarding path, and a business model that does not quietly penalize the customers who get attacked.
We are beginning with gaming because it is where we come from, and because it is an unforgiving environment in which to prove that model. Latency matters, packet loss matters, sessions persist, and poor decisions in the network become immediately visible to the people using it.
Gaming is the starting point, not the boundary. Wirescope is being built for individual operators, hosting networks, larger real-time platforms, and infrastructure providers with customers of their own.
Whatever the workload or scale, the standard is the same: during an attack, the service behind the protection should continue to function, not merely remain reachable.
Why gaming is a useful test
Web applications can absorb or conceal transient network failures remarkably well. Content can be cached, requests retried, traffic distributed across replicas, and a failed page load repeated without lasting consequence.
A live multiplayer session affords far less tolerance. The player needs a continuous path to the machine holding the state of that session. A packet that arrives too late may be as useless as one that never arrives, and thirty seconds of disruption can empty a server that took hours to populate.
This exposes an important distinction in DDoS mitigation.
A prefix may remain announced and a server may continue responding to probes. A monitoring system may report that 99.9% of an attack was filtered. Yet if the remaining traffic overwhelms the destination, or the filtering removes enough legitimate players, the service is still offline in every meaningful sense.
We do not think "online" should mean online only below a particular attack size; online after a route diversion that materially worsens latency; online with enough packet loss to make a real-time application unusable; or online only while the upstream carrying the attack remains willing and able to carry it.
The relevant question is not simply how much hostile traffic the mitigation system discarded. It is what happened to legitimate users while it was doing so.
Reaction time is part of that standard.
Cloudflare reported that 89% of network-layer DDoS attacks it observed in Q3 2025 ended in under ten minutes. Its later 31.4 Tbps Aisuru event lasted roughly 35 seconds. An attack can arrive, do the damage, and disappear before a response process built around investigation, manual intervention, or route diversion has completed.
For a game server, that distinction is immediate. By the time someone notices that players are disconnecting and begins moving traffic, the server may already be empty.
Your port speed is not your threat ceiling
Headline attack figures tend to read as somebody else's problem. If you run a community game server on a 1 Gbps port, a handful of racks, or a small platform nobody outside your customers has heard of, a 30 Tbps botnet sounds like something that happens to banks, exchanges, and hyperscalers. Nobody is going to aim thirty terabits at you, and even if they did, your port would fill roughly thirty thousand times over before the attack noticed.
That reasoning is understandable, and it is wrong in two ways.
The first is that the attack does not begin at the customer-facing port.
Before traffic reaches that interface, it may already have crossed access networks, interconnections, carrier links, edge routers, and mitigation infrastructure shared with many other customers.
Consider a botnet of one million broadband devices, each contributing 20 Mbps. Twenty megabits per second is unremarkable on a modern residential connection. In aggregate, those devices can generate 20 Tbps.
A 30 Tbps attack does not need to fit through a 1 Gbps port to take a service offline. It only needs to exhaust something important along the path.
The second is that the attack does not have to be aimed at you at all.
Cloudflare's Q3 2025 DDoS Threat Report, citing reporting by KrebsOnSecurity, noted widespread collateral disruption associated with Aisuru. Many infected systems sat inside consumer access networks, meaning those networks were carrying enormous volumes of attack traffic generated by their own subscribers.
That distinction matters. An access provider does not merely receive the flood near its destination; it may first have to carry traffic generated throughout its own subscriber base. If enough hostile traffic originates inside one of those networks, the access network itself, or its interconnection with one of our carriers, can become impaired before the packets ever reach a Wirescope router.
A filter cannot repair a congested path it never gets to see.
It also changes what a blunt response costs you.
The devices in a modern IoT botnet are not sitting in some clearly hostile corner of the internet that can be cleanly separated from your customers. They are cameras, routers, and set-top boxes inside consumer broadband networks: the same access networks your players, viewers, and customers connect from. Aisuru made that unusually visible, but it is a property of every large IoT botnet.
That makes the coarse tools self-defeating in a way they were not when attack traffic mostly came from compromised servers in datacenters.
Blackholing the destination finishes the attacker's work; that is the RTBH tradeoff, and it is sometimes still the right call. Filtering by source ASN or by country disconnects a slice of your own customer base, because the botnet is inside the same ASNs and the same countries. And allowing a port to saturate is the least discriminating option of all: congestion is not a filter. A full link drops packets according to arrival timing rather than intent, so the legitimate one percent is discarded at the same rate as the hostile ninety-nine.
Saturation was always a bad outcome. It is a worse one now, because the traffic you are indiscriminately discarding is arriving over the same paths as your revenue.
This matters at every scale. A hosting customer cares whether another tenant's attack can saturate shared infrastructure. A host cares whether one customer's incident can become a network-wide outage. A mitigation provider has to ensure that the largest attack on its platform does not consume the infrastructure protecting everybody else.
A mitigation provider therefore has to be engineered around the largest event that can reach its shared edge, not merely the port speed of the individual customer being attacked.
The customer's own port may not even be the first limit at the destination. A game server can exhaust CPU, connection state, NIC processing, kernel resources, or game-loop capacity long before the physical interface is full. The meaningful threshold is the weakest resource across the entire path from source to application.
A protected 1 Gbps service does not need 30 Tbps of connectivity to its origin. It needs to sit behind an architecture capable of confronting a 30 Tbps-class event without allowing that event to collapse the shared infrastructure in front of it.
During 2025, Cloudflare reported Aisuru attacks reaching 29.7 Tbps and 14.1 billion packets per second, followed later by an event reaching 31.4 Tbps.
The headline number is impressive. What matters to us is the architecture required to survive it.
Bandwidth is only part of the problem
At minimum Ethernet frame sizes, a 100GbE interface can receive roughly 148.8 million packets per second. A 400GbE interface can receive approximately 595 million.
Expressed as time, minimum-size frames can begin arriving about every 6.72 nanoseconds on 100GbE and every 1.68 nanoseconds on 400GbE.
A packet-processing system does not need to complete an entire classification decision within that interval. Modern dataplanes rely heavily on pipelining and parallelism. The system does, however, have to accept new work at that rate.
The doorman does not literally have 1.68 nanoseconds to think. Another arrival can be at the door 1.68 nanoseconds later.
At 14.1 billion packets per second, the Aisuru event was roughly equivalent to the maximum minimum-frame packet rate of almost twenty-four saturated 400GbE interfaces.
Transporting that traffic and making useful decisions about every packet are different engineering problems.
Some attacks are inexpensive to classify. Others are deliberately constructed to resemble legitimate application traffic. For a game protocol, a useful decision may depend on whether a client completed a valid handshake, which stage of the protocol it has reached, how quickly packets are arriving, whether the sequence is plausible, and what happened earlier in the session.
This is where the problem at the door returns. The packet currently in front of the filter is not always enough to determine whether it belongs.
That introduces state, and state creates additional resources an attacker can target. Memory matters. Lookup cost matters. Connection-creation rates matter.
The mitigation system has to learn enough about a session to distinguish a legitimate user without allowing the process of learning about that session to become the denial-of-service vector itself.
If something resembling a legitimate session causes resources to be allocated, an attacker can create enormous numbers of apparent sessions. If one protocol transition is substantially more expensive to process, traffic can be constructed to force the classifier repeatedly through it.
Two attacks with identical bandwidth can therefore impose very different workloads.
This is why we are reluctant to describe mitigation capability with a single aggregate capacity number.
Capacity exists on particular ports, paths, interconnections, routers, processors, and memory systems. A network can have terabits of total transit while the relevant exchange port is only 10 Gbps. External interfaces can be larger than the transport path toward the filtering layer. Routers can retain forwarding headroom while the classifier has exhausted packet-processing capacity, and the classifier can sustain packet rate while running out of session state.
Capacity in Amsterdam cannot rescue a saturated port in Ashburn.
An attacker only needs to exhaust the resource standing between a legitimate user and the application.
Filtering accuracy presents the same problem from another direction.
At 30 Tbps, one percent leakage is 300 Gbps. A tenth of one percent is 30 Gbps. Even one hundredth of one percent is still 3 Gbps.
For a customer with a 1 Gbps interface, that last figure alone is three times the capacity of the entire port.
"99.99% mitigated" can still mean "offline."
Dropping more indiscriminately is no better. A filter that removes legitimate sessions together with the attack has simply created its own denial of service.
The difficult part is not dropping packets. It is deciding which packets can safely be dropped, quickly enough for the decision to remain useful.
Mitigation that was already running
For most of the industry's history, "quickly enough" meant several minutes.
The commercial model was detect, then divert, then mitigate. Flow telemetry identifies an anomaly, the customer's prefix is announced toward a scrubbing centre, routing converges, traffic starts arriving where the filters are, and mitigation begins. Vendors still publish those as three separate commitments — time to detect, time to divert, time to mitigate — which is itself an admission that a gap exists between them.
The gap is not small. Flow-based detection typically propagates in two to three minutes, and global BGP convergence after a diversion announcement takes minutes more. An on-demand scrubbing model leaves that entire window exposed, and a short attack can start and finish inside it.
For a website, several minutes of degradation is a bad afternoon. For a game server, it is the whole incident. Sessions are already gone, players have already joined a competitor's server, and the mitigation arrives in time to protect an empty lobby.
That constraint is where Erik's work at ProxyPipe started. Rather than detecting an attack and then moving traffic to the filtering, the filtering sat permanently in the path across mitigation points in Los Angeles, Reston, and Amsterdam, with customers able to announce prefixes over BGP and receive clean traffic back over tunnels or interconnects. Time to mitigate was not a response time. It was the time it took a packet to cross a filter that was already running.
It is worth putting that against the calendar. The proxypipe.com domain was registered in 2012 — the Internet Archive's first capture that October is still the registrar's parking page — and by June 2014 the company was absorbing the largest attack Verisign had recorded, which we come back to later in this article.
Look at what a game host could actually buy at that moment. Prolexic, founded in 2003 as the first in-the-cloud mitigation platform and acquired by Akamai in December 2013 for $370 million, ran scrubbing centres on the detect-and-divert model, as did Verisign and Neustar. Black Lotus launched Protection for Networks for datacentres and service providers in January 2013. Always-on filtering was not unheard of, but where it existed it was largely a property of a hosting provider's own platform, the way OVH's VAC was bundled with OVH servers. The reverse proxies of the period were built for websites and terminated protocols a game server does not speak.
So the options in front of a Minecraft host in 2013 were roughly: diversion-based scrubbing measured in minutes, a web proxy that could not carry the traffic, or somebody else's always-on filter provided you also moved your servers into their datacentre. Permanent in-path filtering, tuned for game protocols, in front of infrastructure the customer had already chosen, was not the standard shape of the market.
We would rather draw that correlation than claim a record we cannot document. The relevant point is not who was first; it is that the requirement is older than the vocabulary. "Always-on" and "instant time to mitigate" are marketing phrases now. For us they are inherited constraints, because the alternative was watching a customer lose their players during a diversion window.
ProxyPipe was simultaneously buying diversion-based scrubbing from Verisign as a volumetric backstop while doing its own filtering inline. That shape — always-on filtering close to the customer, with a hyperscale layer behind it for the events that outgrow the edge — is the same one we run today.
Protection should be part of the network
We want the complexity required to make those decisions to remain on our side of the connection.
DDoS mitigation is often delivered through additional tunnels, proxies, forced return paths, DNS changes, or separate protected services. These techniques solve legitimate engineering problems, and there are circumstances in which they are appropriate.
We regard them as tools, not prerequisites.
It is worth being precise about why those requirements exist, because they are rarely there for the customer's benefit. A proxy terminates the session so that something stateful has a place to watch it. A forced symmetric return path exists so that a device can observe both directions of a flow before it will judge one of them. A DNS change exists so the provider can move traffic without touching your routing. Each one is a workaround for a filter that cannot reach a correct decision from the inbound direction alone, at line rate, in the path.
They are crutches. Useful ones, occasionally necessary ones, but crutches — and every one of them is a constraint the mitigation provider has exported to the customer's architecture. We would rather carry that constraint ourselves.
When Wirescope is already carrying a customer's traffic, mitigation should be a property of that network path. Applications do not need to know that filtering is taking place. Servers do not require agents. Customers do not need to insert another application proxy merely to receive protection, and return traffic does not need to traverse Wirescope simply so that inbound filtering can function.
In the common case, onboarding should be a network operation rather than an application migration: establish connectivity, exchange routes, apply the appropriate policy, and carry traffic.
For a hosting provider, that can mean announcing a customer prefix once and allowing the workloads behind it to inherit protection without per-server agents, DNS changes, application proxies, or customer-side migrations. If the preferred return path is elsewhere, inbound mitigation should not require return traffic to come back through Wirescope merely to preserve protection.
That simplicity matters when one application becomes ten thousand servers or hundreds of routed customer prefixes.
The same model applies to other mitigation providers. A provider may already have detection systems, filtering logic, automation, a portal, a brand, and customers of its own. It may simply need protected transit, additional capacity, regional reach, attack overflow, or another layer beneath its existing product.
We want Wirescope to work there too. A host can build protected services on our network without us competing for its hosting customers. Another mitigation provider can use our infrastructure beneath its own brand without replacing the product it has already built.
Sometimes the most useful place for us is underneath.
The philosophy extends to transit itself. A customer should not have to choose between behaving like a normal BGP network and receiving DDoS protection.
Customers can bring their own address space, establish BGP, exchange ordinary routes, and retain control of their routing policy. Adding prefixes or changing policy should remain routine network operations rather than security-product upgrades. We do not want basic ISP functionality hidden behind unusual forwarding requirements or layers of per-prefix complexity.
Customers should also be able to use the capacity they purchased for legitimate traffic without redesigning their applications around restrictions imposed because the mitigation system finds the workload inconvenient.
Every network has real technical limits. We would rather state those limits directly than hide them behind arbitrary traffic policy, unusual forwarding requirements, or commercial mechanics that become visible only once the customer tries to use the network normally.
Protection should improve the network you already operate, not require you to construct a different one around it.
What we built
Our initial core network operates in Ashburn, Frankfurt, and Amsterdam, with multiple high-capacity relationships and multiple 400GbE upstream interfaces. Our own edge is designed to handle attacks above 1 Tbps in-house, depending on the vector and where traffic enters the network.
For conventional IP transit, our initial relationships include GTT and Zayo, with RETN alongside them as a specialized backbone and an additional Tier 1 expected later this quarter. Separately, Cloudflare provides the hyperscale mitigation layer we can use when an event no longer makes sense to absorb entirely at our own edge.
Those relationships are deliberate.
We care about the route a carrier provides on an ordinary day, but also about what happens when hundreds of gigabits or terabits of hostile traffic begin crossing that relationship. Path diversity matters. So do escalation paths and the people who will answer when something has gone wrong.
Those arrangements need to exist before the incident, not be negotiated during it.
Under normal conditions, traffic enters our network and is filtered inline. Routing remains part of the mitigation system because an excellent path under ordinary conditions can become the wrong path during an attack.
A 10 Gbps exchange connection, for example, may be a low-latency and efficient path under normal traffic conditions. It becomes a liability the moment substantially more than 10 Gbps of attack traffic tries to arrive through it.
Prefixes can be advertised differently, impaired paths can be de-preferenced, and traffic can be redistributed among available upstreams. Good mitigation sometimes means deliberately abandoning the route that looked best five minutes earlier.
We also build on the assumption that Wirescope itself will eventually become a target.
A mitigation provider does not get to treat hostile traffic as an exceptional condition that only affects somebody else's network. The infrastructure carrying the defense is part of the attack surface too.
For events beyond the sensible limits of our own edge, Cloudflare provides another failure boundary.
Cloudflare has reported more than 500 Tbps of provisioned external interconnection capacity across hundreds of cities. That figure deserves the same qualification we apply to every aggregate capacity number: it is distributed capacity, not hundreds of terabits available at one router.
The topology is what makes it useful.
A large botnet is geographically distributed too. A correspondingly distributed network can ingest that traffic across many edges rather than forcing the entire attack toward one location before it can be discarded.
We are not relying on the fiction of a 500-terabit bucket. We are relying on another layer whose scale and topology complement the much smaller network we operate directly.
If an event exceeds both our own edge and the hyperscale layer behind it, the remaining options become substantially narrower. We do not claim that no conceivable attack can defeat this architecture. No serious network operator should make that claim.
What we do have is a deliberately layered escalation path: application-aware filtering and routing control close to the customer, substantial capacity at our own edge, and a globally distributed mitigation network behind it when the event becomes primarily one of extreme volumetric scale.
Three core locations are still three core locations. We would rather be explicit about that than combine every interface into one impressive number that says little about what a particular customer can actually survive.
The economics matter too
Wirescope is a new company, but some of the experience behind it is not.
Erik Buckingham's work at ProxyPipe, described at the start of this article, was not simply about absorbing bandwidth. Protecting game servers meant reasoning about application and session behavior rather than relying only on generic rate limits. That is the direct ancestor of the handshake, protocol-stage, and session-aware filtering described earlier.
The scale involved is a matter of public record. In June 2014, ProxyPipe was hit with a 300 Gbps attack while buying mitigation from Verisign, which described that quarter's 300 Gbps attack against a Media and Entertainment customer as the largest DDoS attack it had ever observed and mitigated. Verisign did not name the customer; Krebs later reported that it was ProxyPipe.
At the time, 300 Gbps was exceptional enough to be an industry record. Today, attacks measured in tens of terabits are real. That is roughly a hundredfold increase in a decade, which is why comparing mitigation capacity across eras can be misleading: the economics of bandwidth improved, but the scale of the threat expanded with them.
ProxyPipe later confronted Mirai directly. Robert Coelho estimated that the attacks cost the company between $400,000 and $500,000 as defensive costs increased and customers left, an estimate documented by KrebsOnSecurity at the time.
The lesson was both technical and economic. A mitigation provider can make the right filtering decisions and still fail if every serious attack produces an extraordinary bandwidth bill, emergency capacity becomes too expensive to use, or the business model quietly assumes customers will never receive the attacks they bought the service to withstand.
That is why Wirescope does not bill customers for attack traffic.
Unmetered attack traffic is a commercial commitment, not a claim of infinite physical capacity.
It means an attacker should not be able to turn somebody else's botnet into your bandwidth invoice, and our willingness to defend a customer should not diminish because an attack has become expensive.
The economics belong inside the architecture.
Test it
Anyone considering placing production traffic behind a new network is justified in being skeptical. A detailed engineering article does not remove that risk, and neither does a sufficiently large number printed beside the word "capacity."
The claims that matter should be observable under real traffic.
Customers can trial Wirescope against their own workloads before depending on it in production. In a meaningful test, we care about outcomes at an agreed measurement point: whether legitimate traffic continues to reach the service, how much hostile traffic leaks through, and what happens to latency, loss, and session continuity while mitigation is active.
Where contractual commitments make sense, those measurements also provide a better basis for defining them than an abstract aggregate-capacity figure.
The level of detail naturally varies. A game-server operator should not need to understand BGP, tunnels, return-path symmetry, or our filtering architecture simply to benefit from it. A hosting network will reasonably want to understand routing, isolation, and failure domains. A mitigation provider building on top of us may want to go much deeper into the dataplane, automation, available capacity, and the boundary between its systems and ours.
We are prepared to have each of those conversations.
Large attacks will continue producing remarkable numbers, but the headline figure alone cannot tell you whether an application survives. It cannot tell you whether an interconnection congests before traffic reaches the filter, whether packet rate exhausts the classifier while bandwidth remains available, whether a tiny percentage of leakage is still fatal, or whether a 30 Tbps attack aimed at the customer beside you takes your service down with it.
Those are the failure modes Wirescope is being built around.
The service behind the protection should continue to function during an attack, not merely remain technically reachable.
Gaming is where we are starting because it makes that standard unusually difficult to fake.
If you run a server, operate a hosting network, build a real-time platform, sell mitigation yourself, or need protected transit beneath a larger product, we would like you to test it. Under attack right now? Start here.