Architecture
How SuperFile and SovereignSky connect, end to end.
Four layers, ten components, one path from a donor's phone to a person's hand — and a proof that travels all the way back. Select any component in the map to see what goes in and what comes out.
Interactive map
Select a component.
The stack reads top to bottom: a name and a proof at the top, a satellite at the bottom, a person in the middle.
SuperFile layer
Identity, notarisation and the proof trail.
SpaceFile layer
The account, the wallet and the value that moves.
Ground layer
Power, connectivity and the point of spend.
Space layer
Settlement, compute and reach from orbit.
Space layer
Orbital ledger nodes
Blockchain nodes hosted on satellites in low Earth orbit. A signature was produced on-orbit aboard AprizeSat-5 on 13 December 2020 and matched the ground checksum byte for byte. Nodes above national jurisdiction have no data centre to flood, no grid to fail and no single country to seize them.
- Takes in
- Signed transactions and anchoring requests from ground stations and passes
- Hands on
- Final settlement, block anchors, proofs of spend
Layer by layer
Ten moving parts, one signed path from a person to the ledger.
From a SuperFile handle on a handset to a notarised block in orbit — every hop below is encrypted, signed and replayable.
The stack ends where the ground network can't follow.
Consensus lives in orbital planes, so no single country, cable or grid outage can take the record away.
Comparison
Sovereign against every chain it will settle beside.
One second to finality, 17,000+ tps, low energy — and the only consensus on this table light enough to run inside an orbital satellite.
| Metric | Sovereign | Solana | Polkadot | Avalanche | Bitcoin | Ethereum |
|---|---|---|---|---|---|---|
| Time to finality | 1s | 12s | 12–60s | 2s | 60 min | 12 min (ETH 2.0) |
| Smart contract support | Yes | Yes | Yes | Yes | No | Yes |
| Market cap (B$) | Launch | $107 Bln | $13 Bln | $18 Bln | $1.9T | $430 Bln |
| Circulating supply | 500M | 500M | 1.2 Bln | 409M | 19M | 120M |
| Capped supply | No limit | No | Yes | 720M | 21M | No limit |
| TPS | 17,000 | 6,500 | 1,000 | 4,500 | 7 | 14 |
| Consensus algorithm | DPoS | PoH & PoS | PoS | PoS (SNOW) | PoW | PoW |
| Energy consumption | Low | Low | Low | Low | High | High |
| Type of blockchain | Antelope protocol | Decentralised | Decentralised | DAG | Linear | Linear |
| Slash amount | No | No | No | No | NA | 32 ETH |
| Number of validators | 500+ | 2,800 | 16 | 1,050 | 12K | 300K |
| Can operate in space | Yes | No | No | No | No | No |
Third-party figures are indicative and drawn from the SovereignSky concept deck; market data moves daily.
Consensus protocols
The difference between consensus families.
Nakamoto-style chains buy decentralisation with latency. Classical protocols buy speed with a closed validator set. Sovereign takes both columns.
| Property | Sovereign | Bitcoin | Classical |
|---|---|---|---|
| High throughput (allows many clients) | Yes | No | Yes |
| Low latency and quick finality | Yes | No | Yes |
| Highly decentralised (many validators) | Yes | Yes | No |
| Robust (suitable for open settings) | Yes | Yes | No |
| Lightweight (works on orbital satellites) | Yes | No | No |
| Quiescent (idle when no decisions run) | Yes | No | No |
| High TPS | Yes | No | No |
| Low energy consumption | Yes | No | No |
| Safety parameterisable beyond 51% adversary | Yes | No | No |
| Highly scalable | Yes | No | No |
High throughput
Whether building a linear chain or a DAG, Sovereign protocols can process thousands of transactions per second (17,000+ tps) while preserving full decentralisation.
Low latency
Sovereign protocols typically achieve finality within just a few seconds.
Scalable and decentralised
Most proof-of-stake systems that aim for large-scale participation achieve scale by delegating validation to subcommittees. Sovereign protocols maintain a fully decentralised model while still scaling effectively.
Permissionless, resilient and robust
Validators can participate in the validation process without needing continuous, full membership knowledge of the network.
Asynchronously safe
Unlike longest-chain protocols, Sovereign protocols do not require network synchronisation to operate safely. That lets them prevent double-spending even during network partitions — the normal condition for a satellite link.
Best of classical and Nakamoto consensus
A lightweight network sampling mechanism delivers low latency, high throughput and scalability while avoiding unnecessary energy consumption.
The Sovereign mechanism
Each node asks a handful of neighbours, and the network agrees in a second.
Every node periodically polls a small, randomly selected subset of its neighbours. If a supermajority backs a different proposal, the node changes its vote. Sampling continues until consensus is reached, which under normal conditions happens almost immediately.
01
A user creates a transaction and sends it to a validating node.
02
The transaction is propagated throughout the network via gossip protocols.
03
Simultaneously the user issues a conflicting transaction, creating a double-spend scenario.
04
To resolve the conflict, each node randomly selects a small subset of neighbours and queries them on which transaction is valid.
05
The querying node adjusts its own response to the supermajority of responses it receives.
06
The process repeats across the network until consensus settles on one of the conflicting transactions.
Protocol architecture
Subnetworks, virtual machines and the chains beside us.
The ledger is not one monolithic chain. Subnets validate chains, virtual machines define what a chain is, and an inter-blockchain communication interface lets value move to and from Solana, Ethereum and Base.
Subnetwork
A dynamic set of validators collaborating to reach consensus.
- Each blockchain is validated by a single subnet.
- A single subnet can validate multiple blockchains simultaneously.
- Validators can participate in an unlimited number of subnets.
- One special subnet exists, known as the Default Subnet.
Virtual machines
Each blockchain operates as an instance of a virtual machine.
The characteristics of a chain are determined by the properties of its VM, including:
- The contents of each block.
- The state transitions that occur when a block is accepted.
- The APIs exposed by the blockchain and their endpoints.
- The data that is persisted to storage.
Investor FAQ
Architecture questions, answered plainly.
Where does the transaction actually settle?
Consensus is reached across orbital ledger nodes, so the authoritative record sits above any single jurisdiction, cable route or power grid. Ground infrastructure is a cache and a delivery mechanism, not the source of truth.
What happens when a satellite is out of view?
The wallet and the Connectivity Box hold a signed envelope and settle on the next pass. Offline peer-to-peer transfers between two handsets clear against the ledger once either device reconnects.
Why blockchain rather than a normal database?
Because the product being sold is proof. Donors, agencies and governments need an auditable trail they do not have to take on trust, and recipients need value that no intermediary can quietly divert.
How is throughput of 17,000+ tps credible in orbit?
Consensus work is small and parallelisable; the bottleneck is link capacity, not compute. Nodes batch and anchor, while high-volume retail activity clears on the ground layer and is anchored in aggregate.