2026년 실패한 Monero 스왑 복구 방법

스왑 입금 주소로 0.05 BTC를 보냈는데 화면이 "교환 중(exchanging)"으로 바뀐 채 40분이 지나도록 꿈쩍도 하지 않습니다. 아니면 XMR를 USDT로 바꾸려 했고 Monero 쪽은 익스플로러에서 분명히 확정(confirmed)되었는데, 받기로 한 코인이 끝내 도착하지 않습니다. 멈춰버린 스왑은 암호화폐를 다루며 겪는 가장 스트레스가 큰 순간 중 하나입니다. 돈이 옛 지갑에도, 새 지갑에도 없는 '비행 중' 상태이기 때문입니다. 본능적으로는 자금이 사라졌다고 단정하게 됩니다. 그러나 자금이 정말로 사라지는 경우는 거의 없습니다.

"실패했다"는 Monero 스왑의 압도적 다수는 사실 손실이 아닙니다. 금액 부족 입금, 환율 적용 시간이 지난 뒤 도착한 입금, 상대 코인에서 누락된 데스티네이션 태그, 혹은 아직 확정을 기다리며 처리되고 있는 트랜잭션일 뿐입니다. 이 각각에는 정해진 복구 경로가 있으며, 어느 레버를 당겨야 하는지만 알면 대부분 몇 시간 안에 해결됩니다. 이 글은 XMR 스왑이 실패하는 이유, MoneroSwapper 같은 비수탁형(non-custodial) 서비스에서 환불이 어떻게 작동하는지, 그리고 멈췄거나 금액이 부족하거나 미궁에 빠진 자금을 되찾기 위한 정확한 순서를 설명합니다. 또한 많은 분이 당황하는, Monero에만 있는 한 가지 특이점도 다룹니다. Monero 체인이 송금인을 숨기는 방식 때문에, 서비스가 여러분의 XMR를 자동으로 환불할 수 없는 경우가 많다는 점과 그것이 여러분에게 의미하는 바입니다.

Monero 스왑은 애초에 왜 실패하는가

스왑은 사실 두 개의 트랜잭션을, 첫 번째 체인을 지켜보다가 두 번째 체인에서 지급하는 서비스가 이어 붙인 것입니다. 실패는 이 두 구간이 맞물리는 지점에 몰려서 발생하며, 유형만 알면 결코 미스터리가 아닙니다. 어떤 유형에 걸렸는지 파악하는 것이 모든 것을 좌우합니다. 금액 부족의 해법은 메모 누락의 해법과 전혀 다르기 때문입니다.

• 금액 부족(Underpayment): 견적된 정확한 금액보다 적게 보낸 경우입니다. 서비스는 특정 수치에 맞춰 환율을 고정했는데, 더 적은 입금은 그 환율로 주문을 채울 수 없어 결정을 기다리는 "보류(hold)" 상태에 머뭅니다.
• 늦은 입금 / 환율 만료: 고정 환율 견적은 보통 15~30분이라는 짧은 시간 동안만 유지됩니다. 시계가 다 돌고 난 뒤 보내면 고정 가격은 사라지고, 주문은 재산정·시장가 완료·환불 중 하나를 거쳐야 합니다.
• 초과 입금(Overpayment): 견적보다 많이 보낸 경우입니다. 초과분은 별도로 돌려보내야 하므로, 지급이 이뤄지기 전에 대개 수동 검토가 발생합니다.
• 데스티네이션 태그·메모 누락: XRP, XLM, BNB, TON, EOS 같은 코인은 메모로 구분되는 하나의 입금 주소를 공유합니다. 메모를 빠뜨리면 여러분의 자금은 태그도 귀속 정보도 없이 서비스의 통합(pooled) 지갑에 떨어집니다.
• 네트워크 혼잡: 멤풀이 꽉 찬 상황에서 너무 낮은 수수료로 방송된 Bitcoin 입금은 몇 시간씩 미확정 상태로 머물 수 있습니다. 입금이 확정되기 전에는 스왑이 시작될 수 없습니다.
• 등록된 환불 주소 없음: 환불 주소를 한 번도 제공하지 않았다면, 서비스는 자금을 신속히 돌려줄 곳이 없어 수동 고객지원 절차에 의존할 수밖에 없습니다.

