wikideck/docs/production-plan.md

Production delivery plan

Status: active engineering plan; not launch or payment authorization. Updated 2026-10-20. The objective is a production service with explicit guarantees, measurable limits and accountable operations—not relabeling the existing testnet. Existing implementations are reusable groundwork; findings are closed only by reviewed implementation and evidence.

1. Decisions agreed with the operator

Topic	Decision / boundary
Initial deployment	One operator, the project owner, in the United States; a capable x86 server and low initial user volume. Design for independently operated markets and larger volumes, without claiming capacity before measurement.
Settlement architecture	Trustless and arbitrated routes were investigated; the operator has now authorized implementing the custodial pooled-balance market. ADR 002 tracks the first isolated sandbox accounting/UI increment and remaining treasury/consensus work. Implementation authorization is not live deposit, key access, consensus activation or launch authorization.
Host responsibility	Host responsibility, reserves and exposure caps are the selected policy direction. Exact liability, amounts and funding remain undecided. This is not authorization for custody and does not make settlement trustless or guarantee solvency. The author fee does not make the author a guarantor of independent markets.
First live market	Fixed-price sales first. Live auctions remain disabled until their funding, nonpayment and abuse controls pass a separate release gate. Existing sandbox auctions can remain clearly labeled.
Pricing	Native XMR prices, replacing the earlier USD-price decision. No economic listing minimum. Represent nonzero prices as integer atomic units: the smallest representable positive XMR amount is 10^-12 XMR, not an imposed USD/XMR minimum. Zero-price gifts should use free transfers unless separately designed.
Sending/network fees	Earlier model: buyer pays sending fee, seller pays disclosed per-sale disbursement costs. Custodial proposal: no per-purchase Monero transfer; depositor pays external sending, withdrawing beneficiary pays approved actual withdrawal fee, operator pays treasury movements. Author-fee withdrawal costs and overruns require explicit policy approval. No fee change is implemented.
Uneconomic small sales	No economic listing minimum. Custodial proposal allows tiny internal settlements and explicitly disclosed backed balance accumulation; withdrawal economics are separate. This changes the earlier per-sale payout-budget model and requires approval under ADR 002. Never silently discard a tiny liability or subsidize a fee.
Payment before sale finalization	A paid sale must not complete or be included as a completed ownership sale on Wikideck until the agreed XMR payment has satisfied its confirmation/unlock policy. Payment notification/mempool presence is insufficient.
Existing boundaries	No real processor access, credentials, invoices, transfers, genesis change, destructive migration or launch approval is authorized by this plan. Software licensing still requires an operator choice and publication.

Production settlement remains disabled. The public sandbox now prices new v3 listings/orders in native XMR atomic units, with mock-only confirmations, fees, refunds and payouts; legacy v2 USD records retain their original terms. The disconnected SHKeeper harness still models USD invoice requests and is not wired to v3. No real XMR invoice, payable address, conversion, transfer or settlement was enabled. Existing records are not silently reinterpreted as XMR.

Current design deliverable: custodial market design. Read the workstreams below with this update: pooled customer liabilities replace per-order incoming invoices and external sale payouts in the proposed architecture. Earlier trustless-first research gates are historical, not a prerequisite to investigating custody. Exact ledger, withdrawal, fee, custody/legal and host-attested NFT consensus rules still require approval and evidence; the existing mock domain cannot authorize real balance debits.

2. Resolve the cross-chain requirement before selecting architecture

What “confirmed before on-chain completion” requires

RandomX verifies work on Wikideck; it proves nothing about an XMR transfer. Monero privacy also means a Wikideck validator cannot infer recipient/amount/payment validity from a transaction ID alone. A processor's status is a trusted attestation, not a trustless cross-chain proof. Naively calling SHKeeper or a mutable Monero RPC from block validation would make consensus depend on credentials, service availability and potentially different observations; do not implement that.

The design must specify what every validator can verify deterministically, which Monero chain/confirmation evidence is used, how its recipient/amount/order binding is established, what private information or keys must be disclosed, and how both chains' reorganizations are handled. Any relayer, committee, market operator, oracle or custodian introduces a named trust assumption. “Non-custodial,” “atomic,” and “trustless” are distinct claims and must be justified separately.

