メールも電話も不要でも：両替で実際にあなたを識別するもの

注文フォームが実際に集めるもの

veilswap.ioの両替は7フィールドのPOSTです。fromAsset、toAsset、fromAmount、toAddress、toExtraId、refundAddress、refundExtraId。うち2つはタグが必要なチェーン向けのメモ欄、5つが必須で、10月25日以降は返金先アドレスも必須の5つに入ります。アカウントもメールも電話も氏名も署名もありません。2026年10月30日06:02 UTCにルートとスキーマを読み直しました。ハンドラはこの7キーだけを分解するので、本文にemailを足しても黙って無視されます。書き込み先のordersテーブルは20列（id、corridor、2資産、2金額、受取アドレス、返金アドレス、プロバイダ、プロバイダ注文ID、入金アドレス、入金メモ、マークアップ、アフィリエイト2列、状態、プロバイダ状態、3つのタイムスタンプ、valid_until）。個人を特定する列は1つもありません。

Cookieはゼロ、それでも3つの識別子

/、/exchange、/api/quote のレスポンスヘッダも取得しました。3つともSet-Cookieはゼロ。セッションCookieも訪問者IDもログインもありません。ただし匿名と同義ではなく、正直な一覧は短いものです。第一に入金アドレス。注文ごとに新規生成され、チェーン上に永久に残り、知った者は出金まで追えます。第二にURLの注文ID。/api/order/<id> はログインなしで入金アドレス・状態・金額を返すので、リンク自体がパスワードの役割をします。第三にIP。エンドポイントはCF-Connecting-IPを読み、これで制限します。1IPあたり毎時6注文、全体120、IP＋コリドー＋金額＋受取アドレスの90秒重複ガード。これが系全体で最も「身元」に近いもので、中身はネットワークアドレスでありメールボックスではありません。

実際にサポートへ書いた場合に残る記録

メールボックスが本当の漏洩面なのは、自分自身の言葉で書き込む唯一の場所だからです。06:03 UTC時点のDNSは、MXがroute1/2/3.mx.cloudflare.net（Cloudflare Email Routing）、SPFがv=spf1 include:_spf.resend.co ~all、送信署名用にresend._domainkey、DMARCがv=DMARC1; p=none; rua=mailto:[email protected]。レポートは同じ受信箱に戻り、p=noneは「認証失敗でも受信側は何もしなくてよい」という指示です。MTA-STSもTLS-RPTもありません。Workerを通過したメールはJSON1行になり、タイムスタンプ、Message-ID、From、To、件名、最大20,000文字の本文、元サイズが残ります。From/Toは320文字、件名は500文字で切り、重複は直近300件とMessage-IDで照合して捨てます。本文先頭700文字はTelegramにも送られるため、メッセージ基盤にも写しが残ります。

捨てるもの、それでも残るもの

Receivedチェーンは破棄するので、中間ホップやクライアントIPはファイルに残りません。添付は解析せず、text/plain（無ければタグを外したHTML）だけを保存します。隠すより書くべき注意が2つ。本文抽出に失敗した場合は生メール（最大8MB）を調査用に保存します。そしてそのJSONLに自動失効はなく、人が整理するまで増え続けます。残るMessage-IDも中立ではありません。送信側メールシステムが発行し、通常はそのホスト名やキューIDを含むため、Gmail利用者か企業テナントかプライバシー中継かが一目で分かります。

1つのアドレスは秘密ではなく結合キー

「別のメールを使え」は定番の助言ですが、安上がりな方法は成立しません。Gmailはローカル部のドットを無視するので j.doe@ と jdoe@ は同じ受信箱です。プラス addressing（RFC 5233）は事業者が実装する慣習でプロトコルの強制ではなく、どの+タグも同じ受信箱・同じ復旧電話・同じログイン履歴に落ちます。2つのデータセットを並べると、USDTを売った取引所は氏名・書類・そのアドレスを持っています。同じアドレスから両替所へ書けば、結合はそのキーで成立し、結合の片側だけが匿名です。サブアドレスは名簿売買には効きますが、相関には効きません。 (XMR→USDT 出口ルート)

電話番号はより悪い鍵

電話番号がアドレスより悪い理由は3つ。第一に実名の錨で、SIM購入に身分証を求める法域が増えています。第二に再利用され、事業者は解約番号をプールへ戻して再割当するため、今日の識別子が来年は他人のものになり、アカウント履歴だけが残ります。第三にSMSはNIST SP 800-63Bで「制限付き認証器」とされ、SIMスワップを理由に高い保証レベルでは認められません。これは注文フロー（電話欄なし）には関係しませんが、資金経路に関係します。USDTを売った取引所が番号を持つなら、その番号があなたの身元と、両替で終わるオンチェーン軌跡をつなぐ鍵になります。 (XMR→USDT 出口ルート)

実際に身元を分ける6つのルール

1) 金銭に関わる相手ごとに別名を1つ。自ドメインのcatch-allか有料の別名サービスを使い、どこに何を渡したか記録する。2) 本文に入金アドレス、txid、金額を書かない。注文IDとUTC時刻だけを伝え、残りは内部で照合させる。3) 当社を名乗るメールはヘッダを見る。当社のDMARCはp=noneなので、偽装を拒否するよう受信側に指示できません。DKIMのd=とMessage-IDを確認し、「新しいアドレスへ送れ」は攻撃として扱う。4) サポートへの連絡は両替と同じプライベートウィンドウと同じ経路で行い、仕事用のブラウザプロファイルを使わない。5) 注文URLはパスワードとして扱う。唯一の資格情報です。6) 電話はTOTPを優先し、SMSは復旧経路であって認証要素ではないと考える。

名指しする価値のある4つの誤り

第一に「アカウントなし」を「記録なし」と読むこと。アクセスログはリクエスト行とCloudflareのクライアントIPを14日保持し、注文ページを開けば /order/<uuid> がそのIPの隣に書かれます。第二に一時メールのドメインを匿名とみなすこと。それは他人が運用する受信箱で、返金について人が連絡する唯一の経路でもあります。第三に偽装対策が自分を守ると考えること。From行は証拠ではなく、p=noneを公開するドメインはそれを証拠にできません。第四に、両替所が聞かないからと電話を任意とみなすこと。2ステップ前の取引所はほぼ確実に聞いており、保存しています。

今日の見積と、それがこの記事に関係する理由

サポートに書かれる内容の大半は、注文ごとの固定控除です。2026年10月30日06:03 UTCの数字を置きます。100 USDT-TRC20 は 0.14880521 XMR、500 は 0.81690534、1,000 は 1.65206439、5,000 は 8.33155676。XMRあたり 672.02、612.07、605.30、600.13 USD で、現物 589.09 に対して 14.1%、3.9%、2.8%、1.9% 高い計算です。逆方向は 1 XMR が 570.560438 USDT（-3.1%）。0.05 BTC は 6.56135913 XMR（131.22718 XMR/BTC）で、入り 3,920.65 USD、出 3,865.23 USD。当時のカタログは75ネットワーク518資産、うち7つがメモ必須。価格は毎分動くので最新の見積を読んでください。 (XMR→USDT 出口ルート)

短くまとめると

7フィールド、Cookieゼロ、そして重要な3つの artefacts（入金アドレス、注文リンク、接続元のネットワーク）。人が返信する必要がある場合だけメールを渡し、そこ以外で使っていない別名を使い、KYC取引所が知っているアドレスは決して使わないこと。主張を信じるより検証したいなら、小額の注文を作り、開発者ツールで全レスポンスヘッダのSet-Cookieを検索してください。見つかりません。