이 중 어느 것도 "블록체인이 내 코인을 삼켰다"가 아니라는 점에 주목하시기 바랍니다. 전부 운영상의 상태일 뿐입니다. 입금은 거의 항상 서비스의 지갑에 안전하게 들어 있거나, 여러분이 보낸 주소에서 온체인으로 확인됩니다. 문제는 암호학적인 것이 아니라 절차적인 것입니다.

스왑 환불은 실제로 어떻게 작동하는가

비수탁형 스왑의 환불은 블록체인 트랜잭션을 마법처럼 되돌리는 버튼이 아닙니다. Bitcoin이든 Monero든 일단 확정된 거래는 그 어떤 것도 되돌릴 수 없습니다. 환불이란 여러분이 한 입금을 재원으로, 여러분이 통제하는 주소로 서비스가 다시 내보내는 새로운 출금 트랜잭션입니다. 이 구분 하나가 여러분이 마주칠 거의 모든 지연과 요구 조건을 설명해 줍니다.

고정 환율 vs. 변동 환율의 동작 차이

주문 시점에 어떤 환율 유형을 골랐는지가 일이 틀어졌을 때 무슨 일이 벌어질지를 결정합니다. 변동 환율(floating rate)에는 고정된 가격이 없으므로, 늦거나 살짝 어긋난 입금도 자금이 확정되는 시점의 시장가로 그냥 처리되는 것이 보통입니다. 실패가 훨씬 적은 대신 가격 변동을 감수해야 합니다. 고정 환율(fixed rate)은 본 그대로의 숫자를 보장하지만 깨지기 쉽습니다. 서비스는 그 가격을 짧은 시간 동안만 헤지(hedge)해 두었기에, 늦거나 모자라거나 넘치는 입금은 헤지를 깨뜨리고 주문을 수동 대기열로 보냅니다. 그 안에서 여러분의 선택지는 추가 입금(top-up), 재견적, 환불뿐입니다.

환불 주소 — 그리고 Monero가 이를 필수로 만드는 이유

바로 여기서 많은 분이 놀랍니다. Bitcoin 같은 투명한 체인에서는 송금 주소가 트랜잭션에 드러나 있어, 서비스가 때로 "보낸 사람에게로" 자금을 돌려줄 수 있습니다. Monero에서는 불가능합니다. 스텔스 주소(stealth address) 기술 때문에 모든 결제는 고유한 일회용 주소로 떨어지고, 링 서명(ring signature)과 Dandelion++가 어떤 입력값과 어떤 IP가 그 지출을 일으켰는지를 가립니다. 네트워크는 환불할 재사용 가능한 "보낸 사람" 주소를 말 그대로 노출하지 않습니다.

현실적인 결과는 이렇습니다. XMR를 내보내는 스왑에서 주문이 실패하면, 서비스는 오직 여러분이 명시적으로 제공한 Monero 주소로만 환불할 수 있습니다. 자동 반환 경로는 존재하지 않습니다. 평판 좋은 모든 스왑 양식이 환불 주소를 미리 요구하는 이유, 그리고 그 칸을 건너뛰는 것이 Monero 환불이 멈추는 가장 흔한 단 하나의 이유인 까닭이 바로 이것입니다. 인터페이스가 선택 항목처럼 취급하더라도 매번 반드시 채우시기 바랍니다.

Monero에서 "원래 온 곳으로 다시 보내기"는 네트워크가 할 수 없는 일입니다. 송금인이 수학적으로 숨겨져 있기 때문입니다. 환불 주소가 없으면 신속한 환불도 없습니다.

실패 유형과 일반적인 해결책

아래 표는 흔한 실패 상태를, 그 아래에서 실제로 무슨 일이 벌어졌는지, 그리고 여러분이 기대해야 할 해결책에 대응시킵니다. 무언가를 하기 전에 먼저 주문의 상태 문구를 표의 한 행과 맞춰 보시기 바랍니다.

아토믹 스왑(atomic swap)은 환불 모델이 본질적으로 다르므로 따로 짚어야 합니다. COMIT/farcaster 프로토콜을 쓰는 Eigenwallet 같은 도구를 통한 진정한 크로스체인 아토믹 스왑(예: BTC ↔ XMR)에는 환불 타임락(timelock)이 계약 안에 새겨져 있습니다. 스왑 도중 상대방이 사라져도 누구에게 이메일을 보낼 필요가 없습니다. 타임락이 만료되면 잠금 스크립트에서 신뢰 없이(trustless) 여러분의 Bitcoin을 되찾으면 됩니다. 대가는 아토믹 스왑이 소프트웨어를 직접 구동하고 진행되는 내내 온라인을 유지해야 한다는 점이며, 그래서 대부분의 사용자는 여전히 즉시 스왑 서비스와 그 고객지원 데스크를 택합니다.

