# Mainnet Go-Live Checklist This checklist is the shortest practical path to decide whether PrivateDAO is ready for a real mainnet cutover. Use it as a go or no-go surface, not as marketing copy. ## 1. Repository Integrity All repository-bound checks must pass first. - `bash scripts/verify-all.sh` - `npm run verify:frontend-surface` - `npm run verify:submission-registry` - `npm run verify:generated-artifacts` - `npm run verify:cryptographic-manifest` Required outcome: - reviewer artifacts are fresh - proof registries are aligned - runtime and operational evidence are current - additive V3 hardening proof remains current - no stale generated files remain ## 2. Program And Authority Controls Before mainnet, authority handling must be explicit and hardened. - upgrade authority is moved to an explicit multisig or governance-owned path - treasury operator path is documented - token admin path is documented - authority rotation procedure is documented and rehearsed - emergency ownership and veto authority are understood by operators Blocking condition: - do not cut over while a single personal key still acts as an unchecked production authority ## 3. External Security Review Repository quality is not a substitute for an external audit. - external audit is completed - findings are reviewed and closed or accepted with explicit residual-risk notes - critical and high findings are not left unresolved - the audit scope covers the deployed program version intended for mainnet Blocking condition: - do not call the system mainnet-ready while external audit status is still effectively pending ## 4. Wallet And Runtime Validation Mainnet readiness requires real signer environments, not repo-only confidence. - Phantom runtime capture recorded - Solflare runtime capture recorded - Backpack runtime capture recorded - Glow runtime capture recorded - Android runtime capture recorded when Android is a supported path Canonical evidence: - `docs/runtime/real-device.generated.md` - `docs/runtime/real-device-captures.json` Blocking condition: - do not claim production readiness while real-device runtime evidence is still missing ## 5. RPC And Monitoring Readiness The protocol depends on RPC infrastructure. Treat that dependency as part of production design. - primary and fallback RPCs are selected - rate-limit behavior is understood - transaction failure alerts are routed - proposal lifecycle alerts are routed - operational diagnostics are tested against the chosen providers Required outcome: - operators know which RPC is primary, which one is fallback, and what to do when either degrades ## 6. Treasury Safety Treasury movement is the highest-consequence path and must be reviewed separately. - recipient validation paths are reviewed - token mint and ownership assumptions are reviewed - treasury funding and execution runbooks are rehearsed - rollback, pause, or containment procedures are written Blocking condition: - do not cut over while treasury recovery or emergency handling remains undocumented ## 7. ZK Boundary Decision The current stack anchors proposal-bound proof material on-chain, records parallel on-chain verification receipts in the legacy path, and keeps Groth16 witness generation and proving off-chain. The V2 strict security layer adds `DaoSecurityPolicy`, `ProposalExecutionPolicySnapshot`, `ProposalProofVerification`, threshold-attested proof records, canonical payload binding, and expiry checks. Before mainnet, be explicit about what is and is not claimed. - on-chain proof anchors are verified - on-chain parallel verification receipts are reviewed - V2 strict proof policy is initialized for the target DAO when strict finalization is required - any policy change after initialization is performed through `update_dao_security_policy_v2` and reviewed as monotonic, not a rollback - `ProposalExecutionPolicySnapshot` exists for proposals that will use V2 strict finalization - proposal policy snapshots are treated as immutable object-level records once captured - off-chain proof generation and proving flow are reviewed - explorer-visible anchor path is documented - operator messaging does not overstate the enforcement boundary Required outcome: - the team can state clearly which path is active: legacy proof anchoring, threshold-attested V2 strict finalization, or future cryptographic verifier CPI. Do not describe threshold attestation as cryptographic verification. ## 8. Confidential Settlement V2 Boundary Strict confidential payout execution is only mainnet-candidate when the V2 evidence path is active. - `SettlementEvidence` exists for every strict confidential payout execution - `SettlementEvidence.status == Verified` - settlement evidence binds to the DAO, proposal, payout plan, payout fields, and source-specific evidence kind - `SettlementConsumptionRecord` is created exactly once per evidence account - evidence TTL and attestor policy are reviewed - REFHE and MagicBlock trust boundaries are described as attested unless a cryptographic receipt or verifier CPI is integrated Blocking condition: - do not claim cryptographic settlement verification when the active mode is threshold-attested settlement evidence ## 9. Release Ceremony Mainnet cutover should be treated as an operational ceremony, not an ad hoc deploy. - release ceremony is reviewed - release drill evidence is current - go-live attestation is regenerated - deployment attestation is regenerated - acceptance matrix and proof package are current Canonical evidence: - `docs/mainnet-blockers.json` - `docs/mainnet-blockers.md` - `docs/release-ceremony.md` - `docs/release-drill.generated.md` - `docs/deployment-attestation.generated.json` - `docs/go-live-attestation.generated.json` - `docs/mainnet-acceptance-matrix.generated.md` - `docs/mainnet-proof-package.generated.md` ## 10. Final Decision Rule PrivateDAO is ready for mainnet cutover only when all of the following are true: - repository verification passes - `npm run verify:mainnet-blockers` passes with all external blockers explicitly tracked - authority handling is hardened - external security review is complete - real-device wallet evidence exists - RPC and monitoring operations are prepared - treasury procedures are documented and rehearsed - ZK boundary language is honest and stable - release ceremony artifacts are current If any of these remain open, the correct state is: - devnet-proven - internally hardened - reviewable - not yet cleared for mainnet cutover