Summary

Three Layers of Evidence, Only One of Them Checkable

Every piece of AI-infrastructure marketing rests on some document. The useful question is never whether the document exists; it is which layer of reality the document belongs to. For Genesis Cloud, the layers are unusually easy to separate, because each one is publicly recorded.

The first layer is declared configuration. PeeringDB's record for AS209045 lists the organisation as Genesis Cloud Ltd., with alternates including Genesis Cloud GmbH and Genesis Cloud Norway AS, a network type of Enterprise, and the as-set AS209045:AS-ALL https://www.peeringdb.com/asn/209045. The net record — number 19680 — declares ten IPv4 and ten IPv6 prefixes, facility entries at the Bulk Norway Data Center Campus N01 in Øvrebø and EMC Home of Data MUC I/II in Germany, and two operational 10G public peering ports: DE-CIX Frankfurt (80.81.195.150) and DE-CIX Kristiansand (185.0.6.2) https://www.peeringdb.com/net/19680. These are self-declared records. They evidence design intent and registry bookkeeping, not delivery.

The second layer is vendor-claimed performance. DE-CIX's case study describes a GlobePEER Remote 10 Gbit service connecting the BULK data centre in Kristiansand to DE-CIX Frankfurt, quotes Genesis Cloud Senior Network Architect Robert Blechinger on the improvement from "a sometimes unstable 40 ms" to a stable 20 ms, and attributes the design to moving AI training data transfer off transit providers whose bandwidth fluctuated https://www.de-cix.net/_Resources/Persistent/7/0/6/4/70646d11ea3d9beea4d676de422368b2bf1ab4e9/AI%20and%20HPC%20in%20the%20Nordics_Genesis%20Cloud%20benefits%20from%20peering%20in%20Frankfurt.pdf. DE-CIX has a direct commercial interest in this narrative: the case study markets its own remote-peering product. The figures are admissible as vendor statements, not as verified performance facts.

The third layer is observable network state — and it is the only layer anyone can independently check today. It is also the layer that has emptied.

What the Routing Collectors Show

The divergence between documentation and observation is stark and dated. bgp.he.net reports AS209045 as not visible in the global routing table since 16 April 2026, counting zero IPv4 prefixes and two IPv6 prefixes in its views https://bgp.he.net/AS209045. CIDR Report states the AS is not currently used to announce prefixes nor visible as transit, while preserving a history of more-specific IPv4 advertisements around 147.189.192.0/20 — including 147.189.192.0/22, 147.189.196.0/22, 147.189.200.0/22 and 147.189.207.0/24 — with the last two withdrawn within a recent seven-day window https://www.cidr-report.org/cgi-bin/as-report?as=AS209045&view=6447.

This is not a contradiction of the PeeringDB record; it is a different kind of fact. PeeringDB says what the operator declared. The routing collectors say what the network observably does. Between May 2025 (the last net-record update) and April 2026, the second fact inverted relative to the first. The IRR as-set AS209045:AS-ALL still exists as a registry object, and the AS still imports AS201537:AS-DECIX-KRS — the DE-CIX Kristiansand route server — in its recorded import policy, but an import policy is a statement of intent about routes, not a guarantee that routes flow https://ipv4.bgp.he.net/irr/as-set/AS209045:AS-ALL.

BTW's prior coverage has already made this separation explicit for this operator: PeeringDB's 10G DE-CIX ports were recorded against zero RIS-visible prefixes, and separate analyses distinguished declared configuration from observed operation and customer continuity https://btw.media/en/peeringdb-recorded-10g-de-cix-ports-zero-ris-visible-prefixes-reading-genesis-cloud-as209045. What the DE-CIX case study adds to that picture is a precise, quotable performance claim attached to a specific design — which makes the divergence measurable rather than merely observable.

The 10G Boundary the Vendor's Own Numbers Describe