멈췄거나 실패한 스왑을 단계별로 복구하는 법

아래 순서대로 진행하시기 바랍니다. 처음 세 단계는 비용이 들지 않으며, 누구에게도 연락하지 않고 "실패"의 상당수를 해결합니다. 블록 익스플로러를 읽는 것 이상의 기술은 전혀 필요하지 않습니다.

1. 멈춰서 증거부터 모으십시오. 두 번째 입금을 보내지 마십시오. 주문/스왑 ID와 입금 트랜잭션 해시(txid)를 복사해 두십시오. 이 두 문자열이 모든 복구 단계의 토대입니다.
2. 온체인에서 입금을 확인하십시오. txid를 블록 익스플로러에 붙여 넣으십시오. Monero는 xmrchain.net, BTC는 표준 Bitcoin 익스플로러를 쓰면 됩니다. 실제로 방송되었는지 확인하고 확정 수(confirmations)를 세어 보십시오. Monero는 약 10확정(2분 블록 타임 기준 약 20분)이 필요하므로, 그 아래라면 답은 그저 기다리는 것입니다.
3. 실패 유형을 식별하십시오. 주문의 상태 문구를 읽고 위 표와 맞추십시오. 옳은 문제에 엉뚱한 해법을 적용하면 몇 시간을 허비하게 되니, 행동에 앞서 상태의 이름을 정확히 부르십시오.
4. XMR를 보냈다면 트랜잭션 증명(transaction proof)을 생성하십시오. Monero는 송금인을 숨기므로, 고객지원은 여러분 지갑이 결제했다는 사실을 볼 수 없습니다. Monero GUI나 CLI에서 "결제 증명(prove payment)" / get_tx_key 기능을 사용해 트랜잭션 증명을 만드십시오. 이는 txid, 수신 주소, 트랜잭션 비밀키로 구성되며, 지갑을 노출하지 않고도 여러분이 결제했음을 암호학적으로 입증합니다.
5. 완전한 묶음(packet)을 갖춰 고객지원에 연락하십시오. 주문 ID, 입금 txid, 여러분이 식별한 실패 유형, 그리고 송금 주소(투명한 체인) 또는 트랜잭션 증명(Monero)을 함께 보내십시오. 자금을 돌려받을 환불 주소도 포함하십시오. 첫 메시지가 완전하면 며칠짜리 핑퐁이 단 한 번의 답장으로 끝납니다.
6. 환불 주소를 제공하거나 확인하십시오. 한 번도 입력하지 않았다면 지금 올바른 네트워크의 새 주소를 알려 주십시오. 네트워크를 두 번 확인하십시오. ERC-20으로 입금했는데 TRC-20 주소로 USDT 환불을 요청하면 두 번째 문제가 생깁니다.
7. 해결 기간을 기다리며 기록을 보관하십시오. 환불은 검토 깊이에 따라 보통 몇 시간에서 영업일 기준 며칠 안에 처리됩니다. 환불이 발행되면 그 환불 자체의 txid도 보관해 두십시오.

여러분의 답글로 슬며시 끼어들어 "멈춘 스왑을 풀어 주겠다"며 선불 수수료를 요구하는 "암호화폐 복구 전문가"에게는 절대 돈을 내지 마십시오. 그것은 두말할 것 없이 복구 사기입니다. 정당한 환불은 여러분의 입금을 보유한 서비스가 처리하며, 그들은 결코 먼저 디엠(DM)을 보내지 않습니다.

실제 복구 사례 따라가기

2026년 초에 끊임없이 반복되는 시나리오를 하나 살펴보겠습니다. 어떤 사용자가 250 USDT(TRC-20)를 XMR로 바꾸려고 30분 시간의 고정 환율을 잠갔는데, 지갑의 방송이 지연되어 Tron 트랜잭션이 41분 뒤에 확정됩니다. 주문은 "만료"로 넘어갑니다. 패닉이 밀려오지만, 잃은 것은 아무것도 없습니다.

