Introduction
Capital providers need to decide which data function deserves an off-Earth location and which orbit fits that function. Storage and compute are different services. Archival storage protects information over time and is judged by integrity, recoverability, authenticity and controlled access. Compute transforms information and is judged by throughput, latency, availability, energy efficiency and the usefulness of its output. A comparison that treats both as generic data-centre capacity obscures their economics.
The Moon and LEO also create different operating systems. The average Earth-Moon distance is about 384,400 kilometres. NASA material places one-way lunar signal latency at roughly 1.3 seconds before routing, coding, queuing or application processing. A 550-kilometre LEO path has an ideal vertical propagation time below two milliseconds, although a real service adds geometry, gateway, network and processing delay. [5][30]
The investment decision should begin with the customer's data, required response time, recovery objective, legal control and willingness to pay. Architecture follows those requirements. The framework in this paper converts them into technical evidence, contracts, cash flow and risk-adjusted value.
1. Define the two services
A lunar archive stores selected data on hardware placed on or around the Moon. Its potential purpose is preservation, delayed retrieval, strategic separation, scientific continuity or a protected record. The service requires data ingestion, replication, fixity checking, custody evidence, access control, retrieval and eventual media migration. A payload that carries a one-time copy without continuing integrity and retrieval service is a demonstration or time capsule rather than an operating archive.
A LEO compute platform processes data in Earth orbit. It may receive sensor data from satellites, run inference or transformation, select information for transmission, coordinate other spacecraft or deliver a managed workload service. Its commercial output must be measured through accepted computation, reduced downlink volume, improved response time or another customer result. Hardware in orbit does not by itself create a compute service.
Both architectures depend on Earth systems. Ground stations, identity, encryption, customer interfaces, monitoring, billing and governance remain material. The investable perimeter should identify which assets and contracts are controlled by the project company and which remain shared with sponsors or third parties.
2. Start with the use case
Lunar storage fits data that can tolerate slow write and retrieval, has high preservation value, benefits from extreme geographic separation and remains useful after long periods without frequent interaction. Candidate categories can include selected scientific records, cultural archives, disaster-recovery keys, regulated records where lawful, and strategic continuity copies. Each category requires customer-specific legal and security review.
LEO compute fits data generated in space, workloads that reduce transmission volume, autonomous operations, time-sensitive satellite coordination and processing that benefits from proximity to orbital sensors. Conventional enterprise applications usually depend on terrestrial users, terrestrial data and millisecond-scale interactions with terrestrial networks. Their service economics generally favour Earth infrastructure unless a specific constraint supports an orbital design.
Use-case discipline protects valuation. A broad claim about sovereign storage or orbital cloud demand should be decomposed into named customers, data classes, transaction frequency, acceptable latency, required retention, retrieval method, security policy and contract value.
3. Separate resilience from remoteness
Resilience is the probability that data remains authentic, readable and retrievable within the agreed recovery time after defined failures. Physical distance can reduce exposure to a shared terrestrial disaster. It can also create new common causes, including launch loss, radiation, thermal failure, communications interruption, power shortage, software defects and unavailable replacement logistics.
Library of Congress guidance for digital preservation emphasizes multiple copies, different media, geographic separation, fixity checks and planned media replacement. A lunar copy can add geographic diversity. It should remain one controlled layer in a wider preservation system with verified Earth copies, metadata and repair capability. [23][24][25]
Measure resilience through end-to-end tests. The service should detect corruption, identify the authoritative version, reconstruct damaged data, prove access control and retrieve a usable object. A hardware-survival claim without data-level evidence should receive no preservation premium.
4. Quantify physical latency
Signal propagation creates a lower bound that architecture cannot remove. At the Moon, NASA uses about 1.3 seconds one way. A request and response therefore require at least about 2.6 seconds of light time before network and application overhead. Multiple protocol handshakes add further delay. This remains compatible with asynchronous archival workflows and many machine-to-machine transfers, while constraining interactive applications. [5]
LEO latency varies with altitude, geometry, handover, routing, gateways and terrestrial transit. A local satellite-to-compute path can be short. A service routed through distant ground infrastructure can lose that advantage. Investors should require measured end-to-end latency for the actual workload and route rather than a calculation based only on altitude.
Latency has economic value only when the contract pays for it. The model should link response time to accepted output, avoided bandwidth, improved asset utilization, customer revenue or reduced loss. A faster path without a valued decision has no independent cash flow.
5. Map the data flow
Describe every movement from data origin to accepted customer result. A lunar archive may involve terrestrial ingest, encryption, launch preload, incremental uplink, storage, fixity verification, status reporting, retrieval request, lunar read, downlink, integrity confirmation and customer delivery. Each step has capacity, availability, cost and control assumptions.
A LEO compute flow may involve sensor capture, inter-satellite routing, workload allocation, processing, storage, downlink selection, gateway receipt and terrestrial delivery. Compression or inference can reduce transmitted volume, while software updates and model refresh create reverse traffic.
The data-flow map should identify custody and authority at each interface. It should also show where plaintext exists, where keys reside, which entity can delete or modify data and how a customer proves that an output came from the approved workload and data set.
6. Define the preservation service
An archival contract should specify accepted formats, object identifiers, metadata, encryption, checksum algorithm, replication, fixity frequency, corruption response, retention, legal hold, retrieval, deletion, migration and evidence reporting. PREMIS defines preservation metadata concepts that support long-term management and proof of events. [25]
The customer needs a recovery point objective and recovery time objective. A lunar tier may provide a very old but isolated copy, while terrestrial or LEO layers provide faster recovery. The architecture should state which failure each copy addresses and the order in which recovery occurs.
Long retention creates format and media obsolescence. A promise to store bits for decades is incomplete without migration rights, replacement funding and a verified process for keeping the content usable. Contract life should not exceed the period supported by hardware life, power, communications, funding and migration capability.
7. Define the compute service
A LEO compute contract should define workload, input, output, throughput, processing time, availability, data handling, model version, customer acceptance, price, service credits and termination. Capacity can be measured through accepted jobs, useful processor time or another unit tied to revenue.
The financed configuration should be frozen sufficiently to complete technical testing. Future processors, accelerators or models can remain outside the debt or acquisition perimeter until qualified. Rapid refresh can improve performance and can also reopen radiation, thermal, software and customer-acceptance risk.
NASA's work on high-performance spaceflight computing targets large gains in processing capability and fault tolerance for future missions. Public technology programmes provide technical direction. A commercial valuation still needs evidence for the specific hardware, software and operating environment. [29]
8. Distinguish active and passive value
Lunar archival value can be mostly passive. The customer may pay for custody, integrity evidence and rare retrieval. Low access frequency can reduce communications demand. It also limits observable service events and makes it harder to prove continuing performance.
LEO compute value is active. Revenue depends on repeated workloads, operating availability and customer acceptance. The platform can generate richer telemetry and commercial evidence. It faces greater energy use, software change, customer support and obsolescence.
Investors should use different key performance indicators. A lunar archive should report protected petabytes, verified objects, fixity exceptions, retrieval tests, media life and migration coverage. A LEO compute service should report usable processing capacity, accepted jobs, billable utilization, latency, failure rate, energy per accepted unit and renewal.
9. Underwrite launch and delivery
Delivery to LEO and delivery to the Moon are different logistics products. Mass, volume, vibration, radiation exposure, integration, transfer, landing and commissioning affect cost and failure probability. A quoted launch price does not include every service required to create an operating lunar asset.
NASA's CLPS initiative procures end-to-end commercial payload delivery, including integration, mission operations, launch and landing. NASA reports 17 delivery contracts and more than 60 instruments, while describing lunar landing as difficult and accepting mission risk. NASA's Inspector General has also identified schedule, evolving-requirement and contracting challenges. [10][11]
Model delivered cost by stage. Include payload qualification, integration, launch, transfer, relay, landing, commissioning, insurance, ground systems and reserve capacity. Require executed contractual evidence for the stages supporting the base case.
10. Model power as a service constraint
Storage consumes less power than high-duty compute, yet both require power for control, communications, thermal management and integrity checks. Lunar surface power depends on site and architecture. NASA identifies continuous localized power as essential and describes a roughly fourteen-day lunar night, extreme temperature ranges, solar, regenerative fuel-cell, radioisotope and fission options under development. [7][15][16]
The power model should use service-available energy after generation degradation, storage loss, thermal loads, communications, platform systems and reserve. A nameplate solar value should not be treated as continuous usable power.
LEO nodes experience eclipse cycles and repeated battery use. Lunar systems face long darkness or require favourable polar illumination, stored energy or non-solar supply. The resulting mass and replacement requirements belong in capital cost and asset life.
11. Underwrite the thermal environment
Electronics and storage media operate within qualified temperature limits. NASA describes lunar surface extremes, cold permanently shadowed regions and the additional mass and power required by warm electronics boxes. Recent lunar payload analysis also found differences between predicted and observed thermal behaviour associated with terrain, radiation environment and dust. [8][13][14]
Require thermal-vacuum tests for the financed configuration and site assumptions. Storage durability, write performance, error rate and read recovery should be tested across relevant cycles. LEO compute should be tested at sustained workload because rejected heat can limit duty cycle.
Thermal evidence affects value through usable capacity, service availability, power, degradation and replacement. A platform that must operate at a low duty cycle has less revenue capacity than its installed hardware suggests.
12. Account for radiation and data corruption
Ionizing particles can cause single-event effects, data errors, resets and permanent damage. NASA's RadPC demonstration uses redundant processors and real-time health assessment to recover from radiation-induced faults. The project shows a mitigation direction and does not validate every commercial storage or compute design. [9]
The diligence programme should cover component selection, shielding, error-correcting code, scrubbing, redundancy, fault injection, safe mode, reboot, corrupted-object repair and telemetry. Data integrity should be proved above the device layer through end-to-end checksums and independent copies.
Model latent corruption separately from visible hardware failure. A storage service can remain powered and responsive while returning damaged or unauthentic data. This risk affects warranty, insurance, reserve and customer remedies.
13. Design the communications architecture
NASA's LunaNet specification defines standards and interfaces for cooperative communications and navigation services around the Moon. It covers direct-to-Earth and relay communications and is designed for multiple government and commercial providers. NASA has selected staged relay development, while ESA's Moonlight programme describes a five-satellite communications and navigation architecture. [1][2][3][4]
These programmes can lower infrastructure barriers over time. Availability, coverage, capacity, price and commercial terms still require contracts. A project should identify primary and alternate links, ground stations, service windows, weather exposure, spectrum rights, protocol, security and restoration.
Delay and disruption tolerant networking stores data until a route becomes available. NASA is deploying DTN as part of its broader network architecture. DTN improves operation through interrupted links; it does not remove light-time latency or create missing bandwidth. [6]
14. Protect spectrum and interoperability
Spectrum coordination affects both lunar and Earth-orbit networks. ITU procedures require non-geostationary systems to identify whether the reference body is Earth or another object such as the Moon. Lunar missions also face frequency coordination and protection requirements, including the shielded zone of the Moon used for radio astronomy. [17][18][19]
The project should record filings, assignments, operating conditions, milestones, interference obligations and change-of-control effects. Customer value can decline if the service lacks reliable communications or if emissions constrain a scientifically sensitive location.
Interoperability reduces dependence on one relay or terminal when multiple compatible providers exist. A claim of standards compliance should be supported by conformance testing, interface documentation and an operational transition plan.
15. Define sovereignty carefully
The Outer Space Treaty states that outer space and celestial bodies are not subject to national appropriation. It also assigns responsibility for national space activities and provides that a state of registry retains jurisdiction and control over its registered object. A lunar location therefore does not create territorial sovereignty. [20]
For customers, data sovereignty can refer to applicable law, controller authority, custody, access, encryption keys, operator nationality, government-access exposure, transfer restrictions and auditability. These attributes depend on contracts and legal analysis across the project company, launch state, registry, operators, ground stations and customers.
The paper uses sovereignty as a commercial requirement for demonstrable control and lawful governance. Any investment case should replace broad strategic language with a jurisdiction map, legal opinions, customer policies and contractual remedies.
16. Build data-centric security
Security should follow the data across Earth, launch, orbit, lunar systems and ground links. NIST zero-trust guidance treats location as insufficient for trust and emphasizes verified access to distributed resources. NIST data-classification guidance supports rules based on the information itself. [21][22]
Classify objects before ingest. Define encryption in transit and at rest, key generation, custody, rotation, recovery, privileged access, device identity, workload attestation, logging, incident response and secure deletion. A lunar copy encrypted with unavailable keys has no recovery value.
Separate cyber resilience from physical separation. A software defect, stolen credential or malicious update can propagate across distant copies. Independent control planes, staged updates, immutable logs and tested recovery can reduce correlated failure.
17. Establish customer acceptance
Revenue becomes financeable when the customer accepts an evidenced service. For storage, acceptance may require verified ingest, independent checksum, replication status, retrieval test and custody certificate. For compute, it may require output accuracy, processing time, availability, data handling and invoice reconciliation.
Contracts should state minimum payment, usage price, indexation, service credits, liability, termination, data return and migration support. Strategic statements, pilot memoranda and reserved capacity without enforceable payment should not enter contracted revenue at full value.
Customer concentration deserves explicit adjustment. Early space-data platforms may depend on one government agency, sponsor affiliate or anchor customer. Procurement, appropriations, termination and policy conditions should be modeled from the executed contract.
18. Construct the revenue model
Lunar storage pricing can include setup, ingest, protected capacity, integrity reporting, retrieval, legal hold and migration. A one-time payload payment should be separated from recurring preservation revenue. Long contract duration can support value only when price, cost escalation, performance and termination remain workable.
LEO compute pricing can include reserved capacity, accepted job, processor time, data reduced, result delivered or availability. Usage upside should receive a lower evidence weight than enforceable minimums until utilization and renewal are observed.
Revenue forecasts should reconcile physical units to invoices. Protected objects, billable capacity, accepted processing and collections should be visible in a common evidence register. Marketing pipeline and technical capacity should remain outside the contracted base case.
19. Model operating and lifecycle cost
Operating cost includes network, ground stations, software, security, monitoring, customer support, insurance, spectrum, regulatory compliance and programme management. Hardware may require remote recovery, replenishment or full replacement because field repair is limited.
Lunar logistics can create long restoration periods. The cost model should include replacement payload, integration, delivery window, commissioning and data re-replication. LEO replacement may be faster and can require more frequent cohorts because of orbit and technology refresh.
Fund lifecycle reserves before distributions. The reserve schedule should follow qualified design life, observed failure, manufacturing lead time, launch access and media migration. An asset with nominal life beyond funded replacement has unsupported terminal value.
20. Compare replacement cycles
Media life, processor obsolescence and platform life are separate. Archival media can remain physically readable while format, controller or encryption systems become obsolete. Compute hardware can remain functional while losing commercial competitiveness.
The lunar case should define planned read verification and migration windows. A long-life claim requires accelerated testing, component evidence and an accessible replacement path. LEO compute should define cohort refresh, backward compatibility and customer transition.
Debt and contract tenor should not exceed the period with resilient service evidence. Terminal value should reflect the replacement capital needed to continue service rather than assuming perpetual cash from the initial hardware.
21. Treat insurance as partial risk transfer
Potential cover can include launch, transit, in-orbit or surface property, third-party liability, cyber and business interruption. Availability and terms depend on the actual mission, technical evidence, aggregation, exclusions and market conditions.
Insurance cannot replace a viable architecture. Data authenticity, customer demand, format obsolescence, software defects or slow replacement may remain excluded or difficult to quantify. Model deductibles, waiting periods, claims delay and uninsured loss.
Assign proceeds and define reinstatement. A claim payment can repay debt or rebuild capacity, and the documents should state which outcome has priority. Customer continuity may require liquidity before an insurer settles.
22. Allocate completion risk
Completion should convert development exposure into an accepted operating service. A lunar archive may require successful delivery, power, communications, storage write, fixity verification, retrieval, security and customer acceptance. LEO compute may require a minimum operating cohort, sustained workload, latency, availability and accepted output.
Sponsor support should cover cost overrun, failed test, delivery delay, replacement and debt service before completion. Release should follow independent certification and funded reserves.
Partial completion deserves a defined treatment. One surviving node or one stored copy may have scientific value and no commercial value. The financing and purchase agreement should tie completion to the service sold to customers.
23. Build the financing perimeter
Early technology, first-of-kind delivery and uncontracted demand usually require equity, grants, customer prepayments or strategic capital. Operating cohorts with accepted revenue may support equipment finance, structured debt or project debt subject to risk allocation.
Keep speculative expansion outside the financed perimeter. A special-purpose vehicle should hold the assets, contracts, accounts, intellectual-property rights and operating access needed to deliver the defined service. Shared sponsor dependencies need arm's-length contracts and transition support.
Cash available for debt service should be calculated after operating cost, tax, working capital and lifecycle reserve. Debt sizing should use downside accepted revenue and should not rely on an unproved exit multiple.
24. Value evidence rather than novelty
Value should be built from contracted units, accepted performance, cost and risk. Apply discounted cash flow to the evidenced service perimeter. Use market references cautiously because terrestrial storage, terrestrial cloud, satellite operators and pre-revenue space ventures carry different economics.
Adjust for remaining capital, schedule, technical completion, customer concentration, lifecycle funding, regulatory rights and liquidity. A novelty premium without cash evidence can conceal cost and risk. Strategic option value should be stated separately with probability and expiry.
IFRS 13 frames fair value around market-participant assumptions. IAS 36 requires supportable cash-flow and impairment analysis, while IAS 38 addresses recognition of intangible assets. These standards do not prescribe transaction value for a lunar platform, but they reinforce disciplined evidence, useful life and cash-generating-unit analysis. [26][27][28]
25. Apply the resilience premium
A resilience premium equals the present value of loss avoided or service preserved for the customer, bounded by the price of credible alternatives. It should be estimated from the customer's data value, threat model, recovery architecture, insurance and willingness to pay.
Extreme distance can address a narrow class of correlated terrestrial events. Multi-region Earth storage, offline media, independent organizations and LEO copies may provide cheaper resilience for many customers. The comparison should include these alternatives.
Allocate no premium when the lunar layer cannot be tested, retrieved, legally used or kept current. Evidence of a paid contract and repeated recovery test provides a stronger basis than a strategic label.
26. Apply the latency adjustment
Latency reduces value for interactive workloads and can have little effect on cold archives. Classify each service by response requirement. Real-time control, trading, voice and interactive software have strict limits. Batch science processing, delayed analytics and archive retrieval can tolerate more delay.
For LEO compute, measure the full path from data origin to accepted output. The value case may arise from local processing before downlink rather than faster interaction with an Earth user.
The valuation model should reduce price, utilization or addressable demand when measured latency exceeds customer requirements. It should avoid a single global latency discount applied to unrelated services.
27. Apply the sovereignty adjustment
Customers may pay for verified key control, restricted operator access, named jurisdictions, sovereign procurement, independent continuity or physical separation. Each requirement should appear in the contract and operating design.
Sovereignty can also add cost. National licensing, export control, procurement, security accreditation, data localization and audit requirements may constrain suppliers and customers. Registry and authorization obligations should be included.
Value the net contracted benefit after compliance cost and concentration. A platform dependent on one policy programme or one sovereign customer can have strategic relevance and material renewal risk at the same time.
28. Compare technical maturity
NASA, ESA and other agencies are developing lunar communications, power, navigation, computing and delivery systems. Demonstrations provide evidence for components and operations. They do not prove a complete commercial archive with long-term paid service. [1][3][4][7][9][10]
Use an evidence ladder. Concept, laboratory test, environmental qualification, flight demonstration, customer pilot, accepted recurring service and repeatable replacement represent different risk states. Each valuation input should identify its current state.
Avoid averaging maturity across the platform. A flight-proven storage device can depend on an unproved power system, relay contract, security process or customer product. The weakest critical dependency can control commercial completion.
29. Construct the hypothetical lunar case
The illustrative lunar archive has ten petabytes of raw capacity and three petabytes under paid contract after completion. Total development, qualification, integration, delivery, commissioning and ground cost is USD 70 million. Annual accepted revenue is USD 12 million, and annual operating and lifecycle cost is USD 6 million.
The model assumes preload on Earth for the initial archive and limited incremental synchronization after deployment. It does not assume that multi-petabyte archives can be economically uploaded through an unverified lunar communications service. Retrieval is rare and tested periodically.
Illustrative operating cash flow is USD 6 million before tax and financing. Probability-weighted enterprise value is USD 14 million after remaining capital and explicit technical, customer and lifecycle adjustments. This value is wholly hypothetical and does not describe market pricing.
30. Construct the hypothetical LEO case
The illustrative LEO cluster contains twenty-four processing nodes. Total development, qualification, launch, commissioning and ground cost is USD 110 million. Annual accepted revenue is USD 42 million, and annual operating and lifecycle cost is USD 24 million.
Revenue comes from reserved and accepted processing for orbital data. The base case excludes generic terrestrial cloud demand. It assumes measured workload performance, customer acceptance and funded replacement.
Illustrative operating cash flow is USD 18 million before tax and financing. Probability-weighted enterprise value is USD 75 million after remaining capital and specific technical, customer and lifecycle adjustments. Every input is hypothetical.
31. Use a common decision scorecard
Score both architectures against customer need, latency fit, resilience, technical evidence, contracts, operating dependencies, replacement, regulation and capital. A high score in one dimension cannot cure a fatal failure in another.
Use red-line conditions before weighted scoring. Unlawful data handling, unavailable communications, unqualified thermal design, unfunded replacement or absent customer acceptance should stop the investment case.
The final recommendation should identify the financed perimeter, evidence required before capital release and conditions that would change the decision.
32. Set capital release gates
Gate one covers legal use case, data classification, customer need and architecture. Gate two covers environmental qualification, communications, power, security and delivery contracts. Gate three covers flight or surface demonstration, end-to-end data integrity and recovery. Gate four covers accepted customer service, recurring payment and lifecycle funding.
Capital at each stage should match recoverable evidence. Early capital funds experiments and qualification. Later capital funds repeatable operating assets. Debt should follow completed, accepted service and resilient cash flow.
Each gate should have named evidence, independent reviewers, exceptions and an approved budget. Passing one technical test should not release funds reserved for commercial acceptance.
33. Define the investment decision
Choose lunar storage when the contracted need is long-duration, low-access preservation with material value from extreme geographic separation, and when the project proves integrity, retrieval, lawful control, power, communications and migration funding.
Choose LEO compute when the workload originates in orbit or gains measurable value from local processing, reduced downlink or operational response, and when the platform proves accepted throughput, latency, availability, customer payment and replacement economics.
Choose a terrestrial or hybrid design when it meets the customer's continuity and processing needs at lower risk-adjusted cost. The board should approve the smallest architecture that delivers the contracted outcome and can be supported through its full lifecycle.
Conclusion
Lunar storage and LEO compute serve different information problems. The Moon can add extreme separation for selected archives, while imposing light-time delay, delivery, power, thermal and repair constraints. LEO can support orbital processing and faster data paths, while facing utilization, refresh and constellation-operating risk.
Investors should value service evidence rather than location. Contracts, acceptance, integrity, retrieval, throughput, lifecycle reserves and lawful control convert a technical concept into cash flow. Public lunar communications, delivery and computing programmes improve the enabling environment. Commercial value remains transaction-specific.
The practical sequence is to define the customer problem, prove the end-to-end service, contract the outcome, fund replacement and then size capital to resilient cash flow. This sequence applies whether the asset is on Earth, in LEO or on the Moon.
The practical comparison should remain evidence-led and service-specific. Decision makers should reconcile physical architecture, customer workflow, contractual acceptance, lifecycle funding and recoverability in one model. Each diligence conclusion should identify its source, effective date, responsible reviewer and consequence for price, structure or capital release. That discipline makes technical uncertainty visible and creates a repeatable basis for investment committee review, financing negotiation and post-closing performance control.
Appendix A. Customer use case checklist
Record the data owner, controller, source, volume, change rate, retention, access frequency, response requirement, recovery point, recovery time, legal restrictions, encryption authority, deletion requirement and loss consequence.
Identify terrestrial, offline, multi-region, LEO and lunar alternatives. Compare their verified service, cost, common-cause exposure and migration path.
Appendix B. Technical evidence checklist
Review component maturity, environmental qualification, radiation, thermal, power, storage integrity, compute performance, communications, security, software, fault recovery, telemetry and safe mode.
Require evidence for the financed configuration and representative workload. Record assumptions, test limits, exceptions and corrective action.
Appendix C. Contract checklist
Review delivery, launch, relay, ground, power, manufacturing, operations, customer, insurance and intellectual-property agreements. Confirm price, schedule, performance, acceptance, remedy, assignment, change control, termination and transition support.
Map every financial-model input to a contract clause, test or identified assumption.
Appendix D. Valuation checklist
Reconcile protected or processed units to accepted revenue and collections. Model operating cost, lifecycle reserve, remaining capital, tax, working capital and financing.
Apply explicit probability, delay, concentration, technical, regulatory and replacement adjustments. Separate strategic option value from the operating enterprise value.
Appendix E. Sovereignty and security checklist
Map project company, registry, authorization, launch state, operators, ground stations, customers, applicable law, data transfers and government-access exposure. Obtain legal advice for the actual structure.
Review classification, encryption, keys, access, attestation, logging, updates, incident response, deletion, recovery and independent audit.
Appendix F. Decision figures and tables
Wholly hypothetical index; LEO equals 1.0. Actual mission pricing requires executed contracts.
| Requirement | Lunar storage | LEO compute | Terrestrial or hybrid comparator |
|---|---|---|---|
| Rare archival retrieval | potential fit | limited advantage | strong baseline |
| Interactive processing | poor fit | workload dependent | strong baseline |
| Orbital sensor processing | indirect | potential fit | bandwidth dependent |
| Extreme geographic separation | potential differentiator | moderate differentiator | multi-region alternative |
| Frequent media migration | difficult | possible through cohorts | operationally easier |
Proposed screening framework.
Wholly hypothetical share of nameplate power after platform and reserve loads.
| State | Minimum evidence | Capital treatment |
|---|---|---|
| Concept | architecture and customer problem | sponsor or research capital |
| Qualified | representative environmental and security tests | milestone equity |
| Demonstrated | flight or lunar test and end-to-end data proof | strategic or structured capital |
| Accepted | paid customer acceptance | potential operating finance |
| Repeatable | replacement and renewal history | broader debt and acquisition perimeter |
Proposed transaction treatment.
Idealized one-way propagation; real services add routing and processing.
| Dimension | Lunar archive | LEO compute |
|---|---|---|
| Primary output | verified preserved object | accepted processed result |
| Main constraint | delivery and retrieval | utilization and service availability |
| Common cause | launch, software, key or relay | launch cohort, design, gateway or software |
| Lifecycle action | media and platform migration | cohort refresh and replacement |
| Core acceptance | write, fixity and retrieval | throughput, latency and output quality |
Proposed diligence map.
Wholly hypothetical units entering service or migration events.
| Metric | Lunar archive | LEO compute |
|---|---|---|
| Total development and delivery cost | 70 | 110 |
| Contracted capacity | 3 PB | 24 processing nodes |
| Annual accepted revenue | 12 | 42 |
| Annual operating and lifecycle cost | 6 | 24 |
| Annual operating cash before tax and financing | 6 | 18 |
| Probability weighted enterprise value | 14 | 75 |
Wholly hypothetical; USD million except capacity.
Wholly hypothetical; USD million.
| Claim | Required evidence | Valuation treatment |
|---|---|---|
| Physical separation | architecture and recovery test | loss avoided where demonstrated |
| Jurisdictional control | registry, licences and legal opinions | customer specific |
| Key control | custody, rotation and recovery test | contract premium where paid |
| Restricted access | identity, logs and independent audit | service acceptance condition |
| Continuity | alternate control and retrieval route | probability and recovery adjustment |
Proposed framework; legal advice is required for an actual structure.
Proposed evidence and capital release framework.
| Workstream | Principal question | Decision evidence |
|---|---|---|
| Customer | who pays for which outcome | executed contract and acceptance |
| Technical | can the configuration sustain service | representative tests and telemetry |
| Data | can integrity and recovery be proved | fixity, retrieval and audit results |
| Legal | who controls the object and data | licences, registry and opinions |
| Financial | can cash fund service and replacement | controlled model and reserves |
Proposed transaction scope.
| Criterion | Lunar storage | LEO compute | Red line |
|---|---|---|---|
| Use case | low access strategic archive | orbital processing | no paying customer problem |
| Latency | asynchronous only | route dependent | misses contracted response |
| Resilience | one layer in diverse archive | distributed service capacity | correlated unmitigated failure |
| Maturity | early commercial evidence | early operating evidence | critical subsystem unqualified |
| Lifecycle | funded migration | funded cohort replacement | unsupported terminal value |
Proposed board framework.
Sources
- National Aeronautics and Space Administration, LunaNet Interoperability Specification. Read the primary source
- National Aeronautics and Space Administration, LunaNet Interoperability Specification Version 5. Read the primary source
- National Aeronautics and Space Administration, LunaNet and Lunar Communications Relay and Navigation Services. Read the primary source
- European Space Agency, Moonlight Connectivity and Navigation Programme. Read the primary source
- National Aeronautics and Space Administration, Communication Delays in Deep Space. Read the primary source
- National Aeronautics and Space Administration, Delay and Disruption Tolerant Networking. Read the primary source
- National Aeronautics and Space Administration, Lunar Surface Technology. Read the primary source
- National Aeronautics and Space Administration, Cold Tolerant Electronics and Packaging for Lunar Surface Exploration. Read the primary source
- National Aeronautics and Space Administration, Radiation Tolerant Computing Demonstration. Read the primary source
- National Aeronautics and Space Administration, Commercial Lunar Payload Services. Read the primary source
- NASA Office of Inspector General, Commercial Lunar Payload Services Initiative, IG-24-013. Read the primary source
- National Aeronautics and Space Administration, Commercial Delivery to the Far Side of the Moon and Lunar Pathfinder. Read the primary source
- NASA Technical Reports Server, CLPS Electrodynamic Dust Shield Payload Thermal Design and Analysis. Read the primary source
- NASA Technical Reports Server, Lunar Thermal Assessment. Read the primary source
- National Aeronautics and Space Administration, Fission Surface Power for Lunar Exploration. Read the primary source
- National Aeronautics and Space Administration, Lunar Power Technologies. Read the primary source
- International Telecommunication Union, Non Geostationary Satellite Networks Regulatory Procedures. Read the primary source
- International Telecommunication Union, Preferred Frequencies and Guidelines for Space Missions Operating in the Lunar Region. Read the primary source
- International Telecommunication Union, Protection of the Shielded Zone of the Moon. Read the primary source
- United Nations Office for Outer Space Affairs, Treaty on Principles Governing the Activities of States in the Exploration and Use of Outer Space including the Moon and Other Celestial Bodies. Read the primary source
- National Institute of Standards and Technology, SP 800-207 Zero Trust Architecture. Read the primary source
- National Institute of Standards and Technology, Data Classification Practices. Read the primary source
- Library of Congress, Digital Preservation Practices. Read the primary source
- Library of Congress, Digital Collections Management Glossary. Read the primary source
- Library of Congress, PREMIS Data Dictionary for Preservation Metadata Version 3.0. Read the primary source
- IFRS Foundation, IFRS 13 Fair Value Measurement. Read the primary source
- IFRS Foundation, IAS 36 Impairment of Assets. Read the primary source
- IFRS Foundation, IAS 38 Intangible Assets. Read the primary source
- National Aeronautics and Space Administration, High Performance Spaceflight Computing. Read the primary source
- National Aeronautics and Space Administration, Average Earth Moon Distance. Read the primary source
