Spawn
Join the waitlist →
Browse documentation
START HEREWhat is Spawn?60-Second ExplanationHow Spawn WorksKey TermsWho Participates
PRODUCTModels & BlueprintsWorldsSeasonsPositionsModel StoreLauncher Configuration
ECONOMICSThree-Asset Architecture$SPAWNOptional World TokensLaunch EconomicsPlayer EconomicsEconomic LineageFeesLiquidity
RUNTIMERuntime OverviewCompute ProfilesRuntime CostRuntime BatteryRuntime DepletionRuntime ProvidersLarge Data
VERIFICATIONDeterministic ExecutionCheckpointsVerification ClassesVerification & ReplayFinality & SettlementData AvailabilityRandomnessVaults & SettlementThreat ModelProtocol Invariants
BUILD ON SPAWNBuild a ModelModel SpecificationBlueprint StatusSpawn LabsLaunch a WorldWorld Creation FlowWorld ConfigurationOptional Token Design
REFERENCEOfficial $SPAWNProtocol StatusTrust ModelContractsChain CompatibilityFormula ReferenceGlossaryRiskFAQ
Docs / REFERENCE / Launch Economics
WORKINGv2.0

Launch Economics

100,000 $SPAWN, pons payment, runtime funding and optional visuals.

Updated 2026-10-14 · Canonical at www.spawnfarm.com · Status labels describe evidence, not marketing readiness

Updated October 14, 2026. This is the recommended launch architecture, subject to verification against the selected deployed pons factory and original $SPAWN token.

The launcher reviews three obligations

ObligationAsset and networkDestination
Retirement gate100,000 $SPAWN on Robinhood ChainVerified burn mechanism or documented dead address
pons launch paymentETH on Robinhood ChainSelected pons factory or supported launch router
Initial runtime fundingQuoted n ETH on Robinhood ChainWorld-specific RuntimeEscrow ledger

Gas is additional. Optional video is an explicit additional service in the quote. Brooks reports 0.01 ETH as the pons requirement; its fee/initial-buy breakdown remains to be verified because public v1 docs list a 0.0005 ETH launch fee.

One guided flow with two standard transactions

  1. Connect a wallet, select Robinhood Chain, and verify ETH and $SPAWN balances.
  2. Read the approved model version, configuration, runtime quote, creator wallets and weights.
  3. If allowance is insufficient, approve the Spawn router to spend exactly the required $SPAWN amount. This does not burn anything.
  4. Send one payable launchWorld transaction to the Spawn router with the pons payment plus n ETH. Native ETH does not require token approval.
  5. The router validates the approval/quote, retires $SPAWN, creates a dedicated fee splitter, invokes pons with that splitter as fee recipient, deposits runtime ETH, and binds the resulting token to the World.
  6. Publish the World only after checking the complete transaction receipt and contract events.

Every step inside the launch transaction must revert on failure. A failed launch must not leave a completed retirement, an unfunded token launch, or an orphaned runtime deposit. Gas spent on failed transactions remains spent. A previously mined spending approval remains until used or revoked.

Compatible wallets may support an atomic approval-and-launch batch; check support on Robinhood Chain before offering it. Permit support in the original token is unverified and is not part of the baseline. The dashboard always shows actual wallet prompts rather than promising one universal confirmation.

Contract responsibilities

  • LaunchRouter validates caller, approved model and quote, coordinates required calls, and enforces exact routing.
  • FeeSplitter fixes Spawn's 2/7 share of incoming creator proceeds and allocates the remaining 5/7 to creator wallets.
  • RuntimeEscrow records deposits and authorized metered expenditure per World.
  • WorldRegistry pins model artifact, configuration, token, splitter and initial state.
  • pons supplies token deployment, trading mechanics and liquidity-lock machinery.

These roles may be consolidated where safe; three payment obligations do not require three user-facing contracts.

Approval and quote integrity

Model approval is bound to an exact executable version and accepted parameter limits. The quote binds launcher, model version, configuration, funding amount, creator allocation, expected pons terms, expiration and one-use nonce. Its signature domain includes chain and verifying contract. A different model or configuration cannot reuse the same authorization.

Preflight simulation checks balances, allowance, required native value, launch access, expected fee recipient and any initial-buy recipient. The router must preserve intended creator management rights; otherwise pons may record the router as deployer. Any trusted-forwarder or whitelist integration is a release prerequisite.

Retirement implementation

Verify the deployed $SPAWN contract at 0x41080c9d7908CE567eFe239042c49D8159a2A3bb. Use an actual supported burn path where available. Otherwise use an approved transferFrom to the documented dead address and label it as retired supply rather than a totalSupply reduction. No additional supply-changing feature is assumed.

Creator proceeds

Set a dedicated per-World splitter as the pons payout recipient. If it receives R units of a payout asset, Spawn is allocated floor(2R/7) and the creator allocation is R minus that amount. Creator weights divide the latter, with a defined rounding rule. Accounting must handle ETH, WETH or launch-token fees according to the actual selected interface, without double-counting or mixing Worlds.

Use claimable balances so one recipient's failing transaction does not stop others. Claiming must send funds to recorded beneficiaries, regardless of the caller. Lock the Spawn entitlement against alternate recipient-update paths where supported; website-only restrictions are insufficient.

Interfaces still to verify

Selected factory and ABI; contract-mediated launch permissions; creator-control preservation; exact required ETH; any initial buy and its recipient; support for a contract fee recipient; payout assets and claim calls; recipient-change authority; original $SPAWN burn and permit support.