WikiDeck/wikideck
3
0
Fork 1
Code Issues 8 Pull Requests Actions Packages Projects 2 Releases Wiki Activity

Remove markets

Browse Source
This commit is contained in:
eric
2026-10-28 18:33:52 -04:00
parent eea2deb1fb
commit b3a1179703
141 changed files with 554 additions and 17365 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/operator-launch.md
+38 -56
View File
@@ -1,78 +1,60 @@
# Operator launch preparation and hold points
The [production delivery plan](production-plan.md) defines the next engineering milestones, acceptance criteria and operator decisions. Its XMR-native pricing direction supersedes earlier production USD-price plans; existing sandbox behavior and historical order terms remain unchanged until an integrated versioned migration. Trustless settlement is a research gate, and any host-custodial fallback requires explicit approval.
The [card-only production readiness plan](card-only-production-plan.md) defines the product scope and release gates. The supported product is mining, collecting, and direct card-for-card trades. Market, custody, and payment source has been removed. **Current decision: HOLD / NO-GO for mainnet, valuable assets, or public exposure until the relevant evidence below is reviewed.**
**Current decision: HOLD / NO-GO for mainnet, valuable assets, or payments.** The production plan now distinguishes a proposed non-monetary testnet beta hosted from the operator's apartment. That beta would not be mainnet production or permission to custody funds. Review [the security findings](security-review.md) before any public exposure. The automated preflight intentionally exits nonzero for mainnet while required blockers remain. An environment variable, successful container startup or genesis timestamp cannot substitute for closing findings.
A successful build, local container startup, peer URL count, genesis timestamp, or configured approval flag is not production evidence. The read-only launch preflight reports local blockers; it is not an independent audit or approval.
[Stage-1 node resource controls and local load tooling](node-resources.md) are implemented. This is partial remediation, not capacity certification or closure of the public-node hold point.
## Safe inspection
[Stage-2 encrypted wallet storage/lifecycle](wallet-security.md) is implemented. Require explicit legacy migration, verified portable recovery, closure of old tabs and review of residual unlocked-page risks before considering the production wallet hold point satisfied. Local implementation/tests are not independent sign-off.
Use Node.js 24 and a clean, reviewed checkout. For mainnet assessment, select `WIKIDECK_NETWORK=mainnet` and run `launch:preflight`. Use `--network-manifest` for chain identity inspection. These commands do not start a node, create a ledger, start RandomX, or contact peers.
## 1. Safe inspection — does not launch anything
Mainnet startup is gated by a chain-specific approval, a review acknowledgement, the candidate genesis time, HTTPS origin, and multiple configured HTTPS peers. These are accident-prevention checks only; they do not prove that review occurred, peers are online/independent, or a network is secure. Keep deployment and release permissions restricted.
Use Node.js 24 and a clean reviewed checkout. For mainnet assessment on a host, select `WIKIDECK_NETWORK=mainnet` in the process environment, then run the `launch:preflight` package script. It runs the node entry point with `--launch-preflight`, prints JSON and exits. `--network-manifest` remains available for identity inspection only.
## Evidence required before a public non-monetary testnet beta
The preflight:
A beta is not mainnet production, valuable-asset use, or a claim of independent network security. Keep testnet explicitly selected, cards valueless, and the deployment described as experimental. Before public exposure:
- Selects the pinned profile and reports network, chain/genesis, fixed fee policy and local gate status.
- Does **not** open/create a ledger or wallet, start a RandomX engine/listener, contact peers or external payment services, or write approval settings.
- Does not print environment values or payment credentials. Reports are still operational information; review them before publishing.
- Lists code blockers and missing external evidence. `productionReady` remains false even if startup approval variables are supplied. Fixes and independently reviewed evidence must be reflected in a future reviewed release; do not turn the report green by deleting findings.
- Freeze the card-only scope, testnet identity, known risks, privacy and data-retention terms, user support/contact, abuse-report path, and stop conditions.
- Prefer managed hosting unless the intended host proves ISP permission/reachability, TLS renewal, trusted-proxy correctness, no direct backend exposure, firewall and admin controls, patching, and power/network resilience.
- Run repeated load, mining, peer-sync, reorganization, crash/restart, and restore tests on the exact release candidate and intended hardware. Set measurable latency, error, memory, CPU, disk, and recovery limits.
- Review wallet migration, lock/unlock, signing, backup, and fresh-profile recovery. Explain same-origin compromise and irreversible-transfer risks.
- Deploy external monitoring and verify alert delivery for peer/tip freshness, reorgs, native failures, overload, disk growth, and service availability. Name a responder and test incident/rollback procedures.
- Encrypt backups off-host and rehearse a cold restore/replay. Define recovery objectives and keep wallet backups separate from node backups.
- Freeze image/dependency/native versions, generate an SBOM, scan the final artifacts, and record exact release hashes and a beta go/no-go. Publish a project license before public distribution.
The runtime image can execute the entry point with `--launch-preflight` as well; it does not include the package-script dev runner or need `tsx`. A Docker `test` target is provided for Node 24 build/test validation with Linux-native RandomX. No production launch command is supplied here while the decision is NO-GO.
If these conditions cannot be verified on a self-hosted site, do not expose it publicly; use a managed host or remain local-only.
**Important:** the report is an assessment, not an additional enforcement layer. Existing startup approval checks are still accident-prevention gates; an operator editing source or setting all approvals can bypass the intended process. Keep release/deployment permissions restricted.
## Mainnet and valuable-card blockers
## 2. Evidence register — all required before production sign-off
Mainnet or valuable-card use requires the beta evidence plus independent protocol/application review, measured and reviewed consensus parameters, adversarial multi-host partition/reorg/hashpower testing, a credible bootstrap and independent-peer/miner plan, production capacity evidence, and explicit governance/upgrade and incident procedures. The current initial target is deliberately easy and the retarget is not production-calibrated. Nodes retain the DAG in memory and replay proofs at startup. There is no formal finality or automatic peer discovery. Keep mainnet **NO-GO** until these gaps are independently reviewed and signed off.
For the proposed **non-monetary testnet beta only**, use a separate scoped decision: the chain/network is explicitly testnet, no valuable cards are offered, real payment/custody settings remain off, mock market delivery is disabled or the deployment is demonstrably valueless, and experimental wallet/data-loss limitations are disclosed. This does not close any mainnet/live-payment hold point below. Apartment-hosting evidence must include ISP/CGNAT/reachability, TLS/proxy/backend isolation, firewall/admin/patch controls, off-host encrypted backup and restore, and external alert delivery. If these cannot be verified, do not expose the apartment host publicly; choose a managed host.
## Hold-point register
The real-money path is still not end-to-end. Mainnet can now be configured for operator-reviewed deposit staging/release and signed customer withdrawal reservations, but those paths remain opt-in and there is no external treasury signer, relay, outgoing transaction confirmation/reorg reconciliation, customer UI or complete recovery procedure. Do not provide addresses or accept funds until a customer can actually withdraw and that send is reconciled against the chain.
[Stage-4 deployment and recovery tooling](operations-recovery.md) adds explicit proxy trust, private loopback diagnostics/checks and stopped-node pair backup/verification/non-overwriting restore. A local native proof-replay restore drill is automated, but actual-host TLS/proxy verification, off-host recovery, alert delivery and operational ownership still require external evidence.
[Stage-3 consensus calibration evidence](consensus-calibration.md) contains a bounded local native measurement and deterministic timestamp/retarget scenarios. It is not the missing representative network-hashpower or independent consensus review evidence. Do not populate launch approvals from its illustrative targets.
For each item record **owner, artifact/release ID, date, evidence location, reviewer and disposition**. Empty means unverified, not passed.
Record owner, exact release/manifest, evidence location and hash, test/rehearsal, reviewer, residual risk, and disposition. Empty or unverified means **not passed**.
| Hold point | Required evidence | Current status |
| --- | --- | --- |
| Independent protocol/application review | Report against the exact release; critical/high findings fixed and retested; reviewed accepted residual risks | Missing |
| Consensus launch design | Final genesis and manifest; measured starting target/hashpower; reviewed timestamp/retarget/partition/reorg attack analysis | Missing |
| Node availability | Bounded public APIs/client; global resource/admission controls; realistic long-chain and hostile traffic capacity report | Missing |
| Production wallet | At-rest/unlock/signing policy, same-origin compromise analysis, user confirmation and offline recovery drill | Missing |
| Real-money market, if offered | Direct wallet deposit observation and exact liability crediting, customer-authorized withdrawals, isolated treasury signing/relay, outgoing-chain reconciliation, custody policy, refund/reorg dispute controls | Partial reservation and reviewed-credit code only; no XMR send; keep real payments blocked |
| Mock-market policy | Ensure public users cannot mistake buyer-triggered mock payment for money; disable sandbox selling/delivery for valuable mainnet cards unless explicitly confined to a valueless trial | Unresolved |
| Peer/miner topology | Multiple independently administered hosts/operators/failure domains; actual online matching manifests and sufficient independent hashpower, not just two URL strings | Unverified |
| Edge and host security | TLS/certificate renewal, firewall, loopback backend, reviewed proxy IP trust, connection/global limits, restricted administration, patched hosts, time synchronization | Unverified |
| Monitoring/on-call | Alert routes and successful drills for node isolation/tip lag, native failure, deep reorgs, WAL/disk exhaustion, queue/latency saturation and market review states | Unverified |
| Restore/reconciliation | Consistent ledger + market SQLite/WAL backup and clean restore/revalidation; original market identity and idempotency history preserved; offline wallet recovery verified | Unverified |
| Release supply chain | Lockfile, reviewed base/native/toolchain versions, runtime image digest, SBOM/advisory/native/container scans, signed provenance and restricted release access | Partial: npm advisory queries and local tests only |
| Incident/governance | Named decision owners, market stop/containment procedure, fork/upgrade policy, communications, rollback criteria; custody/legal review if real money | Missing |
| Independent protocol/application review | Review against the exact release; critical/high findings fixed and retested | Missing |
| Consensus launch design | Final manifest; measured starting target/hashpower; timestamp, retarget, partition, and reorg analysis | Missing |
| Node availability | Realistic long-chain and hostile-traffic capacity report with explicit limits | Missing |
| Production wallet | Same-origin threat model, user confirmation, supported-browser lifecycle and offline recovery drill | Unverified |
| Peer/miner topology | Independently administered hosts/failure domains, verified online peers, and sufficient independent hashpower | Unverified |
| Edge and host security | TLS/certificate renewal, firewall, backend isolation, proxy trust, patching and restricted admin | Unverified |
| Monitoring/on-call | External alert routes and successful drills for isolation, reorg, native failure, overload and disk pressure | Unverified |
| Restore/reconciliation | Encrypted off-host ledger backup, isolated restore and proof replay; separate wallet recovery | Unverified |
| Release supply chain | Frozen image digest, SBOM, dependency/native/container scans, provenance, and restricted release access | Partial; repeat for final artifact |
| Incident/governance | Named decision owners, upgrade/fork policy, communications, rollback and stop criteria | Missing |
## 3. Freeze and rehearse before authorization
## Freeze and authorize
1. Close the security-review blockers in a separate reviewed release. Do not change consensus rules/difficulty under an existing launched chain ID. Prelaunch changes must generate a new pinned manifest and approval target where applicable.
2. Freeze the actual UTC genesis date. **2027-01-01 is a candidate placeholder, not an announced launch.** On the review date (2026-10-20), that time gate is not satisfied.
3. Freeze the exact image digest and review artifact hashes, network manifest, selected build/runtime profile, fee policy and intended public origins/peers. Confirm testnet data/backups are not reused.
4. Rehearse on isolated, disposable nonvaluable networks with the reviewed rules: initial synchronization, competing miners, partitions/reconnects, invalid traffic, restart after crash, disk pressure and full restore. Never delete production data or lower confirmations to make a rehearsal pass.
5. Verify the **intended production hosts**: DNS/TLS, proxy forwarded-IP handling, no direct backend access, matching chain IDs, data permissions, disk/memory/CPU capacity and observable peer freshness. `/healthz` alone is not acceptance evidence.
6. Confirm fee address control out of band, without requesting or transmitting any seed/private key. Checksum validation alone does not prove control. No live test payment is authorized by this document.
1. Fix critical findings in a separately reviewed release; do not change consensus rules under a launched chain ID.
2. Freeze the reviewed genesis/manifest, exact build/runtime profile, image digest, peer origins, and artifact hashes.
3. Rehearse initial sync, independent mining, partitions/reconnects, invalid traffic, disk pressure, restart, and isolated full restore. Do not delete production data or weaken rules to pass a drill.
4. Verify DNS/TLS, proxy forwarded-IP handling, no direct backend access, permissions, resource capacity, and monitoring on intended hosts. `/healthz` is liveness only.
5. Record a go/no-go with operator/reviewer names, evidence, known residual risks, change window, recovery objectives, and stop conditions in the controlled operations system.
## 4. Explicit operator go/no-go meeting
Do not set review acknowledgements merely to bypass gates. This internal code work is not the independent review required for launch.
Record the final release digest, immutable manifest, all hold-point dispositions, change window, operator/reviewer names, monitoring/on-call contacts, recovery point/RTO, stop conditions and signatures/approvals in your controlled operations system.
## Stop conditions
Only after independent evidence has been reviewed should the authorized operator intentionally supply the existing chain-specific startup approval and review attestation. **This internal coding review is not the independent review referenced by that attestation.** Do not put private keys, seed phrases, payout credentials or backup passwords in the approval record, source tree or browser environment.
The launch preflight must not be repurposed to auto-populate approvals. No approval variables have been written by this work. Payments remain mocked even if network startup is later authorized; changing that requires a separately reviewed live-settlement release and explicit payment activation process.
## 5. Stop conditions and containment
- Halt new marketplace activity and investigate if invoice identity/amounts disagree, delivery is ambiguous, a settled order enters review, or payout status is unknown. Do not replay an ambiguous payout or automatically clear payout markers.
- Treat deep reorgs, isolation, divergent manifests, sustained queue/latency overload, disk/WAL exhaustion, native-engine failure, key compromise or loss of monitoring as incidents. Stop accepting new risk using the approved containment procedure.
- Stopping a node does not undo confirmed transactions or cancel previously signed transfers. Do not promise financial rollback from a software rollback.
- Preserve logs and consistent backups. Never delete the ledger/market database, shorten history or change genesis to get a node to start. Remove a stale lock only after verifying that its process is stopped and completing the documented recovery review.
- Resolve conflicting chains by the reviewed consensus/incident policy; do not silently install an ad hoc checkpoint or restore stale payment state against a newer chain.
After a controlled launch, observe the agreed soak period and obtain a second operational acceptance before expanding exposure. Real payments must not be part of a mock-market soak.
Treat deep reorgs, isolation, divergent manifests, sustained overload, disk exhaustion, native-engine failure, key compromise, or loss of monitoring as incidents. Stop accepting new exposure using the approved procedure. Stopping a node does not undo confirmed transactions. Preserve logs and backups; never delete the ledger, shorten history, or change genesis to get a node to start. Remove a stale lock only after verifying all owning processes have exited. Resolve chain conflicts under a reviewed incident policy, not with an ad hoc checkpoint or stale restore.