SPAWN

Spawn is a launchpad on Robinhood Chain where anyone can deploy a small, formally specified dynamical system: a neural circuit built on published connectome data, a reaction-diffusion field, an oscillator network, a cellular automaton, or an agent-based model. It launches with its own token in a single transaction, and that token's trading activity funds the compute required to keep the model running. Two guarantees are designed to be enforced at the contract level, not promised in prose (Section 17 states which contracts are live). A third mechanism, independent of any individual organism, lets any third party recompute a model's published state from its seed and step function and check it against a hash recorded on-chain, turning the claim “this is really running” into something falsifiable rather than something to be believed.

Spawn is a launchpad where anyone can be the scientist: write a small model that actually runs, launch it with its own token in one transaction, and let the pool that people trade and farm pay for it to keep stepping.

DeSci. The specification defines the state and step function; provenance separates sourced material from engineering choices; checkpoints let anyone replay the execution and challenge a mismatch.

DeFi. The token, trading pool, farming positions, and runtime escrow form the funding loop. Swaps produce both LP fees and the escrow share that pays for ticks.

• 01A creator writes a small model — a neural circuit from a published connectome, a reaction–diffusion field, an oscillator network — plus a concrete description of how it executes.
• 02They complete a provenance document: what the model is not, every dataset with its origin and license, a real citation, and an explicit split between sourced data and their own engineering decisions.
• 03They submit one transaction. It deploys the token with a fixed supply, records the provenance hashes on-chain, creates the trading pool, and locks the liquidity. If any step reverts, the whole launch reverts.
• 04Trading fees are split by the locker: a majority share into a runtime escrow, a bounded share to the creator, a fixed share to the protocol.
• 05The escrow pays for ticks. While it has balance, the organism runs and its page shows current state. When it empties, the organism pauses visibly and says so.

What “running” means here. There is no single runtime. An organism may be a client-rendered browser process, an on-chain state machine advanced by public calls, or an off-chain worker posting checkpoints. What is required is that the creator states which one it is, and what advances a step, in terms a reader can check. Descriptions like “an AI runs it” fail validation in the launch flow.

Fixed supply, no mint. The token contract has no mint function. The supply entered at step 1 is the supply that will ever exist. There is no team unlock schedule to disclose because there is no minting path to schedule.

Two enforced guarantees. Liquidity cannot be pulled, because the locker exposes no withdraw path to anyone. Provenance cannot be skipped, because the launch form will not submit without it. These are the two things Spawn is actually for; everything else is presentation.

A Spawn organism is a bounded dynamical system whose state and execution can be inspected and replayed by a third party.

S is the state space: the complete set of values that may exist at one tick.

f is the step function: the complete rule that maps the current state and seed to the next state.

sigma is the launch seed: the fixed input that makes seeded choices replayable.

tau is the tick trigger: the observable event that authorises and advances one step.

State space S. S must be finite and serialisable. A checkpoint must contain enough information to reconstruct one complete state without hidden memory.

• 01Gray–Scott Field: 256 × 256 × 2 float32 values = 512 KiB.
• 02Kuramoto Lattice: 512 float64 phase values = 4 KiB.
• 03EB Ring Attractor: N neurons × (v, s), containing one membrane-potential value and one spike-state value per neuron.

Step function f. Given (s, sigma), f must be pure and deterministic: the same inputs produce the same next state, with no undeclared clock, network response, or local randomness. Floating-point reproducibility requires the creator to state the arithmetic — float32, float64, fixed-point, or integer — the summation order, and the platform when it can affect results. Integer or fixed-point models are preferred because they replay bit-exactly across machines.

Seed sigma. sigma is recorded on-chain at launch. For a seeded-stochastic model, the runtime description must name the pseudorandom number generator, such as xoshiro256** or PCG32, and define how its state advances.

Tick trigger tau. Accepted triggers are:

• 01A new block observed.
• 02An explicit public call.
• 03A wall-clock interval with block-hash anchoring.
• 04User input logged as an event.

Every trigger must be observable by a third party. An operator-only timer or private event stream is not sufficient.

The launch specification declares a minimum checkpoint cadence and where each checkpoint hash is published. A runtime may publish more often, but it cannot silently publish less often than declared. A mismatch means the recorded execution has been publicly falsified. It does not remove the organism or take down its record; the launch, specification, and mismatch remain inspectable.

A class describes the mechanics a specification must expose. It does not grant biological meaning or scientific validity.

