Skip to main content

​
Mainnet readiness

PressChain does not treat mainnet as a DNS change or a copy of testnet state. The V3 authority files define a set of readiness gates that must be satisfied before an approved mainnet launch. That policy protects developers from one of the most common infrastructure mistakes: documenting planned behavior as if it were already deployed and immutable.

​
Required readiness gates

Current token authority identifies the following launch gates:
  1. V3 protocol complete
  2. Portal and PressKey unified
  3. Explorer complete
  4. SDK complete
  5. Feed Intelligence hardened
  6. Trust Platform access controls complete
  7. Economy and bounty engine audited
  8. Security audit complete
  9. Testnet launch rehearsal complete
A launch decision should have evidence for each gate, not simply a percentage in a roadmap.

​
New PRESS asset

Mainnet receives a new PRESS asset. Current testnet PRESS balances do not automatically migrate, and the testnet genesis is not reused as the mainnet genesis. The planned mainnet supply is:
with 18 decimals. That planned supply does not imply that allocation, vesting, treasury distribution, fee routing or validator rewards are already finalized. Those policies require their own approved manifests and verification.

​
Economic approvals still required

Before mainnet, the authority process requires at minimum:
  • final tokenomics approval
  • allocation and vesting manifest
  • treasury and bounty policy
  • validator reward policy
  • burn and fee routing policy
  • independent supply verification
Applications should therefore integrate economic classes now and keep final amount tables configurable. For example, an application can know that challenge.open is an elevated action without embedding an invented mainnet PRESS amount.

​
Deployment manifest discipline

A mainnet-ready application should receive contract addresses as a versioned deployment set. A useful deployment manifest records at least:
Values shown as placeholders above are intentionally not guessed. The mainnet authority manifest should be the source.

​
Rehearsal before launch

A meaningful testnet rehearsal should simulate the complete operating path, not just deploy contracts. It should include identity creation or recovery, role activation, publication, evidence attachment, contributor operations, bounty state, indexing, Explorer rendering, API health, pause procedures and recovery from an RPC or projection failure. The goal is to discover cross-system assumptions while assets are still testnet-only.

​
What application teams should do now

Build environment switching without embedding mainnet assumptions. Make chain ID and deployment manifests explicit. Label testnet data in UI. Reject unknown networks. Store token quantities in integer base units. Avoid promising migration of test balances. Treat contract addresses as environment data rather than source constants. Most importantly, keep product copy aligned with authority. A feature can be planned, implemented on testnet or approved for mainnet. Those are three different states.