입금은 서비스의 주소에 확정된 채 놓여 있고, txid로 Tron 익스플로러에서 확인됩니다. 환율 시간이 닫혔으므로 서비스는 원래 견적을 지킬 수 없어 두 개의 문을 제시합니다. 현재 XMR 가격으로 스왑을 완료하거나, 소액의 Tron 네트워크 수수료를 뺀 250 USDT를 환불 주소로 돌려받는 것입니다. 이 사용자는 주문 시점에 환불 주소를 입력해 두었기에 환불 경로가 클릭 한 번이었습니다. 그 칸을 건너뛰었다면, 고객지원 티켓을 열고 먼저 검증을 기다려야 했을 것입니다.

교훈은 일반화됩니다. MoneroSwapper처럼 계정이 필요 없는 서비스에서 복구의 마찰은 거의 전적으로 여러분이 전송 버튼을 누르기 전에 내리는 선택으로 앞당겨집니다. 입금이 제때 도착할지 자신이 없다면 변동 환율을 고르고, 반올림하지 말고 정확한 금액을 복사하며, 환불 주소를 절대 비워 두지 마십시오. 기록 관리를 위한 한 가지 메모를 덧붙이면, 한국 국세청은 가상자산 거래를 점진적으로 과세 체계에 편입해 왔는데, 환불된 스왑은 여러분이 보냈던 코인을 그대로 되돌려받은 것이므로 자산의 "처분"이 아니라 비과세 사건(non-event)으로 보는 것이 일반적입니다. 실제 과세 대상이 되는 처분은 완료된 거래뿐입니다. 장부를 깔끔하게 관리한다면 환불 txid와 함께 이 점을 기록해 둘 가치가 있습니다.

한국 사용자를 위한 추가 맥락

한국에서 Monero 스왑이 유독 흔한 데에는 분명한 배경이 있습니다. 특정금융정보법(특금법) 시행 이후 업비트, 빗썸 같은 국내 거래소들이 Monero를 비롯한 프라이버시 코인을 줄줄이 상장 폐지했습니다. 그 결과 국내에서 XMR를 합법적으로 직접 사고팔 창구가 사실상 사라졌고, 많은 사용자가 비수탁형 즉시 스왑이나 P2Pool 채굴, 또는 다른 코인을 XMR로 교환하는 경로로 옮겨 갔습니다. 거래소를 거치지 않는 만큼 "문제가 생기면 고객센터에 전화하면 된다"는 안전망이 없으므로, 위에서 설명한 환불 주소·트랜잭션 증명 절차를 스스로 챙기는 습관이 한층 더 중요해집니다.

또 한 가지, Monero의 작업증명 알고리즘인 RandomX는 일반 CPU에 최적화되어 있어 개인이 채굴로 소량의 XMR를 직접 확보하기도 합니다. 다만 채굴이든 스왑이든, 자금이 한 지갑에서 다른 지갑으로 옮겨 가는 모든 순간에는 위에서 본 것과 동일한 절차적 위험이 따른다는 점을 기억하시기 바랍니다. 익스플로러로 확정 수를 확인하고, 보내기 전에 주소를 다시 점검하는 한 가지 습관만으로 대부분의 "사고"는 애초에 일어나지 않습니다.

기록 관리 측면에서도 한국 사용자에게 한 가지 권하고 싶은 습관이 있습니다. 스왑 한 건마다 주문 ID, 입금 txid, (해당된다면) 환불 txid, 그리고 거래 시점의 원화(₩) 환산 가치를 간단한 표로 남겨 두십시오. 국내 거래소를 거치지 않는 비수탁형 스왑은 거래소가 발급하는 거래내역서가 없으므로, 훗날 가상자산 과세나 자금 출처 소명이 필요해질 때 스스로 만든 이 기록이 유일한 증빙이 됩니다. 앞서 설명했듯 환불받은 스왑은 처분이 아니라 비과세 사건으로 보는 것이 일반적이지만, "처분이 아니었다"는 사실 자체도 txid라는 증거로 뒷받침될 때 비로소 설득력을 가집니다. 트랜잭션 증명까지 함께 보관해 두면, 송금인을 숨기는 Monero의 특성 때문에 사후에 입증이 까다로워지는 상황을 미리 막을 수 있습니다.

실패를 미리 막는 전송 전 체크리스트

