Launch flow — UI, fields, and the 100k burn-to-mint mechanics

Compiled from the live /launch form (Step 1 rendered) + the official /docs/launching walkthrough + /token + whitepaper §16 + the FAQ.

This is what a user fills out to create ("mint") a new organism, and exactly how the 100,000-token burn gate works. Token shown as $SPAWN (v1); for v2 this becomes $RESPAWN at the new CA.

Overview

A launch is presented as six steps. Step 2 (Provenance) is a hard gate — the flow cannot be submitted until it is complete and specific. Later steps unlock only once the current one validates. Nothing is stored until the launch transaction is signed. On-screen, every step that refuses to continue lists the exact reasons; there are no silent dead ends.

Step rail: 01 Basics · 02 Provenance · 03 Runtime · 04 Funding rule · 05 Review · 06 Launch

Step 1 — Basics (fields captured live from /launch)

Live validation example (all five must clear): name ≥3 chars, token name present, ticker valid, supply as whole number, description ≥40 chars.

Step 2 — Provenance (THE GATE)

Required contents — placeholder text ("n/a", "tbd", "not financial advice") is rejected, and each statement has a minimum length so one word can't satisfy it:

• One-line summary (what appears on cards / explore list).
• "What this is NOT" — at least two specific statements about what the organism does not claim to be (not a living animal, not a complete emulation, not a trained model). Generic disclaimers rejected.
• Data sources — at least one dataset with name, origin, license, and a valid 64-char SHA-256 if a file is bundled (the hash is written on-chain at launch so the file can't be silently swapped).
• Citations — at least one entry containing a DOI or link; prose about "published research" fails.
• Sourced-vs-designed — at least one pair with both sides written out (e.g. "adjacency from the published connectome" vs "integer threshold activation, not conductance-based").
• License of the organism's own code / model.

The document renders in full on the organism page (not collapsed, not summarised). There is no separate marketing-description field by design.

Step 3 — Runtime

• Selecting a runtime engine is required for a burned launch; the engine determines the model class (you can't file a swimmer as coupled oscillators).
• Two required free-text fields, both must be concrete:
  1. How the process executes (location of execution, what state persists between steps).
  2. What advances a tick (the trigger, τ).
• Must name the arithmetic, the PRNG if any, and the checkpoint cadence.
• "AI runs it" is explicitly rejected. You are describing f and filling in τ.

Step 4 — Funding rule (+ the burn is stated here)

• Runtime share: 40–80% (into the runtime escrow).
• Creator share: 0–40% (claimable).
• Protocol share: fixed 15%, not editable.
• The three must total exactly 100%; the page restates the split in plain language before you continue.
• Declare c — the cost per tick — in the pool's quote asset. Fixed after launch.
• This step states the $SPAWN burn required to launch**, separate from the fee split: **100,000$SPAWN — burned on launch, not refundable. The step reads your real on-chain balance.

Step 5 — Review

• Provenance document rendered exactly as it will appear publicly.
• Fixed supply restated; the burn restated as permanent + non-refundable; the liquidity lock restated in full.
• Required checkbox: "I understand this provenance document and liquidity lock are permanent once launched."

Step 6 — Launch

• One transaction: token deploy → provenance hashes recorded → pool created → liquidity locked. Tx hash + explorer link appear once mined; the organism page goes public immediately after.
• Today this is disabled. Wallet connection is live (EIP-6963 + WalletConnect + Coinbase Wallet; can add/switch network), but the submit button stays disabled until the factory + locker contracts are deployed. (On Arc the stated blocker is the missing v4 PositionManager; on Robinhood the factory/locker simply aren't deployed yet.)

The 100k burn → mint mechanics (interim registry)

Because the factory/locker aren't deployed, "minting" an organism today is a burn plus an off-chain registry insert. This is the flow to preserve (repointed to $RESPAWN) in v2:

1. Burn 100,000 $SPAWN — one on-chain transaction. Uses burn(uint256) where the token supports it; otherwise a transfer to 0x000000000000000000000000000000000000dEaD. Irreversible, spent (not staked, not refundable).
2. Sign a free message (no gas) with the burning wallet over:

   Spawn launch
   burn: {tx}
   provenance: {hash}
   chain: {id}
   

3. Server verifies the burn receipt:
   • the Transfer log originates from the $SPAWN contract,
   • it carries ≥ the required amount to a burn destination,
   • the signer equals the log's from.
4. Registry insert — the organism is recorded in Spawn's database, where burn_tx_hash is unique (one burn → at most one organism). Burned launches are documented as "migrated first" when the factory deploys.

The burn creates no organism token, pool, or liquidity lock today — those contracts aren't deployed. The registry is an application database (stated as such on every organism page), not a contract.

"Local launch" (no burn)

The FAQ documents a local launch: the full launch flow ending in a browser-local organism instead of a transaction. It exercises the provenance gate and runtime spec but creates no token/pool/funding and exists only on the user's device. Useful for testing the v2 form without spending anything.

v2 changes to this flow (see the v2 launch spec for full detail)

• Burn-gate token → $RESPAWN at the new CA (amount = your decision; v1 is 100k).
• Step 4 reads $RESPAWN balance; the signed message's chain: {id} must match.
• The provenance gate itself should stay unchanged — it's the core value prop.