XMR Escrow

⚠ DO NOT USE — Grade demoted C → F on 2026-08-05 for active exit-scam by verified operator.

xmrescrow.app is currently taking new escrows while its operator ("TT" per victim reports; GitHub org display name literally reads `xmrescro (tt)`; @xmrescrow X account previously operated as the real service owner) is actively scrubbing accountability surfaces after at least one on-chain-documented user-loss event.

Evidence chain (all verified 2026-08-05, preserved to the Internet Archive):

• On-chain BTC theft — \$6,000 documented via three verifiable txids on Bitcoin mainnet:
• Test transfer (\$1,000 + \$50 fee, received via Zelle): `46acf6af…5153ee`
• Main transfer 1 (\$6,000 total, never received): `daf6d7f5…c74e14`
• Main transfer 2 (companion): `fa9f9bd9…d87982`
• Community-level corroboration in Monero Society TG group — a second Monero Society community member publicly stated they had already suspected `@xmrescro` of scamming before the victim's evidence surfaced, and that the evidence has now confirmed it for them. Pre-existing suspicion in the community, independent of the initial victim report. Chat log preserved.
• Moderator-abuse pattern in Monero Society Telegram group — victim was banned, muted mid-response, and had messages deleted after complaint. Corroborated by another moderator (Mav) via chat log.
• Operator identity confirmed as `@xmrescrow` on X via a documented DM history between xmrescrow.app operator and xmr.club (screenshots on file) — the operator engaged with our C-rating listing, ran "official updates" against our critiques, discussed roadmap ("out of beta"). Not imposter behavior.
• Operator flight signals coincident with victim's public complaint:
• `@xmrescrow` X account deleted (platform returns "account no longer exists")
• GitHub commit "Contact: XMPP only; drop ref" — active scrub of non-XMPP contact references
• xmrescrow.app `/about` page recently added a "we have no social media accounts" line — contradicting the operator's own DM history with xmr.club
• Site itself still fully operational. Actively accepting new escrows at the moment of this update. Every new escrow is a potential victim.

READER ADVICE — UNAMBIGUOUS:

• Do not initiate a new escrow with xmrescrow.app under any circumstance.
• Do not send funds to any address provided in an existing xmrescrow flow that hasn't yet completed — the operator is actively covering tracks.
• If you have an open dispute or completed escrow with them, treat funds as at material risk and take screenshots of every chat, PGP-signed message, and address NOW before further scrubbing.
• If you were also scammed by the same operator, please submit via /tools/xmrescrow/reviews with your evidence — a cluster of first-party reports may support recovery efforts.

Snapshots preserved to the Internet Archive on 2026-08-05 covering: xmrescrow.app homepage, xmrescrow.app/about (the "no social media" whitewash), github.com/xmrescro (the "tt" org display name), github.com/xmrescro/xmrescrow-client (the codebase state + latest whitewash commit), and the /commits/main history. Reference the Wayback captures if the operator continues scrubbing.

---

*The rest of this review reflects XMR Escrow's live posture prior to the 2026-08-04 incident and is preserved for audit continuity.*

An account-free centralized Monero escrow service. One party creates a deal, the site issues a buyer link and a seller link as single-use session tokens, and the operator's wallet holds the deposited XMR until the buyer clicks release or an admin force-releases on dispute. Listed at Grade C because the service is fresh (first public traces 2026-06), there's no peer-directory track record, the operator (handle `@T_Txmrescrow` on X) is pseudonymous with no published PGP key, and the homepage's "non-custodial" framing is contradicted by the actual flow — but the product itself is a working Monero-only escrow with a Tor mirror and a clearly explained mechanic that some buyers and sellers will find useful for low-value P2P deals.

