Architecture
The focus here is structural clarity: which components exist, what authority each has, and how they interact. Every component is designed to minimise overlap, reduce discretionary power, and enforce non-extractive behaviour by construction.
Overview
A PURITY launch is not a single contract. It is a small, fixed set of contracts deployed together, wired to each other through immutable references, with the Treasury at the hub. The Treasury owns the market, holds the token supply at deployment, and holds a permanent reference to every peer contract — which makes a launch's Treasury address a complete handle to the whole system. Around it sit the token itself, two distribution contracts that hold the team and supporter buckets, a pre-launch supporter vault, and a governance module.
Launches are isolated from one another. No launch shares liquidity, treasury capital, or market-making state with any other, and the failure of one cannot cascade into another. One narrow, deliberate exception exists: every third-party launch forwards a fixed ecosystem contribution to the $PURE ecosystem receiver — and even that hand-off is engineered so that no launch's contracts can ever become a liveness dependency for another's market-making. The transfer is a plain token transfer that runs no code on the receiving side; nothing the recipient does (or fails to do) can block the sender.
Third-party launches are deployed through an on-chain launch factory, which assembles the full contract set in a single atomic transaction, verifies its wiring on-chain, and records the launch in a public provenance registry. The factory grants itself no power over anything it deploys. It is described in The Launch Factory.
The PURITY Standard defines the constraints every launch must satisfy. These constraints are enforced through contract architecture — immutable parameters, fixed value routes, and code-gated roles — not through governance discretion or off-chain oversight. Once deployed, a launch operates autonomously within its configured parameters. The platform does not curate, promote, or intervene in individual projects.
One money, internally
A system-wide principle worth stating once, up front: internally, all value is held and moved as WETH (wrapped ETH — the base asset in ERC-20 form). Native ETH appears only at the final step, when a payout leaves the system to a person — a team claim, a supporter claim, a holder claim. Because every internal movement is an ERC-20 transfer, which runs no code on the recipient, no contract in the system can be reverted, re-entered, or held hostage by a recipient during internal accounting. There is no stateful receive() logic anywhere in the value path.