Orbital Compute Constellations

An orbital compute constellation is a set of satellites carrying general-purpose processors — increasingly, machine-learning accelerators — that cooperate to run computational workloads in space rather than on the ground. It is the application that most directly motivates Arboria’s research, because it forces the constraint we study to be taken seriously: coordination under a communication delay that cannot be engineered away.

Why compute is moving up

Three physical arguments, none of them about space being interesting.

Power. A satellite in a sun-synchronous orbit receives near-continuous solar illumination, unmoderated by atmosphere, weather, or night. The available power per square metre substantially exceeds what terrestrial photovoltaics deliver, and it arrives without the storage requirement that makes ground solar expensive.

Cooling. Terrestrial datacenters reject heat into air or water, and the water is increasingly contested. A spacecraft rejects heat by radiating it into a 3 K background. Radiators are heavy and thermal design is genuinely hard, but the sink is free and inexhaustible.

Siting. No land, no grid interconnection queue, no local opposition, no water rights.

Against these: launch mass costs money, radiation degrades semiconductors, maintenance is impossible, and — the constraint that concerns us — the nodes are separated by distances over which light takes measurable time.

The interest is not speculative. Recent commercial activity has put GPU-class hardware in orbit and announced constellations of tens of satellites flying in kilometre-scale formations, linked by optical inter-satellite links, carrying tensor accelerators. The engineering is being attempted now.

The coordination problem

A compute constellation is a distributed system whose network topology is a function of orbital mechanics. This changes the problem in ways that are easy to underestimate.

The network is a schedule, not a graph

Two satellites can exchange data when they have line of sight, when they are within range of their optical terminals, and when the relative geometry permits pointing and Doppler compensation. All three conditions are deterministic functions of time, computable in advance from the orbits.

The correct abstraction is therefore not a network graph but a time-expanded contact plan: a schedule of when each link exists and what capacity it has. This is the setting of delay-tolerant networking , developed originally for deep-space communication, in which there may be no contemporaneous end-to-end path between two nodes and data must be stored, carried, and forwarded.

Consensus protocols designed for datacenter networks — Paxos , Raft — assume that a majority is reachable most of the time. That assumption does not hold here, and the FLP impossibility result means it cannot simply be assumed away.

Power and thermal state are the scheduling problem

A ground datacenter schedules against compute capacity. An orbital one schedules against energy, which arrives as a function of orbital position and stops entirely during eclipse ; against thermal capacity, since a node that has been computing hard has heat it must radiate before it can compute again; and against downlink windows, since results must reach the ground and the ground station is only overhead sometimes.

Node capability is therefore time-varying, predictable, and coupled across the constellation. A job placed on the wrong satellite at the wrong time does not run slowly — it does not run.

Formation keeping

Optical inter-satellite links are narrow. Holding a kilometre-scale formation to the tolerance a link budget demands is a control problem in relative orbital dynamics , executed continuously, with a propellant budget that is finite and unreplenishable, and a collision consequence that is unrecoverable.

Radiation

Cosmic rays and trapped protons flip bits. Single-event upsets corrupt memory and occasionally corrupt the state a node uses to participate in a protocol. A node suffering an upset does not fail cleanly — it may continue to participate while reporting nonsense.

This is the difference between a fail-stop fault and a Byzantine one. Most swarm coordination mechanisms tolerate agents that die and are defeated by agents that lie. Radiation makes the second case ordinary rather than adversarial.

Why this is a swarm problem

The obvious architecture is a central scheduler — on the ground, or on a designated satellite — that assigns work.

It does not survive contact with the constraints. A ground scheduler is separated from the constellation by a downlink that exists intermittently. A designated satellite is a single point of failure in an environment that destroys hardware, and its decisions reach the rest of the constellation over the same contact plan everything else does. Centralized coordination requires an always-on channel, which is exactly what orbital geometry withholds.

What remains is decentralized coordination: each node reasons from what it knows, agrees with its neighbours where it can, and acts without waiting for permission that may not arrive.

And that turns the constellation into an instance of the general problem this lab studies. Every coordination decision made in orbit is made against a picture of the constellation that is already out of date — but it is worth being precise about why, because the intuitive answer is wrong.

The delay is not light-lag. It is contact-wait. Light crosses a 1 km satellite formation in about 3 microseconds, and even a 5,000 km inter-satellite link costs only 17 milliseconds — six orders of magnitude below the boundary where our measured coordination collapse begins. No propagation delay anywhere in cis-lunar space comes close to it. What actually makes a message late is waiting for a link to exist at all: store-and-forward across a sparse, time-varying mesh whose nodes drift in and out of view on orbital timescales. Measured on a Walker 24/4/1 constellation with 5,000 km optical links, the mean end-to-end delay is 140 seconds — of which 99.95% is waiting and 0.05% is flight.

That distinction is not pedantry; it changes what you can do about it. Light-lag is fixed by physics and cannot be engineered away. Contact-wait is a property of your topology and your schedule, and it can be — by densifying links, by routing over the contact graph instead of an assumed always-on network, or by letting nodes act on a prediction rather than wait for a fact. Which is exactly what the research below is about.

What our research says about it

Our measured result is that decentralized coordination quality does not degrade smoothly as communication delay grows. It collapses through a boundary — near 10 to 20 steps of delay in units of the task timescale — and three things about that collapse make it consequential here.

It is primitive-independent: gossip consensus, flocking, and replicated-intent propagation over a delay-tolerant network all fail at the same place. Choosing a cleverer coordination algorithm does not move the boundary.

It is invariant in swarm size across the range we tested. An 81-satellite formation and a 2,000-node constellation face the same boundary, which is unusual and useful: it means the result can be established at a scale that simulates cheaply.

And it is recoverable by anticipation. Letting each node extrapolate where its peers have gone since it last heard from them restores most of the lost coordination quality — and the cheapest predictor wins. Constant-velocity extrapolation outperformed a Kalman filter, because bounded actuation keeps trajectories nearly linear over the prediction horizon.

For a constellation, the practical reading is that what matters is not which consensus protocol you deploy but whether your nodes model each other’s near-future state, and whether the ratio of your contact-wait to your scheduling timescale sits on the safe side of the cliff. Note which lever that hands you: contact-wait is set by the contact plan, so it is a quantity a constellation designer can actually move.

Scope, honestly

Those results come from a simplified three-dimensional kinematic simulator with a real communication model — range, bandwidth, propagation delay, loss, and a per-bit transmit energy that grows with distance — and no orbital dynamics. They are claims about coordination algorithms, not about spacecraft.

Extending them to a constellation requires fidelity we are building rather than claiming: real orbit propagation and the contact plans that follow from it, eclipse and solar geometry, power and thermal budgets, single-event-upset fault models, and — for formation work specifically — relative orbital dynamics and a conjunction model. We say which claims need which fidelity in Reproducibility and Data Availability, and we do not make the ones we cannot back.

The delay results are in Phase Diagram of Coordination Under Delay and Anticipatory Coordination via Peer-State Prediction. The consistency machinery for propagating intent over a contact plan is described in ICCD, whose mechanism is implemented but whose result tables are illustrative rather than measured — cite it for what it builds, not what it reports. The market mechanism that schedules work without a planner is measured in Energy-Aware Hierarchical Markets, which also carries the precondition that any orbital retarget inherits: the market beats a first-come baseline only where capacity is scarce, and is measurably worse than it when over-provisioned.

Adjacent applications include orbital debris mitigation, which any constellation operator must reckon with, and Dyson swarm energy harvesting, which is the same coordination problem several orders of magnitude further out. The underlying obstacle is set out in communication in harsh environments.