Skip to main content
Protocol·Updated Jul 2026Standard V1.0

Deployment Sequence

A PURITY launch set is wired together through constructor immutables, and many of those references are circular: the token needs the Treasury's address, the Treasury needs the token's; the Treasury and GovernanceModule reference each other; the token must whitelist a pair that does not exist yet. None of these references can be set after deployment — immutability is the point — so the circularity has to be resolved before anything is deployed.

Address prediction​

The resolution rests on a property of the EVM: a contract's CREATE address depends only on the deployer's address and its nonce — not on constructor arguments. That means every contract in the set can be deployed with the predicted addresses of peers that do not exist yet, and as long as deployment proceeds in the predicted nonce order, every prediction lands.

One address in the set works differently: the Uniswap pair is a CREATE2 address (that is Uniswap's own mechanism), precomputed from the predicted token address. The Treasury constructor creates exactly that pair via the Uniswap factory, and the token whitelists it at construction — before the pair exists.

After deployment, every cross-reference is immutable. No contract can ever be re-pointed at a substitute — contract substitution after launch is structurally impossible.

$PURE genesis (seven contracts)​

$PURE deploys through a dedicated genesis script, in predicted-address order, asserting after each deployment that the address landed exactly where predicted:

  1. PurityToken — constructed with the predicted Treasury and precomputed pair; mints the full supply to the predicted Treasury.
  2. TeamDistribution — predicted Treasury, the team address, WETH, and the predicted EcosystemReceiver (its second authorised depositor).
  3. SupporterDistribution — predicted Treasury, predicted SupporterVault, WETH.
  4. Treasury — the full parameter set, all peer addresses (deployed or predicted), and the committed launch amounts. Its constructor validates every economic parameter against the protocol ranges, creates the pair, and grants the two distribution contracts their WETH allowances.
  5. SupporterVault — deployed against the now-live Treasury. Its finalize minimum is read from the Treasury's own getters (poolSeedingETH + accumulationETH + MIN_SURPLUS_ETH) rather than from a config file, so the vault's gate and the Treasury's commitment cannot drift apart.
  6. EcosystemReceiver — wired to the $PURE Treasury and TeamDistribution.
  7. GovernanceModule — deployed with a placeholder treasury, then resolved with a one-time initTreasury() call (the last circular reference).

The deploy script seeds nothing and does not launch. Pool seeding happens later, in the supporter-funded launch() transaction — deployment and launch are two separate moments, and the gap between them is when the supporter vault raises.

Third-party launches: the factory​

Third-party launches do not run a deploy script at all. The entire predict → deploy → wire → verify flow above is performed on-chain, atomically, in one transaction by the launch factory. A fresh single-use deployer contract is created for each launch; because a new contract always starts at nonce 1, its CREATE sequence is deterministic, and it deploys the six-contract set in predicted order exactly as the script does — with the same target == predicted assertion after every step.

The third-party wiring differs from genesis in three fixed ways: the Treasury is flagged as a third-party launch (which hardcodes the 500 bps ecosystem share), its ecosystem hand-off points at the canonical $PURE EcosystemReceiver, and its TeamDistribution has no ecosystem depositor. Third-party launches deploy no receiver of their own.

Wiring verification​

Deployment ends with a full wiring verification pass: every immutable cross-reference between the contracts is read back and checked, along with the WETH allowances, the pair's existence, the token-supply consistency between token and Treasury, and the vault-to-launch binding (that the vault's finalize minimum equals the Treasury's committed launch capital plus the surplus floor).

For $PURE this pass runs in the deploy script. For factory launches it runs on-chain, inside the deploy transaction itself — any mismatch reverts the entire deployment. A misconfigured launch set is therefore not something to detect after the fact; it is something that cannot come into existence.