Runtime Funding and Compute

Simulations consume real resources. A small browser game may cost almost nothing to run. A detailed climate, market, or multi-agent Model may require substantial CPU, GPU, memory, storage, and data access.

Spawn treats compute as an explicit operating cost rather than hiding it inside token language.

Cost profile

Before launch, a Blueprint should be benchmarked at representative workload sizes. The resulting profile should estimate:

• cost per tick or run;
• expected ticks per minute, hour, or Season;
• CPU or GPU requirements;
• active memory;
• checkpoint and archive storage;
• data-provider costs;
• verification overhead;
• expected monthly cost at low, normal, and high usage.

These are estimates, not guarantees. The World page should show the assumptions behind them.

How runtime is funded

The initial design uses $ETH to pay for compute and blockchain gas. A Launcher funds a runtime balance before the World begins. Additional funding may come from World fees, sponsorships, direct top-ups, or another policy disclosed at launch.

Trading volume is not a reliable runtime guarantee. A World must be viable under its disclosed prefunding and pause policy even if token trading or fee activity falls to zero. Projected fees may extend runway; they must not be represented as committed funding.

$SPAWN is not intended to pay for every CPU cycle. Keeping compute funding in $ETH separates a measurable operating expense from the network's capital asset.

One run and a persistent World

A one-time job and a persistent World use the same basic infrastructure but have different billing shapes.

For example, running a baseball matchup 10,000 times is a bounded batch job. Its cost can be estimated from the number of simulations, Model complexity, data preparation, and output detail.

A WW3 World may remain active for months. It needs an uptime budget, scheduled ticks, player-event processing, checkpoints, storage, monitoring, and possibly continuous verification.

The runtime system should quote both in understandable units.

Each economic Season should define minimum funded runway, who may top up, whether unused funds are refundable, how failed jobs are charged, and what happens if the World reaches its deadline while paused.

Pause and resume

If a persistent World cannot pay for its next required execution, it should pause at the last finalized checkpoint. It must not invent missing states or place participant funds at risk merely to appear online.

The World can resume when funding returns, subject to its declared rules. A pause is an operational state, not proof of fraud or Model failure.

Runtime providers

The planned path is:

1. Spawn-managed infrastructure during early development;
2. approved external providers with defined service requirements;
3. an open provider marketplace if security, verification, and demand justify it.

A runtime provider computes state. It does not receive unilateral authority over settlement funds.

Designer and Launcher economics

Runtime charges should be separated from Designer royalties, Launcher revenue, protocol fees, and player settlement. Every World should disclose who receives each fee and which activity generates it.