크립토 스왑 환불 주소는 어디로 써야 하나 (쓰면 안 되는 곳)

모든 인스턴트 스왑은 두 개의 주소를 요구하지만, 진지하게 고민되는 것은 그중 하나뿐입니다. 지급 주소는 명백합니다 — 코인이 착지하는 곳입니다. 두 번째 필드, 즉 환불 주소는 보통 다른 탭에 열려 있는 소프트웨어 지갑, 하드웨어 지갑, 거래소 입금 주소, 또는 반년 전 채팅에서 복사한 문자열로 채워집니다. 값비싼 실수는 이 두 번째 칸에서 발생합니다. 작성 시점(2026-10-15) 기준 저희 견적 API는 100 USDT-TRC20에 대해 0.1621607 XMR, 0.01 BTC에 대해 1.46243728 XMR을 반환했습니다 — 주문이 실패하고 환불이 아무도 쓸 수 없는 곳으로 떨어지면 이 숫자는 당신에게 오지 않습니다. 이 글은 어느 주소를 써야 하는지, 그리고 틀렸을 때 실제로 무슨 일이 일어나는지를 다룹니다. (XMR→USDT 출구 루트)

환불 주소는 입금 네트워크의 주소이며, 지급 네트워크의 주소가 아니다 대부분이 반대로 이해하는 지점이고, 규칙은 한 문장입니다: 환불은 당신이 보낸 자산을, 당신이 보낸 체인 위에서 되돌려줍니다. API 문서는 이를 한 번의 요청으로 보여줍니다 — eth-eth 주문에서 지급 주소는 비트코인 주소(bc1q…), 환불 주소는 이더리움 주소(0x…)입니다. 한 주문에 두 네트워크가 공존하고, 이를 도와줄 네트워크 선택기는 없습니다. 지급 네트워크의 주소를 환불 칸에 넣으면 대개 형식 오류로 거부됩니다. 가끔은 통과되고, 문제는 환불이 브로드캐스트되는 시점에 드러납니다 — 받는 체인이 쓸 수 없는 자금이 되는 것입니다. 작성 시점에 VeilSwap은 74개 네트워크의 541개 자산을 집계하므로, 한 주문의 두 주소가 서로 다른 체인에 놓이는 편이 오히려 일반적입니다.

환불 경로가 실제로 사용되는 시점 환불은 흐름의 본선이 아니라 가장자리입니다. 주문은 waiting_deposit으로 열리고 confirming, settling을 거쳐 paid에 이릅니다. 30분 안에 입금이 없으면 입금 주소는 만료되고 주문은 닫힙니다 — 자금은 애초에 저희에게 맡겨진 적이 없으므로 환불할 것도 없습니다. 입금이 도착했는데 스왑이 완료되지 못하면(경로 소멸, 제공자 체결 거부, 금액이 페어 한도를 벗어남) 보낸 자산이 반환됩니다. 주문 페이지에 명시된 정직한 한계가 있습니다: 안내 금액을 크게 밑도는 입금은 처리할 수 없고 환불도 할 수 없습니다. 그러니 본인이 보낸 트랜잭션 ID를 보관하세요. 환불이 브로드캐스트되면 주문 페이지에 그 해시가 표시되어, 이야기의 앞부분과 뒷부분이 각각 체인에서 독립적으로 검증 가능한 상태로 남습니다.

자기 보관 주소가 거래소 입금 주소보다 나은 이유: 세 가지 구체적 결과 첫째, 귀속입니다. 거래소 입금 주소는 신원 확인을 통과한 계정에 속합니다. 환불이 그곳에 도착하면 거래소는 그 입금의 금액과 시각, 출처를 관측합니다. 본인이 관리하는 지갑으로의 환불은 본인 명의 주소 사이의 이동에 그칩니다. 둘째는 메커니즘 문제로, 메모(태그) 체인입니다. 저희 카탈로그에서 7개 자산은 주소와 함께 메모·태그를 요구합니다(XRP, XLM, HBAR, ATOM, Algorand판 USDC, Stacks 등). 이런 체인에서 태그 없이 거래소 주소로 환불을 보내면 자금은 거래소의 통합 지갑에 떨어지고, 입금 계상은 체인이 아니라 고객지원 절차에 달리게 됩니다. 셋째는 최소 금액입니다. 거래소는 입금을 계상하는 자체 기준선을 두며, 2026-10-15 기준 1 XMR은 0.00657903 BTC로 견적되었습니다 — 그 규모의 환불은 아무도 읽지 않은 기준선 아래에 머물 수 있습니다. 자기 보관 주소는 이 세 가지를 한 번에 제거합니다. (모네로 확인 대기)

