Recommendation

docs/settlement-feasibility.md

@@ -9,6 +9,8 @@ Status: **proposed; research checkpoint, not an approved exchange protocol**. So
 - No practical reviewed Wikideck-compatible trustless design has yet been demonstrated. This is an evidence gap, **not a proof of impossibility**. M0 remains open pending protocol specification, disposable-fixture spike, failure tests, specialist review and operator approval.
 - Do not connect SHKeeper or replace trustless exchange with host attestation/custody by default. If the researched route fails its gates, return for explicit fallback approval.
 
+**Recommended path forward:** build proof-backed order evidence and fair, host-scoped reputation as a non-settlement safety layer; for future live fixed-price sales, evaluate per-order 2-of-3 Monero multisig escrow with independent dispute arbitration as the pragmatic buyer-protection candidate. Keep permissionless conditional XMR↔NFT research separate. A payment proof and delivery record cannot return direct-to-seller XMR. The escrow candidate is **arbitrated, not trustless**: the arbitrator and wallet/recovery procedures become material trust and availability dependencies. This recommendation does not authorize live funds, key custody, or new consensus rules; independent security review and explicit release gates remain mandatory.
+
 ## Evidence and compatibility boundaries
 
 | Source | Obtained evidence | Implication / unresolved work |
@@ -16,8 +18,9 @@ Status: **proposed; research checkpoint, not an approved exchange protocol**. So
 | [Hoenisch / Soriano del Pino, 2021, v2, sections 3–4](https://arxiv.org/html/2101.12332v2) | Section 3 describes Bitcoin lock/redeem/cancel/refund/punish transactions, adaptor signatures and cross-curve discrete-log equality proofs. Monero is funded into a shared-key output after Bitcoin is locked. Timely chain observation and reaction matter. Section 4 explicitly describes further work, not a completed proof/implementation of its alternative. | Potential structure for NFT-first research, not a ready-made NFT exchange. Cross-curve proof and adaptor implementations must match the chosen curves. Never infer current Monero capabilities solely from a 2021 proposal. |
 | [COMIT upstream](https://github.com/comit-network/xmr-btc-swap) | Archived/unmaintained; README points to eigenwallet and warns of incompatible peer changes. README states its cryptography was not formally audited. GPL-3.0. | Do not adopt archived upstream as a production dependency. Its historical direction/limitations are not proof of current feasibility or impossibility. |
 | [eigenwallet core](https://github.com/eigenwallet/core), [protocol explanation](https://docs.eigenwallet.org/advanced/refund_punish), [4.16.1 release](https://github.com/eigenwallet/core/releases/tag/4.16.1) | Maintained project with 4.16.1 release. Its current docs explicitly define taker as Bitcoin seller and maker as Monero seller; its lock/cancel/refund/punish flow is Bitcoin-timelock centric. The docs and site describe Bitcoin→Monero only. GPL-3.0; historical COMIT README says formal crypto audit absent, but that is not evidence about every current successor version. | Useful comparative protocol and operational lessons, but not the requested XMR-for-NFT direction or an arbitrary-NFT/P-256 integration. No audit artifact for a proposed Wikideck adaptation was found/evaluated. Review exact current source before considering any reuse. |
-| [Monero wallet RPC: check_tx_proof / check_tx_key](https://docs.getmonero.org/rpc-library/wallet-rpc/#check_tx_proof) | Reports proof validity, recipient amount, in-pool status and confirmations; explicitly warns that proofs do not guarantee spendability (locked, already spent or duplicated/burnt one-time outputs). | A valid proof/txid is not by itself a release condition. Define exact output validity, order binding, chain evidence, confirmation and unlock semantics. Merely requiring that funds remain unspent after a seller legitimately spends them would also be incorrect. |
+| [Monero payment-proof guide](https://www.getmonero.org/resources/user-guides/prove-payment.html), [wallet RPC `check_tx_proof`](https://docs.getmonero.org/rpc-library/wallet-rpc/#check_tx_proof) | The payer can give a payee a transaction ID, destination address and transaction proof/key. The payee checks the proof against an up-to-date Monero blockchain view; RPC reports validity, received amount, in-pool status and confirmations. The RPC explicitly warns proof does not guarantee spendability (locked, already spent or duplicated/burnt one-time outputs). | Buyers can prove payment to a seller/market verifier for accountability. This does not identify a real-world person, reverse payment, or give every Wikideck validator an independently verifiable canonical-chain proof. Bind each order to a unique destination and exact amount; treat proof verification/depth as sensitive evidence. |
 | [Monero wallet RPC: transfer](https://docs.getmonero.org/rpc-library/wallet-rpc/#transfer) | Supports multiple recipients and atomic-unit amounts; warns against subtracting fees from outputs when exact recipient amounts are required. | Native wallet multi-recipient capability is not the same as SHKeeper multi-payout support and does not make NFT exchange atomic. Amounts need lossless JSON encoding, not conversion to JavaScript Number. |
+| [Haveno trade protocol](https://docs.haveno.exchange/overview/trade-protocol/), [dispute resolution](https://docs.haveno.exchange/overview/dispute-resolution/), [project status](https://github.com/haveno-dex/haveno) | A maintained XMR P2P exchange documents per-trade 2-of-3 Monero multisig: one key for each trader and one for an arbitrator. Two keys are needed to spend. Parties normally co-release funds; when they disagree, an arbitrator investigates and co-signs with one party. Security deposits are locked to discourage protocol abuse. Its current project README says the upstream project does not support real trades directly; real networks use third-party builds/networks it does not endorse. | Strong prior art for an **arbitrated escrow**, not a trustless/automatic refund and not an NFT cross-chain protocol. The arbitrator is a real trust and availability dependency in disputes; deposits, key ceremony, wallet recovery, multisig fees, network governance and third-party network integrity matter. Its second asset/payment is fiat/other cryptocurrency and does not answer Wikideck card lock or consensus validation. Treat as a design pattern to adapt only after specialist review, not as a drop-in integration or endorsement. |
 | [SHKeeper API 2.1.47](https://shkeeper.io/api/) | Documented invoice creation accepts USD fiat amounts; returns converted crypto amounts. XMR multipayout unsupported. Payout fee input is priority, not an atomic cost cap. | Exact native-XMR invoice and bounded-fee guarantees remain unverified. No hidden USD conversion. Processor status is trusted external observation, not deterministic consensus evidence. |
 
 The initial Monero atomic-swaps glossary URL returned 404 and is not relied upon. Sources above are primary project/paper documentation, not independent certification. Their live pages can change; a release decision needs archived/pinned evidence against actual dependencies.
@@ -106,7 +109,40 @@ The operator's proposed accountability route is technically plausible as a **mar
 - Publicly linking XMR proofs, an XMR destination, Wikideck wallet, card ID, counterparties and order IDs can substantially weaken transaction privacy. Make evidence disclosure explicit and minimize retention/access. Do not require buyers to publish transaction keys or proofs by default without a privacy review.
 - A good reputation reduces perceived counterparty risk; it is not escrow, a guarantee of delivery, a refund, or proof for consensus. If a seller keeps direct XMR and withholds the card, a ban is at best an ex-post deterrent. For positive buyer protection, research must still solve conditional exchange or obtain approval for an accountable custodial arrangement.
 
-**Recommendation:** carry this as a separate reputation/abuse workstream for a future fixed-price product; do not select it as the payment-settlement architecture. First prototype evidence verification offline against disposable Monero fixtures (no live RPC/funds), threat-test both truthful and false disputes, and decide whether any status is host-local or portable. Keep M0's atomicity and validator-evidence decisions open.
+**Implementation recommendation:** proceed with an offline evidence and case-journal prototype for fixed-price abuse prevention; do not require buyers to publish transaction keys/proofs without explicit consent. A buyer can submit Monero proof, txid, order-specific recipient address and exact amount; a named verifier checks it against a synced chain view and later correlates it with the canonical Wikideck transfer. Record evidence and an appealable case; a host may apply a local restriction only under a published review policy. This is not automatic settlement, a global blacklist or buyer compensation. Keep M0's consensus proof and two-sided atomicity questions open.
+
+## Recommended product path after comparing XMR market patterns
+
+**Recommendation: use layered protection, with an opt-in evidence/reputation layer now and an arbitrated multisignature escrow as the first serious live-sale candidate. Do not treat proof/reputation as settlement, and do not make direct-to-seller XMR the default live purchase.**
+
+This is a design recommendation, not authorization to accept money, use custody, or write consensus rules. Haveno documents per-trade 2-of-3 Monero multisig: each trader holds one key and an arbitrator holds the third; two keys are required to spend. Normal release is collaborative, while disputes require an arbitrator to decide and co-sign with one party. Security deposits are used to make some abuse costly. This is a more credible buyer-protection model than a website's “paid” flag or an XMR proof alone. It does **not** provide unilateral cryptographic timelocks, eliminate arbitrator trust, guarantee a refund, or supply Wikideck/NFT transaction semantics. Haveno is active, but its official project says the upstream does not directly support real trades; third-party networks are not endorsed. Treat it as protocol prior art, not a dependency or network recommendation. Adapt only after independent protocol, security, custody/legal and operational review.
+
+### Stage 0 — proof-backed evidence and fair reputation (can be designed before settlement selection)
+
+- For each order, bind a buyer-generated Monero payment proof to a fresh order nonce/message, expected recipient/subaddress, exact gross and expiry. Verify against a fully synchronized, trusted-by-the-verifier Monero wallet/node; show the verifier, check time, observed height/depth, transaction identity, amount and limitations. A positive proof establishes that the output was paid to the indicated address under the checked chain view; it does not establish buyer identity, spendability, absence of a deeper reorg, or that Wikideck consensus independently verified Monero.
+- Correlate the proof to canonical Wikideck delivery using order ID, seller/buyer/card/sequence and transfer ID. Store an append-only, access-controlled case record with evidence digest and versions. Keep detailed proof material private by default; make the buyer consent to any disclosure to an arbitrator or portable verifier because the proof links XMR activity to a sale.
+- Record states such as `payment evidence submitted`, `proof verified by [named verifier]`, `delivery observed`, `non-delivery alleged`, `under review`, and `adjudicated`. Never label an allegation or timeout “fraud” automatically. Preserve appeal, correction and expiry/audit history.
+- Launch reputation as transparent **per-host, evidence-backed counters or filters**, not cross-host wallet blacklists, opaque emoji thresholds, or proof of safety. Report completion and adjudicated outcomes with denominators; distinguish abandoned buyer checkout, technical failure, chain reorg and proven deliberate non-delivery. Wallet addresses are pseudonymous and cheap to replace.
+- A host may choose not to accept new orders from a wallet after a documented review, but that is a local service decision, not a ban from Wikideck consensus and not compensation. Add report-rate limits and seller response/appeal to reduce extortion, Sybil and false-claim abuse.
+
+This layer improves detection, customer support and deterrence. If direct payment has already reached the seller, it still cannot recover the buyer's XMR when the seller refuses delivery. Reputation is a complement to the escrow mechanism, never a substitute.
+
+### Stage 1 — fixed-price escrow candidate (blocking live-sale design)
+
+1. Put the card in a reviewed consensus-enforced preparatory lock, with exact seller/card sequence/order ID, no completed ownership transfer, and safe cancel/release authorization. A node-local reservation alone is insufficient against conflicting sales at other hosts.
+2. Buyer funds an order-specific 2-of-3 XMR multisig: buyer, seller and a selected independent arbitrator (or explicitly disclosed host-operated arbitrator). Routine success requires buyer+seller release signatures after verified canonical NFT delivery. In a dispute, the arbitrator can co-sign with the rightful party according to published evidence rules. No arbitrator can move funds alone; the arbitrator is nevertheless trusted to adjudicate, available to help, and may collude with one participant.
+3. Define seller/buyer security deposits, if any, as a separate approved anti-griefing and liability policy. Haveno uses deposits as incentives; it does not make every cross-chain fact machine-verifiable. No deposits, amount, confiscation rule or operator reserve are approved here.
+4. Make delivery and XMR fund release states explicit, with durable key/backup recovery, key loss and unresponsive-party procedures. Monero multisig has no automatically expiring refund merely because a Wikideck timer elapsed. Do not promise automatic refunds or instant settlement.
+5. Fix the accounting model before enabling XMR: who contributes the hosting/author legs, who pays each Monero fee, how precise output amounts and fees are reviewed, and whether the 1% commission remains feasible for a conditional multisig protocol. Any arbitrator, operator or host fee/reserve is separately visible and authorized.
+
+**Trust claim if approved:** “arbitrated, non-custodial multisig escrow” may be supportable only if the operator never holds enough keys to spend alone, key control is independently tested, and terms accurately identify arbitrator powers. Do not call it trustless atomic exchange. The arbitrator can censor/withhold cooperation or side with one party; disputes require human evidence review; funds can be locked during outages. Buyers and sellers must verify the locked amount and agreed release destinations. Do not reuse an unreviewed network or assume Haveno is production-certified for NFT sales.
+
+### Release recommendation
+
+- Keep current marketplace and XMR payment actions **mock only** until a reviewable order escrow + lock + recovery protocol is implemented and the operator approves an accountable arbitrator model, exposure limits/reserves, disputes, privacy disclosure and legal review.
+- In parallel, implement an offline test harness for proof-bound order evidence and the non-punitive reputation case model; do not expose a global automatic-ban feature.
+- Run separate multi-process/multi-host adversarial tests for false proof, wrong recipient/amount, duplicate/replayed proof, stale/out-of-date node, payment reorg, buyer false dispute, delayed NFT transfer/reorg, arbitrator unavailable/colluding, key loss, and partial payout. Require an external Monero multisig/security review before staging.
+- If the operator's eventual priority is permissionless no-arbitrator exchange, keep pursuing the custom conditional XMR↔NFT protocol separately; no practical current implementation is established. Do not downgrade to direct payment while describing buyer protection.
 
 **Decision request remains open:** no live settlement flow or Monero verifier has been selected. Direct seller payment plus proof and reputation (A) may deter abuse but is not buyer-protecting; B is a custodial fallback; C is the researched direction intended to target two-sided atomic control, but remains unproven and may be impractical. The public marketplace now displays native-XMR prices under a mock-only v3 domain; actual XMR payments remain disabled and the separate SHKeeper prototype still takes USD.