The most probative detail in the case study is not the 50% claim. It is the throughput figure. DE-CIX's material says latency "remain[ed] low" at 6 Gbit load https://www.de-cix.net/_Resources/Persistent/7/0/6/4/70646d11ea3d9beea4d676de422368b2bf1ab4e9/AI%20and%20HPC%20in%20the%20Nordics_Genesis%20Cloud%20benefits%20from%20peering%20in%20Frankfurt.pdf. Genesis Cloud's own PeeringDB record states 5–10 Gbps of traffic, mostly inbound https://www.peeringdb.com/asn/209045. Put those two numbers side by side and the design reads as what it is: a single 10 Gbit remote-peering path carrying a traffic profile that runs into the port's ceiling at the top of its declared range.

For AI workloads this matters more than for ordinary web traffic. Training-data movement between a Nordic GPU site and central European compute is bulk, sustained, and latency-sensitive in aggregate even when individual flows tolerate jitter. A 10G port — even a well-utilised one with stable 20 ms round-trip time to a large exchange — is a boundary, not a backbone. The case study's framing of access to "more than 1,000 networks" through DE-CIX Frankfurt is real as a reachability statement; it does not multiply the physical capacity of the path https://www.de-cix.net/en/resources/case-studies/genesis-cloud.

It is also worth noting what the design does not include in the public record: no documented second diverse path, no stated capacity headroom above the port ceiling, no independently published telemetry. The vendor's case study is the only performance evidence in the public domain, and it is a vendor document.

Corporate Continuity Is a Separate Axis

The routing story and the corporate story must not be conflated, but they rhyme. RIPE registration shows the AS is administered by ORG-GCL19-RIPE, Genesis Cloud Limited, a Malta-registered LIR with company number C 88032 https://www.cidr-report.org/cgi-bin/as-report?as=AS209045&view=6447. The operating company in Germany, Genesis Cloud GmbH, München, is registered as HRB 250051 and has been described in third-party registry listings as in liquidation https://www.northdata.com/Genesis%20Cloud%20GmbH,%20M%C3%BCnchen/HRB%20250051. In September 2025, Bizety published an analysis titled around the fall of the neocloud provider https://bizety.com/2025/09/23/the-fall-of-neocloud-provider-genesis-cloud/.

Against that backdrop, the company's own blog still carries the positioning: an "Empowering Europe's AI future" mission statement, an expansion-to-Norway announcement, and H100-based offerings for 2025 https://www.genesiscloud.com/blog/genesis-cloud-expands-to-norway. Those pages persist unchanged while the routing footprint does not. That persistence is exactly the point: marketing and documentation assets survive the network that they describe.

No operator statement, liquidator statement, or registry filing in the public record explains the prefix withdrawals. Whether the April 2026 visibility collapse reflects deliberate decommissioning, financial distress, or renumbering cannot be determined from routing data alone. What can be said is that the collapse is contemporaneous with a company described in liquidation, and that the more parsimonious reading is service wind-down — an inference, stated as such.

The Evaluation Rule This Case Yields

The generalisable finding is a four-part grading of AI-infrastructure claims:

  1. Declared configuration (PeeringDB ports, as-set, stated traffic) proves design intent.
  2. Vendor-claimed performance (the DE-CIX case study's 40→20 ms, 50% faster, stable at 6 Gbit) proves marketing positioning and carries the vendor's incentive.
  3. Observable network state (routing-table visibility, prefix announcements, withdrawals) proves operability.
  4. Corporate and legal continuity (LIR domicile, GmbH status, insolvency reporting) proves durability.

Genesis Cloud is a clean instance of divergence between layers one and two on one side and layer three on the other. Documentation quality and vendor celebration persisted; independent verifiability of the live network did not. When that pattern appears, the gap is itself the finding. A 10G remote-peering design for AI data movement is a legitimate, intelligible architecture — but as of 2026, the claim that this specific design carries live European GPU workloads is not independently corroborated, and the responsible reading of the public record says so plainly.

BTW maintains a running directory record for this subject that consolidates the network-record evidence cited here.

Sources