Sovy Cloud Services: What AS401110 Can Still Prove When

Summary

ARIN records AS401110 as the active autonomous-system registration AS-SOVYCLOUD, linked to Sovy Cloud Services and the handle SCSL-51. That establishes a real registry identity, not current service availability.
On 20 July 2026, registry and DNS checks found sovy.cloud available for registration and returning NXDOMAIN through three resolvers. ARIN contacts still use addresses at that domain and carry unvalidated contact remarks after no response since 7 May 2025.
PeeringDB retains a global NSP profile for Sovy Cloud Services LLC, five facility rows and no public exchange-LAN or contact rows. Those entries are verification leads, not proof of active equipment, contracts, customer workloads or current presence.
RIPEstat marked AS401110 unannounced at 08:00 UTC on 20 July 2026, with no current prefixes, neighbours or visible route surface. Historical data nevertheless shows that AS401110 originated six IPv4 and IPv6 prefixes between 2024 and early 2025.
The defensible assessment is a weak current-operating grade, not a closure finding. Buyers should separate durable identity evidence from fresh operating proof and require independently verifiable service, control and exit paths before relying on the brand.

The mismatch is the evidence

Internet infrastructure records age at different speeds. A route collector can stop seeing an autonomous system within minutes of a withdrawal. DNS can change just as quickly. A domain registration can lapse while records in resource registries and industry directories remain available for years. Corporate names, network handles, contact entities and facility associations may therefore describe different moments in the life of the same operator.

Sovy Cloud Services brings that timing problem into a single, unusually clear profile. The ARIN record for AS401110 remains active as a registry entity. It names the autonomous system AS-SOVYCLOUD, dates its registration to 29 May 2024, and records its last change on 30 May 2024. The linked organisation record identifies Sovy Cloud Services through SCSL-51 and gives an address at 25 First Ave. SW STE A, Watertown, South Dakota 57201, United States. PeeringDB separately preserves a profile for the network and its organisation.

Those records are not empty. They establish that a named operator acquired a public network identity, supplied contact information and described an intended interconnection footprint. Historical routing observations add proof that AS401110 was not merely a reserved number sitting unused. It originated multiple routes during 2024 and into February 2025.

The current public signals point in another direction. At the time of the checks for this article, sovy.cloud did not resolve and the domain registry reported it as available. RIPEstat did not see AS401110 announced. Its current-prefix and neighbour views were empty. PeeringDB exposed no exchange-LAN rows and no public points of contact for the network.

No one of these facts should be made to carry more weight than it can support. An active ARIN entity does not certify a live cloud platform. An empty RIPEstat view does not reveal private services. A PeeringDB facility row does not confirm equipment on a particular day. NXDOMAIN does not prove that every mailbox ever associated with the domain is permanently unreachable. The analytical value lies in combining the records while preserving those boundaries.

That is the first lesson of the Sovy case: the mismatch is not noise to be averaged away. It is the evidence. The records prove different things at different dates. A buyer, supplier, network operator or investigator should ask which layer is current enough for the decision being made.

An ASN record proves identity, not operation

AS401110 is a genuine public routing identity. ARIN labels the record active and associates it with the name AS-SOVYCLOUD. The record is linked to Sovy Cloud Services, and the related organisation handle is SCSL-51. These are high-confidence registry facts. They support attribution: when AS401110 appears in a routing observation or historical dataset, there is a documented organisation and network name against which it can be evaluated.

The word "active" needs discipline, however. In this context it is the status of the registry record. It does not mean that AS401110 is currently visible in global BGP, that servers answer under the company name, that a support desk is staffed, or that customer contracts remain in force. Resource registration and service operation are separate systems with separate update cycles.

The Watertown address has the same limitation. It is part of the ARIN identity record. It can be used to connect the ASN and organisation handle to a supplied postal location. It cannot establish that the address is a network site, that equipment is installed there, or that an operating team is present. Treating registry contact data as a map of physical infrastructure would convert administrative evidence into a claim the source does not make.

