XMREscrow - White Paper

[xmrescrow]

*Monero-only, operator-mediated escrow for private peer-to-peer trades.*
Version 1.0 · Covers service v1.0.9-beta

---

## 1. The problem

Peer-to-peer Monero trades have no safety net. When two strangers agree an OTC or P2P deal, one side has to move first - and whoever moves first can be scammed. The buyer who pays up front risks getting nothing; the seller who ships first risks never being paid.

The usual fixes don't fit privacy-focused traders:

- **Centralized exchanges and marketplaces** require accounts, identity verification (KYC), and often ban Monero outright. They also see every trade.
- **Multisig wallets** are trustless but hard to use correctly. Coordinating a 2-of-3 wallet, exchanging keys, and constructing partially-signed transactions is beyond most traders and error-prone even for experts. Monero multisig has historically been fragile.
- **"Just trust each other"** works until it doesn't.

XMREscrow fills the gap between "too hard" (multisig) and "too exposed" (KYC platforms): a simple, no-account escrow that holds funds during a trade and releases them when both sides are satisfied - with a dispute path if they aren't.

## 2. How it works (in plain terms)

1. Two traders agree a deal and open an escrow. No account, no email, no KYC.
2. The buyer sends Monero to the escrow's deposit address.
3. Once the deposit confirms, the seller delivers.
4. The buyer releases the funds to the seller.
5. If something goes wrong, either party opens a dispute and the operator adjudicates.

Each escrow is reachable by a private link. There are no usernames, no login, and no profile tying trades to a person.

## 3. The trust model - stated honestly

**XMREscrow is a *trusted-operator* escrow, not a trustless one.** This is the single most important thing to understand, and we state it plainly rather than dress it up.

During an active escrow, the operator has technical custody of the deposited funds and is the party who resolves disputes. That means:

- You are trusting the operator to release funds correctly and to adjudicate disputes fairly.
- You are trusting the operator's infrastructure to stay secure and available.

This is a real trust assumption. It is the same assumption you make with any human escrow agent, lawyer's trust account, or marketplace escrow - but it is a trust assumption, and multisig does not require it.

We believe the honest response to this is **verifiability, not marketing claims**. Rather than ask you to "trust us," XMREscrow publishes the tools to hold the operator accountable:

- **Public PGP identity** (fingerprint `CD37A31282542C2ACE91FED3A345CD6C2674D00A`) so every official statement can be signed and verified.
- **Warrant canary**, updated on a schedule, so its absence is itself a signal.
- **`/solvency` and `/status` endpoints** so anyone can check the service is live and funds are accounted for.
- **Published Terms of Service and dispute policy** so the rules are the same for everyone.
- **A public track record** via signed version updates and transparent changelogs.

Trust is earned through consistent, verifiable behavior over time. The design goal is to make dishonesty detectable.

## 4. Privacy architecture

XMREscrow is built to collect as little as possible and expose nothing unnecessary:

- **Monero-only.** Every leg of every trade uses XMR, whose ring signatures, stealth addresses, and confidential amounts hide sender, receiver, and value by default.
- **Tor-native.** The service runs as a Tor onion service (`xmrescrobcw33cnm5ajyzn5xaqr5vkdsqxmptc55plgvxsnqybmhszqd.onion`), so users never need to reveal an IP address. A clearnet mirror exists for convenience with an `Onion-Location` header pointing to the onion.
- **No accounts, no KYC, no email.** Nothing to breach, subpoena, or leak, because it is never collected.
- **Zero JavaScript on public pages.** No client-side scripts means no fingerprinting surface, no tracking, and full functionality in the hardened "Safest" Tor Browser setting. Clipboard copy, fee calculation, and toggles are done with pure HTML/CSS and server-side logic.
- **"Invisible" escrows.** An optional mode where the escrow leaves no operator-visible description of what is being traded.
- **Minimal, expiring sessions.** Strict same-site, short-lived sessions; escrows auto-expire.
- **10-language interface** so privacy isn't limited to English speakers.

Privacy here is a *default*, not a setting you have to find.

## 5. Operator verification

Because this is a trusted-operator model, verifying who you're dealing with matters. Every official XMREscrow channel is cross-linked and PGP-anchored:

- **PGP fingerprint:** `CD37A31282542C2ACE91FED3A345CD6C2674D00A` (published at `/pgp.txt` and mirrored in every social bio).
- **X:** @xmrescrow · **Telegram:** @escro / @nonnegotiable · **XMPP:** xmrescrow@conversations.im
- **Warrant canary** and **signed announcements** for anything material.

