wikideck/docs/settlement-feasibility.md

ADR 001 — XMR/NFT settlement feasibility investigation

Status: proposed; research checkpoint, not an approved exchange protocol. Source review: 2026-10-20. Related: production plan. No processor instance, credentials, wallet or funds were accessed. No swap implementation was installed or run.

Direction update, 2026-10-20: the operator has authorized implementing a pooled custodial XMR balance model instead. ADR 002 — custodial market design tracks the implemented isolated sandbox foundation and remaining production work. The recommendations and next gates below are retained as the earlier trustless/arbitrated research record, not a requirement to implement multisig first. Live funds, treasury key access, production fee-policy activation and new consensus activation remain gated. The distinctions between proof, trust, custody and atomicity below still apply.

Decisions and recommendation

• 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.

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.

Evidence and compatibility boundaries

Source	Obtained evidence	Implication / unresolved work
Hoenisch / Soriano del Pino, 2021, v2, sections 3–4	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	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, protocol explanation, 4.16.1 release	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, 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	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, dispute resolution, project status	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	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.

What Wikideck lacks today

Current transaction types implement ordinary P-256 ECDSA transfers and signed two-party card trades. There is no sale lock, expiry/revocation, conditional witness, payment evidence or cancel/refund branch. An ordinary signed transfer can be submitted later; an off-chain database reservation cannot stop a valid conflicting chain transfer.

Bitcoin's secp256k1 transaction graph, witness rules and timelocks cannot be assumed from the fact that Wikideck also uses ECDSA. P-256 is a different curve. Adding another per-sale cryptographic key scheme might be an alternative to changing wallet identity, but neither is selected. The NFT's uniqueness and absence of a fungible settlement asset also change the economic meaning of the paper's punishment paths.

Most importantly, the paper's participants observe Monero before cooperating; that is not a light client inside every validator. A signature may establish one party's authorization or reveal a secret without proving the full XMR payment condition to consensus. The operator's requirement that completed-sale inclusion require confirmed payment needs a separate explicit guarantee: is this validator-enforced Monero evidence, or participant-verified conditional authorization? Do not conflate them.

Mining remains roughly one card per 15-minute Wikideck block. Preparatory-lock inclusion, Monero funding confirmation/unlock, completed-sale inclusion, Wikideck depth, and any Monero withdrawal are separate milestones. Either chain may stall; no numerical threshold or recovery latency is approved here.

Options under investigation

Route	Possible guarantee	Named assumptions and release blockers
Conditional NFT-first adaptor/shared-key exchange	Potential atomic control exchange without host custody under stated protocol assumptions	Requires new NFT lock/redeem/cancel rules, compatible reviewed cryptography and keys, both-chain reorg/timing analysis, recoverable secrets and funded fee handling. Payment-to-conditional-output versus seller-net-direct semantics unresolved. Participant observations alone are not global payment-proof validation. The maintained Eigenwallet implementation reviewed is BTC→XMR, not this direction.
Deterministic Monero evidence/light client	Validators could evaluate a precisely specified payment condition	Need canonical Monero chain selection/work/difficulty/upgrade verification, recipient/amount/output evidence, privacy disclosures, reorg handling and resource bounds. A header/txid or successful wallet-RPC response alone is insufficient. Not implemented or established feasible in scope.
Host/committee attestation	Deterministic verification of an authorized signature	Verifies what an attestor asserted, not Monero truth. Theft/censorship/key compromise and cross-host trust remain. Not trustless; explicit approval required.
Host custody plus chain-enforced lock	Coordinated payment/disbursement and refunds under an accountable host	Host can lose/steal/freeze XMR; lock releaser can censor or misrelease depending on rules. Requires explicit fallback approval, legal/policy/reserve controls and full journal/recovery design. Not selected.

Operator briefing: concrete flow choices (no choice made)

These are architecture shapes for discussion, not approved protocol specifications. “Confirmed” must eventually be a named Monero-chain inclusion/depth/unlock policy; none is selected here.

A. Direct XMR payment, then seller delivery

