이메일도 전화번호도 없이: 스왑에서 실제로 당신을 식별하는 것

주문 폼이 실제로 받는 것

veilswap.io 주문은 필드 7개짜리 POST입니다. fromAsset, toAsset, fromAmount, toAddress, toExtraId, refundAddress, refundExtraId. 두 개는 태그가 필요한 체인용 메모 필드, 다섯 개는 필수이며 10월 25일부터 환불 주소도 필수 다섯 개에 포함됩니다. 계정도 이메일도 전화번호도 이름도 서명도 없습니다. 2026-10-30 06:02 UTC에 라우트와 스키마를 다시 확인했습니다. 핸들러는 이 7개 키만 구조분해하므로 본문에 email을 추가해도 조용히 무시되고, 기록되는 orders 테이블은 20개 컬럼(id, corridor, 두 자산, 두 금액, 수취 주소, 환불 주소, 프로바이더, 프로바이더 주문 ID, 입금 주소, 입금 메모, 마크업, 제휴 2개 컬럼, 상태, 프로바이더 상태, 타임스탬프 3개, valid_until)입니다. 사람을 식별하는 컬럼은 하나도 없습니다. (모네로 확인 대기)

쿠키는 없지만 식별자는 셋

/, /exchange, /api/quote의 응답 헤더도 확인했습니다. 세 곳 모두 Set-Cookie가 없습니다. 세션 쿠키도 방문자 ID도 로그인도 없습니다. 그래도 익명과 같은 뜻은 아니며, 정직한 목록은 짧습니다. 첫째, 입금 주소. 주문마다 새로 생성되고 체인에 영구히 남으며, 아는 사람은 출금까지 추적할 수 있습니다. 둘째, URL의 주문 ID. /api/order/<id>는 로그인 없이 입금 주소·상태·금액을 반환하므로 링크 자체가 비밀번호 역할을 합니다. 셋째, IP. 엔드포인트는 CF-Connecting-IP를 읽어 제한을 겁니다. IP당 시간당 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도 없습니다. 워커를 통과한 메일은 JSON 한 줄이 됩니다. 타임스탬프, Message-ID, From, To, 제목, 최대 20,000자 본문, 원본 크기. From/To는 320자, 제목은 500자로 자르고, 중복은 최근 300건과 Message-ID로 대조해 버립니다. 본문 앞 700자는 Telegram으로도 전송되므로 메시징 플랫폼에도 사본이 남습니다. (모네로 확인 대기)

버리는 것과 그래도 남는 것

Received 체인은 버리므로 중간 홉과 클라이언트 IP는 파일에 남지 않습니다. 첨부는 파싱하지 않고 text/plain(없으면 태그를 제거한 HTML)만 저장합니다. 숨기기보다 적는 편이 나은 주의점이 둘 있습니다. 본문 추출에 실패하면 원본 메일(최대 8MB)을 조사용으로 저장합니다. 그리고 그 JSONL에는 자동 만료가 없어 사람이 정리할 때까지 계속 늘어납니다. 남는 Message-ID도 중립적이지 않습니다. 발신 메일 시스템이 발급하며 보통 그 호스트명이나 큐 ID를 담으므로, 한눈에 Gmail 사용자인지 기업 테넌트인지 프라이버시 릴레이인지 구분됩니다.

이메일 주소 하나는 비밀이 아니라 조인 키

'다른 이메일을 써라'는 표준 조언이지만 값싼 방법은 통하지 않습니다. Gmail은 로컬 파트의 점을 무시하므로 j.doe@와 jdoe@는 같은 받은편지함입니다. 플러스 주소(RFC 5233)는 사업자가 선택해 구현하는 관례일 뿐 프로토콜이 강제하는 것이 아니며, 모든 +태그가 같은 받은편지함·같은 복구 전화번호·같은 로그인 이력으로 들어갑니다. 두 데이터를 나란히 놓으면 USDT를 판 거래소는 이름, 서류, 그 주소를 갖고 있습니다. 같은 주소로 스왑 데스크에 메일을 쓰면 조인은 그 키로 성립하고, 조인의 한쪽만 익명입니다. 서브주소는 명단 판매에는 유효하지만 상관관계에는 무력합니다. (XMR→USDT 출구 루트)

