ADR-0049 — Payment-proof-weighted reputation

Status: Proposed — XMR / privacy-asset exclusion CONFIRMED (@agorise, 2026-07-04: "for monero it's a disaster; we do not want to sacrifice privacy"). The transparent-chain tier itself is still pending a privacy-vs-value decision (see the Update note under Decision). Date: 2026-07-04 Deciders: @agorise Supersedes: — Superseded by: —

Context

Reputation today (ADR-0014 + the cp421 hardening) is a time-decay weighted average of 1–5 ratings with a 365-day half-life. Only order-tethered feedback counts, reviews from detector-flagged pairs (suspicious_reciprocity / related_accounts / one_way_pile_on / review_concentration) are excluded from the aggregate, and — as of cp421 — a review is only accepted at all if the two parties have a substantiated two-way on-chain conversation (≥2 morphit_chat_v1 each way, ≥15-min span, unflagged = the has_verified_chat bar). So the current floor is "you provably had a real conversation with this person." There is no notion of proof strength in the weight — every accepted review counts the same.

The ask (Ken): a review backed by a provable full-amount crypto payment should carry materially more weight than a conversation-only review. Working assumption for the threat model: a majority of users will, at some point, try to inflate their reputation by nefarious means, so any "payment-verified" tier must be substantially harder to forge than a conversation — otherwise it just moves the gaming target.

This ADR works out whether that tier is achievable, what it can and cannot prove, and — critically — how it collides with Morphit's #1 priority (privacy / anonymity).

The three hard constraints

The fiat leg is never on-chain. Every Morphit trade is fiat↔crypto. The cash/bank side leaves no TxID, ever. So a payment proof can only ever attest the crypto leg. Consequence: a verified payment is a signal about the crypto sender's reliability (they delivered), so it can only boost the review of the crypto sender, by the crypto receiver. The cash payer's reliability stays conversation-only — it is structurally unprovable. A pure "cash both directions" trade cannot exist (one leg is always crypto), but a trade can only ever earn the tier for the one party who sent crypto.
The agreed amount and the recipient address live in E2E chat. The indexer never sees the negotiated amount or (for external chains) the payee address — they are exchanged inside encrypted morphit_chat_v1 payloads (ADR-0015). So the indexer cannot autonomously judge "was this the full agreed amount to the right person." Any design that tries to derive "full amount" from the order alone is wrong: orders are frequently ranges/rates, and the actual trade size is negotiated in chat.
Assets are asymmetric in verifiability.
- BLURT: a transfer between two Morphit accounts is fully on-chain — sender, recipient (a Morphit account), amount, and memo are all public and directly indexable. Recipient identity is proven with no attestation needed.
- BTC / LTC / BCH / DOGE / stablecoins (transparent chains): the existing fee verifiers can confirm "txid delivered ≥ amount to address Y," but the address-Y-belongs-to-the-counterparty binding is not on-chain — it was exchanged in chat. So this tier needs the recipient to attest.
- XMR (and any privacy asset): see the privacy tension below — an on-chain-verifiable proof is fundamentally incompatible with the reason someone chose XMR.

The central tension: this feature trades privacy for reputation

A publicly verifiable payment proof is, by definition, published evidence that links you to a counterparty for a specific amount on a public ledger. For a privacy-first marketplace that is a real cost, and it is not uniform across assets:

For transparent chains (BLURT/BTC/…), the payment is already visible on-chain; a settlement proof mainly adds the linkage(this txid ↔ this Morphit trade ↔ these two accounts), which aids chain analysis. A meaningful but bounded privacy loss.
For XMR, it is catastrophic. Monero's privacy comes precisely from not being able to prove amounts/recipients. The only way to prove an XMR payment is to publish the transaction key (plus the address and amount), which permanently deanonymizes that transaction to anyone. That directly contradicts (a) the platform's #1 priority, (b) the reason XMR users are here, and (c) the standing invariant that the XMR private view key is env-only and never published. Building an XMR settlement proof would hand privacy- seeking users a footgun.

This tension is the crux of the decision, not a footnote.

Decision

Update (2026-07-04, @agorise): the XMR / privacy-asset exclusion below is confirmed — we will not publish anything that deanonymizes a Monero transaction. That leaves one open question: whether the transparent-chain tier is worth building at all. Even for BTC/LTC/… a settlement proof adds an on-chain linkage (this txid ↔ this trade ↔ these two accounts) that aids chain analysis — a bounded but real privacy cost on a privacy-first platform. Given (a) that cost and (b) that the cp421 verified-chat gate already makes ghost/self-boost reviews impossible and gives reputation a strong, spoof-resistant floor, the standing recommendation is to NOT build the payment tier and keep reputation conversation-based — holding this ADR as the worked-out record so the option is one decision away if a concrete need appears. The rest of this section documents the design if the transparent-chain tier is ever green-lit.

Adopt a two-sided, opt-in, transparent-assets-only settlement proof, and use it as a weight multiplier — never for XMR/privacy assets, and never automatically.

1. Scope — which assets

Settlement proofs are offered only for transparent-chain assets already governed by ADR-0026 (BLURT, BTC, LTC, BCH, DOGE, and transparent-chain stablecoins). XMR and any privacy asset are explicitly excluded — a trade whose crypto leg is a privacy asset earns reputation through the verified-chat baseline only. This is a deliberate privacy-over-reputation choice for the privacy core, and it is the correct one: you cannot have both a public payment proof and transaction privacy; those are fundamentally opposed.

2. Mechanism — a `morphit_settlement_v1` op with two roles