1. Seller commits a card to a preparatory Wikideck lock, with a deadline and no ownership transfer.
2. Buyer sends the signed, exact XMR price to the seller's ordinary address.
3. Buyer (or a service with sufficient view/proof data) supplies payment evidence. Some trusted observer or a future Monero verifier decides whether the XMR transaction is in the accepted chain and meets the policy.
4. Seller signs the ordinary NFT transfer. Wikideck accepts it only if the applicable confirmation evidence has been attached/validated under the selected rules; otherwise the lock eventually expires.

Guarantee: the seller can receive XMR before delivering the card. A malicious seller can keep the payment, let the card lock expire, and never deliver. The NFT lock only prevents a competing card sale while it is live; it cannot reverse Monero. Seller signature or processor status does not fix this. This flow is not a trustless two-sided exchange. It may fit a deliberately seller-trusting product, but that would be a material policy change.

B. Custodial/host payment escrow (explicit fallback only)

1. Seller locks the NFT. Buyer sends exact XMR to a host-controlled invoice/address or wallet.
2. Host observes and accounts for the incoming transaction; after its selected confirmation/unlock policy it directs NFT delivery and then sends seller/author/host allocations, or refunds if policy permits.
3. Wikideck completes the sale only under a host attestation or new host-controlled release rule.

Guarantee: operationally straightforward comparison point; host controls or can censor the funds and may fail, be compromised, refuse a valid action, or become insolvent. Buyers trust its accounting, keys, confirmation observations, recovery process and dispute decisions. A host signature proves only that the host authorized the assertion. Independent market hosts each need their own limits and responsibility policy. This is custody/attestation, not trustless settlement. No approval to build or use it exists.

C. Conditional Monero funds + conditional NFT exchange (trustless target)

1. Seller locks the NFT on Wikideck; it is unavailable for conflicting transfers but remains seller-owned. Buyer and seller commit to one order, exact amount, destinations, fees and two-chain time windows.
2. Buyer funds a Monero output whose spend path is jointly/cryptographically conditional, not an ordinary immediate payment to the seller. The parties verify inclusion and selected finality/unlock condition.
3. A reviewed cross-chain adaptor/shared-secret protocol couples the Monero release path to the NFT completion witness. The NFT sale is included only after the payment condition is satisfied; the secret/redeem path lets the seller claim XMR. A separately secured cancel/refund path must ensure buyer funds return and the lock releases if the sale cannot finish.
4. Wikideck validators check the exact new lock/completion/cancel rules. Monero state is either independently verified by each validator, or a specifically named participant proof/attestation assumption is accepted. These are different security models.

Potential guarantee: no single party should be able to obtain both assets or take one asset while the other is permanently unrecoverable, within the explicitly modeled chain and liveness assumptions. Not established: the current chain has none of these transaction rules; no reference implementation was mapped for an NFT↔XMR trade; the maintained software reviewed covers BTC↔XMR, while the paper's XMR-first construction leaves Monero adaptor details as work in progress. Monero's lack of script timelocks means neither the NFT expiry nor a website timer can refund a Monero output by itself. The timeout/recovery construction is a cryptographic hard gate.

Failure after conditional funding	Must be solved before this can be called trustless
Buyer funds, then refuses to complete or disappears	Buyer must have an enforceable recover path after a specified condition, without seller stealing the funds; no unilateral host decision.
Seller locks NFT, then refuses to cooperate	Buyer must not lose the conditional funds forever; NFT lock expiry alone is insufficient.
One chain stalls or reorgs after the other chain advances	Lock windows and secret revelation order must preserve the option to complete or recover, with a quantified depth/liveness assumption and adversarial race tests.
Completion witness/secret leaks in a mempool or losing Wikideck fork	Reorg must not permit a party to take XMR and then restore NFT ownership, or otherwise claim both sides.
Refunder/publisher loses local wallet or settlement journal	Required protocol material and recovery authorization must survive; Monero chain replay may not reconstruct wallet-only transaction metadata.
Author/host fees or payout network cost consume the conditional amount	Define exact output split, fee payer, quote bounds and whether fee legs are part of the atomic protocol. No automatic subsidy or royalty enforcement outside recognized sale rules.

Who verifies Monero? Separate consensus decision

