There is a sales pitch circulating in the satellite communications industry that goes something like this: the future belongs to multi-orbit architectures. Combine LEO constellations for low latency, MEO satellites for wide coverage, and GEO birds for global reach, stitch them together with intelligent routing, and you get a network that is resilient, flexible, and impossible to deny all at once. The pitch is elegant. It has won contracts. The Pentagon has seemingly embraced it as a path to reducing dependence on any single orbital layer or provider.

A San Francisco telecom software startup called Contrivian thinks the pitch is wrong. Not wrong in the way that a bad business plan is wrong, but wrong in the way that physics makes things wrong: the kind of wrong that shows up in packet loss graphs, frozen video feeds, and TCP congestion windows that cannot figure out what the network is doing.

Contrivian’s counter-thesis is simple. Instead of stitching together satellites at different altitudes, stay in LEO and stitch together different providers. Provider diversity within the same orbital regime instead of orbital diversity across regimes. The performance stays consistent. The redundancy comes from having multiple independent constellations rather than multiple orbital layers.

The debate between these two approaches is becoming one of the more consequential arguments in satellite communications, touching everything from Pentagon acquisition strategy to how commercial operators design their next-generation networks. And at its core, it is a debate about a physical constant that no amount of engineering can change: the speed of light.

The Case for Multi-Orbit

The multi-orbit argument starts with resilience. If an adversary jams or destroys satellites in one orbital layer, traffic routes through another. SES, which operates both GEO satellites and the MEO-based O3b mPOWER constellation, has been the most vocal proponent of this architecture. Telesat, with its Lightspeed LEO constellation designed to complement its existing GEO fleet, makes a similar argument. Intelsat has pursued comparable strategies.

The logic has a military appeal that is hard to dismiss. A threat actor targeting LEO satellites faces a different problem than one targeting GEO satellites. The jamming power requirements differ. The orbital mechanics differ. The anti-satellite weapon profiles differ. Forcing an adversary to develop capabilities across multiple orbital regimes raises the cost and complexity of any denial-of-service campaign against your communications infrastructure.

SES’s CEO has also pushed back on the assumption that LEO always wins on latency. The argument is that LEO constellations, because each satellite covers a relatively small area, require multiple hops for long-distance communications. A call from Africa to London on a LEO network might pass through several satellite-to-satellite links before reaching its destination, and each hop adds delay. On a MEO or GEO system, the coverage footprint is large enough that the signal can reach its destination with fewer hops, potentially offsetting some of the altitude penalty.

Telesat has bolstered this point with real-world data. A Lightspeed prototype demonstrated 26.5 ms latency at speeds of 100/96 Mbps, a figure that is competitive with many LEO measurements and well below what most people associate with higher-altitude systems.

The Physics Problem

Contrivian’s argument begins where the multi-orbit pitch glosses over details. The issue is not that any single orbit is bad. GEO satellites work well for broadcast applications and maritime coverage. MEO systems like O3b mPOWER deliver impressive throughput. LEO constellations provide latency that approaches terrestrial networks. Each regime has its strengths in isolation.

The problem emerges when you combine them into a single managed network and expect traffic to flow seamlessly across altitude boundaries. The physics of signal propagation at different altitudes creates fundamentally different network characteristics, and modern internet protocols were not designed to handle that kind of variability on a single connection.

Consider what happens to a video conference call when its traffic path shifts from a LEO satellite (40 ms round-trip) to a GEO satellite (600+ ms round-trip). The latency does not just increase by a fixed amount. The jitter, the variation in packet arrival times, spikes dramatically. The TCP congestion control algorithms running on both endpoints, which have spent the last several minutes calibrating their behavior to a 40 ms path, suddenly encounter a path that is fifteen times slower. The algorithms interpret this as network congestion and throttle back. Buffers fill. Video freezes. Audio drops.

This is not a theoretical concern. It is a known characteristic of TCP behavior across heterogeneous network paths. The protocols that carry the vast majority of internet traffic assume a degree of path consistency that multi-orbit routing fundamentally violates. You can engineer around it with protocol-aware traffic shaping, per-orbit tuning, and application-layer buffering, but each of those solutions adds complexity, latency, and cost. At some point, the engineering required to make multi-orbit routing work smoothly starts to undermine the performance advantages that drove the architecture in the first place.

What Contrivian Is Actually Building

Contrivian’s product, called Contrivian Constellation, takes a different approach to the redundancy problem. Instead of routing traffic across orbital layers, it routes traffic across LEO providers. If your Starlink terminal loses connectivity, your traffic shifts to Amazon Kuiper, or to another LEO constellation, under a single managed service layer. The user sees one network. The routing engine sees multiple independent LEO constellations and picks the best available path.