ARIN's nested contact records add another kind of signal. Administrative, technical and abuse contacts use email addresses at sovy.cloud. They also include unvalidated point-of-contact remarks following no response since 7 May 2025. That is a concrete weakness in the public accountability chain. The resource record persists, but the registry's validation process has not received the response needed to keep those contact entities validated.

Even here, restraint matters. The remarks do not prove that an individual address always rejects mail. They do not test a customer-support queue, a billing system or an off-domain escalation path. They show that the public registry contacts were not validated after a recorded failure to respond. Combined with the later domain state, that becomes material. Alone, it remains a contact-validation finding.

The correct use of the ARIN record is therefore two-sided. It prevents the analysis from erasing Sovy's documented network history: AS401110 and AS-SOVYCLOUD are real records tied to Sovy Cloud Services. At the same time, it prevents an "active" label from becoming a shortcut for present-tense operation. The registry answers who and what was recorded. Fresh network and service evidence must answer whether the public operation can be observed now.

The branded control surface has disappeared from public DNS

The freshest and most direct break in the public surface is the state of sovy.cloud. On 20 July 2026, the .cloud registry's RDAP service reported the domain available for registration. DNS A lookups through the system resolver, Cloudflare's 1.1.1.1 resolver and Google's 8.8.8.8 resolver each returned NXDOMAIN.

This finding is stronger than a single web request that times out. A timeout could result from a server fault, filtering or a path problem while the domain remains delegated. NXDOMAIN indicates that the queried name did not exist in DNS at those resolvers at the time of the checks. The registry response independently describes the domain as available. Together, the results show that the branded domain was not functioning as an ordinary public naming surface on the check date.

For a cloud or hosting brand, the domain is more than a marketing address. It commonly anchors account recovery, service notices, billing correspondence, abuse handling, status links, documentation and the human verification of support requests. The available evidence does not show which of those functions Sovy once placed under sovy.cloud, and it would be unsafe to claim that every possible private or off-domain channel is absent. It does show that the domain embedded in ARIN and PeeringDB no longer provided a resolvable public root.

That distinction matters during an incident or ownership check. A customer may still have a working workload even when the provider's branded domain disappears. Existing sessions, direct IP access, private circuits or third-party service components can outlast the public control surface. But the ability to authenticate instructions, recover an account or identify an authorised contact can deteriorate before the workload itself fails. Continuity is not only a question of whether packets still move; it is also a question of who can safely direct a change when they do not.

The ARIN contacts intensify the concern because they use the same domain. The combination creates correlated public evidence: the registry lists sovy.cloud contact addresses, the contacts carry unvalidated remarks, the domain registry reports the name available, and DNS returns NXDOMAIN. This does not justify saying the abuse, technical or administrative mailboxes are definitively dead. It does justify saying that their shared public naming dependency was not intact at the time of inspection.

A prudent counterparty would therefore avoid treating an old email thread or a persistent registry entity as sufficient authentication. The next step is independent verification: an off-domain contact, a signed notice, a known contractual address, a validated phone path or another method agreed before an emergency. The Sovy record shows why such paths need to be established while the ordinary control surface is healthy.

PeeringDB preserves a claimed operating picture

PeeringDB gives Sovy a fuller public shape than the current routing table does. Its network record identifies sovy.cloud, Sovy Cloud Services and Sovy Cloud Services LLC in connection with AS401110. It classifies the network as an NSP, gives it global scope, records the IRR name AS-SOVYCLOUD, and points to the branded domain as its website. The profile reports zero IPv4 prefixes, zero IPv6 prefixes, zero internet-exchange count and five facilities.

These fields are useful because they record how the network presented itself to the interconnection community. The organisation and network names reinforce the link established in ARIN. The ASN and IRR name align with the registry identity. The NSP classification and global scope describe an intended market or network role. The facility rows provide specific places where an interested counterparty might seek confirmation.

