The Launch Factory

Third-party launches are deployed through the PurityLaunchFactory — a persistent, immutable on-chain contract that assembles a fully-wired, conformant PURITY launch set in a single atomic call, records the launch in a public registry, and grants itself no power over anything it deploys.

The factory exists to make two guarantees structural rather than procedural. First, conformance: a factory-deployed launch cannot be miswired, because the deployment transaction verifies every wiring edge on-chain and reverts entirely on any mismatch. Second, provenance: anyone can check on-chain whether a given launch genuinely came from the canonical factory — which, because the factory enforces correct wiring and hardcodes the PURITY arbitrator, is equivalent to checking that the launch genuinely runs the standard's mechanics.

A factory-deployed set is byte-identical to a script-deployed one. The deployed contracts cannot tell which path created them, and the factory adds no behaviour to any of them.

What a launcher provides — and what they cannot choose

deployLaunch() is permissionless and takes the launcher's inputs: the token identity (name, symbol, total supply), the team's controlling address (teamAddress), the vault admin, the vault contribution caps, the committed launch capital (poolSeedingETH and accumulationETH), the full economic parameter array, and a salt for address pre-computation.

The parameter array is validated by the Treasury constructor's own range checks — the same enforced bounds every PURITY launch passes through (see Reference). The factory adds no validation surface of its own and carries no on-chain defaults; within the vetted ranges, the configuration is the launching team's call.

Two things are deliberately not inputs:

• The arbitrator. PURITY's multisig is a factory construction immutable, wired into every launch's Treasury and GovernanceModule identically. A launcher cannot choose their own arbitrator — so every factory launch is independently PURITY-arbitrated by construction, and no launching team holds shutdown powers over its own holders.
• The ecosystem share. The factory deploys third-party sets only, and the 500 bps ecosystem contribution is enforced in the Treasury's third-party path. A launching team cannot reduce or waive it.

One transaction, verified

For each launch the factory creates a fresh, single-use deployer contract at an address derived from the launcher and their salt — which means a launcher can pre-compute their entire launch's addresses before deploying, useful for listing preparation or pre-funding from a known address. The deployer then performs the whole sequence described in Deployment Sequence: predicts the six addresses, deploys each contract in order with the predicted references, resolves the governance circular reference, and runs the full on-chain wiring verification.

If anything mismatches — any address, any reference, any allowance, the vault's launch binding — the whole transaction reverts, and the launcher's payment reverts with it. There is no partially-deployed state and no fee-kept-on-failure path.

Provenance: the registry and the event

On success the factory records launcherOf[treasury] = launcher in an append-only registry, from which isCanonicalLaunch(treasury) answers the only trust question that matters: was this launch deployed by the canonical factory? The registry lives on-chain and survives any indexer or website — verification never depends on PURITY's own infrastructure being up or honest.

The factory also emits a PurityLaunchDeployed event carrying the full address set (treasury, token, both distribution contracts, vault, governance module, pair), the launch's committed amounts and vault caps, the team address, and the fee paid — the feed any index of launches is built from. $PURE itself is not in this feed: genesis predates the factory and stays on its bespoke deploy, serving as the known root rather than a registry entry.

Independent verification without the registry is also possible: all of a launch's wiring is readable from public getters, so anyone can re-derive the edge checks themselves — including that a claimed launch's Treasury points at the canonical EcosystemReceiver and the canonical arbitrator.

Deploy is not launch

The factory deploys the set and opens the vault for contributions. It does not call launch() — going live remains a separate, later transaction callable only by the launching team, once the raise has filled. Deployment costs the launcher a fee but moves no launch capital; the launch capital is the supporter vault's, and it moves only at launch().

The deploy fee

A permissionless deploy entrypoint with no cost would be a spam amplifier, so deployLaunch charges a launcher-paid fee (initially 0.1 ETH), forwarded to an immutable recipient. The fee is a service charge on the launcher — it is never launch capital, and it touches neither token buyers nor the market engine, so the non-extraction guarantee is unaffected. The current fee is always readable from the factory (deployFee()), and it is bounded: an immutable ceiling (MAX_DEPLOY_FEE) means it can never be raised into a de-facto gate on launching.

The guardian — and its limits

The factory has exactly one administrative role, a guardian multisig with exactly two powers: pausing new deployments, and setting the deploy fee within its immutable ceiling. Neither power reaches any deployed launch. The guardian cannot touch, freeze, drain, or modify a live launch set — its scope ends at the factory's front door. The role is also renounceable, one-way, at which point the factory's remaining levers freeze permanently.

This is the shape of the factory's overall security claim. It is not "PURITY retains nothing" — PURITY holds the arbitrator role in every launch, deliberately, as the governance-gated backstop described in Core Contracts & Roles. The claim is narrower and verifiable: the factory is not a privileged deployer. It holds no role in anything it deploys, cannot mint, redirect liquidations, drain a treasury, alter parameters, or backdoor any set — and every part of that claim is checkable on-chain.

Team-funded launches

A team that wants to fund its own launch entirely — no outside supporters — does not need a special deploy path. It is a configuration of the standard one: set the supporter share to zero (folding it into market-making), size the vault caps so a single wallet can fund the whole raise, enable the vault whitelist with the team's address as its only member, and have the team fund the vault and then launch. The on-chain trail is the familiar one, with the same guarantees. One operational note: the whitelist is enabled by the vault admin in a follow-up call after deployment, so a team intending a closed raise should enable it before funding the vault.