wikideck/docs/mainnet-launch.md

Mainnet-first, gated candidate

The repository defaults to a mainnet candidate, not an audited or launched production network. Shipping code does not establish independent miners, economic security, or an operational public network. Market and payment features have been removed from the card-only product.

Current production decision: NO-GO. See the 2026-10-20 security review and operator evidence register and launch procedure. The read-only launch:preflight package script (or node entry-point --launch-preflight) reports local gates and unresolved blockers without starting a node or setting approvals. It deliberately exits nonzero while production readiness is blocked.

What is implemented

Property	Mainnet-first default	Explicit development fixture
Selection	WIKIDECK_NETWORK=mainnet (or unset)	WIKIDECK_NETWORK=testnet
Network ID	wikideck-randomx-mainnet-1	wikideck-randomx-testnet-6
Protocol	Version 6	Existing fixed local testnet version 6
Genesis timestamp	Fixed launch default: 2026-11-01 00:00 UTC (1793491200); ready to start now	Fixed at 2026-10-19 00:00 UTC
Ledger directory	mainnet	testnet
Browser wallet	IndexedDB name derived from exact chain ID	Separate chain identity
New backup	v2 header authenticates exact chain ID	Same v2 format; legacy v1 is accepted only on the original testnet

Both profiles use real RandomX validation, cumulative-work branch selection, the 15-minute target, mint maturity, signed NFT transfers, atomic card trades, and SQLite persistence. The mainnet candidate has no premine, token migration, hidden checkpoint, or fake-PoW option. Changing the network identifier and candidate genesis derives distinct chain/genesis IDs, RandomX initial keys, signature domains, and consensus manifest checks. Existing testnet values and data remain unchanged.

Cards and backups do not migrate across chain identities. Browser storage and backup headers are bound to the exact chain ID; peers reject mismatched manifests, and transactions are checked against the active chain. The selected profile and genesis are pinned at startup/browser build, never silently adopted from an RPC response. The original fixed-testnet v1 backups remain supported only on that testnet.

Inspect without launching

The node entry point accepts --network-manifest. With WIKIDECK_NETWORK=mainnet set in the process environment, this prints the candidate network/chain/genesis/timestamp and exits before opening databases, starting a RandomX engine, listening, or contacting peers. It does not require activation credentials or approval and does not launch anything.

Browser builds select VITE_WIKIDECK_NETWORK=mainnet; server/miner processes select WIKIDECK_NETWORK=mainnet. These must match. WIKIDECK_GENESIS_TIME is also part of the chain identity. Docker's network/genesis build arguments pin the browser and immutable image manifest; a runtime variable cannot alter an already compiled UI. To choose another genesis, set it for the image build and runtime together, publish the resulting manifest, then use that immutable image and exact timestamp for every node and browser. A runtime-only genesis override fails closed. A mismatched UI rejects the node rather than signing for it.

Explicit launch gates

compose.yaml and compose.mainnet.yaml are mainnet-first definitions, use separate named volumes, bind only loopback for an external HTTPS reverse proxy, and do not auto-restart a failed candidate. They have no default peers, approval, or public origin. The default service therefore exits until the operator supplies real deployment values. The testnet Docker fixture is separate and explicit. This code change does not establish or certify a public mainnet.

Starting the candidate node or native miner requires all of:

1. WIKIDECK_MAINNET_LAUNCH equals the exact candidate chain ID printed by the manifest command.
2. WIKIDECK_MAINNET_RISK_ACK=operator-accepts-unaudited-risk records the operator's explicit acceptance that no external audit is planned and residual risks remain. This is not a safety certification; the manifest honestly reports audited: false.
3. The candidate genesis timestamp has arrived. If the operator changes the timestamp or consensus manifest before launch, the chain ID also changes and the old approval is invalidated. Freeze and publish the final manifest before launch.
4. An HTTPS PUBLIC_ORIGIN and at least two distinct configured peer origins. Public deployments require public HTTPS peers by default. An operator-controlled private candidate cluster may explicitly set WIKIDECK_ALLOW_PRIVATE_PEERS=1 to permit private/HTTP peer RPC; this does not relax browser HTTPS, chain approval, risk acknowledgment, or genesis-time gates. Configuration count cannot prove the peers are online, independent, or sufficiently distributed; verify that operationally. Existing public peer DNS/origin controls still apply when the private opt-in is off, and HTTPS certificate verification is never disabled.

For Kubernetes public peering, give every node a stable, unique public HTTPS endpoint. For an explicitly private candidate, separate single-replica Deployments, Services and exclusive PVCs may use distinct ClusterIP DNS origins with the private opt-in. Each validator lists the other two internal Services, never itself. The browser-facing node needs a TLS ingress/reverse proxy; internal-only validators may share that HTTPS browser origin without their own ingress. NetworkPolicy must restrict peer RPC to the selected validator pods on target TCP port 3001. Private HTTP RPC is unauthenticated and unencrypted unless protected by an independently configured mesh; do not use it across untrusted networks. Three validators in one cluster/storage failure domain are not independent operators or proof of production readiness.

See the Kubernetes mainnet preparation checklist for the deployment contract and the values needed before manifests can be finalized. Unknown profile names fail closed. A direct import of the HTTP entry point is also guarded. Library-level manifest/consensus/storage inspection remains possible for tests and review; activation gates are accident prevention and operator risk acceptance, not a security boundary against someone who edits the source.

Required before an actual production launch

• Internal readiness review: track code findings and regression evidence in-repository. No external audit is planned; the operator accepts the additional risk and must not describe the candidate as audited or certified.
• Security model: quantify hashpower, chain-rewrite cost and majority attacks. The inherited easy initial target and ten-block retarget are not production-calibrated. Choose reviewed launch difficulty/retarget behavior and test start-up/stall/recovery scenarios. Independent mining participation and sufficient hashpower are not provided by running multiple containers on one host.
• Adversarial rehearsal: sustained multi-host simulations, partitions/eclipses, competing branches, deep reorganizations, clock skew, bad peers, load/mempool saturation, corrupted state and restart recovery. Test the candidate rules with no valuable assets.
• Operations: independently administered public HTTPS nodes and miners across failure domains, pinned release artifacts and dependencies, firewall/reverse proxy/rate-limit policies, bounded storage and sync strategy, metrics, alerts, rotation and emergency-response procedures.
• Recovery: verified offline wallet recovery, consistent ledger snapshots, full replay/revalidation, documented incident and fork handling. No silent ledger reset or reuse of testnet data.
• Launch governance: select the actual genesis date, freeze the identity/configuration, publish binaries and configuration hashes, agree peer/miner readiness and upgrade policy, and explicitly record the operator's risk acceptance. Do not treat the flag as proof of safety or peer readiness.
• User and legal review: no monetary value or security is promised. NFT rights do not imply article/image copyright ownership. Publish experimental-use, privacy, support, and abuse-report terms appropriate to the release.

Still not production-ready

This remains experimental software. Nodes retain the DAG and overlays in memory, rebuild state roots over the full NFT set, and revalidate proofs at startup. The HTTP UI trusts its connected node rather than independently validating the chain. There is no automatic peer discovery, established bootstrap infrastructure, formal finality, independent audit, or production abuse system. Mainnet selection does not remove any of these limitations. See the card-only production plan for the current readiness gates.