A second agent-based family in the running set is the undulatory swimmer: a travelling body wave h(s,t) = A(s) sin(2πs/λ − ωt) with a tail-biased amplitude envelope A(s) = a0 exp(k(s/L − 1)), where k selects the gait between anguilliform and carangiform. Forward speed is not chosen independently: it follows from the beat through the Strouhal number, v = f · 2A(L) / St with St held in the cruising band 0.25–0.35 reported across swimming animals (Triantafyllou et al. 1991/1993), one wave on the body at λ ≈ 0.85L (Videler & Wardle 1991), and escapes executed as C-starts (Domenici & Blake 1997). It is a distinct gait from the nematode crawler, whose undulation is track-following rather than body-frame.

Other classes are accepted when S, f, sigma, and tau are concrete and the provenance gate passes.

Launching on Spawn requires a structured provenance document. It is not a disclaimer field and it is not optional; the launch transaction cannot be submitted until it is complete.

Good documentation answers one question: is a claim specific enough to check. It answers nothing about whether the money behind it stays where it was put. Spawn treats those as two separate requirements. A launch isn't complete until a provenance document exists, and it isn't complete until liquidity is locked in a contract with no withdraw function for anyone. Neither one is a promise in a blog post.

What this is NOT. At least two specific statements, written by the creator, about what their organism does not claim to be — not a living animal, not a complete biological emulation, not a trained model. Generic disclaimers are rejected by the form.

Data sources. Each dataset named, with its origin, its license as the source states it, and a SHA-256 of any bundled data file. When a hash is given it is written on-chain at launch, so the file behind the claim cannot be silently swapped afterwards.

Citations. A paper, DOI, or dataset repository reference. Each entry must contain a DOI or a link; prose about “published research” does not pass.

Sourced data vs. design choices. A structured table separating what comes from the data from what the creator decided. This is the field that stops overstatement: “the adjacency is from the published connectome; the activation is a discrete integer threshold, not conductance-based electrophysiology.”

License of the organism's own code and model.

Where it lives. The document renders in full on the organism's page — not collapsed, not behind a link, not summarised. It is linked from the token page, and the one-line summary field is what appears on cards and in the explore list. There is no separate marketing description field, because that is where overstatement usually goes.

Atomic with the launch. The factory deploys the token, creates the pool, deposits the initial liquidity, and calls lock() in a single transaction. The locker's lock function accepts one call per token, and only from the factory. A launch that fails to lock reverts entirely — there is no window in which a pool exists unlocked.

Why there is no unlock. The usual pattern is a timelock: liquidity is locked until a date, then the creator can take it. That is a delay, not a guarantee. The locker here implements no withdraw, unlock, release, emergency, migrate, or sweep function in any form. Because the code does not exist, no key, multisig, governance vote, or future decision can call it.

The contract also has no owner and no admin role, and it is not deployed behind a proxy — the bytecode at the address is final. There is no selfdestruct.

Fees still flow. The locked position keeps earning trading fees, and collectFees routes them to fixed destinations set at deploy: the runtime escrow, the creator's claim balance, and the protocol share. Collecting fees never touches the principal, and the destinations cannot be edited after launch.

The same organism-pool swaps that produce LP fees also refill the escrow that pays for model execution.

The loop. Trading produces fees. The locker splits them: a runtime share enters escrow E, a bounded creator share is claimable, and a fixed 15% protocol share is routed separately. Escrow then pays c for each tick, and the organism steps.

Metering c. The cost per tick is declared at launch in units of the pool's quote asset per tick. It must be concrete and public so anyone can calculate runway, reproduce deductions, and distinguish execution cost from an operator's claim. c is fixed after launch. A runtime whose cost cannot be stated in those units does not have a complete funding rule.

Farming the pool. Farming here means holders provide liquidity to the organism's pool and receive the LP share of swap fees on their position through standard AMM mechanics. Deeper liquidity lowers slippage, which tends to raise V, which raises dE/dt. This is the incentive alignment: the yield farmers earn and the escrow that keeps the model running come from the same swaps. Farming is not a promised yield, not a guarantee that V stays above V*, and not a claim about token price.

When escrow reaches zero, the trace freezes at s_t and H_t stays public. Once E is greater than c again, execution resumes from the last checkpoint rather than inventing the missed states. Direct top-ups are allowed, but nobody is obliged to provide one.

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.

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.