What it is. A web-based centralized escrow for Monero. Either party (typically the buyer) fills a form on `xmrescrow.app` — optional Alice/Bob labels, XMR amount, optional deal description — and the site returns two URLs with random session tokens (`?t=…`), one for the buyer and one for the seller. The site also issues a Monero subaddress (starts with `8`) under the operator's master wallet; the buyer sends XMR to that subaddress and pastes the transaction ID back into the page. A bot then waits for 10 confirmations and marks the deal as funded. The seller delivers off-platform; the buyer clicks "Release" and the operator's wallet sends to the seller's Monero address. If something goes wrong, either side opens a dispute and the operator's admin "can force-release or refund" — the dispute panel's own words. Clearnet (`xmrescrow.app`) and Tor (`wptywii7…onion`) mirrors serve the same content; both are reachable as of this review.

Background. Operator is pseudonymous — X handle `@T_Txmrescrow` posted a launch tweet on 2026-06-23 announcing "XMRescrow.app is now live! Automated Monero escrow for P2P. I've moved away from personal onboarding and launched a fully automated middleman (MM) service so you can keep transacting p2p privately with trust." The tweet carries a PGP signature, but the site has no about page, no contact page, and no published public key — so the signature can't be checked against anything the operator hosts themselves. The site itself also doesn't link to the X account or to any other operator channel; the tweet is the only thing tying that handle to the service. No peer directory carries the listing yet — not monerica, not kycnot.me, not Monero Observer, not no-kyc.io.

What you trust.

• The operator, fully. The deposit address is a subaddress under the operator's master wallet — every escrow funded sits in that single wallet until released. The operator can move funds at any time without user signatures; the dispute panel says so explicitly ("admin will review and can force-release or refund"). The trust model is "trust the operator to release honestly," not "the math prevents anyone from moving the funds."
• The Tor mirror. The .onion address served from the launch tweet resolves to the same site and returns the same content as the clearnet — meaningful for users who want to negotiate a deal without revealing their IP to the operator or to a CDN.
• The 1-click release path. When the deal goes smoothly, the flow is the simplest possible: buyer pays, waits ten confirmations, clicks Release, seller receives the XMR. No accounts, no email, no KYC, no manual operator intervention.
• The single-use session tokens. Each party authenticates by URL alone (`?t=…`). Treat them like passwords — anyone with the link can act as that party. There's no second factor, no recovery, no account.

Operational specs.

• Site. `xmrescrow.app` (clearnet) and `wptywii7oaqvbe4lb4ko6qlo5rtnat2gj5x57rlrrrvwshl3oorustad.onion` (Tor, same codebase).
• No account. No signup, no email, no KYC. Each escrow's authentication is a single-use URL token per party.
• Wallet model. Centralized. Each escrow gets a subaddress under the operator's master wallet. Funds remain in the operator's wallet for the duration of the deal.
• Confirmations. Bot waits for 10 Monero confirmations before marking a deal as funded.
• Release authority. Buyer's click is the normal path. The operator's admin can force-release or refund on dispute — single-key authority, no multisig.
• Fees. 3.5% of the escrow amount or $3 USD-equivalent in XMR, whichever is greater. On a 0.10 XMR (~$31 at $315/XMR) escrow the minimum-fee floor dominates and the effective fee is ~9.4%; the marketed 3.5% rate only kicks in once the escrow is large enough that 3.5% > $3 (about ~$86 / ~0.27 XMR and up).
• Disclosed BETA. Operator's launch tweet describes the service as "In BETA" and as a *"fully automated middleman (MM) service"* — the operator's own framing is centralized middleman, even where the homepage marketing reads "non-custodial."
• Codebase. Closed-source as far as anyone can see — no GitHub link on the site, no repo URL anywhere. "Hosted locally" per the launch tweet.
• Channels. X `@T_Txmrescrow`. No Matrix, Signal, SimpleX, GitHub, or published PGP key on the site itself.

