wikideck/docs/card-only-production-plan.md

Card-only production readiness plan

Status: proposed readiness plan, updated 2026-10-28. This is not launch approval, security certification, or permission to expose a public node.

Product and release boundary

Wikideck's current product scope is RandomX mining, collecting cards, and direct player-to-player card transfers/trades. This release will not implement or offer a marketplace, auctions, sales, custody, XMR deposits/withdrawals, or real-money checkout. Direct card trades are signed and applied atomically by the chain; they are not paid orders.

The nearest reasonable release target is a publicly hosted, non-monetary testnet beta. It must be labeled experimental and valueless. It is not a mainnet launch, a promise of ownership permanence, an investment product, or an independently secured network. Mining consumes compute, electricity, and time; no reward rate or profitability is promised.

Mainnet or valuable-card use is a separate, higher bar. It remains NO-GO until consensus, wallet, network, capacity, deployment, and independent-review gates below have evidence and named sign-off. The mainnet candidate's launch date and approval flags do not substitute for that evidence.

Current starting point

• Mining, local encrypted wallets, collections, transfers, and atomic card-for-card trades are implemented for the experimental testnet.
• Marketplace, custody, sale-settlement, and Monero payment source, UI, APIs, deployment profiles, active tests, and operator documentation have been removed from the supported repository. Direct on-chain card transfers/trades remain core functionality.
• Existing runtime volumes and historical backup packages may contain local financial journals or external database bindings. Removing source code does not delete or resolve those records; preserve them separately and do not claim new ledger-only backups include them.
• The current network has no public bootnodes or automatic peer discovery. Peers must be configured by operators; containers on one host do not provide independent network security.
• The inherited initial proof-of-work target accepts one in sixteen hashes, and the ten-block retarget is not production-calibrated. Nodes retain the DAG in memory, rebuild state roots across the NFT set, and revalidate stored proofs at startup.
• Browser-wallet encryption is implemented, but same-origin code can abuse an unlocked wallet; old plaintext copies, cross-browser recovery, and independent wallet review remain concerns.

See the mainnet launch limitations, consensus reference, wallet limitations, and security review. Existing passing tests and local rehearsals are useful evidence, not production certification.

Ordered release gates

Gate 0 — freeze the card-only scope · implemented

• Publish the scope above in the product and operator docs. Market/custody/payment source, UI, APIs, dependencies, tests, deployment files, and operator tasks are removed from the supported repository.
• Preserve existing node and financial data during retirement. Do not remove Compose volumes, old journals, PostgreSQL schemas, or historical backups. Review/archive any existing market journal before stopping a market deployment; the card-only node will not reconcile or resolve it.
• Version the node backup contract for ledger-only backups. Refuse to create a ledger-only package if legacy financial data or a PostgreSQL custody binding remains in the selected data directory. Keep old paired backup verification/restore available as a data-preservation path; restored legacy files are inert and are not reopened by the card-only application.
• Update the production plan, operator launch checklist, security scope, support text, and release notes so they no longer imply that market, custody, or payment work is part of this release.
• Choose and document the only supported launch target: testnet beta or a separately reviewed mainnet. Do not mix the two identities or reuse testnet data/backups as mainnet state.

Exit evidence: scope owner approval is still required. Source/deployment removals are complete; API regression checks cover removed routes while preserving card trades; backup v2 and legacy-data refusal are covered; old paired backups remain portable. No active product docs promise sales or payments.

Gate 1 — independent protocol and application review

• Commission independent review of consensus serialization, signatures, state roots, fork choice, timestamp/retarget logic, peer message validation, RandomX integration/native boundary, and wallet signing/recovery.
• Test competing branches, deep reorgs, clock skew, eclipse/partition behavior, malformed traffic, mempool/resource exhaustion, and crash/restart recovery on disposable networks.
• Fix critical/high findings and add regression evidence. Publish the exact reviewed protocol manifest and residual risks; do not set review acknowledgements merely to pass startup gates.

Exit evidence: review against the exact release candidate, issue dispositions, regression tests, and named reviewer sign-off. An internal code review or test count is not independent assurance.

Gate 2 — establish a credible network

• Measure expected and adversarial hashpower on intended hardware; quantify rewrite costs and concentration risk. Choose and review initial difficulty, retarget, timestamp, and stall-recovery behavior before freezing a mainnet identity.
• Design the bootstrap and peer-operations model: independently administered nodes, supported peer discovery or a documented trusted bootstrap list, upgrade coordination, and abuse/isolation response.
• Demonstrate actual connectivity and independent mining across failure domains. Peer URL count alone is not evidence that peers are online, independent, or secure.
• State the finality/reorganization limits honestly. There is no formal finality today; a confirmation count is not an absolute guarantee.