A checkpoint hash is only useful if two honest parties serialise the same state to the same bytes. The specification must therefore declare serialise(s) exactly: field order, field widths, endianness, and encoding of every value in S. Floating-point values may not appear in serialised state unless the arithmetic is fully declared; integer and fixed-point (Q32.32 recommended) are preferred because they replay bit-exactly on any machine.

Randomness is state, not a hidden input. A seeded-stochastic organism names its PRNG (xoshiro256**, PCG32, or another published generator), seeds it from sigma, and includes the generator's state in S. A replayer who has s_t has the generator's state too.

Rather than independent per-tick hashes, checkpoints form a chain:

Reference builds. WebAssembly specifies IEEE-754 semantics without fast-math or fused-multiply-add contraction, so a pinned .wasm binary, identified by its SHA-256 in the launch record, is the preferred form for f when floating point is unavoidable. The reference build is what replayers run; the browser rendering is a view of its output, not the authority.

A tick is an observable event, not an operator's decision. The trigger tau is realised on-chain as a call:

Per-tick entropy for seeded-stochastic organisms is derived from the chain, not the operator:

This yields two distinct idle states, and the organism page names which one applies:

• 01stalled — escrow is funded, no keeper has submitted a tick
• 02paused — escrow is below the tick cost

Only the second is a funding failure.

In discrete form, with F_n the fees collected at step n and phi the runtime share:

Which side of the pool pays. Swap fees accrue in both the organism token and the quote asset. The runtime share is taken from the quote side only; organism-token fees are routed to the creator and protocol shares. The escrow therefore never sells the organism's own token into its own pool, and funding the model creates no sell pressure on it.

Hysteresis. Pausing exactly at E < c + c_k and resuming the moment E >= c + c_k would flap on every small swap. The organism pauses when E < c + c_k and resumes only when E >= h * (c + c_k), with h declared at launch (default 24). A resume therefore implies at least h ticks of funded runway.

Direct top-ups are deposits to E by any address. They are not repaid and confer nothing.

Checkpoints are posted optimistically: the runtime submits H_t and it is presumed correct. Anyone who replays and obtains H'_t != H_t may open a challenge by posting a bond.

Bisection. The two parties hold an agreed H_a (the last checkpoint both accept, initially H_0) and a disputed H_b. Each commits to a hash at the midpoint tick m; if they agree, a becomes m, else b becomes m. After log2(b - a) rounds they agree on H_(k-1) and disagree on H_k. The dispute is now one tick wide.

Resolution. Both parties publish serialise(s_(k-1)) — which must hash into the agreed H_(k-1) or the party is slashed immediately — and their serialise(s_k). Anyone holding the reference build recomputes the single step f(s_(k-1), sigma, tau_k). Where f is small enough to execute on-chain within a gas bound declared at launch, the contract adjudicates. Where it is not, the record is social: the launch page permanently shows the disputed tick, both candidate states, and both hashes, and tags the organism

Nothing is deleted and the organism may keep running; the tag is permanent.

Bounty. A falsification bounty, paid from the protocol share, goes to the first challenger whose challenge resolves against the runtime. The challenger's bond is forfeited if their own s_k does not hash to their claim. This is the mechanism by which “verifiable” becomes a paid activity rather than a property nobody exercises.

What an organism page displays is a derived quantity, not the state itself:

Observables are the vocabulary in which the source literature reports results. Displaying them, rather than a rendered animation alone, is what lets a reader compare an organism to the paper it cites.

An organism may declare an input port that reads another organism's observable:

Consequences stated plainly: replaying A requires B's checkpoint history, so a composed organism is only as verifiable as its least verifiable input. If B pauses, o_B freezes and A continues on stale input; A's page states this. A cannot fund B; escrows are independent.

Properties every conforming deployment must satisfy. Each is checkable by reading contract code or public records.

I1, I4, I5 hold for the burn registry today (I3 is enforced by a database uniqueness constraint, not a contract). I2, I6–I8 describe the factory, locker, and escrow contracts and apply when those deploy.

$SPAWN is the protocol token. Contract: 0x41080c9d7908ce567efe239042c49d8159a2a3bb on Robinhood Chain. Its utility is narrow and does not extend into verification, replay, or provenance, which remain free and open regardless of holdings.

Creation gate. Launching an organism requires burning 100,000 $SPAWN. The burn is an on-chain transaction — burn(uint256) where the contract supports it, otherwise a transfer to 0x...dEaD — and is irreversible. The figure is fixed in tokens, not tied to market price, and may be revisited only under a published process.