If a message claims to be from XMREscrow but isn't signed by that key, treat it as an impostor.

## 6. Fee structure

- **Fee:** configurable, currently **2.5%** of the escrow amount.
- **Minimum:** currently **$3 equivalent** (in XMR) per escrow, so tiny trades stay viable while the service stays sustainable.
- **Referral codes** allow partners to offer reduced fees or share revenue via admin-set overrides.
- **Caps:** hard minimum and maximum escrow amounts are enforced to prevent mistakes and abuse.

Fees fund the infrastructure, dispute handling, and continued development. No hidden charges; the fee is shown before you commit via a server-side fee calculator.

## 7. How XMREscrow compares

| | XMREscrow | Monero multisig (2-of-3) | Centralized / KYC escrow |
|---|---|---|---|
| **Trust model** | Trusted operator, verifiable behavior | Trustless (cryptographic) | Trusted operator + custodian |
| **Ease of use** | High - a link, no setup | Low - key exchange, PSTs, fragile tooling | Medium |
| **Account / KYC** | None | None | Required |
| **Dispute resolution** | Operator adjudicates | Whoever holds the tie-breaking key | Platform staff |
| **Privacy** | Monero + Tor + no logs | Monero, but coordination leaks metadata | Usually poor; full visibility |
| **Availability of funds if operator vanishes** | At risk (custodial) | Not at risk | At risk |
| **Best for** | Fast, simple private trades | Users who can run multisig correctly and want zero custody | Users who accept KYC for recourse |

**The honest summary:** if you can run Monero multisig correctly and want no custodial risk, do that — it's cryptographically stronger. XMREscrow exists for the large majority of trades where multisig is impractical and KYC platforms are unacceptable, offering a usable middle path with the trust made as transparent and accountable as possible.

## 8. Design principles

- **Radical transparency** about the trust model as a credibility asset, not a liability.
- **Collect nothing you don't need.**
- **Make dishonesty detectable** through cryptographic identity and public status.
- **Privacy by default**, usability without compromise.

---

*This document describes the service as of v1.0.9-beta and may be updated. Verify the current version and any official statement against the PGP key above. XMREscrow is a tool for private peer-to-peer trading; users are responsible for complying with the laws that apply to them.*

[xmrescrow]

Yes used AI to fix my writing/formatting for a more professional layout. Tend to be all over the place with stuff im passionate about.
The website was developed by me and me only over the passed couple months. everything hosted on my own HW with a priority focus on privacy.
All feedback is noted, Id like to create a good product

[xmrescrow]

Two days of heavy work across the stack. Highlights:

Security & correctness — Completed a full audit of the escrow money-movement flow. Every fund-moving path (release, refund) is now fully atomic and protected against duplicate-submission edge cases. CSRF coverage extended to every state-changing action. Address validation now verifies directly against the Monero wallet instead of surface-level checks. Refund logic corrected so cancelled escrows return the full deposited amount — no fee on refunds, you only pay on a completed release.

New: buyer refund addresses — Buyers can now optionally set a refund address directly from their escrow link. If the operator refunds a disputed or cancelled escrow, funds return there automatically and the refund TX is shown on-chain to verify. Buyers still cannot move funds themselves — refunds remain operator-reviewed, which protects both parties.

Reliability — Migrated clearnet routing to an architecture that no longer depends on home-network port forwarding, eliminating a whole class of outages. Router reboots and ISP hiccups no longer take the site down. Monitoring now covers every service including listener-level health.

Backups — Daily integrity-checked DB backups plus encrypted disaster-recovery bundles, verified restorable.

Roadmap — Researching an optional 2/3 multisig mode for higher-value deals, for users comfortable running Monero wallet software. Given Monero multisig's complexity, this will be prototyped and tested extensively on stagenet before any mainnet release.

Official stable release coming soon.

Private. Monero only. Operator-mediated, honestly.

PGP: CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A

[xmrescrow]

Update — v1.1.3: honest-disclosure pass + Partner Program

Two things since the last update — a correctness pass after a public audit, and a new partner program for Monero sites.

Honest-disclosure pass (audit response)
A public audit flagged some overstated claims. Most were fair, so we corrected the record:

• Cloudflare: the clearnet is CF-fronted for DDoS and injects its own challenge scripts — now disclosed per-surface instead of a blanket "no external JS." The onion has zero third-party code.
  
