Removed SHKeeper

docs/production-plan.md

@@ -16,7 +16,7 @@ Status: active engineering plan; **not launch or payment authorization**. Update
 | 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.
+**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. No real XMR invoice, payable address, deposit, credit, withdrawal, or settlement path is enabled. Existing records are not silently reinterpreted as XMR.
 
 **Current design deliverable:** [custodial market design](custodial-market-design.md). 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.
 
@@ -56,7 +56,7 @@ This scope is a proposed release boundary, not an approval to deploy. The operat
 
 ### 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**.
+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 payment service's status is a trusted attestation, not a trustless cross-chain proof. Calling an external service or 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.
 
@@ -85,7 +85,7 @@ 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.
+- Use the selected pooled-custody model: direct Monero wallet/daemon observation and durable subaddress allocation for deposits, internal liability transfers for sales, and a separately constrained treasury withdrawal path. No third-party processor is selected or required. Preserve exact native-XMR prices; do not introduce fiat conversion as settlement authority.
 - 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.
 
@@ -134,14 +134,14 @@ Acceptance: safety/liveness matrix covers every state transition and adversary;
 
 ### 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.
+Depends on the pooled-custody decision in ADR 002 and the separately reviewed NFT lock/completion/cancellation protocol.
 
-- 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.
+- Deposit enrollment and allocation: authenticate the Wikideck beneficiary, create a durable one-to-one mapping to a Monero subaddress before displaying it, and keep old allocations monitored. The spend-capable wallet must be isolated from the public API.
+- Observation and credit: consume wallet-owned output records with stable per-output identity, canonical inclusion, versioned confirmation/unlock policy, exact atomic amounts and idempotent ledger writes. Unknown, late, duplicate, partial and reorged outputs require defined suspense/hold treatment; observations alone never authorize spendable credit.
+- Marketplace settlement: reserve available customer liability and order state atomically in PostgreSQL; release seller/author/host liabilities only from the agreed canonical sale outcome. A user-signed mock-payment action is never payment evidence.
+- Withdrawals: authorize exact destination, amount and maximum fee; reserve liabilities; fence one treasury worker; durably store prepared-transaction identity before relay; reconcile chain status and actual fee. Ambiguous outcomes must not trigger a second transaction or release of the reservation.
+- Recovery and operations: include customer-to-subaddress mapping, wallet generation/high-water marks, journal, pending outputs, signed approvals and prepared transactions in encrypted backups. Restore without spending, reconcile with Monero state, then explicitly re-enable the treasury worker.
+- Set measured liability/exposure caps and independent alert/stop controls. Stopping new deposits or orders must not abandon existing liabilities. Separate observation, ledger, operator review and spend-signing privileges.
 
 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.
 
@@ -225,6 +225,5 @@ Not every value is needed to begin engineering; each becomes a blocking decision
 - [Current participant payment disclosures](market-transparency.md) — describes existing behavior, not future promises.
 - [Security findings](security-review.md) and [operator hold-point register](operator-launch.md).
 - [Resource controls](node-resources.md), [wallet lifecycle](wallet-security.md), [calibration evidence](consensus-calibration.md), [operations/recovery](operations-recovery.md).
-- [Offline SHKeeper contract/state-machine work](shkeeper-settlement.md) — 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.