Mining one new card per roughly 15 minutes is independent of Monero's block schedule, but today's transfers are included in the same Wikideck blocks. Therefore XMR confirmation, Wikideck inclusion, Wikideck confirmation depth and any final XMR disbursement/unlock are separate timing milestones. Fast end-to-end settlement or a separate transaction-finality layer would need a reviewed consensus design, not just a faster payment poll. The operator has specified ordering, not yet approved changing Wikideck's block schedule.

Pre-payment lock/reservation transactions might be needed to prevent double-selling. They must not transfer completed-sale ownership, and they would appear on-chain before XMR payment. The operator approved preparatory locks/reservations for design research on 2026-10-20. This does not approve an escrow authority, custody model, expiry policy or consensus implementation.

P0 — architecture research and decision record (first critical path)

Deliverables:

1. A threat model: dishonest buyer/seller/host/miner/relayer, compromised keys, eclipse/partition, one-chain stall/reorg, late payment, stale signature, disputed quote and processor partial-send/timeout.
2. A comparison of (a) feasible researched XMR-compatible atomic/adaptor-signature or other non-custodial approaches, (b) deterministic verification/light-client or attestation approaches, and (c) host-custodial settlement with consensus-enforced NFT locks as a fallback. Research compatibility with this chain's P-256 signatures and Monero's transaction model; do not assume a Bitcoin-style HTLC works for Monero or that an existing swap library supports arbitrary NFTs.
3. Exact protocol messages/state transitions, release/refund ordering, timeouts, fee-collection enforcement, replay/domain separation, key-loss recovery and what happens if either party stops cooperating. Identify whether selling can bypass host/author commissions and what can realistically be enforced by a modifiable independent peer.
4. Primary-source/release evidence, maintained dependency/license assessment, feasibility spike using disposable fixtures, attack/failure tests and independent cryptographic review requirements. An unevaluated paper or toy demonstration is not production feasibility.
5. A recommendation with explicit guarantees, trust assumptions, costs, latency and unresolved risks. If trustless settlement is infeasible in scope, present a fallback decision for the operator; keep live sales blocked until approval.

Acceptance: operator approves an architecture decision record (ADR), with external review where required. No live adapter/consensus release is connected merely because the research finishes. Discovery of an impractical design is a valid outcome, not a reason to hide trust assumptions.

3. Workstreams, dependencies and acceptance criteria

P1 — native-XMR domain model and migration

Can begin independently of P0, but must not hardwire a settlement architecture.

• Define canonical decimal input/output backed by integer atomic units, bounded values/precision, exact comparisons and independent commission rounding. No float-based amounts or implicit USD conversion. Optional fiat display, if added, is informational and never settlement authority.
• Replace USD listing/bid/checkout fields and UI with versioned XMR-native terms. Sign currency, gross, commissions, destinations, fee policy/estimate limits, expiry, order/market/network identity and selected settlement protocol version. Update invoice/checkout review and participant disclosures.
• Migration plan: preserve existing USD/mock order history in its original version. Close/relist old open listings with fresh seller authorization; define disposition of bids/reservations before migration. No automated reinterpretation, deletion or mainnet asset migration.
• Resolve SHKeeper's documented USD-denominated invoice input. Verify whether a supported deployed version offers exact native-XMR invoices and stable amounts; otherwise research direct Monero wallet-RPC/payment infrastructure or a reviewed adapter. Do not reintroduce an approximate USD conversion behind XMR-native pricing. SHKeeper is the preferred processor where compatible, not a justification to violate exact-price requirements.
• Separate payment-sending fees, hosting/author commissions and payout network fees in quotes/accounting. Define who pays author-leg network costs and fee-overrun caps. Handle sub-atomic commissions without overcharging. Preserve the fixed 1% address/rate in the distributed policy.
• Checkout preflight determines economic viability under the selected architecture before accepting an order. For the custodial proposal, internal sales have no per-sale Monero payout cost; deposit eligibility, available balance and withdrawal economics are separate checks. Accumulated balances are proposed in ADR 002 but not implemented/approved for funds; batching remains deferred. Disclose uneconomic withdrawals before deposit rather than silently forfeiting balances.

