Removed SHKeeper

docs/market-transparency.md

@@ -8,7 +8,7 @@
 
 **Card delivery is real on the selected blockchain.** When a seller signs delivery, they authorize an actual NFT transfer, even though the buyer only clicked a simulated-payment button. A `paid` or `mock-paid` label here is **not evidence of real money received**. Do not deliver valuable assets in exchange for mock payment.
 
-A separate offline SHKeeper prototype tests a possible future real-payment workflow. It is not connected to public checkout or the current market journal. There is no supported setting that enables live checkout today.
+There is no live payment integration or supported setting that enables live checkout today.
 
 ## Who controls what?
 
@@ -19,7 +19,7 @@ A separate offline SHKeeper prototype tests a possible future real-payment workf
 | Confirmed card ownership | The selected network's canonical blockchain, subject to reorganizations. The browser trusts the connected node's reported chain; it is not an independent validating wallet. |
 | Listings, auction bids, reservations and orders | The particular hosting peer's local marketplace database. They are not replicated as blockchain consensus records or shared with every other market. |
 | Payment money today | No money is collected, held or sent by this release. Amounts are accounting simulations. |
-| Money in the proposed live design | The market operator's merchant wallet managed through SHKeeper would receive gross buyer payments and send net payouts. **That would be custodial**, not trustless escrow or a non-custodial exchange. It is not active. |
+| Money in the proposed live design | The selected direction is a pooled Monero treasury and internal liability ledger controlled by the market operator. **That would be custodial**, not trustless escrow or a non-custodial exchange. It is not active. |
 
 Your NFT wallet address is not an XMR payment address. Sharing the RandomX algorithm with Monero does not merge the two networks, payments or security budgets.
 
@@ -43,7 +43,7 @@ The auction winner must check out and complete mock payment within **30 minutes
 
 For a new version-3 order, the buyer sees the exact signed XMR gross, host fee, author fee, seller net and payment deadline. No USD conversion or exchange rate is applied. Legacy version-2 USD orders retain their previously signed USD price and snapshotted mock-XMR quote; they are not reinterpreted as XMR. Quote amounts, fee allocations and delivery-confirmation requirements remain stored with each order.
 
-Only the order's buyer can sign **Simulate XMR payment**, and eligibility is checked again. This action changes an accounting status; it does not verify a Monero transaction or contact SHKeeper. Other users cannot mark the order paid through the normal participant-authorized API, but the buyer's signature alone never proves real payment.
+Only the order's buyer can sign **Simulate XMR payment**, and eligibility is checked again. This action changes an accounting status; it does not verify a Monero transaction. Other users cannot mark the order paid through the normal participant-authorized API, but the buyer's signature alone never proves real payment.
 
 ### 4. Seller reviews and signs delivery
 
@@ -101,19 +101,9 @@ Fees apply to completed marketplace sales—not listing creation, auction bids,
 
 There is currently **no built-in arbitration service, buyer insurance, chargeback system, guaranteed reimbursement, operator override/payment-recovery endpoint, or dispute-resolution SLA**. A `review` label means investigation is needed—not that a resolver or repayment fund exists. Do not infer those protections from words such as “market,” “confirmation” or “settlement.”
 
-## What the offline SHKeeper prototype demonstrates—not a live promise
+## Future live custody is not active
 
-The earlier disconnected prototype modeled a USD-denominated SHKeeper invoice, gross XMR into an operator merchant wallet, seller-signed NFT delivery, then operator payout of seller net and the separate author allocation. This would temporarily entrust funds to the operator and its processor administration. SHKeeper does not by itself guarantee that a seller delivers or that an operator honors a refund. This USD invoice prototype is **not connected to the new native-XMR marketplace** and must not be silently used to convert its prices; any future processor path requires verified exact-XMR capability or a separately approved architecture.
-
-The disconnected prototype tests:
-
-- Seller-signed payout destination and buyer-signed exact invoice amount/address/expiry and fee allocations.
-- Authoritative invoice lookup rather than trusting a browser claim or callback `paid` flag; matching currency, amount, destination, unique incoming transactions and confirmed status.
-- Waiting on partial/unconfirmed payment; holding late, overpaid, contradictory or changed evidence for review.
-- Recording payout intent durably **before** sending a payout request. A lost response may mean money was sent; ambiguous requests are not blindly retried.
-- Tracking separate seller/author payout tasks. Seller success followed by fee failure preserves the completed seller leg rather than paying it again. Known task IDs can be polled without creating another payout.
-
-This is fake-processor test evidence, **not** a deployed SHKeeper contract verification, functioning buyer-protection service or live-fund recovery system. No real Monero confirmation threshold, reserve/hold duration, refund rules or dispute policy has been approved. The prototype's journal is separate from production market backups. See [technical prototype and activation holds](shkeeper-settlement.md).
+The intended direction is direct wallet/daemon observation into a pooled liability ledger; it does not depend on a third-party invoice processor. That future flow is not implemented end-to-end. There is no customer-facing deposit route, automatic customer credit, treasury withdrawal service, or real sale settlement. No confirmation threshold, funded reserve, loss allocation, refund policy or dispute process has been approved. This document describes current behavior and does not promise future buyer protection.
 
 ## Privacy, evidence and host accountability