Model	Validator action	Trust / privacy / cost
Monero light client in every Wikideck validator	Validate headers/work/forks and the relevant payment proof under deterministic, versioned rules.	Strongest independent-chain verification option, if correctly implemented; large cryptographic, maintenance, resource, upgrade and consensus-complexity burden. The public transaction/recipient proof may expose linkage/privacy. Must study whether the evidence is actually succinct and complete for Monero's confidential outputs.
Participant-generated conditional authorization	Parties verify Monero in their own wallets and provide a protocol witness; Wikideck validates signatures/witness but not Monero's canonical chain itself.	Reduces node requirements but shifts chain observation/finality and censorship/eclipse assumptions to named parties. A signature cannot prove that the signed observation was true. Must analyze how an honest party can safely refuse/force progress.
Market-host/committee/oracle assertion	Validators check a configured public key's attestation.	Explicit third-party trust, censorship/key-compromise risk, and operator governance. Not the trustless option; selecting it is an explicit fallback.

No current Monero proof RPC response alone resolves this choice. check_tx_proof verifies a proof against the wallet/node's observed chain and reports confirmations/in-pool/received; it is not a proof that every independent Wikideck node can validate canonical Monero history. Its documentation also warns the received funds may not be spendable. A fixed threshold reduces but never eliminates reorg risk.

Payment proof + delivery record + reputation: useful deterrence, not atomic settlement

The operator's proposed accountability route is technically plausible as a market abuse-control layer, with important limits:

1. Buyer supplies evidence: Monero's wallet RPC get_tx_proof creates a proof for a transaction and destination address; check_tx_proof can report good, received, confirmations and in_pool. A proof's optional message can bind the displayed order ID/domain, helping deter reuse of evidence for a different sale. The verifier still needs a Monero wallet/node view of the chain to determine confirmation state; a copied RPC response is not a trustless proof of canonical chain inclusion to all Wikideck validators. The RPC docs explicitly warn that a valid proof does not prove associated funds are spendable.
2. Delivery can be independently checked: Wikideck's signed NFT transfer and canonical block are public under its chain rules. A market host can check whether the exact card/sequence moved to the buyer and whether it reached its own configured depth. Proving that delivery did not occur by a deadline is harder than showing an inclusion: the observer must have a complete, current canonical view, handle reorgs/partitions and allow for pending or late-signed transfers. A single host's assertion about absence is not consensus evidence.
3. A host can record non-delivery: under a disclosed process, one host could record “verified XMR payment; no matching canonical NFT delivery by deadline; seller wallet address flagged.” This may warn that host's users, enable local order throttling/denial and deter repeat abuse. It does not reverse XMR, provide compensation, force another peer to enforce the flag, prove the buyer was the sender, or prevent the seller from changing wallet/host. Monero's proof shows receipt to an address/amount, not a real-world person or necessarily the sender's identity.

Reputation and automatic-ban limits

• Start with evidence records and opt-in/filterable indicators, not an automatic global wallet ban or a single opaque emoji score. Show denominators and outcome states: completed orders, seller cancellations, expired buyer checkouts, independently verified non-delivery findings, disputed/reorged/under-review cases and their age. Do not count unresolved or pending cases as proven fraud.
• A marketplace host can ban an address locally. The address can create another wallet, and another peer can admit it. A network-wide blacklist would require a shared authority/registry or new consensus and governance rules, be easy to Sybil-evade absent identity, and create censorship/false-positive risks. Do not imply a local block is a chain ban.
• Threshold auto-bans can be gamed: attackers create many new wallets, trade cheaply to build reputation, coordinate false claims, or target a seller with buyer-side mispayments and outage/reorg disputes. A threshold does not establish intent. Any punitive case needs evidence rules, seller response/appeal, expiry/correction, privacy limits and a responsible decision-maker.
• 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.

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.

Earlier recommended product path (superseded by custodial investigation)

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.

Threat model and required failure evidence

Assets: NFT ownership/availability, buyer gross payment, seller proceeds, host/author allocations, refund liabilities, wallet/conditional secrets, order privacy and durable recovery evidence. Independent hosts, miners, relayers, processors and user wallets are separate trust boundaries. An author commission does not underwrite hosts.

