Launch a protocol release

Know what a release cannot do

Zoltar and Statoblast are intended to launch as immutable, permissionless contracts. Launch documentation should not assume an operator can pause, upgrade, roll back, or disable protocol behavior after deployment. Release work should instead publish verifiable provenance: final commit and tag, deterministic addresses, continuous integration (CI) and local quality assurance (QA) results, production UI artifact hash, and any known limitations. UI deployments may describe data freshness and route users to verified artifacts, but they must not be documented as emergency controls over the protocol. This is the protocol's EG05 no-pause, upgrade, rollback, or rescue boundary.

Run the release checklist

1. From a fresh dependency install, run bun run ui:build:prod.
2. Run bun run check:mainnet-deployment:generated. It fails when either generated deployment manifest is stale. If so, refresh and review both manifests with bun ./tooling/contracts/check-mainnet-deployment.mts --write, which writes and checks mainnet-deployment-addresses.json and sepolia-deployment-addresses.json, then rerun the check.
3. Confirm the build used the pinned compiler configuration in solidity/ts/compile.ts, the exact tool versions in solidity/package.json, and the imported OpenOracle profile in UPSTREAM.md.
4. Publish the reproducible-build runtime hashes with the release, keyed to the manifest addresses. Compare both a clean local rebuild and the deployed runtime code against those reviewed hashes before marking the release canonical.
5. Push the final tag only after the CI gate succeeds on the same commit. The tag must match v<number> (for example v12); the Version deploy workflow rejects any other form. That workflow builds the IPFS publisher, verifies the InterPlanetary File System (IPFS) content identifier, and creates or updates the GitHub release with that identifier in its notes. Confirm the release exists and records the hash before announcing.
6. In the production UI release notes, state that ?simulate=1 is a browser-local sandbox. Mainnet and Sepolia quote-dependent actions use live RPC data plus available network-local Uniswap liquidity; simulation uses its configured mock where supported. Stale, unavailable, or unsupported quotes are production blockers for the affected client action, never inputs to replace with simulation prices. RPC and client integrity remain covered by A24; quote availability is an official-client limitation, not a protocol security assumption.

Review genesis REP allocations

Sepolia genesis REP allocations are canonical source data in sepoliaRepAllocations.ts. The configured 11 million REP mint cap is divided equally among the listed holders; adding a holder automatically reduces every holder's allocation. Integer division may leave the total minted supply below the cap by less than one attoREP per holder. Review both the holder list and the computed total before deployment. The GenesisReputationToken constructor requires at least one allocation, matching holder and balance array lengths, unique nonzero holders, nonzero balances, and a total supply no greater than 11 million REP. It emits the standard ERC-20 mint Transfer event once for each allocation.

The sum of the constructor balances is immutable and is returned by the REPv2-compatible getTotalTheoreticalSupply() selector. There is no administrator, post-deployment mint, allocation correction, or recovery entrypoint. An incorrect allocation must be fixed in the source list before deployment and the deterministic manifests must then be regenerated. Because constructor arguments are part of CREATE2 init code, any allocation change produces a new genesis REP address and new addresses for every deployment step whose constructor wiring depends on it. Never continue a deployment from a manifest generated for a different allocation list. A future release that intentionally changes starting holders must follow the same source review and full-manifest regeneration procedure.