Removed SHKeeper

2026-10-22 10:45:32 -04:00
parent e835238d05
commit 5d607c1521
18 changed files with 41 additions and 662 deletions
@@ -9,7 +9,7 @@ Status: **proposed; research checkpoint, not an approved exchange protocol**. So
 - Operator approved preparatory on-chain NFT locks/reservations for design research. They must not transfer completed-sale ownership before the agreed XMR condition. This does **not** approve a custodian, lock authority, timeout or new consensus rule.
 - Continue research into an NFT-first, XMR-compatible conditional exchange. Do not port Bitcoin swap code as though Wikideck were Bitcoin. Current transfers cannot implement the researched protocol.
 - 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.
+- The later approved direction is pooled custodial XMR balances under ADR 002; the trustless/arbitrated analysis below remains historical research, not the active implementation plan.

 **Earlier recommendation (superseded as the preferred investigation):** build proof-backed order evidence and fair, host-scoped reputation as a non-settlement safety layer; evaluate per-order 2-of-3 Monero multisig escrow with independent dispute arbitration as a live-sale 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. No live funds, key custody, or new consensus rules were authorized by that recommendation.

@@ -21,9 +21,8 @@ Status: **proposed; research checkpoint, not an approved exchange protocol**. So
 | [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 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. |
+| [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 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.

@@ -146,7 +145,7 @@ This layer improves detection, customer support and deterrence. If direct paymen
 - 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.
+**Historical research status:** this ADR records earlier trustless/arbitrated options. The operator subsequently selected pooled custodial XMR balances in [ADR 002](custodial-market-design.md). The public marketplace displays native-XMR prices under a mock-only v3 domain; actual XMR payments remain disabled. No payment processor is part of the selected path.

 ## Threat model and required failure evidence