Interim registry. Until the factory deploys, a launch consists of: (1) the burn transaction; (2) a free signature by the burning wallet over “Spawn launch\nburn: {tx}\nprovenance: {hash}\nchain: {id}”; (3) server-side verification that the receipt's Transfer log originates from the $SPAWN contract, carries at least the required amount to a burn destination, and that the signer is the log's from; (4) insertion into Spawn's registry, where burn_tx_hash is unique. Burned launches are migrated first when the factory deploys. The registry is Spawn's database and is stated as such on every organism page.

Trading tax. $SPAWN trades on Pons v2 and carries a 1% tax that funds routine injections into $SPAWN's own pool. This is separate from the fixed protocol share of organism trading fees (§6).

True at the document date; verify against the live site and explorer.

Live. Wallet connection (EIP-6963 injected discovery, WalletConnect, Coinbase Wallet), network add/switch to Robinhood Chain. Launch by burning 100,000 $SPAWN with server-side receipt verification and a shared registry. A browser sandbox exposing the crawler's parameters and generating its <S, f, sigma, tau> specification live.

Running, browser-local, no pool: a C. elegans track-following crawler (klinotaxis, reversals, omega turns; Fang-Yen 2010, Pierce-Shimomura 1999, Iino 2009); a Drosophila third-instar larva executing a posterior-to-anterior peristaltic wave, segment count per Heckscher et al. 2012; an adult fly tripod gait, alternating leg triads with inter-leg coordination timing from Wosnitza et al. 2013 and DeAngelis et al. 2019; an undulatory swimmer whose body wave sets its own cruising speed through the Strouhal number (Triantafyllou 1991/1993, Videler & Wardle 1991, Domenici & Blake 1997); a Lenia orbium (Chan 2019); a Vicsek flock (Vicsek 1995). Worked examples, not running: an EB ring attractor from roughly 200 E-PG/P-EN neurons of the 2026 Drosophila male CNS connectome, a Gray-Scott field, a Kuramoto lattice.

Not deployed. Factory, locker, runtime escrow, tick/keeper contract, challenge contract (§5, §9–11). No organism token or pool exists. No APR, yield, price, or holder figure is shown anywhere.

Smart contract risk. The factory, token, locker, and runtime escrow are code, and code has bugs. A flaw in any of them could cause loss of funds, a stuck position, or an organism that cannot be funded. Audits and public review reduce this risk; they do not remove it. The immutability that makes the lock trustworthy also means a discovered bug cannot be patched in place.

Robinhood Chain itself is infrastructure we do not control. Reorgs, outages, or changes at the chain or explorer level affect this application.

What the locked-liquidity guarantee can and cannot prove. It can prove one thing precisely: the initial liquidity position cannot be removed, by anyone, because the locker contract exposes no path to remove it. It cannot independently verify that a creator's claimed dataset is authentic. Spawn checks that a citation is well-formed and that a submitted hash is a valid SHA-256 pinned on-chain. It does not read the paper, and it cannot confirm that the hashed file is the dataset it claims to be. That still relies on public scrutiny — the provenance requirement exists to make claims specific enough for someone to check. A lock also says nothing about price. Holders can sell, volume can be zero, and a token with permanently locked liquidity can still go to near-zero.

Runtime funding depletion. Organisms are funded by trading fees. When trading slows, the escrow empties. This is the normal, expected end state for most organisms, not an anomaly. When it happens the organism pauses, its page says so, its status changes, and the trace freezes at the last state. Nothing is deleted and the provenance document stays public. A paused organism can resume if funding returns. There is no guarantee that it will, and no one is obliged to top it up — not the creator, and not the protocol.

Model and claim risk. An organism is a small computational model. Even a well-sourced one is a simplification, and the sourced-vs-designed section of each provenance document exists so you can see how large that simplification is. A creator can also be wrong or dishonest in that document. Read it, and treat unchecked claims as unchecked.

No warranty, no advice. This software and these contracts are provided as-is, without warranty of any kind, express or implied, including merchantability and fitness for a particular purpose. Nothing here is financial, investment, legal, or tax advice, and nothing here is an offer or solicitation to buy or sell any asset. Tokens launched on Spawn are created by third parties. We do not endorse, vet, or take responsibility for any organism, its creator, or its claims. You are responsible for your own decisions and for the laws that apply where you live.

Fang-Yen, C. et al. (2010). Biomechanical analysis of gait adaptation in the nematode C. elegans. PNAS 107(47), 20323-20328. doi:10.1073/pnas.1003016107