PeeringDB is not a continuous operating monitor, however. Its records are entity-maintained directory data. A profile can remain available when the conditions it once described have changed, and an empty field can reflect either absence or incomplete publication. The appropriate verb is "records" or "lists", not "verifies".

This distinction becomes especially important because the profile contains both specificity and emptiness. Five named facility associations create the impression of a broad footprint. At the same time, the network record reports no prefixes and no exchange count, the exchange-LAN endpoint returns no rows, and the public point-of-contact endpoint returns no rows. RIPEstat also sees no current route or neighbour surface. The directory residue is richer than the current operating evidence.

The profile should not be discarded merely because fresher signals are weak. It remains evidence of declared identity and historical intent. It can guide outreach to facilities, former counterparties or the organisation itself. It may help distinguish AS401110 from similarly named companies. It also establishes that Sovy once chose to describe itself as a global NSP rather than leaving the public network record blank.

But it cannot answer present-tense customer questions by itself. It does not show a current service catalogue, a reachable portal, an active NOC, an executed cross-connect, a paid facility account or equipment under power. It does not establish that the company currently controls a route to any customer endpoint. Those questions require evidence from systems that change with operation, not only a directory entry that can persist after the fact.

Five facility rows are five verification leads

The PeeringDB facility endpoint lists five rows for AS401110: Equinix SG1 - Singapore, Equinix SG3 - Singapore, Equinix HK2 - Hong Kong, Linxdatacenter (Moscow) and NewTelco Kiev. The geographic spread is striking. It reaches from Singapore and Hong Kong to Moscow and Kyiv, far from the South Dakota address in the ARIN record.

It would be easy to turn that list into a map of active Sovy regions. The evidence does not permit it. A netfac association says that the network is listed against a facility in PeeringDB. It does not disclose what equipment, if any, is currently installed; who owns it; whether a cross-connect remains live; what service was delivered; or whether customer data ever passed through the site. It does not provide a contract, an inventory or a current facility confirmation.

Nor does the current lack of visible routes prove that every association is obsolete. Equipment can be present without originating a globally visible route at the moment of observation. A network can use another ASN, private addressing or services not visible to RIPE RIS. Directory maintenance can also lag in either direction: a live association may be missing, or an old association may remain. The public data cannot choose among those possibilities.

The right interpretation is operationally useful precisely because it is modest. Each facility row is a verification lead. A due-diligence process can ask the named facility whether a current relationship can be confirmed within contractual and privacy limits. It can ask Sovy for a recent service order, cross-connect identifier or other evidence appropriate to the claimed use. It can compare the answer with current route observations and the customer's own traffic path.

The absence of exchange-LAN rows adds another boundary. PeeringDB's netixlan endpoint returns no entries for the network. That means there is no public PeeringDB evidence here of AS401110 joining an exchange fabric. It does not mean Sovy has no transit, no private interconnection or no other arrangement. The public POC endpoint likewise returns no rows, but private contacts may exist.

For a buyer, the facility list should therefore trigger questions rather than confidence. Which rows describe current equipment? Which describe an earlier plan? Which legal entity contracts for the service? Which network identity is used on site? What independent evidence can connect a listed location to a current customer service? Without those answers, five rows remain five claims to verify, not five operating zones to count.

RIPEstat sees no current public route surface

The current routing evidence is more time-sensitive than either ARIN or PeeringDB. RIPEstat's AS overview marked AS401110 as not announced at the query time of 20 July 2026 at 08:00 UTC. Its announced-prefixes endpoint returned no current prefixes for the latest two-week window. The service notes an important measurement caveat: routes with very low visibility across RIS full-feed peers can be excluded.

The routing-status response reaches the same broad conclusion through several fields. It reports zero current IPv4 announced prefixes, zero current IPv6 /48s, zero observed neighbours, and zero current IPv4 or IPv6 RIS visibility for AS401110. The ASN-neighbours endpoint separately returns zero left, right, unique and uncertain neighbours at the latest available time.