Acceptance: exact-amount property/boundary tests, versioned signature tests, zero/tiny/large-price and fee-spike tests; migration dry run/rollback on copied data; all displayed totals reconcile; no USD-authoritative live path; user review of fee semantics. No live payments yet.

P2 — production-scale state and transaction infrastructure

Can run alongside P0/P1. Addresses SEC-01/SEC-06 rather than adding more fixed caps.

Implemented M2 increment, 2026-10-20: canonical indexes and durable market observation. Canonical ownership/transaction SQL indexes now serve NFT, deck, custody availability and mock-market queries; per-block undo and anchored connect/disconnect events commit with ledger updates. Market checkpoint/reorg holds persist atomically and bounded catch-up blocks new mutations. Final TypeScript/Vite build and 149 offline tests passed. A disposable 10,000-NFT SQL baseline is recorded, not a target-hardware SLO or complete M2 acceptance. Production financial storage, incremental order scheduling, retained-DAG capacity and operator dataset/latency targets remain open.

Next financial-storage increment: ADR 003 — PostgreSQL selects and integrates the custody SQL backend with existing HTTP callers, exact constrained accounting, explicit migration/runtime roles, source-freezing SQLite import and dump/restore rehearsal. The adapter remains on the fictitious sandbox domain; it is not a production deposit/withdrawal worker. SQLite node-only backup deliberately refuses PostgreSQL-bound financial state. Production hardware/SLO tests, coordinated backup/PITR/failover, real payment schema/worker controls and independent review remain open, so this does not close M2/M4 or authorize funds.

Financial reconciliation increment: business-liability checks now tie each order/withdrawal to its exact reservation, journal lifecycle and pending work, including reverse orphan/duplicate checks. PostgreSQL startup/import/explicit/periodic audits and targeted mutations use these checks; redacted durable incident holds fence new postings, while private reads and original receipt replay remain available. Private operations reports audit freshness/holds, and schema-owner incident acknowledgement requires a successful locked full audit plus evidence reference. No automatic repair, real payment, schema reset or consensus activation is enabled. Production capacity, coordinated recovery and external review remain open.

Deployment increment: persistent local custody stack now starts PostgreSQL and the actual app together, with private TLS/SCRAM networking, separate owner/runtime roles, explicit migrations and scoped persistent credential/data volumes. A signed fictitious credit and custodian identity survived container/network removal and recreation; the server rejected plaintext authentication. Existing deployments and SQLite custody were not switched. Production certificate rotation, coordinated backup/restore and external operating review remain open; all XMR remains simulated.

• Indexed canonical ownership, NFT/transfer lookup and paged wallet/explorer APIs: browser signing must not require loading all history. Tip-pinned queries detect reorgs and preserve complete ownership semantics.
• Incremental market reconciliation from durable canonical/reorg events. Maintain rollback-safe indexes and a recoverable cursor; catch-up after restart must not miss delivery or payout holds. Bound worker time/concurrency; move expensive work off the request event loop where appropriate.
• A versioned production market/settlement schema with append-only financial events and balanced accounting entries for buyer liabilities, host revenue, author liabilities, seller liabilities, paid/refunded amounts and actual network fees. Derived views are rebuildable; financial history and idempotency keys are not discarded to reclaim space.
• Durable inbox/outbox, processor attempts and reconciliation states; no network operation inside a long DB transaction. Store intent before external side effects; unknown POST outcomes stay quarantined until evidenced resolution. Per-market isolation, actor-scoped paged reads, queue/backpressure and tenant/global exposure budgets.
• Database architecture ADR: retain a measured single-writer SQLite deployment if it meets declared limits, or choose a production DB/worker topology and supported migration. Do not claim horizontal safety merely by launching multiple workers against local state. Start with one authoritative writer per market.
• Ledger/DAG storage and startup-replay capacity plan: disk usage budgets, archival/reindex strategy, fork handling, retention rules that do not silently alter consensus or lose recovery evidence.