• "Open source": the shipped monero.js / worker are the unmodified monero-ts build, not our source. The README now pins the exact version + upstream commit and publishes the bundle sha256, so you can diff it against npm yourself.
  
• IP handling: dropped the "one-way hashed = not personal data" line. Anti-abuse now uses a keyed HMAC; raw IPs aren't stored.
  
• GDPR: removed the disclaimer clause — you can't opt out of a regulation with a sentence. We hold no accounts, no email, no IPs.
  
• "Tor-ready": now labeled per-flow — Vault runs fully with JavaScript off (Safest); multisig needs JS (Standard).
  

Partner Program (new)
For Monero markets, directories, and services — offer your users escrow without building it:

• Embed our card (one line of HTML, no JS or keys on your site). It carries your referral code.
• Completed trades from your referrals earn your site a share of the fee, paid in XMR to an address you hold. Costs your users nothing extra.
• Read-only partner panel: referrals, earnings, XMR withdrawals. Access is a one-time token + a PIN we never see.
• Listed sites appear on our Partners page as official partners.

Verify, don't trust

• Client + Build & Verify: github.com/xmrescro/xmrescrow-client
• PGP: CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A (same key on /pgp, /canary, and every announcement)
• Onion: xmrescrobcw33cnm5ajyzn5xaqr5vkdsqxmptc55plgvxsnqybmhszqd.onion

Still no accounts, no KYC, Tor-first. Both flows unchanged. Feedback and teardowns welcome — that's how this gets better.https://xmrescrow.app/blog/v1-1-0

https://xmrescrow.app/blog/v1-1-1

https://xmrescrow.app/blog/v1-1-2

https://xmrescrow.app/blog/v1-1-3-corrections

https://xmrescrow.app/blog/partner-program

[xmrescrow]

Update - v1.1.4: verification, live status, feedback, partner program

Trust-and-transparency release. Neither escrow flow changed - this is about making the service easier to verify, easier to talk to, and easier to build on.

Verify you're on the real site
Escrow services get cloned, so there's now a permanent verification block on the About page listing the only official site, onion, and X account, plus our PGP fingerprint. And what we will never do:

• Never message you first or DM you to start a deal.
• Never ask for your restore key, seed, or PIN.
• Never tell you to move funds to a "new" or "updated" address.

Anything doing those is a scam regardless of how it looks. Real announcements are PGP-signed - check the signature. "Verify site" is now linked in the footer of every page.

Live activity, counts only
The status page shows real signals instead of a static claim: when the last escrow was released, completions in the last 7 days, a 14-day opened/completed table, and the wallet's synced height. Counts only - no amounts, no parties, no identifiers. A dead service can't fake a recent release.

Anonymous feedback
New one-way feedback form. No account, no email, nothing identifying. We store only the message; a short keyed hash stops flooding and can't be reversed to an address. Tell us what's broken.

Partner program
For Monero markets, directories, and services: offer your users escrow without building it. Embed our card (one line of HTML, no JS or keys on your site) and completed trades from your referrals earn your site a share of the fee, paid in XMR to an address you hold. Costs your users nothing extra. Includes a read-only panel and an official listing on our Partners page.

Clearer timing
Both flows enforced timeouts silently; now they're stated up front. Vault escrows auto-cancel if unfunded within 9 hours. Multisig setup expires if both parties don't finish in-browser key setup within 6 hours. Nothing is funded when either window passes, so nothing is at risk - just create a new escrow.

Under the hood
A hardening pass caught a real bug in the operator cold-storage sweep - it drained only the main wallet address instead of every funded subaddress. Fixed and verified end to end. Also verified onion session handling, confirmed proof-of-work DDoS defenses on the hidden service, and added an off-site encrypted backup.

Verify, don't trust

• Client + Build & Verify: github.com/xmrescro/xmrescrow-client
• PGP: CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A
• Onion: xmrescrobcw33cnm5ajyzn5xaqr5vkdsqxmptc55plgvxsnqybmhszqd.onion

Still no accounts, no KYC, Tor-first. Feedback and teardowns welcome.Small update - delivery references, webhooks, and Tor tx broadcast

Three additions since the v1.1.4 post, all user-facing.

Delivery reference
Sellers can now attach a short delivery reference to an escrow - a tracking number, order ID, transfer reference, or "delivered in person" with a date. The buyer sees it before deciding to release, and if a dispute is opened the operator reads it as part of the review. Text only, no file uploads: uploads are a deanonymisation and liability risk we are not willing to add.