These observations support a precise statement: AS401110 had no public route surface visible in the inspected RIPEstat views at the stated time. They do not support the larger statement that Sovy had no networking or service of any kind. RIPE RIS observes global routing from participating peers. It does not inspect private networks, customer-specific tunnels, internal systems, direct arrangements outside collector visibility or services using another origin.

Measurement limitations should not erase the result. The announced-prefixes caveat matters most at the edge, where an exceptionally low-visibility route could escape the returned set. Yet multiple RIPEstat views agree on the absence: the overview says not announced, routing status reports zero prefixes and visibility, and the neighbour view is empty. PeeringDB also reports zero prefix and exchange counts. The combined public evidence is materially weaker than a single missing observation.

For a cloud-service assessment, route absence has a specific meaning. It removes public BGP support for the claim that AS401110 currently carries a Sovy-branded service edge. It does not rule out services delivered through another provider's address space or ASN. It does not tell whether an old customer deployment continues on a direct IP path somewhere. It does mean that the autonomous system named in the registries cannot presently serve as public proof of live network operation.

That is why current operating status should be graded rather than guessed. The grade should distinguish between "no visible evidence" and "proven not to exist". Sovy belongs in the first category. Fresh public routing evidence is absent across the inspected sources, but the limits of those sources leave room for private or differently addressed activity that would require direct verification.

Historical routes prove that the network once spoke

The empty current view should not be confused with a network that never appeared. RIPEstat routing history records AS401110 originating six prefixes across windows beginning in May and June 2024 and ending by February 2025: 166.88.177.0/24, 2a12:8fc6:4011::/48, 81.161.230.0/24, 109.206.237.0/24, 136.0.121.0/24 and 23.27.222.0/24.

That history changes the interpretation of the registry record. AS401110 was not only assigned a name and left as administrative potential. Public collectors observed it originating both IPv4 and IPv6 routes. The timing begins close to the ARIN registration in late May 2024. RIPEstat routing status records the IPv6 prefix 2a12:8fc6:4011::/48 as first seen on 31 May 2024, and it records the IPv4 prefix 109.206.237.0/24 as last seen on 14 February 2025.

Historical origination still does not disclose the services behind the routes. A BGP announcement proves that an origin appeared in the control plane, subject to collector visibility. It does not identify customers, applications, servers, contractual rights or utilisation. The six-prefix list cannot be converted into six facilities or a measure of commercial scale.

It does provide a baseline. When a public ASN that once originated several routes now presents zero visible prefixes and zero neighbours, the absence is not merely a failure to find evidence for a new entrant. It is a change from observed routing activity. That temporal comparison is stronger than reading the current snapshot alone.

The sequence also prevents an opposite error: describing the persistent ARIN and PeeringDB records as entirely hollow. They correspond to a network identity that had visible route history. A serious due-diligence account must preserve that fact even while grading current evidence weakly.

The practical question is not whether the history was "real". It was real as observed routing history. The question is what continuity exists between that period and the present. Did the service move to another ASN? Were address resources returned or reassigned? Did the business change form? Are private customers served outside the visible edge? The sources used here do not answer those questions. They identify the gap that direct evidence would need to close.

Prefix movement is evidence, not a business explanation

Two historical resources illustrate what route history can and cannot reveal. RIPEstat identifies 109.206.237.0/24 as the last-seen AS401110 IPv4 prefix in its routing-status summary. The current prefix-overview response shows that the same /24 is now announced by AS16045 BULINFO-HOSTING Spektar AD. The IPv6 prefix 2a12:8fc6:4011::/48, first seen for AS401110, is not currently announced in the corresponding prefix overview.

These are current-origin observations. They show that one formerly visible Sovy-originated IPv4 route now has a different public origin, while the cited IPv6 route is not currently visible as announced. That strengthens the conclusion that the old AS401110 route set should not be treated as a current Sovy operating footprint.

The observations do not explain why the state changed. Address space may be reassigned, leased, returned, reconfigured or used under arrangements that cannot be inferred from BGP alone. A change in origin does not reveal a sale, a customer migration, a dispute or a company closure. No such commercial explanation is supported by the source set.