Pierce-Shimomura, J. T., Morse, T. M., Lockery, S. R. (1999). The fundamental role of pirouettes in C. elegans chemotaxis. J. Neurosci. 19(21), 9557-9569. doi:10.1523/JNEUROSCI.19-21-09557.1999

Iino, Y., Yoshida, K. (2009). Parallel use of two behavioral mechanisms for chemotaxis in C. elegans. J. Neurosci. 29(17), 5370-5380. doi:10.1523/JNEUROSCI.0012-09.2009

Stephens, G. J., Johnson-Kerner, B., Bialek, W., Ryu, W. S. (2008). Dimensionality and dynamics in the behavior of C. elegans. PLoS Comput. Biol. 4(4), e1000028. doi:10.1371/journal.pcbi.1000028

Heckscher, E. S., Lockery, S. R., Doe, C. Q. (2012). Characterization of Drosophila larval crawling at the level of organism, segment, and somatic body wall musculature. J. Neurosci. 32(36), 12460-12471. doi:10.1523/JNEUROSCI.0222-12.2012

Wosnitza, A., Bockemuhl, T., Dubbert, M., Scholz, H., Buschges, A. (2013). Inter-leg coordination in the control of walking speed in Drosophila. J. Exp. Biol. 216(3), 480-491. doi:10.1242/jeb.078139

DeAngelis, B. D., Zavatone-Veth, J. A., Clark, D. A. (2019). The manifold structure of limb coordination in walking Drosophila. eLife 8, e46409. doi:10.7554/eLife.46409

Cook, S. J. et al. (2019). Whole-animal connectomes of both Caenorhabditis elegans sexes. Nature 571, 63-71. doi:10.1038/s41586-019-1352-7

Dorkenwald, S. et al. (2024). Neuronal wiring diagram of an adult brain. Nature. doi:10.1038/s41586-024-07558-y

Berg, S. et al. (2026). Sexual dimorphism in the complete Drosophila male central nervous system connectome. Cell. doi:10.1016/j.cell.2026.08.015

Turing, A. M. (1952). The chemical basis of morphogenesis. Phil. Trans. R. Soc. Lond. B 237, 37-72. doi:10.1098/rstb.1952.0012

Pearson, J. E. (1993). Complex patterns in a simple system. Science 261(5118), 189-192. doi:10.1126/science.261.5118.189

Kuramoto, Y. (1975). Self-entrainment of a population of coupled non-linear oscillators. International Symposium on Mathematical Problems in Theoretical Physics. doi:10.1007/BFb0013365

Strogatz, S. H. (2000). From Kuramoto to Crawford: exploring the onset of synchronization in populations of coupled oscillators. Physica D 143, 1-20. doi:10.1016/S0167-2789(00)00094-4

Wolfram, S. (1983). Statistical mechanics of cellular automata. Rev. Mod. Phys. 55, 601. doi:10.1103/RevModPhys.55.601

Triantafyllou, M. S., Triantafyllou, G. S., Gopalkrishnan, R. (1991/1993). Wake mechanics for thrust generation in oscillating foils. Phys. Fluids A 3, 2835-2837. doi:10.1063/1.858491

Domenici, P., Blake, R. W. (1997). The kinematics and performance of fish fast-start swimming. J. Exp. Biol. 200, 1165-1178. doi:10.1242/jeb.200.8.1165

Videler, J. J., Wardle, C. S. (1991). Fish swimming stride by stride: speed limits and endurance. Rev. Fish Biol. Fish. 1, 23-40. doi:10.1007/BF00042660

Chan, B. W.-C. (2019). Lenia: Biology of artificial life. Complex Systems 28(3), 251-286. doi:10.25088/ComplexSystems.28.3.251

Vicsek, T., Czirok, A., Ben-Jacob, E., Cohen, I., Shochet, O. (1995). Novel type of phase transition in a system of self-driven particles. Phys. Rev. Lett. 75, 1226. doi:10.1103/PhysRevLett.75.1226

Reynolds, C. W. (1987). Flocks, herds and schools: a distributed behavioral model. SIGGRAPH Comput. Graph. 21(4), 25-34. doi:10.1145/37401.37406

Nothing in this document is financial advice. No figure describing live activity, holders, or funding for any organism should be treated as current beyond the date this document was generated. Verify all current state directly at spawn.farm and on the Robinhood Chain explorer.