Practical effect: disputes get decided on something concrete instead of two people describing events differently.

Optional webhooks
When you create an escrow you can supply an HTTPS URL. We POST a minimal JSON payload to it when the escrow is created and when it completes - the event, the flow type, and the escrow ID. Nothing else: no amounts, no addresses, no party details.

It is push-only. It is not an API, nobody can query us with it, and you only ever receive events for escrows you created yourself. Useful if you run a site or a bot and want to stop polling.

Transactions broadcast over Tor
Our Monero node now relays every transaction it broadcasts through Tor. That covers escrow payouts. It means the transactions we send do not enter the network from a clearnet address tied to this service.

Also
Timing is stated up front on both flows now: Vault escrows auto-cancel if unfunded within 9 hours, multisig setup expires if both parties do not finish their in-browser key setup within 6 hours. In either case nothing has been funded when the window passes, so nothing is at risk - you just create a new escrow.

As always: verify, don't trust. Client and build verification at github.com/xmrescro/xmrescrow-client, PGP CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A.

[xmrescrow]

Update - v1.1.4.5: multisig that tells you what is happening
 
Multisig is where users get stuck, and the reasons are well known across the Monero ecosystem - key exchange breaks if a tab closes at the wrong time, restore errors are cryptic, and a stalled setup looks the same as a broken one. This release goes at that.
 
Pre-flight checks
Before setup starts, the page verifies WebAssembly is available, that your browser will let it save recovery state, and that our node is reachable. Shown as pass or warning. You find out at step zero, not mid-ceremony.
 
Restore-key errors that mean something
The key is now validated before the wallet library ever sees it. You get told it is truncated, corrupted, for a different escrow, or fine - instead of an opaque failure.
 
Presence
The page now shows whether your counterparty is actually there: "on their page right now", "last seen 4 min ago", or "has not opened their link yet". After a minute it says plainly that setup needs both parties present. It also distinguishes a slow counterparty from a network problem instead of sitting silent.
 
Partner webhooks
Sites referring trades can set one webhook URL in their panel. We POST event, flow type, escrow ID and which of your codes was used - no amounts, no addresses, no party details. Push-only; you only get events for your own codes.
 
Fixed: onion users could be wrongly rate-limited
Our anti-flood limits were not behaving correctly for onion visitors - some could be told they were sending too much when they had sent nothing, mainly on the feedback form. Fixed, with a much larger shared allowance for onion traffic sized so ordinary use never hits it.
 
Also
Routine security review this week over the newer parts of the site - partner panel, feedback, webhook paths. Findings addressed same day. We do not publish specifics of internal controls, but the review happened.
 
Client and build verification: github.com/xmrescro/xmrescrow-client
PGP CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A

[xmrescrow]

XMREscrow v1.1.6 - Public reviews, a fee change, and fixes worth naming

Three things in this release. One is a feature people asked for, one costs some of you money and saves others money, and one is a short list of bugs we would rather describe than quietly patch.

Reviews are live

You can now leave a review after a completed escrow, and approved reviews appear on the homepage and on the feedback page.

Reviews carry no escrow ID. The prompt appears after a release, but what you submit is not linked to the trade it came from. Publishing a review cannot be used to show that you traded, when, or for how much. That is deliberate, and it is most of the reason the feature took as long as it did.

Reviews are also approved before they appear, which means you are reading a curated set and should weigh it accordingly. The alternative - an open review box on an escrow site - is a spam and extortion surface. We would rather tell you it is curated than let you assume otherwise. Nothing is public until it is approved, and nothing you submit can publish itself.

The Vault fee changed, in both directions

Vault escrow moves from 1% with a $3 minimum to 1.75% with a $1 minimum.

A $30 trade used to cost $3. That is a 10% fee on a small trade and it was indefensible; it now costs $1. A $1,000 trade used to cost $10 and now costs $17.50. The break-even sits at roughly $170: below that you pay less than before, above it you pay more. You can check any amount with the calculator on the homepage.

Two-of-three multisig is unchanged at 3% with a $3 minimum. The ceremony, the dedicated wallet each escrow gets, and dispute co-signing are genuinely more work, and that minimum is also what funds partner payouts.

We are stating both directions in the same breath on purpose. Announcing a lower minimum while quietly raising the rate is exactly the sort of thing that got picked apart in July, and correctly.