For customers and counterparties, the lesson is about dependency and attribution. An old invoice, allowlist or architecture diagram may contain a prefix that no longer maps to the same origin. Monitoring only the address can therefore preserve a false sense of continuity. The current origin ASN, registry chain, route authorisation where available, reverse DNS and contractual allocation all need separate checks.

This is particularly important during recovery. If a customer believes that a service is "with Sovy" because an old /24 appears in documentation, the present route may tell a different story. Contacting the current origin operator would still not prove who controls the customer's application or data. It would simply update one layer of the dependency map.

The IPv6 result makes a complementary point. A resource that is not currently announced cannot establish public reachability, but it may still exist in registry or private records. Absence from the current route view should lead to verification, not invention. The evidence supports a changed public network state. It does not supply the business narrative behind that change.

A three-layer test for operating claims

Sovy's records are easier to interpret when divided into three evidence layers: durable identity, historical activity and current operation. Mixing the layers produces either unwarranted confidence or unwarranted erasure.

The durable-identity layer is the strongest and slowest-moving. ARIN records AS401110, AS-SOVYCLOUD, Sovy Cloud Services and SCSL-51. PeeringDB records the network, Sovy Cloud Services LLC, the global NSP description and the claimed facility footprint. These sources answer whether a public identity and directory presence exist. They are useful for attribution and for finding the claims that need confirmation.

The historical-activity layer shows that the identity was used in public routing. RIPEstat observed six originated prefixes over periods from 2024 into February 2025. This evidence answers whether AS401110 ever appeared as more than a registry allocation. It establishes control-plane history, while saying little about what commercial service ran behind it.

The current-operation layer is where the evidence weakens sharply. On the check date, sovy.cloud was available and returned NXDOMAIN. ARIN's domain-based contacts carried unvalidated remarks. PeeringDB showed no prefixes, exchange count, exchange-LAN rows or public POC rows. RIPEstat showed no announced ASN, prefixes, neighbours or RIS visibility.

A current operating claim should be supported primarily at the third layer. The first two layers can make the claim plausible and explain its history, but they cannot substitute for live proof. Useful current evidence might include a resolvable controlled domain, a reachable authenticated support path, current route observations, recent service documentation, a verified customer control plane, or direct confirmation from a relevant facility or network counterparty. The exact evidence depends on the service being assessed.

The method also works in reverse. Weak current evidence should not overwrite identity and history. Sovy should not be treated as fictional merely because the present public surface is silent. The company and ASN remain meaningful subjects for infrastructure intelligence. The right record is one with a confidence boundary: identity proven, historical routing proven, current public operation not proven.

This layered approach is more durable than a binary "active/inactive" label. It can absorb new evidence without rewriting the past. A restored domain would improve one current signal. A new AS401110 announcement would improve another. A facility confirmation could validate one directory claim. None would retroactively change what was observed on 20 July 2026; each would update the current layer.

Why small customers should care about the control surface

Large infrastructure buyers can demand architecture documents, escalation matrices and contractual continuity provisions. Small and medium-sized organisations often rely on what is publicly visible: a website, a support address, an invoice, a control-panel login and perhaps an IP range. Sovy's public evidence shows how those identifiers can diverge.

The risk is not limited to a total service outage. A workload can continue to answer while the customer loses confidence in who is authorised to administer it. Password resets may depend on a domain that no longer resolves. An emergency request may arrive from an unfamiliar address. A historical prefix may now originate from a different ASN. A directory may still list facilities without explaining whether any are relevant to the customer's service.

This creates an authentication problem before it creates a performance problem. During an incident, a customer needs to know which instruction is genuine, which account controls billing, who can authorise a data export, and where an abuse or security escalation will be received. If every trusted path depends on one provider domain, the disappearance of that domain removes more than a web page.

The sensible response is not to assume wrongdoing or abandonment. It is to reduce correlated dependencies in advance. A service relationship should include at least one verified contact method outside the provider's own domain, a named legal counterparty, a process for authenticating changes, and a customer-controlled record of account and resource ownership. Critical credentials should not be recoverable only through an address under the provider's namespace.