Operator philosophy. Marketed as private, non-custodial, trustless: *"Peer-to-peer Monero escrow. Private, non-custodial, and works over Tor. No accounts. No KYC. Just a secure hold between two parties."* In practice it is centralized escrow — the operator holds funds during the deal and is the sole authority on disputes. The homepage uses "non-custodial" in a marketing sense (the buyer and seller don't have a *xmrescrow.app* account or fiat custodian behind them) rather than the strict cryptographic sense the term carries in the Monero community, where it means party-held keys / multisig. By that strict definition — the one this directory uses for the `non_custodial` tag — xmrescrow.app is not non-custodial. The directory lists it honestly as what it actually is: an account-free *centralized* escrow with a Tor mirror.

Grade rationale. Listed at Grade C because the service is fresh, the operator is pseudonymous with unverified-from-site identity, the marketing-vs-mechanics gap exists (claimed non-custodial, actually custodial), and no peer-directory has independently reviewed it yet. Custodial-escrow services hold real user funds for real time, which is a high-loss-asymmetric position even when the operator is honest — so the tenure floor applies regardless of how clean the published surface looks. Path to B: publish operator PGP public key + site→X bidirectional ownership proof; correct the homepage to drop "non-custodial" or document an actual 2-of-3 multisig flow; accumulate ≥6 months of incident-free operation with documented dispute outcomes; pick up at least one independent peer-directory review (monerica, kycnot). Path to A: all of the above plus a year of incident-free operation on real escrow volume and a published source repo so the bot, the subaddress generation, and the dispute logic can be audited.

Useful when.

• You're doing a small P2P trade with a counterparty who refuses to ship first, and neither side wants the friction of installing a multisig wallet or coordinating a 2-of-3 setup over chat. A centralized escrow with no account barrier is the path of least resistance and 3.5% (above $86) is a reasonable price for that simplicity.
• You want a Tor-native escrow service — the .onion mirror is the same site as the clearnet and serves identical content, so you can negotiate a deal end-to-end without ever touching the clearnet.
• You're a buyer and want a single-click release UX once the seller delivers, rather than running a multisig signing ceremony.

Not useful when.

• The trade is large. Holding 1+ XMR in a third party's wallet for the duration of a deal is a different risk profile than the ~$30 escrow this service is implicitly priced for.
• You actually need cryptographic non-custody. Use Haveno, AgoraDesk's 2-of-3 multisig flow, or XMRTrades for that.
• You can't keep the session-token URL safe. Lose the link and you lose access; the operator is the only path back in.

Caveats.

• "Non-custodial" framing is marketing, not mechanics. The homepage and the operator's X post both use the word, but the dispute panel says verbatim *"admin will review and can force-release or refund"* — that is single-key custodial authority. The directory does not tag this listing `non_custodial`. Read the service for what it is: a centralized middleman that the homepage describes in the slightly looser community sense of "no fiat-custodian, no KYC, you don't have an account here." The strict cryptographic sense doesn't apply.
• Operator identity unverified from the site. The X handle `@T_Txmrescrow` claiming to be the operator can't be cross-checked against the site itself — no link, no PGP key. If the X account is compromised or impersonated, you'd only find out by the discrepancy after the fact.
• Fee cliff on small escrows. $3 USD minimum hits hard below 0.27 XMR. A 0.10 XMR escrow eats 9.4%, a 0.05 XMR escrow eats 19%. The 3.5% headline is only the truth once the escrow is large enough that 3.5% > $3.
• Token-loss equals fund-loss for the buyer path. Single-use URL tokens with no recovery. If the buyer's link is lost before release, the buyer can't trigger Release; the seller has to flag dispute and rely on the operator's admin to force-release. If the link leaks, anyone with the URL can act as that party.
• No published security review, no published source. The proof-verification path, the subaddress generation, and the dispute logic are all opaque to outside review. The operator says "hosted locally" but there's no published infrastructure attestation or repo URL to check.
• BETA, self-disclosed. Operator's own launch tweet calls it "In BETA" and asks for feedback. Treat dispute outcomes and edge cases accordingly until the service settles.
• No peer-directory coverage. Not listed on monerica, kycnot.me, Monero Observer, or no-kyc.io. The only public signal of life is the operator's own X account.