Summary

  • On 17 October 2026, autonomous system AS57063 was recorded as announced and originating exactly two prefixes — 213.5.72.0/24 and 2001:67c:f74::/48 — while a third prefix associated with it in the registry, 91.236.201.0/24, was not announced at all.
  • The RIPE database names the holder as GPU Computing OU, an Estonian private company with registration number 14476114 and a Tallinn address, but no retrieved public source establishes GPU hardware, compute capacity, customer contracts or a published service offering.

What the registry actually records

The RIPE database organisation object ORG-GCO2-RIPE records the org-name as GPU Computing OU, country EE, registration number 14476114, and an address at Tartu mnt 83-701, 10115 Tallinn, Estonia (RIPE Database search for AS57063). The same record set associates the organisation with autonomous system AS57063, and RIPEstat renders that system's holder string as PUZL-AS GPU Computing OU (RIPEstat AS overview, AS57063).

Those are narrow, administrative propositions. A registry object says who is accountable for a number resource and where correspondence goes. It does not say what the holder does with the resource, how much equipment sits behind it, or whether anyone has bought anything. The BTW directory entry for this object makes the same distinction explicitly: it classifies the subject as an enterprise network resource-holder footprint rather than a connectivity-provider service claim, and records no service, contact or personnel evidence at all (BTW directory entry).

What the routing record shows

The routing layer is more informative than the registry layer, and it is small. At the 08:00 UTC window on 17 October 2026, AS57063 was recorded as announced (RIPEstat AS overview, AS57063). Its announced-prefix record lists exactly two entries — the IPv4 prefix 213.5.72.0/24 and the IPv6 prefix 2001:67c:f74::/48 — both with observed timelines running from 3 October to 17 October 2026 (RIPEstat announced prefixes, AS57063).

A /24 and a /48 are the shape of an enterprise allocation, not the shape of a compute platform selling capacity to the public. A single IPv4 /24 holds 256 addresses. A single IPv6 /48 holds 65,536 subnets. Either is enough to run a serious internal network; neither implies a fleet of accelerators behind it. Address volume is not a proxy for compute volume, in either direction, and the record here is deliberately unhelpful to anyone trying to read capacity off a prefix table.

The prefix-level views agree with the AS-level view. The IPv4 prefix resolves to AS57063 with the same holder string (RIPEstat prefix overview, 213.5.72.0/24). The third prefix is the interesting one. The routing-consistency record lists 91.236.201.0/24 with in_bgp false and in_whois true, alongside the two announced prefixes marked in_bgp true and in_whois true with RIPE as the IRR source (RIPEstat routing consistency, AS57063). The prefix overview for that address block confirms it is announced false, carries no associated autonomous systems, and is not a less specific of some other announcement (RIPEstat prefix overview, 91.236.201.0/24).

So the registry holds an address block that the routing system does not currently carry. That is a normal state — reserved space, a decommissioned service, a block held for future use — and the public record does not distinguish among those explanations. It is worth stating precisely because it separates two questions that are often merged: what a holder is entitled to originate, and what it is actually originating.

The gap between policy and observation

The most technically revealing part of the record is the routing policy, because it names parties that the routing table does not show. The import and export entries for AS57063 reference peer AS50794 and peer AS200675, both with in_bgp false and in_whois true; a third entry references peer AS15830 with in_bgp true and in_whois false (RIPEstat routing consistency, AS57063).

The two policy-only peers resolve to recognisable operators. AS50794 is registered to the holder string levira Levira AS (RIPEstat AS overview, AS50794), the Tallinn media-services and data-centre business. AS200675 is registered to HYDRO66 NORTHERN DATA SERVICES (UK) LIMITED (RIPEstat AS overview, AS200675), a high-density colocation operator associated with Nordic sites. Those two names are, on their face, exactly the kind of counterparties a small GPU-hosting venture would write into a routing policy: a domestic facility operator and a specialist high-density colocation provider.

And yet neither appears in BGP against this system. The one adjacency that is visible in BGP — AS15830 — is the RIPE NCC's own network, and it is visible in BGP while absent from the routing registry. That asymmetry matters for how the record should be read. A policy entry is a declaration of intent; a BGP observation is a measurement of what a vantage point actually saw. The record here contains a declaration naming two hosting operators and a measurement showing neither of them, plus a measurement showing a registry operator that the declaration does not mention.

There are ordinary explanations. Import and export policy can be stale, aspirational, written for a planned interconnection that never went live, or scoped to routes that this particular set of vantage points does not observe. The RIPE NCC's own network appears in measurement data for reasons that have nothing to do with commercial endorsement — the registry operates measurement infrastructure, and an adjacency to it is not a credential. What the record does not support is any reading in which the named hosting relationships are confirmed, and it equally does not support a reading in which they are disproven.

The honest statement is that the declaration and the observation do not reconcile from public data alone.

What none of this establishes

No retrieved public source establishes GPU hardware model, count, aggregate capacity, facility location, power or cooling arrangements, or operating telemetry for this company. No retrieved public source establishes a service description, pricing, service-level terms, customer references, contracts, or evidence of actual workloads. Those are the layers a compute claim actually lives in, and they are empty in this record.

One further layer is unresolved rather than absent. Route-origin authorisation status could not be determined: the validation endpoints consulted on 17 October 2026 returned no usable data, so the two announcements cannot be described as RPKI-authorised or unauthorised on this record. That is a retrieval boundary, not a finding about the operator's hygiene, and it should be re-checked rather than inferred.

The observations themselves are time-bounded. The announced-prefix timelines cover 3 October to 17 October 2026. Persistence before or after that window is not established by these sources, and a two-week window is a snapshot of routing behaviour, not a history of a business.

Why the distinction carries commercial weight

Compute capacity is bought against delivered, measurable service. A capability-signalling company name is cheap to register and slow to disprove. When a name asserts a capability and the public record establishes only resource scale, the risk does not sit in the registry — it sits in the counterparty that reads identity as evidence of a product.

That risk is concrete and asymmetric. A buyer who contracts for GPU hours, a data-residency commitment, or a sovereign-capacity arrangement is relying on facts that must come from the supplier's own operational disclosure: hardware inventory, facility attestation, power contracts, benchmark results under defined conditions, and named customer references. None of those can be substituted by an autonomous system number, and none of them appear here.

Conversely, an analyst who concludes from the absence of public service evidence that the company is a shell, dormant, or incapable of private GPU work has overreached just as far in the other direction: private hardware and private customers are entirely compatible with a thin public record.

The defensible classification as of 17 October 2026 is an enterprise network-resource footprint carrying an unverified service claim. The routing is live, small, and dated. The name is not evidence of a fleet. The distance between those two statements is the entire analytical content of this entry, and it will not be closed by more reading of the same registry — only by evidence from a different layer.