Exit evidence: reviewed launch manifest/genesis for mainnet (or explicit testnet-only beta decision), multi-host partition/reorg/stall rehearsal, measured hashpower assumptions, and an operator-owned peer/upgrade plan.

Gate 3 — demonstrate capacity and recovery limits

• Define the expected chain length, block rate, peer count, user/API load, disk budget, memory ceiling, startup time, and latency/error objectives.
• Run repeated tests on populated long-chain fixtures and the intended hardware, with concurrent mining, peer sync, wallet/deck reads, transfers/trades, reorgs, and hostile traffic. Measure tail latency, memory, CPU, disk/WAL growth, and restart/revalidation time.
• Test clean shutdown, process crash, disk pressure, corrupted/stale state, isolated restore, and replay using the exact release binary. Do not treat /healthz alone as readiness.
• Define and test an archival, pruning, or capacity transition before resource growth can make nodes unable to sync or restart. Do not alter consensus history silently to reclaim storage.

Exit evidence: reproducible benchmark report with workload and limits, enforced resource budgets, failure/reorg results, and a successful isolated restore/replay drill.

Gate 4 — wallet, trades, and user protection

• Test create, lock, unlock, backup, restore in a fresh browser/profile, and recovery after app/browser upgrade across the supported browser matrix. Test signed transfer/trade review, stale offers, pending state, and reorg outcomes.
• Review same-origin script compromise, extensions, password entry, old plaintext-wallet migration, downloaded backup handling, and key-loss support. Decide whether production needs hardware/isolated signing; document residual risks if it does not.
• Publish experimental/no-value disclosures, mining resource risks, irreversible-transfer warnings, privacy/data-retention terms, Wikipedia text/image attribution and license handling, support contact, abuse-report path, and stop conditions.
• Select and publish an appropriate project software license before public distribution. A Wikideck license does not replace Wikipedia or dependency licenses.

Exit evidence: independent wallet review, verified recovery drill, tested trade flows, reviewed participant disclosures, public support/abuse contacts, and license decision.

Gate 5 — operate and release safely

• Prefer a managed host unless the intended self-hosted site proves ISP permission, reachable ingress/CGNAT handling, DNS/TLS renewal, trusted-proxy correctness, no direct backend exposure, firewalling, restricted administration, patching, and power/network resilience.
• Deploy independent monitoring and alert delivery for peer/tip freshness, reorgs, native miner failures, latency/queue saturation, disk/WAL growth, and service availability. Assign a real responder and incident/rollback procedure; do not imply HA or 24/7 response without it.
• Encrypt backups off-host and rehearse cold restore. Define and meet recovery point/time objectives; protect wallet recovery separately from node data. Preserve database/WAL consistency and verify restored proofs/ownership before resuming service.
• Freeze the release artifact: reviewed base-image digest, dependency/native versions, SBOM, vulnerability and native-code scans, build provenance/signature, configuration manifest, and rollback image. Re-run the complete suite and smoke test against that exact artifact.
• Run a limited, non-monetary soak and record go/no-go, known risks, release hashes, operator, reviewer, and stop criteria. Do not convert a beta into mainnet by changing an environment variable or changing the chain identity after launch.

Exit evidence: intended-host deployment test, alert drill, off-host restore result with measured RPO/RTO, signed/frozen artifacts, exact-release test report, and recorded operator/reviewer approval for the beta's limited exposure.

Release decisions

Non-monetary public beta

May be considered only after all applicable gates pass, the node remains on the explicitly labeled experimental testnet, cards are not represented as valuable, and the operator accepts the single-host or stated availability limits. This is a production-hosted beta, not production chain security.

Mainnet or valuable cards

Requires all gates plus independent consensus/economic-security review, calibrated and frozen consensus parameters, a credible independent peer/miner topology, reviewed wallet protections, sustained capacity and adversarial evidence, and explicit governance/upgrade and incident procedures. Mainnet activation is a separate authorization. Until then, retain NO-GO.

Markets and real money

Out of scope for this product plan. No market/custody/payment milestone is a prerequisite to the card-only beta. Any later decision to add sales or funds requires a new product scope, threat model, legal review, settlement/custody design, and separately approved release plan; it must not be inferred from this document.

Evidence record

For every gate, record an owner, exact release/manifest, test or rehearsal, measured result, artifact location/hash, reviewer, residual risk, and disposition. Missing evidence is unverified, not passed. A successful build, local container startup, peer count, test total, or environment flag is never launch approval by itself.