The key advantage is consistency. Every path in a LEO-only architecture shares roughly the same latency characteristics. TCP congestion control behaves predictably because the round-trip times stay in the same range. Video calls do not freeze when traffic shifts between providers because the shift does not cross an altitude boundary. The performance envelope stays narrow and predictable, which is exactly what latency-sensitive applications need.

The provider-diversity model also offers its own form of resilience. Starlink and Kuiper operate on different frequencies, use different ground infrastructure, and are controlled by different organizations. An adversary would need to deny multiple independent systems simultaneously, which presents a similar challenge to denying multiple orbital layers. The resilience comes from architectural independence rather than altitude diversity.

The Military Calculus

The Pentagon is watching this debate closely, and its own investments reflect the tension. The Space Development Agency’s Proliferated Warfighter Space Architecture (PWSA) is primarily LEO-based, built around a transport layer of hundreds of satellites in low Earth orbit with optical inter-satellite links. The design philosophy aligns more with Contrivian’s thesis than with the multi-orbit approach: proliferate in one regime, make the constellation too numerous to deny completely, and keep the latency low enough for tactical applications.

Contrivian itself is being tested with U.S. Special Operations Forces. SOF missions place a premium on consistent, low-latency communications. A Special Forces team coordinating a raid needs its video feed, its voice comms, and its data links to work without interruption. If the network routes traffic through a GEO satellite and the video stutters for two seconds during a critical moment, the performance cost is not measured in user experience metrics. It is measured in operational risk.

The SDA released a list of 19 commercial firms eligible for PWSA prototype demonstrations, signaling that the military market is open to multiple providers within the LEO layer. This is precisely the kind of competitive, multi-provider ecosystem that Contrivian’s platform is designed to orchestrate. If the Pentagon concludes that provider diversity in LEO delivers sufficient resilience without the performance penalties of multi-orbit routing, it could shift significant acquisition dollars away from traditional multi-orbit operators.

That said, the military’s requirements are not monolithic. Strategic communications can tolerate the higher latency of GEO. Intelligence, surveillance, and reconnaissance downlinks often use dedicated high-bandwidth GEO channels. The question is not whether GEO and MEO satellites have military value, because they clearly do, but whether integrating them into the same tactical network as LEO assets creates more problems than it solves.

The Counter-Counter-Argument

The multi-orbit proponents have reasonable responses to all of this. On the latency mixing problem, they argue that intelligent traffic management can assign latency-sensitive applications to LEO paths and route bulk data through MEO or GEO. Not every application needs 40 ms latency, and forcing all traffic into LEO when some of it would be perfectly happy on a GEO link wastes LEO capacity that could serve users who actually need it.

On the multi-hop concern, SES’s point about LEO inter-satellite routing adding latency on long-distance paths is valid. A LEO constellation without optical inter-satellite links (which describes many current deployments) must bounce traffic down to a ground station, across terrestrial fiber, and back up to another satellite for long-haul routes. That ground segment adds latency and introduces terrestrial infrastructure dependencies that partially negate LEO’s altitude advantage.

Telesat’s 26.5 ms latency demonstration also complicates the clean narrative that MEO is too slow. If a MEO system can deliver latency comparable to LEO for many use cases, the performance gap narrows and the multi-orbit routing penalty becomes smaller. The debate is not as simple as “LEO fast, GEO slow” when the middle orbit delivers competitive numbers.

Where This Goes

The satellite industry has a history of arguments that seem like technical debates but are actually market positioning. The multi-orbit pitch benefits operators who have invested billions in GEO and MEO assets and need those assets to remain central to next-generation architectures. The LEO-only pitch benefits startups like Contrivian that are building software layers on top of someone else’s constellation hardware without the capital burden of launching their own satellites.

Neither side is entirely wrong. Multi-orbit architectures offer a form of resilience that LEO-only cannot replicate: physical diversity across altitude regimes that complicates any single-vector attack. LEO-only provider diversity offers performance consistency that multi-orbit cannot match without significant protocol engineering. The right answer probably depends on the application. A maritime operator who needs global coverage and can tolerate latency variation has different requirements than a Special Forces team that needs 40 ms video feeds in contested environments.

What makes the debate worth watching is that Contrivian is building a product that lets the market test its thesis, not merely arguing about architecture in conference keynotes. If Contrivian Constellation can deliver seamless failover between LEO providers with consistent latency, the value proposition of multi-orbit resilience starts to look like an expensive solution to a problem that provider diversity solves more cheaply. If the product stumbles on coverage gaps, capacity constraints, or provider coordination problems, the multi-orbit operators will have their answer too.

The physics, at least, is not going to change. Light still takes 240 milliseconds to reach GEO and come back. Whether that matters depends on what you are doing with the signal when it arrives.