A distinctive ETHPrague 2026 track introduced satellite-based compute infrastructure as an emerging crypto-native primitive. Orbitport (Space Computer, Amir Yahalom) and Space Fabric (Filip Rezabek) form the working ecosystem. The core thesis: physical inaccessibility plus TEE-based attestation gives stronger trust guarantees than any earth-based confidential-compute deployment, with cosmic-radiation entropy as a bonus true-randomness source. The track is the most concrete instance of a 2025–2026 pattern — crypto investing in physical infrastructure beyond pure-software stack.

Key Ideas

Why orbital compute is interesting for crypto

The constellation of properties that make space attractive:

  1. Physical inaccessibility — Nobody can reach the hardware. Side-channel attacks, supply-chain hardware tampering, and physical key extraction are all impossible.
  2. Verifiable origin — Cryptographic attestation that compute is happening on a specific satellite at a specific altitude (the SEAP protocol).
  3. True randomness from cosmic radiation — Space radiation provides a natural high-entropy source.
  4. Geopolitical neutrality — Compute that is not under any sovereign’s jurisdiction in any straightforward sense.

Orbitport architecture (Amir Yahalom, Space Computer)

The end-to-end stack as presented:

Earth side (TDX-based TEE):

  • Intel TDX confidential VMs running on GCP confidential compute.
  • Reverse proxy, account provider, gateway, connector services.
  • Open Bao (open-source Vault fork) for KMS, extended with Go plugins (Ethereum signing, threshold ECDSA roadmapped, post-quantum signature roadmapped).
  • All container images Docker Hardened, full SBOM tracking, integrated into MOSI-built OS images.

Space side (ARM TrustZone on hardware):

  • USB Armory (ARM TrustZone-capable secure device) on top of a Raspberry Pi.
  • Custom YOCTO-built OS, secure boot ceremony.
  • Two secure elements (NXP SE050, Tropic Square TROPIC01) for hardware-backed key generation.
  • Aluminium box for radiation shielding; copper striping for thermal dissipation.
  • CubeSat form factor.

Communications:

  • Ground stations for command/control (UHF) and bulk data (S-band).
  • Iridium constellation for low-latency uniccast (Short Burst Data; bursts limited to ~340 bytes; tens-of-seconds to minutes latency).
  • Starlink for high-bandwidth (but Starlink ISL is now laser-based, not RF, which is hard to retrofit to small satellites).

Orbitport itself:

  • Aggregation/batching of incoming compute requests to maximize ground-station utilization.
  • Multi-provider redundancy (Iridium + ground station) for reliability-vs-cost balance.
  • Bidirectional attestation between TDX-on-earth and TrustZone-in-space.

CTRNG — Cosmic True Random Number Generator

The headline service. Entropy gathered from on-satellite cosmic-radiation sensors, certified random by statistical verification (multiple tests built in). Two access modes:

  1. API access with client credentials — full per-request true randomness from space.
  2. Public randomness beacon — a chain of blocks with new randomness posted every ~5 minutes; freely queryable.

The beacon is implemented as mixed-RNG: cosmic entropy as seed, deterministically expanded via ChaCha into many outputs until the seed pool is exhausted. SDK provides the standard Rust RNG trait, so existing threshold-cryptography libraries can drop it in.

KMS in space

The headline application. Earth-based KMS has the classic chicken-and-egg root-key problem — you need to store the root key in some KMS, which means you trust some cloud or HSM. Space-based KMS lets you store the root key inside a TrustZone enclave on a satellite, with cryptographic attestation that the key never left the enclave and the satellite is the one you provisioned.

Plugins implemented or roadmapped:

  • Ethereum key management and signing (live).
  • Threshold ECDSA (roadmapped).
  • Post-quantum signature schemes (roadmapped).
  • General cloud-KMS operations (decrypt/encrypt/sign per Open Bao).

SEAP — Security Execution Assurance Protocol

The provisioning protocol Orbitport developed with Common Prefix. Designed to convince an earth-based party that a specific satellite is running a specific software image:

  1. At satellite launch, generate two keys (on the SE050 and the TROPIC01).
  2. The keys must be used in a multi-ground-station challenge-response ceremony.
  3. Multiple geographically-distributed ground stations must each see a fresh response, forming a proof that the satellite is at the claimed altitude (you cannot fake the propagation delay).
  4. The attestation is currently one-shot at provisioning but designed to extend to periodic re-attestation.