대부분을 막아주는 규칙: 환불받고 싶은 지갑에서 보내라 따로 지정하지 않으면 환불은 당신이 보낸 주소로 돌아갑니다 — 즉 가장 안전한 환불 대상은 보내는 데 쓰는 그 지갑입니다. 구조상 반드시 올바른 네트워크에 있고, 이미 당신이 보유하고 있습니다. 함정은 거래소입니다. 거래소에서 출금할 때 자금을 지출하는 주소는 거래소의 핫월렛이며 당신의 입금 주소가 아닙니다. 핫월렛에 도착한 환불은 당신이 볼 수도, 증명할 수도, 항의할 수도 없는 내부 회계 처리이고, 그중 일부는 아예 계상되지 않습니다. 자금이 이미 거래소에 있어 반드시 그곳에서 나가야 한다면, 주문 생성 시 10초만 더 써서 환불 칸에 본인이 보유한 지갑의 주소를 입금과 같은 네트워크로 적으세요.

환불에 드는 비용, 그리고 비용이 거의 문제가 되지 않는 이유 환불은 평범한 온체인 거래이므로 그 네트워크의 시세를 지불합니다. 2026-10-15 비트코인 멤풀은 가벼웠습니다: 미확인 거래 80,607건, 합계 39.47 MvB, 권장 최속 요율 1 sat/vB. 전형적인 단일 입력·이중 출력 SegWit 거래는 약 141 vB이므로 대략 141 사토시, 0.00000141 BTC입니다. 이 수준에서 비용이 환불 실패의 원인이 되는 일은 거의 없습니다. 네트워크마다 과금 방식은 다릅니다. TRC20 전송은 요율 시장에 입찰하는 대신 에너지와 대역폭을 소모하므로, 그 시점은 송신 측의 에너지 보유량에 달려 있고 얼마를 지불하는지와는 무관합니다. 실용적 결론은 이렇습니다 — 사람들이 실제로 쓰는 체인에서는 돈이 문제인 경우가 드물고, 문제는 주소입니다. (모네로 확인 대기)

보내기 전 다섯 가지 확인 하나, 네트워크 일치 — 환불 대상은 지급 자산이 아니라 입금 자산의 네트워크여야 합니다. 둘, 메모·태그 — 태그가 필요한 자산은 주문 흐름이 이를 표시합니다. 그대로 복사하세요. 선택 사항이 아니고, 당신의 주문 ID도 아닙니다. 셋, 발신 주소 확인 — 지갑이 실제로 지출할 주소를 읽어보세요. 거래소나 컨트랙트에 속한다면 환불은 스스로 되찾을 수 없는 곳에 떨어진다고 보세요. 넷, 형식 점검 — 제대로 된 지갑은 서명 전에 잘못된 주소를 거부합니다. 당신의 지갑이 거부하는 주소를 스왑 폼이 받아들였다면 멈추고 다시 확인하세요. 다섯, 복사본의 신선도 — 채팅 기록, 스크린샷, 편집되었을 수 있는 메모가 아니라 지갑 자체에서 복사하세요. (모네로 확인 대기)

실제로 일어나는 실수들 환불 실패는 거의 모두 여섯 가지 습관 중 하나로 귀결됩니다: 해당 계정에서 이미 폐기된 거래소 입금 주소를 적었다 / 지급 네트워크의 주소를 환불 칸에 넣었다 / 거래소 핫월렛에서 입금해 발신 주소가 애초에 내 것이 아니었다 / 태그 체인에서 태그를 빠뜨렸다 / 컨트랙트나 지갑 내장 스왑이 쓰는 릴레이처럼 자금을 받을 수 없는 주소에서 보냈다 / 그리고 환불도 불가능할 만큼 크게 부족하게 보냈다. 어느 것도 운이 나빠서가 아니라, 주문 생성 시 1분의 주의력 문제입니다. 검증에 필요한 정보는 주문 페이지에 모여 있습니다: 주문 전용 입금 주소와 30분 유효기간, 보낸 금액의 payin 해시, 지급된 금액의 payout 해시, 자금이 돌아올 때의 refund 해시, 그리고 문자 그대로의 상태 이름 — waiting_deposit, confirming, settling, paid, expired, refunded, failed.

환불 칸은 형식처럼 보이지만 실제로는 보험처럼 작동합니다. 입금 네트워크 위에 있는, 본인이 보유한 지갑 주소를 적고, 체인이 태그를 요구하면 태그를 붙이면, 위에 적은 실패 유형은 당신에게 해당되지 않습니다 — 완료할 수 없는 주문은 당신이 보낸 것을, 당신이 쓸 수 있는 곳으로 그대로 돌려줍니다. 아직 시도해보지 않았다면 실무 절차는 짧습니다: 페어를 고르고, 확정 전에 견적을 읽고, 두 주소를 의식적으로 설정하고, 본인이 소유한 지갑에서 보내세요. 여기 인용한 모든 요율은 작성 시점(2026-10-15) 기준이며 시장과 함께 움직입니다. 실제로 의미 있는 숫자는 교환 페이지의 실시간 견적입니다.