전화번호는 더 나쁜 키

전화번호가 이메일보다 나쁜 이유는 셋입니다. 첫째, 실명 앵커입니다. SIM을 사려면 신분증이 필요한 관할이 늘고 있습니다. 둘째, 재활용됩니다. 통신사는 해지된 번호를 풀에 되돌려 재할당하므로 오늘의 식별자가 내년에는 남의 것이 되고, 계정 이력만 붙어 남습니다. 셋째, SMS는 NIST SP 800-63B가 '제한된 인증기'로 분류하며 SIM 스왑 때문에 높은 보증 수준에서 허용되지 않습니다. 이는 전화 필드가 없는 주문 흐름과 무관하지만 자금 경로와는 관련됩니다. USDT를 판 거래소가 당신의 번호를 갖고 있다면, 그 번호가 신원과 스왑에서 끝나는 온체인 흔적을 잇는 키가 됩니다. (XMR→USDT 출구 루트)

실제로 신원을 분리하는 여섯 규칙

1) 돈과 관련된 상대마다 별칭 하나. 자체 도메인 캐치올이나 유료 별칭 서비스를 쓰고 어디에 무엇을 줬는지 기록합니다. 2) 본문에 입금 주소, txid, 금액을 쓰지 않습니다. 주문 ID와 UTC 시각만 알리고 나머지는 내부에서 조회하게 합니다. 3) 우리를 사칭하는 메일은 헤더를 봅니다. 우리 DMARC는 p=none이라 수신 측에 위조 거부를 지시할 수 없습니다. DKIM d= 도메인과 Message-ID를 확인하고 '새 주소로 보내라'는 지시는 공격으로 취급합니다. 4) 고객센터 연락은 스왑에 쓰는 같은 프라이빗 창과 경로로 하고, 업무용 브라우저 프로필은 쓰지 않습니다. 5) 주문 URL은 비밀번호로 취급합니다. 유일한 자격 증명입니다. 6) 전화는 TOTP를 우선하고 SMS는 복구 경로로 보되 인증 요소로 보지 않습니다. (모네로 확인 대기)

이름 붙일 가치가 있는 네 가지 실수

첫째, '계정 없음'을 '기록 없음'으로 읽는 것. 접근 로그는 요청 라인과 Cloudflare 클라이언트 IP를 14일 보관하고, 주문 페이지를 열면 /order/<uuid>가 그 IP 옆에 기록됩니다. 둘째, 임시 메일 도메인을 익명으로 보는 것. 남이 운영하는 받은편지함이며, 환불 관련해 사람이 연락할 유일한 경로이기도 합니다. 셋째, 위조 방지가 자신을 보호한다고 믿는 것. From 줄은 증거가 아니고, p=none을 게시한 도메인은 그것을 증거로 만들 수 없습니다. 넷째, 스왑 사이트가 묻지 않으니 전화번호가 선택이라 여기는 것. 두 단계 전 코인을 판 거래소는 거의 확실히 물었고 보관했습니다.

오늘의 견적과 이것이 이 글에 속하는 이유

고객 문의의 대부분은 주문당 고정 차감액입니다. 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개, 쿠키 0개, 그리고 실제로 중요한 세 가지: 입금 주소, 주문 링크, 접속한 네트워크. 사람이 답해야 할 때만 이메일을 주고, 오직 그곳에서만 쓰는 별칭으로 주며, KYC 거래소가 이미 아는 주소는 절대 쓰지 마세요. 주장을 믿기보다 검증하려면 소액 주문을 만들고 개발자 도구에서 모든 응답 헤더의 Set-Cookie를 검색해 보세요. 없습니다.