This is the cryptographic answer to “how do I know the operator didn’t just put the Raspberry Pi in their garage and claim it’s in space?”

Space Fabric (Filip Rezabek)

Companion talk: reinventing hardware architecture for orbital infrastructure. Key constraints:

  • Single-event upsets — Cosmic radiation flips bits in standard RAM. Mitigations: triple-modular-redundancy hardware patterns, error-correcting memory, software-level execution-of-the-same-computation multiple times.
  • Power budgets — Satellites have very limited power. Solar plus battery, but most subsystems compete for power; the compute layer cannot assume always-on.
  • Thermal management — Vacuum has no convection. Aluminium-and-copper passive thermal dissipation is the working solution at this scale.

Space Fabric is the hardware-architecture layer; Orbitport is the application layer; both work toward the same vision.

Confidential Compute for Orbital AI — Daniel Bar

Daniel Bar’s complementary talk: combine the orbital-TEE pattern with confidential-AI workloads. The product is “I send you my prompt; you (the operator) cannot read it; your model weights stay encrypted; the satellite runs the inference; the answer is encrypted to my key.” For valuable IP (model weights) and sensitive inputs (medical, financial, government), this is structurally stronger than any earth-based TEE because the physical attack vector is closed.

Details / Subtopics

Why TDX on earth and ARM TrustZone in space

Different optimisation targets. TDX gives you VM-level isolation and is mature on GCP/Azure. ARM TrustZone fits the embedded/single-core/low-power profile of satellite compute (no virtualization overhead). The two are bridged via mutually-attested encrypted communication channels.

Iridium SBD format constraints

The brutally specific limit: ~340 bytes per Iridium Short Burst Data packet. Implications for crypto-compute requests: you cannot send arbitrary inputs — must batch, must use compact encodings, must accept tens-of-seconds latency. Orbitport’s aggregation/batching is partly about packing requests into these constraints efficiently.

What it doesn’t try to do (yet)

  • Heavy compute — Power budgets prevent GPU workloads at the scale of earth-based confidential AI today. Confidential AI in space is therefore inference of small models and high-value but low-volume operations.
  • Real-time response — Best-case Iridium round trip is ~30 seconds; worst-case ground-station window may be minutes to hours. Use cases are batch-friendly.
  • High-throughput data — S-band ground stations can push more data but only within the limited operational windows.

Statistical-verification harness

The CTRNG outputs are validated using a built-in statistical-verification suite (chi-square, runs, NIST SP 800-22, etc.). The team has shipped a separate repo for this, which is also useful for any RNG validation work — not just cosmic.

Trust model summary

Earth-based confidential compute requires you to trust either: (a) a specific cloud provider (AWS, Azure, GCP) and their TEE attestation, (b) an HSM vendor and the specific hardware. Both have known supply-chain risks (firmware backdoors, vendor coercion).

Orbital compute adds the trust assumption that the satellite cannot be physically accessed. Subtracts the trust assumption that any single nation-state can compel the operator. The supply-chain risk on hardware is comparable (you still trust the Raspberry Pi vendor and the secure-element vendors), but the operational risk drops sharply.

Adjacent work

  • Confidential compute on existing cloud has been a 5-year-old story; what’s new is the orbital substrate.
  • Helios Light Client and Logos Freedom Browser (other ETHPrague decentralization talks) treat the earth-side trust assumption; orbital compute treats the operator-side trust assumption.

Connections

Open Questions

  • Does the orbital substrate generalize to mass-market deployment, or is it a high-end product for sovereigns, defense contractors, and regulated finance? Current economics suggest the latter.
  • The SEAP protocol’s one-shot provisioning attestation is a known weakness. Periodic re-attestation is on the roadmap but adds power-budget cost. What’s the right cadence?
  • What’s the cost-per-key-signing in space vs. on earth? If the orbital premium is 10×, that’s acceptable for high-value KMS; if it’s 100×, the market shrinks.
  • Cosmic-radiation entropy is rare and slow — a few bytes per minute typically. Can it support high-throughput VRF without compromising the “true random” property when expanded via ChaCha?