Liquidity

Spawn launches integrate pons infrastructure. Token deployment, trading mechanics and liquidity locking follow the selected pons factory and locker version; Spawn must verify that version before publishing guarantees.

Current pons v1 documentation describes tokens launching directly into locked Uniswap V3 liquidity. The separate pons v2 documentation describes a bonding curve followed by a locked Uniswap V4 pool. These are different interfaces and lifecycles. The Spawn integration must identify which deployed version it uses rather than combining their assumptions.

Public evidence

For each World, show the token address, factory, trading venue or curve, lock record where one exists, fee recipient and launch transaction. Read supported controls and immutable or mutable properties from verified contracts. Do not display a pool lock before a version's lifecycle actually creates that pool.

The Spawn fee splitter routes creator proceeds; the RuntimeEscrow funds simulation services. Neither component is represented as a new pons liquidity locker. Fee claims, principal withdrawal and runtime payments are distinct operations.

Limits

A verified liquidity lock restricts specified withdrawal paths. It does not prevent ordinary token sales, guarantee price or trading depth, validate a simulation, or eliminate contract bugs. Use precise deployed evidence rather than a general claim that all funds are permanently inaccessible.

Primary references: https://docs.ponsfamily.com/ and https://docs.ponsfamily.com/v2