Acceptance: indexed-vs-full-replay differential tests; adversarial reorg/crash/cursor tests; invariant/property tests for accounting; benchmark populated long-chain/journal fixtures at a declared target dataset and SLO; overload preserves validation/health capacity; explicit supported storage/node/operator envelope. Target numbers must be selected from measurements, not invented here.

P3 — implement the approved exchange protocol

Blocked on P0 ADR; use P1 amount types and P2 durable events. Consensus work is a separately reviewed change.

Candidate increment, 2026-10-20: ADR 004 — sale locks now specifies and implements an offline deterministic signed lock/completion/cancel/expiry model, exact height boundaries, native transfer/trade lock guards, replay-resistant sequences, state commitments and a non-posting financial observation policy. A pure bridge checks terms drafted from actual sandbox reservations. Final build and 162 offline tests passed. Active v6 consensus still rejects the candidate and no host signer or balance-posting integration is enabled. Independent review, policy approval, versioned network activation, actual PoW/peer/index integration and PostgreSQL terminal workflow remain open; M3 is not accepted.

Accounting rehearsal increment, 2026-10-20: signed candidate → PostgreSQL reservation resolution now exercises actual restricted-role SQL terminal postings from bounded synthetic transcripts, behind explicit disposable database/instance guards and without an HTTP route. Exact terms/hosting recipients and reservation commitments are checked; mature completion credits seller/fees once, cancellation/non-admission releases buyer funds, and conflicting post-settlement evidence durably holds mutations rather than repaying. Insert-only first/terminal evidence is audited. Final build, 172 offline tests and 22 PostgreSQL integration tests passed. This supersedes the earlier absence of any balance-posting test integration, not the production/activation boundary: caller-supplied seeds/blocks are not canonical evidence, intermediate unseen disconnects cannot be detected, and no signer, canonical inbox, live deposit/withdrawal or current-chain paid sale is enabled. M3 remains open.

Canonical/per-order reorg rehearsal increment, 2026-10-20: the gated disposable PostgreSQL observer stores bounded pages from an in-process Ledger adapter, checks stream/anchor/hash/tip/ancestor continuity, supports retries, and audits retained history. A local-ledger test using fake PoW covers an excluded equal-work branch and reorg. A separate synthetic-event test links the deterministic candidate terminal transaction ID to its posted order; disconnecting that ID (even followed by same-page re-inclusion) commits the event history and durable order review hold atomically, without undoing or repeating the payout. Generic incident resolution cannot clear a sale-reorg record. Final build and 28 PostgreSQL tests pass; offline regressions remain 172. The worker is not scheduled, active v6 cannot emit candidate IDs, and synthetic linkage is not canonical sale evidence. Stream hashes are not tamper-proof against the schema owner; 4,096-event cap/full scan are non-production. M3 remains blocked on reviewed candidate activation, actual candidate IDs from a production local ledger, observer/checkpoint design and production readiness.

• If a reviewed trustless design is selected: implement its actual cross-chain validity/evidence rules, compatible cryptographic primitives, both-party failure/refund paths and commission semantics. Run maintained reference vectors, negative tests, fuzz/property tests and specialist audit before claiming atomicity.
• If a custodial/attested fallback is explicitly approved: define chain-enforced NFT lock, order identity, authorized releaser, cancellation/refund/expiry and stale-signature rules. Separate host control keys from seller wallet and processor payout keys. Reserve/refund procedures must not permit both buyer refund and later seller delivery/release. Describe who can steal, censor or lock assets and how recovery is authorized.
• Completed-sale inclusion must require the approved evidence that payment is sufficiently confirmed. A peer must not insert a completed sale merely because its local database says paid. Define threshold/policy version, proof/attestation authorization and deterministic validation; no external HTTP calls in consensus validation.
• Define lock/release race outcomes, multi-market double-listing, expiry at exact heights/times, unavailability of the host/parties, reorg on either network, network upgrades and replay across canceled/relisted orders.
• If protocol data/rules change, use a reviewed new network/manifest/version and migration strategy. Do not change existing testnet/production rules under the old identity. Existing free transfers/card trades must not accidentally inherit false payment-proof claims.