Network identifiers also need regular refresh. Customers should record the ASN and prefixes observed for their service, but they should not treat those values as permanent proof of provider identity. Current origin checks and registry attribution can reveal changes. When an address starts originating from another network, the customer should ask for an explanation tied to its own service rather than inferring one from public BGP.

Finally, the customer needs an exit path that does not depend on the failing control surface. That may include recent data exports, configuration backups, documented DNS control, portable credentials and a tested way to move traffic. The sources do not reveal Sovy's customer arrangements, so none of these safeguards can be credited or denied in this case. They are the questions made urgent by the gap between its persistent identity records and missing public operating signals.

What a buyer would need to verify now

A current review of Sovy Cloud Services should begin with authority, not capacity. Who can bind Sovy Cloud Services LLC today? Which legal or contractual identity corresponds to the ARIN organisation record? Which off-domain channel can authenticate that person? The public sources connect names and handles, but they do not provide a currently validated operating contact.

The next question is service identity. If a service is said to remain active, which domain, portal, address or private endpoint proves it? Is the endpoint controlled by the same counterparty named in the contract? Can the customer validate it without relying on sovy.cloud? A screenshot or old login bookmark is weak evidence unless it can be connected to present control.

Network claims should be tested at the same date. If AS401110 is still said to carry the service, the provider should be able to identify the current prefixes and paths. Public RIPEstat evidence did not show them at 08:00 UTC on 20 July 2026. A private service may not appear there, but that makes direct documentation more important, not less. If another ASN delivers the service, the relationship and responsibilities should be stated explicitly.

Facility claims need site-specific confirmation. The five PeeringDB rows should not be accepted or rejected as a group. Evidence for Equinix SG1 - Singapore says nothing automatically about Equinix SG3 - Singapore, Equinix HK2 - Hong Kong, Linxdatacenter (Moscow) or NewTelco Kiev. Each association may have a different date, purpose and current status. A buyer needs to know which location supports its actual service, if any, and what independent evidence confirms that relationship.

Contact and incident handling should be verified separately from service reachability. The ARIN validation remarks and domain state make public contact continuity a specific concern. A test should confirm that administrative, technical, security and billing escalations reach authorised people through agreed channels. It should not rely on unsolicited probing or assume that a failed registry validation equals a failed customer desk.

Address continuity deserves its own evidence. Historical AS401110 prefixes cannot be assumed to remain under Sovy's current operational control. The current origin of 109.206.237.0/24 is AS16045 BULINFO-HOSTING Spektar AD, while 2a12:8fc6:4011::/48 is not currently announced in the inspected prefix view. A customer using any historical address should reconcile it against live routing, registry data and its contract.

The final check is recoverability. Can the customer export data, rotate credentials, change DNS, retrieve configurations and move service without waiting for the provider's branded domain to return? That question is not an allegation about Sovy. It is the practical test that turns uncertain public evidence into a manageable dependency.

What would improve the current-operating grade

The current grade should change only when the evidence changes. Several public developments would be meaningful, though none would prove every part of a cloud operation on its own.

A newly registered and resolvable sovy.cloud under demonstrable company control would restore the branded naming surface. It would be stronger if current administrative and technical contacts were validated and if public service information clearly identified the responsible legal entity. Domain restoration alone would not prove live customer infrastructure, but it would repair a major part of the public control path.

A visible AS401110 route announcement would update the routing layer. The most useful evidence would include stable current prefixes, observable neighbours and consistent attribution across ARIN, routing data and the operator's own disclosure. A brief or low-visibility announcement would need time and multiple observations before supporting a strong continuity claim.

Updated PeeringDB data could clarify the interconnection picture. Public exchange-LAN rows, current contact roles or revised facility associations would add specificity. Because PeeringDB is still a directory, the claims would benefit from confirmation through route observations or counterparties. Removing old rows would also be informative by narrowing what the operator currently claims.