복구는 결국 사후 처리입니다. 진짜 절약은 보내기 전 1분에 있습니다. 아래 항목은 실제 환불 요청의 대부분을 애초에 없애 주는, 비용이 들지 않는 점검입니다.

• 정확한 금액을 직접 복사하십시오. 손으로 입력하거나 반올림하지 마십시오. 0.0500이 아니라 0.04998 같은 소수점 끝자리 하나가 금액 부족(underpaid) 상태를 만듭니다. 서비스가 표시한 수치를 그대로 복사해 붙여 넣으십시오.
• 네트워크를 두 번 확인하십시오. USDT는 ERC-20, TRC-20, BEP-20 등 여러 체인에 존재합니다. 입금 네트워크와 환불 네트워크가 일치해야 합니다. Tron으로 보냈다면 환불 주소도 Tron(TRC-20)이어야 합니다.
• 메모/데스티네이션 태그를 빠뜨리지 마십시오. XRP, XLM, TON, EOS, BNB로 보낼 때 메모 칸이 비어 있으면 전송하지 마십시오. 메모 없는 입금은 통합 지갑에 묻혀 복구에 며칠이 걸립니다.
• Bitcoin 수수료를 멤풀 상황에 맞추십시오. 혼잡한 시기에 최저 수수료로 보내면 입금이 몇 시간씩 미확정으로 멈춥니다. 멈췄다면 RBF(수수료 대체)나 CPFP(자식이 부모 수수료 부담)로 끌어올릴 수 있는지 지갑을 확인하십시오.
• 환불 주소를 반드시 채우십시오. 특히 XMR를 내보내는 스왑이라면 이 칸이 선택 항목으로 보여도 비워 두지 마십시오. Monero는 자동 반환 경로가 없습니다.
• 입금이 제때 도착할 자신이 없다면 변동 환율을 고르십시오. 모바일 지갑이나 혼잡한 네트워크에서 방송이 늦어질 듯하면, 시간이 짧은 고정 환율보다 변동 환율이 만료 실패를 피하게 해 줍니다.

이 여섯 가지를 습관으로 만들면, 이 글의 앞부분에서 다룬 복구 절차를 실제로 쓸 일이 거의 없어집니다. 가장 좋은 복구는 복구할 필요가 없는 스왑입니다.

자주 묻는 질문(FAQ)

Monero 스왑이 실패했다고 단정하기까지 얼마나 기다려야 하나요?

먼저 확정 수를 확인하십시오. Monero 입금은 보통 약 10확정이 필요하며, 이는 2분 블록 타임 기준 대략 20분입니다. 이후 지급 구간이 몇 분 더 걸립니다. 정말로 정상인 스왑은 대부분 30~45분 안에 완료됩니다. 입금이 온체인에서 완전히 확정되었는데도 주문이 몇 시간째 "교환 중"이라면, 그때가 고객지원에 연락할 시점입니다. 15분 지났다고 연락할 때가 아닙니다.

스왑 서비스가 Monero를 제 원래 지갑으로 자동 환불해 줄 수 있나요?

아니요, 그리고 이 점이 거의 모든 사람을 헷갈리게 합니다. Monero는 스텔스 주소와 링 서명을 사용하므로, 네트워크는 서비스가 자금을 되돌려 보낼 재사용 가능한 송금 주소를 결코 노출하지 않습니다. Monero 환불은 여러분이 명시적으로 제공한 주소로만 갈 수 있습니다. 선택 항목처럼 보일 때조차 환불 주소 칸을 항상 채워야 하는 이유가 바로 이것입니다.

트랜잭션 증명이란 무엇이고, 고객지원은 왜 이를 요구하나요?

Monero 트랜잭션 증명은 특정 트랜잭션이 특정 주소로 결제했음을 보여 주는 암호학적 영수증으로, 여러분 지갑의 txid와 트랜잭션 비밀키에서 생성됩니다. 체인이 송금인을 숨기기 때문에, 고객지원은 이것 없이는 여러분 지갑이 입금했다는 사실을 확인할 방법이 없습니다. 이 증명은 여러분의 시드(seed), 지출키(spend key), 또는 전체 지갑 내역을 노출하지 않고도 결제 사실을 입증합니다.

스왑 금액을 부족하게 보냈습니다. 그냥 차액을 보내면 되나요?

