No Email, No Phone: What Still Identifies Your Swap

What the order form actually collects

A swap on veilswap.io is a POST with seven fields: fromAsset, toAsset, fromAmount, toAddress, toExtraId, refundAddress and refundExtraId. Two of them are memo fields for chains that need a tag, five are mandatory - and since 25 October the refund address is one of the mandatory five. There is no account, no email, no phone, no name, no signature. We re-read the route and the schema at 06:02 UTC on 30 October 2026: the handler destructures exactly those keys, so an extra email key in the body is silently ignored, and the table it writes to has 20 columns - id, corridor, the two assets, the two amounts, payout address, refund address, provider, provider order id, deposit address, deposit extra id, markup, two affiliate fields, status, provider status, three timestamps and valid_until. Not one of them identifies a person. (recovering misdirected funds)

No cookie, but three identifiers anyway

We also pulled response headers from /, /exchange and /api/quote: zero Set-Cookie on all three. No session cookie, no visitor id, no login. That is still not the same as anonymous, and the honest list is short. First, the deposit address: fresh per order, permanent on-chain, and whoever learns it can follow the payout. Second, the order id in the URL - /api/order/<id> returns deposit address, status and amount to anyone holding it, without a login, so the link behaves like a password. Third, your IP: the endpoint reads CF-Connecting-IP and keys its limits on it - 6 orders per IP per hour, 120 globally, and a 90-second duplicate guard on IP plus corridor plus amount plus payout address. That is the closest thing to an identity in the whole system, and it is a network address, not a mailbox.

If you do write to support, this is the record

The mailbox is a real leak surface precisely because it is the one place you type in your own words. Our DNS at 06:03 UTC: MX to route1/2/3.mx.cloudflare.net (Cloudflare Email Routing), SPF v=spf1 include:_spf.resend.co ~all, a resend._domainkey selector for outbound signing, and DMARC v=DMARC1; p=none; rua=mailto:[email protected] - reports go into the same inbox, and p=none tells receivers to take no action when a message fails. No MTA-STS, no TLS-RPT record. A message that clears the worker becomes one JSON line: timestamp, Message-ID, From, To, subject, body text up to 20,000 characters, raw size. From and To are capped at 320 characters, subject at 500, duplicates are dropped by Message-ID against the last 300 records, and the first 700 characters are also pushed to Telegram - so a messaging platform holds a copy as well.

What is dropped, and what survives anyway

The Received chain is discarded, so intermediate hops and your client IP are not in the file; attachments are not parsed; only the text/plain part, or a de-tagged HTML fallback, is kept. Two caveats we would rather state than hide. If body extraction fails, the full raw message - up to 8 MB - is dumped to disk for debugging. And that JSONL file has no automatic expiry: it grows until a human prunes it. The Message-ID that survives is not neutral either. It is minted by the sending mail system and normally carries that system's hostname or a queue id, so one glance separates a Gmail user from a corporate tenant from a privacy relay.

One address is a join key, not a secret

Use a different email is the standard advice, and the cheap versions of it do not work. Gmail ignores dots in the local part, so j.doe@ and jdoe@ are one mailbox. Plus-addressing (RFC 5233) is a convention a provider chooses to implement, not something the protocol enforces, and every +tag lands in the same inbox with the same recovery phone and the same login history. Now put the two datasets side by side: the exchange that sold you the USDT has your name, your documents and that address. If you then write to a swap desk from the same address, the join is made by the key - and only one side of that join is anonymous. Subaddressing is good against a list being sold; it is useless against correlation. (XMR to USDT exit)

The phone number is the worse key

A number is worse than an address on three counts. It is a real-name anchor, because buying a SIM requires ID in a growing list of jurisdictions. It is recycled: carriers return disconnected numbers to a pool and reassign them, so today's identifier becomes next year's stranger while the account history stays attached. And SMS as a factor is what NIST SP 800-63B calls a restricted authenticator - not accepted at the higher assurance levels, precisely because of SIM swap. None of this touches our order flow, which has no phone field. It touches the funding path: if the exchange that sold you the USDT holds your number, that number is the key between your identity and the on-chain trail that ends at your swap. (XMR to USDT exit)

Six rules that actually separate identities

1) One alias per money-adjacent counterparty - your own domain with a catch-all, or a paid alias service - and keep a note of which alias went where. 2) Never put a deposit address, txid or amount into an email body; quote the order id and the UTC timestamp and let support look the rest up internally. 3) Read the headers of any mail that claims to be from us: our DMARC is p=none, so we cannot instruct your provider to reject a forgery. Check the DKIM d= domain and the Message-ID, and treat any instruction to send funds to a new address as an attack. 4) Do support from the same private window and route you swap from, not from the browser profile you use for work. 5) Treat the order URL as a password - it is the only credential. 6) For phones, prefer TOTP and assume SMS is a recovery channel, not an auth factor.

Four mistakes worth naming

First, reading no account as no record: access logs still hold the request line and the Cloudflare client IP for 14 days, and visiting an order page writes /order/<uuid> next to that IP. Second, treating a temp-mail domain as anonymity - it is a mailbox somebody else operates, and it is also the only channel if a human has to reach you about a refund. Third, assuming anti-spoofing protects you: the From line is not evidence, and a domain publishing p=none cannot make it one. Fourth, treating the phone as optional because the swap site never asks - the exchange that sold you the coins two steps earlier almost certainly did, and it kept it.

What today's quotes look like, and why it belongs here

The fixed deduction per order is what most support mail is actually about, so here are the numbers at 06:03 UTC on 30 October 2026. 100 USDT-TRC20 bought 0.14880521 XMR, 500 bought 0.81690534, 1,000 bought 1.65206439 and 5,000 bought 8.33155676 - that is 672.02, 612.07, 605.30 and 600.13 USD per XMR against 589.09 spot, so 14.1%, 3.9%, 2.8% and 1.9% over. Selling 1 XMR returned 570.560438 USDT (-3.1%). 0.05 BTC bought 6.56135913 XMR at 131.22718 XMR per BTC: 3,920.65 USD in, 3,865.23 USD out. The catalog at that moment was 518 assets on 75 networks, 7 of them needing a memo. Read the live quote - these move every minute. (XMR to USDT exit)

The short version

Seven fields, zero cookies, and three artefacts that matter: the deposit address, the order link, and the network you connect from. Hand over an email only where a human genuinely has to reply, from an alias that exists nowhere else, and never from the address a KYC exchange already knows. If you would rather test the claim than trust it, place a small order, open dev tools and search every response header for Set-Cookie. You will not find one.