Direct facility confirmation could validate one or more of the five listed associations. It would need to be specific about the network identity, date and nature of the relationship without exposing protected customer information. A confirmed association would prove more than a directory row, but it still would not by itself establish customer service, redundancy or performance.

Customer-side evidence can be decisive even when public sources remain thin. A functioning authenticated control plane, recent support response, current invoice, documented network path and tested export may demonstrate a live relationship. Such evidence is private and cannot be inferred from the public record, but it is exactly what an affected customer should seek.

These improvements are modular. A stronger domain signal does not automatically repair routing evidence. A new route does not validate old facility rows. A support reply does not prove every historical prefix remains controlled by Sovy. The three-layer method keeps each update in its proper place.

What the silence does not prove

The public evidence supports a weak current-operating assessment, but several stronger claims remain unsupported.

It does not prove that Sovy Cloud Services is definitively closed. Registry identity and historical routing remain real, and the sources do not include a corporate closure record or an authoritative statement ending all activity. The absence of a public domain and route surface is serious evidence, but it is not a legal or universal operating determination.

It does not prove that no customers exist. A customer could use private connectivity, an address originated by another ASN, a third-party control plane or a service that does not advertise itself under the Sovy brand. The source set cannot inventory private contracts.

It does not prove that the five PeeringDB facilities are inactive. Current public routing does not validate the rows, but neither does it inspect equipment or contractual status inside the facilities. Each row remains unconfirmed in current operating terms.

It does not prove that support, billing, technical or abuse mailboxes are permanently dead. The evidence is narrower: the domain was available and returned NXDOMAIN on the check date, while ARIN contacts using that domain carried unvalidated remarks. Those facts weaken confidence in public contactability without testing every possible delivery or alternate channel.

It does not prove that AS401110 has no private route, private peer or non-public service. RIPEstat and PeeringDB expose public views with known coverage limits. A service hidden from those views would require direct evidence to verify.

These limits are not qualifications added to soften a conclusion. They define the conclusion. Good infrastructure intelligence records absence where absence was observed and uncertainty where the method cannot see. In Sovy's case, the public operation is not proven current; the company is not proven nonexistent.

A weak current-operating grade is the useful answer

Sovy Cloud Services occupies a clear place in the infrastructure record. ARIN identifies AS401110 as AS-SOVYCLOUD, links it to Sovy Cloud Services and SCSL-51, and preserves the supplied organisation and contact data. PeeringDB records Sovy Cloud Services LLC as a global NSP and retains five facility associations. RIPEstat history shows that the ASN originated six prefixes. Those are durable facts about identity, presentation and past routing activity.

The evidence for present public operation is much weaker. On 20 July 2026, sovy.cloud was reported available and returned NXDOMAIN through three resolvers. ARIN's domain-based contacts carried unvalidated remarks. PeeringDB exposed no current prefix count, exchange count, exchange-LAN rows or public POC rows. RIPEstat saw no current AS announcement, prefix, neighbour or RIS visibility.

The appropriate result is therefore a weak current-operating grade. It says that a Sovy network identity and historical route surface are established, while a live Sovy-branded customer cloud surface is not established by the current public evidence. It does not convert uncertainty into a closure claim.

For buyers, the grade is actionable. Do not rely on the persistence of an ASN record, facility list or old prefix as proof that a service can be administered today. Verify authority, current routing, support continuity, the location relevant to the actual service, and an exit path that remains usable if the provider's domain does not.

For operators and researchers, Sovy is also a reminder to time-stamp every layer. Registry records, directory claims, DNS and BGP observations should not be blended into one undated profile. The most accurate account preserves both sides of the case: AS401110 once had a visible routing history, and its current public operating signals were absent at the moment examined.

That is not a dramatic verdict. It is the more valuable one. Infrastructure due diligence works when it distinguishes what remains on record from what can still be independently observed.

Sovy Cloud Services: What AS401110 Can Still Prove When the Public Surface Is Silent