대개는 가능하지만, 무엇이든 보내기 전에 서비스에 먼저 확인하십시오. 많은 서비스가 유예 기간 안에 정확한 금액까지 추가 입금하도록 허용하고, 어떤 곳은 부족분을 환불하거나 더 적은 금액 기준 현재 환율로 완료합니다. 이미 만료된 주문의 주소로 두 번째 입금을 무턱대고 보내면 새로운 미아(orphaned) 결제가 생길 수 있으니, 주문이 아직 열려 있는지부터 확인하십시오.

Bitcoin 입금이 미확정 상태로 멈췄습니다. 어떻게 빨리 확정시키나요?

방법은 어떤 지갑을 쓰느냐에 달려 있습니다. 보낼 때 RBF(Replace-By-Fee)를 켜 두었다면, 동일한 입력값을 더 높은 수수료로 다시 보내 기존 미확정 거래를 대체할 수 있습니다. RBF가 비활성화되어 있다면 CPFP(Child-Pays-For-Parent)를 시도하십시오. 해당 거래의 잔돈(change)을 입력으로 쓰는 높은 수수료의 새 거래를 만들어 채굴자가 둘을 함께 처리하도록 유도하는 방식입니다. 둘 다 불가능하면, 멤풀이 빠지면서 결국 확정되거나 거래가 떨어져 나가 자금이 지갑으로 돌아올 때까지 기다리는 수밖에 없습니다. 스왑은 입금이 확정되기 전에는 시작될 수 없다는 점을 기억하십시오.

아토믹 스왑과 즉시 스왑 중 무엇을 골라야 하나요?

신뢰를 최소화하고 직접 소프트웨어를 구동할 의향이 있다면 아토믹 스왑이 더 안전합니다. 타임락 덕분에 상대가 사라져도 자금을 신뢰 없이 되찾을 수 있기 때문입니다. 다만 진행되는 내내 온라인을 유지해야 하고 도구 사용이 까다로울 수 있습니다. 반면 즉시 스왑은 클릭 몇 번으로 끝나고 문제가 생겼을 때 기댈 고객지원이 있지만, 그만큼 서비스를 신뢰해야 합니다. 소액을 빠르고 간편하게 바꾼다면 평판 좋은 즉시 스왑이, 큰 금액이거나 신뢰 가정을 줄이고 싶다면 아토믹 스왑이 합리적입니다.

선불 수수료를 요구하는 "Monero 복구 서비스"는 정당한가요?

아닙니다. 선불로 수수료를 받고 멈춘 스왑을 복구하거나 풀어 주겠다며 여러분에게 접근하는 계정은 모두 사기를 치고 있는 것입니다. 진짜 환불은 오직 여러분의 입금을 받은 서비스에서만 오고, 네트워크 수수료 외에는 비용이 들지 않으며, 여러분이 요청하는 것입니다. 답글이나 디엠에서 낯선 사람이 먼저 제안하는 일은 결코 없습니다.

맺음말

실패한 Monero 스왑은 응급 상황처럼 느껴지지만 거의 언제나 하나의 절차일 뿐입니다. 상태를 식별하고(금액 부족, 만료, 멈춤, 오발송), 블록 익스플로러에서 입금을 확인하면, 기다릴지·추가 입금할지·환불을 요청할지를 몇 분 안에 알 수 있습니다. 대부분의 고통을 막아 주는 단 하나의 습관은 환불 주소를 미리 제공하는 것입니다. Monero의 프라이버시 보장은 곧 네트워크가 볼 수 없는 송금인에게 XMR를 되돌려 보낼 수 없음을 뜻하기 때문입니다. 연락할 때는 주문 ID, txid, 트랜잭션 증명을 앞세우면 대부분의 환불은 당일에 해결됩니다. 무엇보다 두 번째 입금을 성급히 보내지 않는 것, 그리고 익스플로러로 사실부터 확인하는 침착함이 자금을 가장 빠르게 되찾는 길입니다. 실패의 위험 자체를 피하고 싶다면, MoneroSwapper에서 변동 환율과 계정 없는 스왑으로, 그리고 전송 버튼을 누르기 전에 환불 주소를 잠가 둔 채 익명으로 Monero를 구매할 수 있습니다. 그러면 늦거나 부족한 입금조차 깨끗하게 집으로 돌아올 길을 갖게 됩니다.