Summary
- The entity called "support 3D CLOUD COMMUNICATION" is a RIPE contact role, not the verified legal name of a support business. The corresponding company is LLC "3D CLOUD COMMUNICATION", a Kyiv limited-liability company incorporated on 9 July 2025 with registered capital of UAH600,000 and a principal registered activity covering data processing, hosting and related work.
- The company is currently attached to AS56421 and AS39755. Both numbers predate the company by years, so their creation dates and old routing histories cannot be presented as the company's operating history. AS39755 had no visible route at the research cut-off. AS56421 had only just begun to originate one IPv4 /24 and had no demonstrated IPv6 origin.
- The one visible block,
185.243.98.0/24, was also still being originated by AS48693, whose organization remains the block's registered assignee and whosentup.netnames remained in reverse DNS. This multi-origin state may reflect an authorized migration, customer arrangement or transition. It does not by itself prove a routing incident, but no public authorization or route-origin authorization settled the relationship. - At 12:00 UTC on 10 July, public route observations showed AS56421 through AS41033 while far more observed paths still ended at AS48693. The RIPE registration listed numerous intended import relationships, but an intended routing policy is not the same as simultaneous usable transit. No second site, exchange port, physical carrier path, backup capacity or failover test was verified for the company.
- The evidence grade is Weak. There is a real legal company, current network registration and a very recent BGP signal. There is not yet enough public evidence to substantiate a customer-facing cloud platform, locate its racks, measure usable capacity, verify power and hardware resilience, establish data locality, or assess restoration and migration obligations.
A support label is not a company history
The entity's unusual public name has a straightforward origin. The RIPE role record calls SCC86-RIPE "support 3D CLOUD COMMUNICATION" and gives it administrative responsibility through SP22450-RIPE. The associated person record identifies Slipych Pavlo. Those records were created on 31 December 2025. They are useful contact and accountability evidence, but the word "support" should not be mistaken for a trading name, a staffed service desk or a service-level promise.
The legal identity is LLC "3D CLOUD COMMUNICATION". Opendatabot's company record gives Ukrainian company number 45920348, an incorporation date of 9 July 2025, a Kyiv registered address and registered capital of UAH600,000. It identifies Pavlo Slipych as director, founder and ultimate beneficial owner. YouControl's record showed the company registered and not in liquidation when updated on 23 June 2026. The same legal identity is independently visible in Hosting Ukraine's company search.
Those dates set an essential boundary. A company formed in July 2025 cannot claim the operational life of an autonomous system first seen in 2011 merely because the number is now attached to it. It may have acquired rights, contracts, equipment or expertise from an earlier operator, but no public transaction account establishes what transferred. The current company can be evaluated from its own incorporation, its present records and its observable conduct. The older number remains relevant technical context, not inherited corporate biography.
The legal record also narrows what can safely be said about ownership. The company is presented as wholly owned by one individual, not as a disclosed subsidiary of a larger hosting group. No public parent-company guarantee, consolidated balance sheet or named infrastructure partner was found. UAH600,000 of registered capital establishes a formal capital commitment; it does not reveal cash on hand, annual revenue, server inventory, insurance cover or the amount available during a prolonged outage. A buyer cannot convert registered capital into an uptime estimate.
This matters because accountability in a small hosted-services business is often concentrated. The same person may negotiate capacity, approve spending, manage address resources and handle escalation. That can make decisions fast, but it can also create key-person risk. The public records do not disclose employee count, shift coverage, engineering depth or an on-call rota. The contact role proves that a responsible handle exists. It does not prove that a second engineer will answer while the first is unavailable.
Registration for hosting is evidence of intent, not a product catalogue
The company's principal registered activity is Ukrainian KVED 63.11: data processing, hosting on web nodes and related activities. Additional registered activities include programming, information-technology consulting, management of computer equipment, software publishing and other information services. This is the clearest public basis for placing the business in a cloud or hosting category. It is still an administrative classification rather than a description of a live product.
A registered activity does not say whether the company sells virtual machines, bare-metal servers, managed applications, colocation, backup storage or only technical consulting. It does not name a hypervisor, storage platform, billing portal, operating-system range, bandwidth allowance, minimum term, support channel or customer jurisdiction. It does not show a price, an order page, a status page, a customer notice or an acceptable-use policy. No public product catalogue tied securely to company number 45920348 was identified at the cut-off.
The distinction is easy to miss because "cloud" is in the company name. The NIST definition of cloud computing describes characteristics such as on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. The legal activity supports hosting intent, while the public evidence does not establish those operational characteristics. A rack of manually provisioned servers can be a useful hosting service without being an elastic cloud. Conversely, a company can resell a third party's cloud without owning a rack. The name alone resolves neither case.
The NIST cloud synopsis and recommendations also distinguishes service and deployment arrangements and emphasizes the need to understand provider responsibilities. That is the practical issue here. If 3D CLOUD COMMUNICATION resells capacity, the underlying operator may control power, hardware replacement and much of the network. If it leases racks and owns servers, it controls a different portion of the chain. If it manages customer equipment, responsibility shifts again. No public contract allocates those duties.
The Ukrainian communications regulator publishes a monthly register of electronic-communications network and service providers, with the dataset page updated on 2 July 2026. A company planning to sell internet carriage may need a different regulatory posture from a business selling computing on another operator's connectivity. The evidence reviewed here does not establish what notifications or permissions apply to this company's actual offer. The safe conclusion is limited: its corporate activities permit a hosting hypothesis; they do not prove what it currently sells or the regulatory character of the service.
Two old network numbers arrived inside a new corporate identity
The RIPE organization record for ORG-LCC13-RIPE was created on 31 December 2025 and names LLC "3D CLOUD COMMUNICATION" with company number 45920348. The next day, the visible autonomous-system records for AS56421 and AS39755 were modified to point to that organization. Both retain the AS name Eurolir-AS, a label that does not match the new legal name. Neither discrepancy is automatically problematic, but both show why each field must be read by date and function.
AS56421's current registration says the number was created on 17 February 2011. RIPEstat's routing-status history first saw it originate 91.223.123.0/24 on 18 February 2011. The company did not exist then. The date records the history of the network number, not the age of LLC 3D CLOUD COMMUNICATION.
AS39755's registration has a current entity creation date in May 2018, while RIPEstat's status view contains older observations ending in July 2010. Reissued or reconstructed registration records can produce this kind of chronology. The relevant point for a customer is simpler: the current AS39755 overview marked it unannounced, and no current prefix was visible from it at the cut-off.
Owning or sponsoring an autonomous-system registration can be useful before traffic begins. It allows a network to define policy and arrange upstream sessions. Yet an ASN is not a router, a fibre, a rack or a megabit of purchased transit. It is an identifier used to express a routing domain. The RIPE NCC explanation of autonomous-system numbers is explicit that an ASN supports a distinct external routing policy. The identifier may be ready long before equipment is installed, or remain registered after traffic stops.
The current company therefore has two registered identifiers but only one with a recent operating signal. That asymmetry should shape any resilience claim. Two ASNs do not mean two networks. They do not imply two data centres, two border routers or two contracts. AS39755's inactivity removes it as evidence of a current backup. A customer would need to see how each number is used, whether both are configured on separate equipment, and whether any service can move between them without renumbering or prolonged downtime.
One /24 became visible only days before publication
AS56421 changed from a registration clue into an operating clue in July 2026. A RIPE route object authorizing the association between AS56421 and 185.243.98.0/24 was created on 7 July. RIPEstat's routing history for the prefix began seeing AS56421 as an origin on 8 July. This is unusually fresh evidence: it says the company-controlled ASN had reached at least part of the global routing system, not that it had done so for months.
At 12:00 UTC on 10 July, the RIPEstat BGP state for the block contained 381 observed paths. Twenty-seven ended at AS56421, while 354 ended at AS48693. Counts from route collectors are not a market-share or traffic measure, and collectors do not represent every network. They do show that the new origin had limited propagation while the established origin remained much more widely visible at that moment.
The prefix contains 256 IPv4 addresses. Even that simple number must be bounded. Network and broadcast conventions, router addresses, customer allocation practices, filtering and reservation can reduce assignable space. One address can host many virtual services behind translation or name-based hosting; one dedicated customer can consume several addresses. The /24 reveals neither server count nor sold capacity. It is also the customary minimum IPv4 prefix length accepted by much of the global internet, so it is a natural unit to advertise even for a small edge.
No IPv6 origin from the company was established at the cut-off. IPv4-only evidence does not make a hosting service unusable, but it narrows what has been demonstrated. A modern service can provide IPv6 through a parent network, a proxy or another routing arrangement without originating its own block. There is simply no public basis here to say that 3D CLOUD COMMUNICATION offers customer IPv6, dual-stack management or a tested migration path between address families.
The short observation window is the most important capacity fact. A route visible for two days can carry production traffic, testing traffic, a migration or a new customer segment. Public routing does not disclose which. It cannot reveal processor count, memory, storage, virtualization density, occupied rack units, power draw, bandwidth commitment or billable accounts. Treating the /24 as proof of a cloud estate would confuse address reachability with compute supply.
The same block still had two origins
The July event was not a clean replacement in the public view. RIPEstat's prefix overview identified both AS48693 and AS56421 as origins. A route announced from more than one autonomous system is commonly called a multiple-origin AS, or MOAS, condition. It can be intentional: operators use overlapping announcements during migrations, customer multihoming, DDoS mitigation and traffic engineering. It can also result from error or unauthorized origination. The observation alone does not decide which explanation applies.
The ownership records keep the uncertainty open. The RIPE inetnum record assigns the block to an organization identified as Rices Privately owned enterprise under the net name NTS-03. Its organization record gives a Ukrainian registration and an ntup.net contact domain. A separate route object for AS48693 had existed since December 2023. The newer route object for AS56421 was maintained under a different maintainer than the company contact record.
The reverse naming also remained associated with the earlier network. IPinfo's block view listed gw.reserved.ntup.net for the first gateway address and free.ntup.net across much of the range in its indexed observation. Reverse DNS can lag a legitimate transfer or lease, and generic free labels do not prove that addresses are idle. They do, however, show that public naming had not yet been reworked into a recognizable 3D CLOUD COMMUNICATION service estate.
Route-origin authorization did not settle the matter. The RIPEstat RPKI validation result returned unknown, with no validating route-origin authorization for the AS56421 and /24 combination. Unknown is not invalid. It means relying parties had no cryptographic statement in the Resource Public Key Infrastructure that authorized or rejected this origin. The RIPE NCC RPKI overview explains how route-origin authorizations let holders specify which AS may announce a prefix.
The practical risk is divergence. Some networks may prefer the path through AS48693, others the path through AS56421, depending on policy and path length. If the two origins do not lead to the same service or coordinated network, users can reach different destinations or lose connectivity. If the arrangement is intentional and both paths converge correctly, it can support a transition. A public letter of authorization, a route-origin authorization covering the intended origin, an updated prefix record and a clear migration date would distinguish a controlled handover from an unresolved overlap.
Registered upstream policy is larger than observed carriage
AS56421's RIPE record listed a long set of intended import and export relationships, including AS6939, AS5577, AS202171, AS174, AS42602, AS50073, AS203142 and AS1299. On 7 July it was updated again to add AS41033 and AS209155. This appears diverse on paper. An RPSL import statement, however, describes declared routing policy. It does not prove that a physical circuit is installed, a BGP session is established, a port is paid, or the alternate path has enough capacity during a failure.
At the 10 July cut-off, RIPEstat's neighbour observation saw one left-side neighbour: AS41033. The time-specific BGP state likewise showed the AS56421 paths passing through AS41033. This is operating evidence for one upstream route. It is not evidence of the eight older registered relationships being active at the same time.
AS41033 is itself a substantial interconnection network. Its PeeringDB record identifies D2 CLOUD COMMUNICATIONS and lists public exchange presence plus facilities in Kyiv, Warsaw, Frankfurt, Amsterdam and other locations. The operator's website presents network services. Those facts help characterize the upstream. They do not locate AS56421's router. A customer session can reach a wide-area upstream from one local cross-connect without occupying every facility that upstream lists.
This distinction matters for the assigned Global region. A route carried by a network with international reach makes an IPv4 service reachable globally. It does not prove that 3D CLOUD COMMUNICATION operates global infrastructure or sells in every market. The verified corporate location is Kyiv. The verified routing edge used an internationally connected upstream. The service area, contracting countries, billing currencies, support languages and data-placement choices were not publicly established.
One observed upstream also leaves a basic recovery question. If AS41033 withdraws the route, does AS56421 have a live second session with independent capacity? The registration suggests possible candidates, but a tested answer requires simultaneous route observations or provider documentation. Even two observed AS paths can share one fibre entrance, one meet-me room, one router, one power feed or one metro corridor. Logical diversity is valuable; physical independence requires additional evidence.
A Kyiv address is not a rack map
The legal and RIPE records place the company at 39 Idzykovsky Family Street in Kyiv. That is a verified registered and contact address. It is not a verified server location. Corporate addresses can identify offices, mail handling, shared commercial premises or facilities in which equipment is also present. None of the company records specifies a suite, rack, cage, power allocation or data hall.
The address has genuine telecom context. R-TEL's public site uses the same street address and advertises business internet and round-the-clock support. R-TEL's corporate record also places the telecommunications company there. Orion's contact page lists the address for internet services, while the property company's record identifies an entity at the same number whose activities include owning or leasing real estate. These are useful location signals, but they do not prove a contract, ownership tie or shared infrastructure with 3D CLOUD COMMUNICATION.
The building could offer carrier access and technical space, or it could simply host several unrelated tenants. A photograph of another operator's server room would not establish ownership of the company's machines. A common postal address would not establish a protected fibre path. The evidence needed is ordinary and specific: the facility operator's name, country and city, whether the company owns or leases rack space, rack power limits, carrier entries, cross-connect providers, access controls and the party responsible for remote hands.
Physical location shapes more than latency. It determines the electricity grid, generator fuel logistics, cooling environment, fire controls, civil-defence exposure, technician travel and the law governing the stored data. Kyiv is operating under wartime infrastructure pressure. That context makes power continuity and geographic recovery especially important, but it should not be used to assume a particular failure. The company has not published its site design, backup-energy duration or recovery location.
A customer should therefore resist two opposite errors. The first is to infer that the legal address is a data centre and attribute every nearby telecom asset to the company. The second is to infer that no infrastructure exists because no public site map was found. Small providers often operate from leased space without extensive marketing. The correct assessment is narrower: a Kyiv operating nexus is plausible and the address has telecom associations, but rack location and ownership remain unverified.
Every hosted instance sits on a physical and contractual chain
Whether the offer is a virtual private server, a managed server or a cloud instance, the customer-visible unit depends on a stack of finite assets. At the bottom are a building, electrical intake, switchgear, batteries, generators or other backup supply, cooling, fire controls and physical security. Above that sit racks, power distribution, servers, storage, switches, routers, optics and cabling. Transit, address space and routing make the system reachable. Billing, monitoring, backups, credentials and technicians turn the machinery into a service.
The public company evidence verifies only fragments of this chain. The registered activity points to hosting. The July BGP observation points to one reachable network edge. The Kyiv address points to a legal and contact location. It does not verify a data hall, a single server, a storage array or a paid customer. No named facility operator, equipment vendor, virtualization layer, backup platform or monitoring system was tied publicly to the company.
This creates an ownership boundary that a contract must resolve. The company may own hardware but lease rack and power. It may lease servers from another host and control only software and billing. It may resell virtual instances and operate no physical machine. It may provide management for customer-owned systems. Each arrangement can deliver a legitimate service, but the failure owner changes. A facility power failure is escalated differently from a failed leased drive; a transit dispute is different from an expired customer subscription.
The prefix records add another contractual layer. The visible IPv4 block remains assigned to Rices Privately owned enterprise, while AS56421 originated it through AS41033. That arrangement could be authorized provider-independent-style use, a lease or a transition, but the public records do not state the commercial terms. If access to the block depends on another party's agreement, termination or dispute can force renumbering. For customers that whitelist addresses, publish DNS records or bind licences to IPs, renumbering can become a business interruption.
The same is true of upstream carriage. If one provider supplies all currently usable transit, a payment or contract failure can remove reachability even while servers remain powered. If a reseller relationship supplies the hardware, missed payments can threaten compute access separately. The cloud invoice hides these dependencies because the customer pays one counterparty. Due diligence should reconstruct the chain and identify where the company can repair directly and where it can only open a ticket with someone else.
Installed capacity is not usable capacity
The only quantified company-facing network asset in the public view is a /24: 256 IPv4 addresses. There is no verified port speed, committed data rate, burst allowance, storage total, core count, memory pool, rack count or power allocation. Even if those figures were advertised, each would need interpretation. Installed interfaces are not the same as traffic headroom, and gross storage is not the same as protected customer capacity.
Consider a hypothetical 10 Gbps uplink. Its label would describe interface speed, not the transit commitment, sustained throughput, packet-per-second limit or capacity available after another circuit fails. A one-gigabit contract on a ten-gigabit port can still congest at one gigabit. Two ten-gigabit ports on one router can fail together. No port figure is currently attributable to 3D CLOUD COMMUNICATION, so even this elementary comparison cannot be made.
Compute capacity has similar traps. A host can contain dozens of processor cores while oversubscription makes busy workloads contend. Thin-provisioned storage can show far more logical space than physical media. Replica copies can improve availability while consuming capacity that is not sellable. Backup data can share the same array or power domain as production. Without utilization, reservation, failure-domain and restore evidence, a catalogue number would still not establish usable resilience.
IPv4 address count is especially weak as a proxy. Virtual hosting can place many domains behind one address; dedicated services can use one address per instance; network appliances and spare assignments consume others. The RIPEstat announced-prefix view showing one /24 says that the edge had a small routable IPv4 footprint. It says nothing about how many addresses were allocated to customers or whether the block carried compute services at all.
A credible capacity statement would separate installed, lit, contracted, occupied and available resources. For the network, that means port speed, paid commitment, normal peak, failure-state peak and route diversity. For compute, it means physical hosts, reserved overhead, allocation policy and remaining headroom. For storage, it means raw, protected, used and restorable capacity. None of these layers is public for the company, so the article cannot responsibly convert the new route into a customer-available capacity claim.
The first failure path is the route itself
The July MOAS condition is the most immediate observable failure path. If AS48693 and AS56421 intentionally lead to the same endpoint, coordination must keep both paths consistent during the transition. If they lead to different endpoints, route selection can split users. An accidental withdrawal by one origin may improve or worsen reachability depending on which path a network preferred. Without route-origin authorization, cryptographic origin validation does not clarify the intended origin.
A route-object entry is helpful but not a complete security control. BGP, standardized in RFC 4271, exchanges reachability according to policy and path attributes; it does not natively authenticate that the originating organization owns the prefix. RPKI, whose architecture is described in RFC 6480, lets address holders make verifiable origin statements. A valid authorization would not prevent every leak or outage, but it would reduce ambiguity for networks that enforce route-origin validation.
The next failure path is upstream loss. At the time-specific observation, AS41033 was the sole visible neighbour for AS56421. A router fault, cross-connect failure, commercial suspension or upstream policy mistake could remove the new origin. The longer list in the registration may become real redundancy, but until multiple live paths appear and can carry the full load, it remains planned or historical policy rather than demonstrated recovery capacity.
Then comes the local edge. The public evidence does not show whether AS56421 runs on one router or several, whether route sessions terminate on separate chassis, or whether configurations are backed up. A single failed power supply, corrupted configuration, expired optic or inaccessible console can defeat multiple nominal upstreams. Spare hardware and out-of-band access often determine recovery time more than the number of carriers in a registration.
Finally, there is DNS and address continuity. The older ntup.net reverse names suggest that naming administration still crosses an organizational boundary. Forward customer DNS may be elsewhere, but no authoritative service was identified. During a prefix migration, stale DNS, allowlists, TLS bindings, geolocation databases and anti-abuse reputation can continue pointing to the previous network. The technical move is only complete when those surrounding systems are updated and customers know what changed.
Power, hardware stock and human repair remain blank spaces
A network route can look healthy while every customer server behind it is unavailable. The physical service depends on power and cooling at each rack. No public statement gives the company's utility feeds, UPS arrangement, generator capacity, fuel duration, cooling redundancy or maintenance schedule. The shared Kyiv address cannot fill those fields because nearby operators may use different rooms, feeds and contracts.
Hardware inventory is equally consequential for a small provider. A failed drive can be routine if compatible spares and a tested replica exist. It can become a prolonged outage if a replacement must cross a border, if firmware differs or if the only knowledgeable engineer is unavailable. The company has not disclosed server vendors, storage protection, spare ratios, remote-hands terms or replacement objectives. This is not evidence that spares are absent; it means repair time cannot be estimated publicly.
Support labour is part of capacity. An advertised CPU remains unusable if no one can recover a failed host or reset a stuck account. The company record identifies one director and the RIPE records identify one named administrative person behind the role. No staffing total, support hours, escalation path or language coverage was found. The label "support" itself cannot substitute for a tested ticket response.
Billing also belongs in the failure map. A new provider may depend on manual invoices, a payment processor or a reseller panel. A billing error can suspend service as effectively as a broken router. Customers need grace periods, dispute handling, renewal notices and a way to export data before termination. No public terms establish those protections for 3D CLOUD COMMUNICATION.
The most useful service-level evidence would be mundane: a support address on the company's own domain, severity definitions, response and restoration targets, maintenance notice rules, credit terms, and a phone escalation that is tested. A provider can be small and still publish clear obligations. In this case, the public Outlook-based contact in registry views and the generic role establish reachability for network administration, not a customer support commitment.
Redundancy needs separate failure domains
Resilience should be tested one layer at a time. Two virtual machines on one host protect against neither host failure nor rack power loss. Two hosts in one rack may protect against a motherboard failure but not a failed power distribution unit. Two racks in one room may share cooling and building power. Two sites connected through one carrier may share the same route. Redundancy exists only when the alternative survives the relevant failure.
No second 3D CLOUD COMMUNICATION site was verified. No public material names a backup region, availability zone, replica location or customer-selectable locality. AS39755 does not provide that evidence because it had no current route. The long AS56421 import list does not provide it because route policy does not locate compute. The global reach of AS41033 does not provide it because an upstream's facility list is not the customer's facility list.
Recovery also requires state. Stateless web traffic can move quickly if DNS, certificates and application deployment are prepared. A database needs consistent replicas or restorable backups. A virtual machine may need disk images, keys, network settings and enough spare compute at the destination. The company has not published recovery-point or recovery-time objectives, backup retention, restore-test results or the scope of any disaster-recovery offer.
The ENISA cloud-computing risk assessment treats provider dependency, data handling, business continuity and technical failure as connected risks. That framing fits this case. A second site matters only if the customer can reach it, the data is there, the identity system works, the provider has authority to activate it and the contract permits the move. A map pin by itself is not recovery.
Evidence that would raise confidence includes two named facilities in distinct power and metro-risk domains, live routes through independent upstreams, documented replication, a recent restoration exercise and customer instructions for exporting data. Evidence that would raise it further includes measured recovery times and confirmation that backup-path network and compute capacity can carry the production load. None was public at the cut-off.
Data locality cannot be inferred from the company address
The assigned topic of data sovereignty is relevant precisely because location is unresolved. A Kyiv legal address establishes the company's jurisdictional nexus. It does not establish where customer data, backups, logs or support copies are stored. A server could be in the same building, elsewhere in Ukraine, in another European country or on a subcontractor's platform. The route path through AS41033 does not answer that question: packets can traverse a city or country without data being stored there.
Customers need four locations, not one. The first is the primary compute site. The second is the backup or replica site. The third is the location from which administrators can access data. The fourth is the legal location of each subcontractor that can process or recover it. These can differ. A contract saying only that the provider is Ukrainian leaves the physical and operational geography open.
Portability is the other side of sovereignty. A customer must know whether it can export virtual disks, database dumps, entity data, logs and encryption keys in usable formats. It must know how long an export takes, what bandwidth limits apply, and whether fees or arrears can block access. The new /24 and the continuing address overlap make network portability particularly concrete: a customer should not assume that an assigned IP can follow it to another provider.
Migration paths also need time and cooperation. DNS time-to-live values can be lowered, replicas can be seeded, and data can be copied before a cutover. But a failed provider contract can remove the time needed for an orderly move. No public termination, deletion, escrow or export terms were found for 3D CLOUD COMMUNICATION. Buyers should treat data exit as an unpriced and unverified dependency until those terms are supplied.
The evidence does not support a claim that customer data is outside Ukraine, nor does it support a claim that it stays inside. It supports only the need for a written locality schedule. That schedule should identify cities and countries, facility operators, backup geography, remote administration, subprocessors, deletion timing and the law governing disputes. Without it, "Global" describes potential network reach, not a verified data-residency offer.
Hosting economics concentrate risk in contracts the customer cannot see
Small hosting providers can compete by buying wholesale inputs and adding responsive management. The economics can be attractive: leased rack units avoid building a facility; rented servers reduce capital expense; transit and address arrangements can be purchased incrementally; a small team can automate routine provisioning. Customers may receive more direct attention than they would from a hyperscale platform. None of these advantages requires the provider to own a building.
The same structure creates dependency on renewal and margin. Rack rent, power, transit, address use, hardware leases, licences and support labour are recurring obligations. A provider can sell capacity only while those contracts remain funded and coordinated. A low introductory price can be sustainable if automation and utilization are strong, or fragile if it omits replacement, backup and support costs. No public price list or financial statement allows that distinction here.
Registered capital of UAH600,000 should not be read as infrastructure spending. It may support startup operations, but the legal figure does not say whether it bought equipment, remains liquid or covers any particular liability. The public company page did not provide revenue, assets, debt, employee count or audited accounts for a completed operating year. The company was less than a year old at the research cut-off.
The freshest technical action - originating a /24 through one observed upstream - is consistent with a business beginning or changing network operations. It is not enough to estimate scale. The block may support a small set of servers, a network transition, a customer, a test environment or future inventory. Reverse names saying free are suggestive but not decisive. A market-facing catalogue, invoices, customer references, utilization reports or service-status history would provide stronger operating evidence.
For a buyer, the key economic question is who must continue being paid for service to work. That includes the facility, electricity, upstream, address-space counterparty, equipment lessor, software vendor and support staff. The provider should be able to identify which dependencies are prepaid, month-to-month or cancellable, and what happens to customer data if one contract ends. A single low monthly fee is not a resilience measure unless it funds those obligations.
Unofficial signals are useful only when their limits are stated
Several public signals point in a coherent direction. The company chose a hosting activity, adopted a cloud name, created RIPE contacts, became the organization on two autonomous-system records and initiated a new origin through a cloud-branded upstream. Its registered address is shared by telecom businesses. Together, these facts suggest an attempt to establish or acquire a hosting and network operation in Kyiv.
They cannot prove a product launch, customer base, server fleet or facility tenancy. The address overlap cannot prove a relationship with R-TEL or Orion. The upstream's facility list cannot prove where the company's router sits. Reverse DNS cannot prove that addresses are unused. A route object cannot prove that every relevant commercial party approved the origin. The MOAS cannot prove either a benign transition or a hostile event without more context.
The date sequence is itself a signal: company formation in July 2025, RIPE organization and contacts at the end of December, ASN updates on 2 January 2026, a route object on 7 July and observed origination from 8 July. This looks like staged preparation followed by network activation. It could also reflect an administrative transfer whose commercial service is not yet public. The evidence settles chronology, not purpose.
What would settle the business question is straightforward. A company-controlled website should name the legal seller and company number, describe products and prices, publish terms, identify support channels, disclose data locations and explain cancellation. What would settle the infrastructure question is a facility and network statement identifying rack operator boundaries, live upstreams, route authorization, port commitments, IPv6, backup sites and tested recovery. What would settle the operating-status question is sustained routing plus customer-facing activity over time.
Until those materials appear, the correct downgrade is explicit. The company is not a fictitious name: it is a registered Ukrainian LLC with current network records and a recent route. But the public case for a dependable customer-facing cloud remains incomplete. The difference protects both readers and the company from claims that the evidence cannot carry.
A buyer should make the dependency chain contractual
Before placing a production workload, a customer should ask the company to identify the legal contracting party as LLC "3D CLOUD COMMUNICATION" and use company number 45920348 on the agreement and invoice. The agreement should state whether the service is resale, managed hosting, virtual private server, bare metal, colocation or another form. It should identify which assets the company owns and which are supplied by other operators.
The network schedule should state the customer prefixes, upstreams, expected origin AS, route-origin authorization status and failover design. For the currently visible /24, it should explain the concurrent AS48693 and AS56421 announcements, identify the address holder's authorization and give a completion date if this is a migration. Customers should know whether addresses are portable, how renumbering is handled and whether a route change triggers notice.
The facility schedule should name the city, country and operator for primary and backup service. It should describe rack power, backup power, cooling, physical access, remote hands and carrier entrances at a level appropriate for due diligence. Sensitive floor plans are unnecessary; the ownership and failure boundaries are not. If there is only one site, the agreement should say so plainly and avoid implying geographic redundancy.
The service schedule should define availability, exclusions, maintenance, severity, response, restoration, credits and escalation. It should state what is backed up, how often, where copies reside, how long they are kept and how restores are tested. It should say which failures the company repairs directly and which depend on a facility or upstream ticket. It should also address the loss of one named engineer.
The exit schedule should be as detailed as the order. Customers need machine-image and data-export formats, throughput and fee limits, retention after cancellation, deletion confirmation, access during disputes and assistance during migration. They should retain their own independent backups and credentials. A service that cannot be exited predictably is not fully controlled by the customer, regardless of how easily it was purchased.
Finally, evidence should be refreshed after the July routing transition. Sustained origin visibility, removal or explanation of the older origin, a valid route-origin authorization, live alternate transit and consistent reverse naming would materially improve network confidence. A public product page, legal terms and status history would improve commercial confidence. Facility and restore evidence would improve resilience confidence. Each closes a different gap; none can stand in for all the others.
The honest rating is a live edge with weak service evidence
There is more here than a name in a company catalogue. LLC 3D CLOUD COMMUNICATION is active in Ukrainian corporate records. It has a hosting-related principal activity. Its RIPE organization and contact records are coherent with the legal identity. AS56421 began appearing as an origin for an IPv4 block through an observed upstream immediately before publication. These are meaningful facts.
The facts stop short of the headline's strongest commercial implication. No customer-facing offer tied to the company was verified. No rack, server, storage platform, data centre, port speed, second site or support commitment was established. The one visible block remained in a multiple-origin state, assigned to another organization, with unknown RPKI status and older reverse naming. The second registered ASN was inactive. The service area and data geography remained unspecified.
That combination supports a Weak network evidence grade, not a finding that the company is inactive. It is a young legal operator with a newly active edge and a large disclosure gap. The route may mature, the address transition may complete and commercial material may emerge. As of 10 July 2026, buyers should treat hosted capacity, redundancy and global service as claims requiring direct proof.
The physical lesson is broader but company-specific in its details. A cloud name can be registered in a day; an ASN can predate its present holder by fifteen years; a /24 can appear through a transit provider in hours. Dependable hosting takes longer because it requires power, hardware, spares, contracts, people, backups and rehearsed exits to work together. For support 3D CLOUD COMMUNICATION, those dependencies are the substance still waiting to be shown.