Verification and replay

Source: https://spawn.farm/docs/verification

Replayability lets a third party test a runtime's published state without trusting its operator.

What is recorded on-chain at launch

1. Token address and fixed supply.
2. sigma and the hash of s_0.
3. The provenance document hash and each data-file SHA-256.
4. The code repository URL and commit hash.
5. c and the complete fee split.

Replaying an organism

1. Fetch s_0 and sigma from the launch transaction, then verify that serialised s_0 matches its recorded hash.
2. Fetch f from the stated code repository at the recorded commit, including the pinned arithmetic and runtime dependencies.
3. Apply f from s_0 through the latest checkpoint t using the recorded trigger events in order.
4. Serialise the recomputed s_t, calculate SHA-256(s_t), and compare it with H_t recorded on-chain.

Public check:

s_t = f^t(s_0, sigma)
H_t = SHA-256(serialise(s_t))

recomputed H_t = recorded H_t     → match
recomputed H_t ≠ recorded H_t     → public falsification

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.

Reproducibility pitfalls

Floating-point addition is not associative. SIMD reduction order, GPU versus CPU execution, and library-version drift can 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.