Verification and replay
Replayability lets a third party test a runtime's published state without trusting its operator.
What is recorded on-chain at launch
- 01Token address and fixed supply.
- 02sigma and the hash of s_0.
- 03The provenance document hash and each data-file SHA-256.
- 04The code repository URL and commit hash.
- 05c and the complete fee split.
Replaying an organism
- 01Fetch s_0 and sigma from the launch transaction, then verify that serialised s_0 matches its recorded hash.
- 02Fetch f from the stated code repository at the recorded commit, including the pinned arithmetic and runtime dependencies.
- 03Apply f from s_0 through the latest checkpoint t using the recorded trigger events in order.
- 04Serialise the recomputed s_t, calculate SHA-256(s_t), and compare it with H_t recorded on-chain.
When hashes mismatch, publish the input state, commit, execution environment, recomputed state, and both hashes. The launch record is permanent; the falsification is public rather than handled as a takedown.
What Spawn checks and what it cannot
Spawn checks that citations are well-formed, SHA-256 values are valid, and the specification is complete.
Spawn cannot establish that a paper says what its creator claims, that a file is the dataset it is labelled as, or that the model is interesting. The posture is the same as the provenance document: make every claim specific and durable enough to challenge.
Reproducibility pitfalls
Floating-point addition is not associative. SIMD reduction order, GPU versus CPU execution, and library-version drift can therefore produce different low-order bits even when the visible model appears equivalent.
Prefer integer or fixed-point stepping for bit-exact replay. When floating point is necessary, use a pinned WASM build and publish the arithmetic, ordering, compiler, and library versions.