Acceptance: safety/liveness matrix covers every state transition and adversary; impossibility/trust limitations disclosed; reference-engine multi-host partition/stall/reorg and recovery tests; explicit protocol freeze and independent review. Delayed inclusion is displayed honestly—no “Monero-speed finality” claim.

P4 — production payment integration, reconciliation and controls

Depends on selected P0 model; may not require SHKeeper if incompatible with the approved native-XMR/trustless design.

• Approved exact-XMR processor contract and private infrastructure: credential scoping/rotation, secrets-file/manager loading, restricted fixed-origin TLS/DNS/egress transport, bounded responses/deadlines, no redirects and no sensitive logs. API keys never enter browser/build variables.
• Actual Monero payment confirmation policy: canonical transaction identity, amount/destination/order binding, incoming/outgoing and locked/unlocked/spendable states. Determine whether processor status is adequate or wallet/daemon evidence is required. “Fully confirmed” must have a defined numerical/policy meaning; no finite count eliminates reorg risk.
• Invoice requests are immutable by version and replay-safe. Late, partial, duplicate, overpaid, expired and unattributed incoming payments get defined liabilities/reconciliation outcomes, not disappearance or unconditional refunds. Callbacks, if supported, are bounded hints; re-read authoritative state.
• Outbound seller/author/refund attempts use unique durable allocations and task IDs. Reconcile exact amounts/destinations/transaction IDs; preserve successful legs during partial failure. No blind resubmission after timeout/crash and no manual DB editing to reset an attempt. Use independent approvals and audited reason/evidence for resolution; exact rules depend on protocol/custody decision.
• Embed all authoritative payment state into the production backup/restore schema, monitoring and retention policy. Test processor external history against restored journals before resuming work; local restore cannot undo an XMR transfer.
• Per-order/daily/total unsettled and hot-wallet exposure caps, immediate disable-new-checkout controls and bounded existing-obligation handling. Stopping new orders is not permission to abandon customer funds. Credentials and signing capabilities have separated roles where possible.

Acceptance: full end-to-end staging against the verified supported processor/network, unauthorized-action tests, injected partial sends/outages/timeout/crash/reorg tests, actual-fund reconciliation procedure and reviewed secret-access controls. Any processor access, credentials or fund movement requires a separate explicit authorized test scope, budgets and network selection. This plan authorizes none.

P5 — buyer/seller policy, disputes and abuse

Policy is a product deliverable, not a footer disclaimer; implementation and legal review must match it.

• Publish host responsibility, contact/support channel, response targets, eligibility/evidence and who decides a dispute. Reserves and caps must be funded and enforceable operationally before they are advertised. No unqualified loss insurance or guaranteed reimbursement without a real funded obligation.
• Define ownership/delivery acceptance, payout hold, cancel/refund/release states and which party bears fees/reorg/processor/key-loss errors. Prevent double compensation. An expired invoice does not erase a legitimate incoming payment.
• Host and author fees remain separately visible. Decide revenue recognition on settled sales versus refunds and who bears sending costs if seller payout succeeded but author payout failed. The author's fee does not imply author arbitration or host underwriting.
• US operator engages qualified counsel for applicable custody/money-transmission, sanctions, consumer, privacy and tax obligations before accepting real funds. Applicability is not decided by the software author/assistant or by calling the product “decentralized.” Do not assume identity collection is required or unnecessary without that review.
• Anti-abuse for fixed-price launch: short bounded reservations, address/account/request limits, deposit or admission policy only if approved, fee-aware dust handling, suspicious-activity and order-churn controls. Consider Sybil attacks; one wallet is not one person.
• Auctions later: dedicated decision on funded bids/deposits, outbid refunds, nonpayment/shill/bid-sniping policy and privacy, with accounting and dispute tests before enabling live auctions. Avoid forcing a large custodial balance system just to ship auctions.