Payer claim (crypto sender): { order_permlink, counterparty, asset, amount, txid[, address] } — "I paid amount asset to counterparty for order O; proof is txid." address is required for external chains, omitted for BLURT (recipient is the Morphit account).
Recipient acknowledgment (crypto receiver): { order_permlink, counterparty, settlement_ref } — "I received the full agreed amount from counterparty for order O," referencing the payer's claim.

Both ops are opt-in and surfaced with an explicit privacy warning ("this publishes a link between your trade and a public transaction") before broadcast.

3. Verification — what makes a settlement "payment-verified"

A settlement is payment-verified iff all hold:

On-chain payment reality (reuse the existing fee-verification machinery — bitcoinExplorerVerifier, the transparent-chain verifiers, BLURT transfer indexing):
- BLURT: the transfer op exists with sender = payer, recipient = counterparty (a Morphit account), amount ≥ claimed. Recipient is proven — no ack needed for identity, but the ack is still required for "full amount" (see 3).
- Transparent external chains: the txid delivered ≥ amount to address. Address→counterparty is unproven on-chain, so it rides on the recipient ack.
Mutual, order-bound reference: payer claims paying counterparty; recipient acknowledges receiving from counterparty; both cite the same order_permlink.
"Full amount" via the recipient, not the indexer: we do not ask the indexer to judge sufficiency (constraint 2 makes that impossible). The receiver — who does know the agreed amount — attests "full." Combined with on-chain proof that a payment of that magnitude actually moved to them, this is strong.
Clean pair + existing gate: the (payer, receiver) pair passes the same verified-chat gate and is not detector-flagged.

4. Weight treatment (tunable)

Two effects, both driven off payment-verified settlements where the subject was the crypto sender:

Rating multiplier in the existing decay formula: SUM(rating · decay · proof_weight) / SUM(decay · proof_weight), with proof_weight ∈ {1 (conversation-only), W (payment-verified)}. Recommend W = 3 as a starting point (a payment-backed review counts like ~3 conversation-only ones); expose as a constant.
A distinct "payment-verified trades" count surfaced alongside the rating. This is arguably the stronger anti-gaming display — a number that costs real on-chain crypto movement to inflate, not just a fabricated conversation.

Alternatives considered

Indexer derives the expected amount from the order. Rejected: orders are ranges/rates; the real amount is negotiated in chat, so the order can't pin "full." Would either false-negative real payments or be trivially gamed by claiming a tiny amount.
Payer-only self-attestation (no recipient ack). Rejected: the payer could cite a real small txid and claim it was the full trade. Proves a payment happened, not that it settled the deal.
On-chain-only, no ack, for all assets. Works for BLURT (recipient is a verifiable Morphit account); fails for external chains (address→counterparty unprovable). Adopted only for the BLURT identity sub-case; the ack still carries "full amount."
Support XMR settlement proofs (opt-in, with a warning). Rejected: even opt-in, it normalizes publishing a tx key that permanently deanonymizes the transaction, on the one asset where that is most harmful, for the exact users who most need privacy. The privacy cost is not worth a reputation nicety. XMR stays conversation-only.
Trusted escrow / oracle attesting settlement. Rejected: violates non-custodial + decentralization principles.

Consequences

Positive

A payment tier that is materially harder to forge than a conversation: a sockpuppeteer must actually move real crypto between addresses they control (real cost + on-chain footprint) and pass the verified-chat gate and evade the reciprocity detector.
Reuses the existing, proven fee-verification machinery.
Degrades gracefully — no proof ⇒ the cp421 verified-chat baseline still applies; the floor never drops.
Respects privacy priority #1 by construction (XMR excluded, opt-in, warned).

Negative

Only the crypto leg is ever provable; cash payers can never earn the tier (inherent, by design).
Privacy-core users (XMR) get no payment tier — a deliberate tradeoff, but it means the tier skews toward transparent-chain traders. Reputation must not punish XMR-only traders for opting out; the multiplier lifts payment-verified reviews rather than demoting others below the baseline, and the "verified-trades" count must be presented as a bonus signal, not a badge of honor whose absence implies distrust.
Second op (the ack) is UX friction — mitigate by prompting for it at feedback time, when both parties are already closing the trade.
Residual gaming: a determined actor moving real crypto between controlled addresses + faking a sustained chat + dodging detectors can forge one settlement. It is expensive and pattern-detectable, but not impossible — the tier raises cost, it doesn't make fraud impossible.
Asset-tiered complexity (BLURT path ≠ external-chain path).

Follow-up work

Final W and whether to also weight by trade size (bigger verified trades → more weight, with strong diminishing returns to avoid a "one huge self-trade dominates" vector).
Exact copy + placement of the privacy warning on the opt-in flow.
A settlement-specific detector (e.g. flag a cluster of accounts circulating the same crypto to manufacture verified trades).
Whether the "verified-trades" count should itself be subject to the suppression filters the rating aggregate already applies.

References

ADR-0014 — Chat and counterparty reputation (the verified-chat badge and the base reputation model this extends).
ADR-0015 — Chat crypto (why amount/recipient live in E2E payloads).
ADR-0026 — Transparent-chain privacy framework (the asset-privacy boundary this decision leans on; XMR's privacy guarantees).
cp421 (TARBALL.md / REVISIT-LIST.md) — the verified-chat gate this builds the weight tier on top of.
apps/indexer/src/indexer/fee/* — the existing on-chain payment-verification machinery to be reused.

13 KiB Raw Permalink Blame History Unescape Escape