Adversary / failure	Required invariant and test before acceptance
Dishonest seller, duplicate listings across hosts, stale signatures	A canonical lock excludes conflicting spends under the selected rules. Exact card sequence/order/network/market binding; cancelled or expired authorizations cannot revive. Race tests at every boundary.
Dishonest buyer, late/partial/duplicate/overpayment	No NFT release for inadequate or misbound evidence; no reuse of one funded output across sales. Define legitimate incoming liabilities instead of discarding late funds. No refund plus later successful delivery.
Buyer aborts after seller locks; Sybil reservation spam	Explicit bounded liveness/cost exposure without assuming a wallet is a person. Quantify locking/griefing costs; no unapproved deposit requirement.
Dishonest host/relayer/processor or compromised authorization key	Forged observations do not bypass selected validity rules. Document which roles can steal, censor or lock funds/assets. Sender identity and authenticated transport are not economic truth.
Miner censorship, eclipse, partition, stalled chain	Deadline safety margins must cover publication/confirmation and observation assumptions. Secret publication in a losing transaction or mempool can be irreversible even when NFT inclusion fails. Test cancel/redeem races.
Reorg of either chain, including after payout/release	Explicit finality and residual-loss model. Never silently repay after an ambiguous send or infer that a local restore reverses XMR. Reorg tests before/after each critical action.
Fee spikes, dust and separately paid author leg	No rounding up sub-atomic commissions; no unapproved subsidy/balance accumulation. Pre-payment viability plus approved fee cap and overrun behavior; partial-success accounting.
Key loss, crash or malicious recovery operator	Required refund/redeem data survives authorized restore. Unknown external effects stay quarantined. No manual journal reset creates duplicate sends; public-chain replay alone cannot recover all wallet metadata.
Disputed or replayed terms	Versioned canonical terms bind price/currency, all destinations, commissions, cost caps, expiry, parties, card sequence and selected protocol. Negative signature/replay tests across market/network/order versions.

Fee enforcement limit

Fixed host and 1% author allocations can be signed and validated for the selected sale protocol, but ordinary free transfers already exist. Parties can exchange XMR off-platform and submit a nominal gift unless new protocol policy prevents it; modifiable peers can also fork policy. Do not claim universal royalty enforcement or infer the value of off-chain consideration. The commission rule for recognized sales and treatment of alternate transfers must be reviewed explicitly.

Next decision gates

1. Payment flow: a direct ordinary XMR payment to the seller followed by seller-authorized NFT delivery cannot protect a buyer from an uncooperative seller: a timeout can unlock the NFT but cannot reverse confirmed payment. Host escrow is simpler but custodial and not approved. Conditional/shared-key funds could target two-sided atomic control but are not seller-spendable proceeds until the protocol releases them. Current Eigenwallet documentation and implementation cover BTC→XMR; the paper's reverse direction leaves Monero adaptor details incomplete. No current reviewed reference was found for conditional XMR↔NFT exchange. Prepare the concrete conditional flow and its failure matrix before a choice is made.
2. Consensus evidence: every Wikideck validator can either run a versioned Monero verifier/light client (larger cryptographic, privacy, maintenance and consensus burden), or validate participant-generated signatures/witnesses without independently proving Monero canonicality (explicit participant-observation trust). A host/committee signature is an oracle/attestation trust assumption, not trustless verification. check_tx_proof RPC output is not itself a consensus-verifiable Monero canonical-chain proof. The operator asked to see concrete options before choosing either the payment flow or verifier model; both remain open.
3. Map each required NFT-first transition and secret exposure to current maintained protocol/reference behavior; identify compatible crypto libraries, audit artifacts and licenses. No hand-written cryptographic substitute.
4. Build only a disposable, offline protocol/state-model spike after selecting its exact assumptions. Include abort, timeout, mempool leak, double-lock, reorg and recovery counterexamples; a happy-path demo cannot close M0.
5. Obtain specialist cryptographic/consensus review and operator ADR approval before any versioned consensus implementation. If no practical reviewed route meets requirements, request custodial/attested fallback approval with its explicit guarantees and liabilities.

No lock code, consensus version change, production migration or payment activation is authorized by this research checkpoint.