Updated October 14, 2026. This revision describes the current product direction and proposed implementation. Proposed components are not represented as deployed contracts.
Purpose
Spawn helps people and AI agents create public simulation models, launch token-associated Worlds through pons, and explore those Worlds. Spawn Labs supports model development; the Model Library holds reusable approved versions; Explore Worlds shows launched instances and their execution history.
The protocol token remains the original $SPAWN on Robinhood Chain at 0x41080c9d7908CE567eFe239042c49D8159a2A3bb. Its existing contract is retained. Spawn v2 adds application and integration infrastructure around it.
Roles and product objects
Designers author models. Launchers choose an approved version, configure a World and token, select creator payout wallets, and fund the launch and runtime. Players inspect or interact with Worlds where the model supports participation. The same participant may fill multiple roles, and supported APIs can allow AI agents to participate.
A model version contains executable rules, state and input schemas, constraints, provenance, a license, a reproducible build, and a renderer specification. A World pins a model version, launch parameters, token identity, creator allocation, initial state, and funding policy. One model can support multiple independent Worlds. Discoverability, eligibility for launch, and actual runtime status are separate properties.
Model development and approval
Spawn Labs is intended to help produce executable models and their documentation. A submission enters schema validation, sandboxed resource measurement, replay checks, and review. AI can assist this work; measured execution determines the resource estimate. Review approval is bounded to an exact artifact and permitted parameter ranges, rather than every future modification.
Fictional games may use entirely designed rules. Research citations and dataset licenses are required where sourced material is used; they are not fabricated to satisfy a form. Public availability does not itself grant unrestricted reuse, so each model declares its license.
Launch economics
The launcher supplies 100,000 $SPAWN for retirement, the pons launch payment, and a separately quoted amount n ETH for simulation funding. Both ETH payments and transaction gas use Robinhood Chain. Optional generated video is quoted separately from deterministic execution and ordinary visual rendering.
Brooks reports a 0.01 ETH pons launch requirement from the October 14 call. Public pons v1 docs list a 0.0005 ETH launch fee and an optional initial buy. The selected deployed factory, its current required payment, and the breakdown of the quoted 0.01 ETH must be confirmed before implementation. A frontend must not silently treat surplus ETH as a launch fee or liquidity deposit.
Trading fee allocation
The agreed target for new Spawn launches is a standard 100 basis point trading fee split as follows:
| Recipient | Basis points of trading amount | Share of standard fee |
|---|---|---|
| Launcher creator wallets | 50 | 50% |
| Spawn | 20 | 20% |
| pons | 30 | 30% |
pons receives its allocation directly under its own protocol. Of its 30 basis points, the reported policy assigns 24 to token buybacks and 6 to operations. These are allocations of collected fees, not extra charges. Existing launches may have different snapshotted terms; this table does not rewrite the original $SPAWN token's historical fee policy.
The pons creator payout recipient for a new Spawn World is intended to be a dedicated fee splitter contract. It divides actual received creator proceeds in the ratio 2:5: Spawn gets 2/7, and the launcher's configured wallets collectively get 5/7. Wallet weights divide that collective allocation and sum to 100%. Use rational integer arithmetic rather than rounding 2/7 into a new basis point rate. Apply a deterministic dust policy.
The exact payout assets, claim authorization, recipient-change controls, and factory version require deployed-interface verification. Public v1 documentation describes fees in both the launch token and WETH. Settlement adapters must account for assets actually received; no automatic ETH conversion is assumed. Runtime receives no automatic share of these trading fees.
Recommended contract architecture
A Spawn launch router coordinates a model approval check, token retirement, pons launch, fee splitter creation, runtime deposit, and World registration in one transaction. A RuntimeEscrow keeps a separate per-World funding ledger. A WorldRegistry binds the token to its approved model artifact and checkpoints. A splitter routes creator proceeds without holding runtime funds.
This is a proposed integration, conditional on the selected pons factory accepting contract-mediated launches and contract fee recipients. The adapter must preserve the launcher's intended control and initial-buy recipient. It must not accidentally assign those rights or purchased tokens to the router. Any pons forwarder trust or whitelist requirement must be explicitly configured and tested.
Wallet approvals and atomic launch
For an ordinary wallet without sufficient existing allowance, the proposed flow has two on-chain transactions: an exact $SPAWN spending approval, followed by one combined launch transaction. Approval does not burn tokens. The combined transaction supplies the required pons ETH payment plus n ETH as native transaction value; native ETH needs no ERC-20 allowance.
All launch effects must revert together if retirement, pons launch, escrow deposit, or registration fails. Gas already spent is not refunded by a revert, and a previously mined allowance remains. Optional atomic wallet batching may combine approval and launch for compatible wallets and accounts after a chain-specific capability check. Permit support is not assumed for the original token.
The deployed $SPAWN burn interface is not yet verified in this review. A true burn reduces totalSupply; transfer to a documented dead address retires transferable supply without necessarily changing totalSupply. The adapter and public counters must identify which mechanism is actually used.
Quotes and runtime funding
An approved model receives a bounded runtime quote based on measured workload, configured tick rate, storage, checkpoint publication, and visual services. Quotes identify the model version, World configuration, funding amount in wei, service budget, expiration and nonce. The launcher, creator allocation and launch terms must be bound to the signed authorization or immutable review record. Chain and verifying-contract domain separation prevent cross-chain or cross-router replay.
The launch deposits n ETH into that World's runtime balance. Authorized, metered service expenditures reduce the balance; anyone allowed by the policy may top up. When the next authorized work cannot be paid, execution pauses with state retained. It resumes from the last verified checkpoint after sufficient funding. A monthly initial budget is a proposal, not a committed requirement. Refunds, unspent balances, operator permissions and price revision rules need a declared policy before release.
Execution and replay
The simulation engine executes off-chain using pinned deterministic code. State, arithmetic, input ordering, external input data, and serialization must be fully specified. AI assists creation and review; unconstrained language-model responses are not silently used as authoritative simulation steps.
Checkpoints publish an execution commitment and a location for the data needed to replay it. The recommended chained commitment binds the previous commitment, model version, tick index, canonical state and accepted input events. On-chain hashes establish what was recorded, not whether execution was correct. An independent replay process compares recomputed checkpoints to published commitments.
Initial authorized operators and their verification limits must be disclosed. Permissionless fund withdrawals or paid tick submission require additional validation machinery; a posted hash alone is insufficient to authorize payment. Full proof or dispute systems are future work unless specifically implemented and tested.
Model changes and player interaction
Published model versions remain available. New versions do not overwrite old rules or traces. Existing Worlds keep their pinned version unless their initial policy explicitly allows a documented version transition. Any allowed transition records approval, effective tick, new code hash and state migration. Gameplay actions under existing rules are distinct from changing those rules.
Tick duration in simulated time, execution cadence in real time, and rendering cadence are separate settings. A daily turn game and a compressed replay can use the same logical model with different scheduling and presentation. External market data and user actions must be recorded to reproduce a run.
Liquidity and dashboard
pons supplies its token, trading venue and liquidity-lock machinery. Spawn must verify the selected version's lock behavior and expose the actual factory, token, venue and lock record. Spawn must not promise a new custom locker or a venue version that has not been integrated.
The Spawn dashboard is intended to expose permitted token management, creator claims and distributions, trading data, runtime balance, top-ups, execution status, model version and verification evidence. Only controls supported by contracts are shown. A website restriction cannot secure a creator fee allocation if an alternate contract call can bypass it.
Release evidence
Release requires a deployed-interface test of the full launch; retirement amount and mechanism checks; exact payment routing; creator-control preservation; splitter asset and recipient accounting; pause/resume and replay checks; and integration tests across supported wallets. Current application and contract deployment status must be verified from the actual repositories and chain, separately from these planning documents.
Primary references
- pons protocol and integration docs: https://docs.ponsfamily.com/
- pons next-generation integration docs: https://docs.ponsfamily.com/v2
- ERC-20 allowance semantics: https://eips.ethereum.org/EIPS/eip-20
- Wallet batching: https://eips.ethereum.org/EIPS/eip-5792
- Reown wallet integration: https://docs.reown.com/appkit/react/core/installation
The October 14 call terms are supplied by Brooks. Exact deployed source and bytecode were not obtained in this review, so ABI-dependent behavior is marked for verification.