Acceptance: executable policy-to-state-machine tests, published versioned participant terms, working support/incident routing, operator sign-off on costs/loss allocations, required legal review. No fabricated SLA/support address or unfunded reserve claim.

P6 — release, wallet, deployment and independent review

Run throughout development; final release gates depend on P2–P5.

• Complete wallet review: same-origin threat model, migration/lock/unlock and recovery across supported browsers, signing review/session invalidation and stale handles; decide isolated/hardware signing support. Close old plaintext copies as a user migration/risk procedure, not a secure-erasure claim.
• Real host/edge verification: HTTPS/cert renewal, forwarded-header trust, firewall, admin access, secrets, egress, CPU/RAM/disk/WAL budgets, time sync, on-call alerts and monitoring of actual peer/tip and payment-worker progress.
• Deployment clarification: production target is behind a firewall in Kubernetes. Database certificate issuance/renewal belongs to the database/cluster infrastructure, not a bespoke application service. Verified PostgreSQL TLS remains the default; explicit infrastructure-managed transport is available only with acknowledged externally enforced encryption/peer authentication. A firewall/NetworkPolicy alone is insufficient evidence. Local Docker TLS provisioning remains sandbox-specific; no certificate-rotation feature is being activated.
• Backups/restore with complete financial journals and off-host encrypted copies: measured RPO/RTO and successful cold restore/reconciliation; test losses of host, journal, wallet key and processor reachability. Recovery of customer keys and recovery of merchant funds are different responsibilities.
• Repeat consensus/hashpower studies on intended miner/validator hardware. Quantify production attack and recovery costs; finalize difficulty/retarget/actual genesis after review. One powerful operator server is not multiple independent validators/miners or Monero-level security.
• Pin release artifacts/dependencies/base images, SBOM, secret/dependency/container/native scans, fuzz/sanitizer runs, reproducible/provenance evidence and signed artifacts. Publish the selected project license and respect dependency/Wikipedia licensing.
• External consensus/application/cryptography review against the exact release; close critical/high findings with regression evidence. This coding session is not independent certification. Provide a versioned technical and participant-facing disclosure set describing real guarantees, not stale mock behavior.

Acceptance: signed release evidence packet; recorded unresolved accepted risks with owners, limits and expiry; named operator/reviewer go/no-go. Runtime preflight reflects verified evidence rather than blindly trusting a boolean operator attestation.

4. Delivery order and parallel work

Milestone	Deliverable	Dependency / decision gate
M0	Threat model + trustless feasibility ADR + preparatory-lock decision	First critical-path design work; fallback requires operator approval
M1	Exact XMR types, versioned signed terms, migration dry-run, fee-viability specification	Can start during research; no production processor assumptions
M2	Canonical indexes/paged wallet, incremental workers, production accounting schema	Parallel infrastructure; measured dataset/SLO envelope required
M3	Approved chain exchange protocol and deterministic payment evidence	M0 + M1; reviewed consensus/version/identity decision
M4	Integrated payment/staging workflow, operator reconciliation and full backup coverage	M2 + M3 + verified native-XMR processor capability
M5	Fixed-price policy/abuse/fee/custody acceptance and external review	M4; US legal/risk decisions; funded caps/reserves if applicable
M6	Multi-host rehearsal, release artifact evidence, explicit launch meeting	All required findings/evidence resolved; network and payments separately approved
Later	Live auctions, broader independent-host rollout, higher exposure	Separate scope/capacity/abuse gates; not automatic launch follow-ons

First implementation increment: write the M0 threat model/ADR research questions and P1 XMR domain specification, then build exact amount/property tests. Do not spend the next increment adding another disconnected “live” scaffold. Each milestone must integrate with its actual callers, persistence, recovery, UI and failure tests before being described as delivered.

