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. Delay is light-lag. It is not a parameter you can reduce by buying better hardware; it is set by geometry and by the speed of light, and every coordination decision made in orbit is made against a picture of the constellation that is already out of date.
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 light-lag to your scheduling timescale sits on the safe side of the cliff.
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.
Related
The delay results are in The Delay Cliff and Seeing Through the Lag. The consistency machinery for propagating intent over a contact plan is described in ICCD; the market mechanism that schedules work without a planner is described in Energy-Aware Hierarchical Markets. Both are working drafts whose result tables await their canonical runs.
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.