Crypto & coordination
Coordinate the work transparently without replicating every computation onchain.
A focused role for crypto
Crypto can provide shared records between participants who do not rely on one operator. Candidate SpaceXSI uses include contribution records, benchmark commitments, resource access and settlement of accepted work.
The efficiency thesis favors separating execution from agreement about execution. Repeating a heavy workload on every validator would add avoidable work.
Consensus matters
Ethereum’s documentation explains how proof-of-stake replaces energy-intensive mining with stake-based consensus. This illustrates the importance of network architecture, but a saving percentage always depends on the baseline and system being compared.
Evaluate operational energy, security assumptions, throughput, settlement time and data availability together. One fee or transaction metric cannot resolve the entire comparison.
Offchain execution, onchain commitments
A hash can show that a record has not changed. It cannot establish the truth of a physical energy measurement. Meter calibration, trusted collection and independent checks remain necessary.
- Execute a task on suitable compute infrastructure.
- Collect a signed result and measurement record.
- Retain detailed evidence outside the settlement layer under an explicit policy.
- Commit a content reference or hash that makes later changes detectable.
- Accept and settle according to the declared verification process.
Recognize outcomes rather than activity
A proposed contribution mechanism could recognize accepted work inside a quality and resource envelope. It must address duplicate tasks, forged telemetry, selective reporting and collusion.
Potential controls include challengeable records, sampling and independent reruns. These controls also consume resources; their overhead belongs in the system-level efficiency calculation.
Resolve the utility before the token
Network, supply, allocations and contract mechanics should follow these requirements. These docs establish design questions rather than inventing token parameters.
| Design question | Requirement |
|---|---|
| What action needs a token? | A specific coordination function. |
| What is priced? | An accepted-work unit and service envelope. |
| How is evidence trusted? | Attestation, audit and dispute rules. |
| Who changes parameters? | A defined governance scope. |
| Can the same goal be simpler? | Comparison with non-token alternatives. |