Current increment status: the operator selected custodial implementation after settlement research. M1 has a signed v3 XMR-native mock path, with historical v2 USD orders preserved. ADR 002 records the implemented isolated custody accounting/UI foundation; production custody is not complete. The next M2 infrastructure increment is canonical indexing and durable reconciliation, now built and regression-tested. Next engineering gates include the remaining production accounting/worker envelope and the separately reviewed NFT lock/completion/cancellation specification (M3); no live Monero integration or consensus activation is authorized by passing these tests. Migration dry-run, final fee/risk policy, capacity SLOs and independent review remain open.

5. Acceptance evidence and release discipline

For each requirement record: identifier, owner, ADR/policy version, code/schema version, tests and adversarial cases, measured limits, reviewed artifact hash, known residual risk and approving party. A test count alone is insufficient. Historical 122-suite/targeted-doc test results remain useful regression evidence, not proof of current production readiness; rerun against the frozen release.

Release stages:

1. Local deterministic/property/fuzz tests and migration on copied disposable data.
2. Isolated multi-process and multi-host staging, no valuable assets, partitions/stalls/reorgs/crash injection and full recovery.
3. Verified processor integration under separately approved network/credential/fund-testing limits, only where architecture and law allow it.
4. Independent review/remediation, policy/legal/operations sign-off and frozen manifest/release digest.
5. Explicit network authorization and separately explicit payment authorization. Initial exposure caps remain restrictive until a measured soak and reconciliation review succeeds.

Never remove a NO-GO finding to make a dashboard green, reset a journal to clear payout uncertainty, or promise a launch date before dependency decisions and review. An architectural dead end is escalated with evidence and alternatives, not worked around with unannounced custody.

6. Remaining operator questions — ask at the relevant milestone

Not every value is needed to begin engineering; each becomes a blocking decision before its related activation.

Decision	Needed by	Why
Preparatory on-chain NFT lock/reservation without completed ownership transfer	M0 — permission agreed	Approved for design research on 2026-10-20; exact rules and authority remain subject to ADR review.
What exactly is the XMR payment destination and amount condition: seller receives net directly, or gross into approved conditional/custodial structure? How are host/author fees enforced?	M0	Buyer payment confirmation, seller proceeds and disbursement may be different events.
Acceptable trustless protocol liveness/cancellation delay, privacy disclosures and emergency recovery authority?	M0	Cryptography cannot resolve an unstated trust/recovery policy.
Author-leg payout costs: charged to seller; what cap/estimate tolerance and quote lifetime?	M1	Net viability and buyer/seller signatures must agree before money moves.
Tiny sale treatment: block checkout, subsidize under a published budget, or separately approved accumulation/batching?	M1	No listing minimum does not mean every amount can economically settle directly. Default planning assumption is block uneconomic checkout, pending explicit confirmation.
Per-sale, daily and total unsettled exposure caps; initial reserve and funding source; who bears which reorg/processor losses?	M4–M5	Cannot claim buyer/seller loss coverage or fee funding without numbers and funded responsibilities.
CPU model/resources, storage, concurrency/user/order dataset targets, operators expected at each scale milestone and latency SLOs?	M2	“Powerful server”/“large volume” is not a benchmark acceptance criterion. Operator count is independent of per-host capacity.
XMR confirmation/unlock and Wikideck finalization policy; payment/disbursement timing UX?	M3–M4	No universal “fully confirmed” threshold; distinguish ordering, inclusion and risk.
Dispute/support SLA, authenticated operator approvals, backup RPO/RTO and incident on-call?	M5–M6	Procedures must work before promising them to customers.
License, actual US legal operating entity/jurisdiction scope and required legal advice?	Before public distribution/live funds	These cannot be selected or certified by code changes alone.

References

• Current participant payment disclosures — describes existing behavior, not future promises.
• Security findings and operator hold-point register.
• Resource controls, wallet lifecycle, calibration evidence, operations/recovery.
• Offline SHKeeper contract/state-machine work — reusable tests/ideas, not the selected production architecture.

This plan supersedes the earlier USD production-pricing direction. New mock listings already use native XMR; historical USD terms remain intact. Custody and M2 implementation status are explicitly bounded above; no sandbox or infrastructure milestone implies live settlement or launch readiness.