Review approval never worked

The approval path had been broken since the day it shipped, and it went unnoticed because the symptom looked like an empty section rather than an error. Every approval attempt failed, so no review had ever been published.

It is fixed. We also wrote an automated check that scans the whole application for the same class of mistake, and there are no other instances of it.

A near-miss, disclosed

Escrow links contain an access token. That is why request logging is switched off - so those links never end up written to disk. For a limited period, a logging setting was active that could have recorded them.

We checked the file it produced. No escrow links had been written to it, and it was securely erased rather than simply deleted. No funds, escrows or messages were affected, and the setting can no longer be reintroduced the way it was.

We are publishing this because a near-miss you never hear about is indistinguishable from one that never happened. Separately, some temporary diagnostic logging added while investigating has been removed - it never recorded escrow links or tokens, and it should not have outlived the work that created it.

Deposits are counted once

The routine that watches for deposit confirmations was running more often than it should, duplicating identical work and putting needless load on our node. It now runs once, and reports enough about itself that we can tell a quiet system from a stopped one. More than one path could also record a deposit as funded; those now share a single atomic step, so a deposit is recorded exactly once no matter which reaches it first.

What has not changed

Multisig is still the non-custodial option and still the one we recommend for anything you would miss. Vault is still custodial and says so on the page where you choose it. The fee address is published and verifiable on-chain. Every transaction our node broadcasts still leaves over Tor.

Verify, don't trust

Client and build verification: github.com/xmrescro/xmrescrow-client
Signed canary: /canary.txt
PGP: CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A
Onion: xmrescrobcw33cnm5ajyzn5xaqr5vkdsqxmptc55plgvxsnqybmhszqd.onion

Full write-up: xmrescrow.app/blog/v1-1-6-reviews-fees-hardening

[xmrescrow]

XMREscrow v1.1.7 - See exactly what you are signing, every time

This release is about one idea: you should never be asked to sign something you cannot see. Most of the multisig flow already worked that way. One part did not, and that part is fixed.

Dispute payouts are no longer signed blind

When a dispute is resolved, the winning party co-signs a transaction to receive their funds. Until now that step showed them nothing - they clicked a button and a signature went out.

That was the wrong place to ask for trust. A dispute is by definition the moment someone has stopped trusting the other side, and it is the one point in the flow where we build the transaction. It now opens the same review card used everywhere else: destinations read out of the transaction itself, shown to you, nothing signed until you confirm. Cancel and no signature exists.

The buyer now verifies the payout independently

When a buyer releases funds their browser builds the transaction. The review card previously showed amounts and an address our server reported. Now the transaction is built first, then decoded, and the card shows what is actually inside it - the same independent check the seller already had.

New guard: if the amounts changed at all since the page opened, a warning appears above everything else telling you not to sign. In normal operation you will never see it.

Where a browser cannot decode the transaction, the card says so plainly and labels the values as server-reported instead of showing them as if verified.

The payout address is locked in every path

The address a signer reviews should be the address that gets paid. That was already true during a normal release. The dispute path did not have the same lock. Now it does.

Our published hashes now verify on Windows

We publish SHA-256 hashes so you can confirm the code we serve is the code we published. That check had been quietly failing on Windows: Git converted line endings on one file at download time, changing its hash. The file was correct, the instructions were correct, the result still came out wrong - which is worse than no check, because a verification that fails for honest users teaches people to ignore it.

Fixed at the source, and the guide now explains what to check first if a hash does not match. If you tried to verify our client and got a mismatch, that was our bug. Please try again.

Quieter in the background

The "other party is on their page" indicator was writing to our database on every poll for information that only needs half-minute accuracy. It now updates far less often and reads the same to you. Service hardening also continued - the application runs under substantially tighter OS restrictions than before.

What has not changed

Multisig is still non-custodial and still what we recommend for anything you would miss; your key is generated in your browser and never sent to us. Vault is still custodial and says so where you choose it. Fees unchanged: Vault 1.75% + $1 min, multisig 3% + $3 min.

Verify, don't trust

github.com/xmrescro/xmrescrow-client · /canary.txt · PGP CD37 A312 8254 2C2A CE91 FED3 A345 CD6C 2674 D00A
Onion: xmrescrobcw33cnm5ajyzn5xaqr5vkdsqxmptc55plgvxsnqybmhszqd.onion

Full post: xmrescrow.app/blog/v1-1-7-see-what-you-sign