전송은 성공했는데 입금이 안 보일 때: 영수증을 대조하는 순서

지갑에서 성공 표시를 봤는데 거래소 잔액이 늘지 않으면 같은 전송을 한 번 더 시도하고 싶어집니다. 그러나 먼저 필요한 것은 재전송이 아니라 어느 단계까지 완료됐는지 구분하는 일입니다. 블록체인의 실행 결과, 실제 토큰 이동, 수신 서비스의 계정 반영은 서로 다른 확인 대상입니다. 성공이라는 단어 하나로 세 단계를 모두 통과했다고 판단하면 원인을 찾기 어려워집니다.

화면 캡처보다 거래 식별 정보를 먼저 모으기

본인이 이용한 네트워크, 거래 해시, 송신 주소, 수신 주소, 토큰 컨트랙트 주소, 전송 수량과 시각을 한곳에 적습니다. 해시는 공개 거래를 찾는 식별자이지 지갑의 복구 비밀이 아닙니다. 반대로 개인키나 복구 구문은 입금 확인에 필요하지 않습니다. 문의를 돕겠다는 사람이 그 정보를 요구한다면 거래 조사 절차와 무관한 요청으로 분리해야 합니다. 캡처에는 다른 자산 잔액이나 계정 정보가 함께 찍히지 않도록 주의합니다.

실행 성공과 내가 기대한 결과를 나누기

이더리움의 거래 영수증에는 블록 번호, 사용한 가스, 실행 상태와 로그 등이 담깁니다. 영수증이 없으면 아직 처리되지 않았거나 조회한 노드가 해당 거래를 찾지 못한 상태일 수 있습니다. 실패한 실행에도 네트워크 자원을 사용한 비용은 발생할 수 있습니다. 따라서 잔액이 조금 줄었다고 전송 금액이 상대에게 도착했다고 판단해서는 안 됩니다. 거래 수수료와 이동 대상 자산을 따로 확인해야 합니다.

또한 성공한 거래가 반드시 송금을 뜻하지는 않습니다. 토큰을 보내기 전에 권한만 승인한 거래라면 그 승인은 정상적으로 실행돼도 상대방의 잔액은 늘지 않습니다. 스왑, 예치, 출금 요청도 각각 다른 동작입니다. 탐색기의 메서드 이름만 믿기보다 토큰 이동 내역과 실제 상대 주소를 함께 대조합니다. 표시되는 자산 이름이 같더라도 컨트랙트가 다르면 다른 토큰일 수 있으므로 심볼만으로 일치 여부를 결론내리지 않습니다.

가상의 입금 지연 사례

가령 A가 토큰 100개를 거래소에 보냈다고 생각했지만, 확인한 해시가 지출 한도를 설정한 승인 거래였다고 가정해 봅시다. 이때 고객센터에 입금 지연이라고 문의하기 전에 실제 전송 거래가 따로 생성됐는지 확인해야 합니다. 다른 사례로 토큰 이동은 100개로 확인되지만 수신 주소가 이전에 쓰던 개인 지갑이라면 거래소의 반영 문제가 아닙니다. 두 상황은 지갑의 성공 표시만으로 구별되지 않지만, 거래 종류와 수신 주소를 대조하면 차이가 드러납니다.

실제 전송이 맞다면 수신 서비스의 입금 화면에서 지원 네트워크, 해당 자산의 입금 가능 상태, 최소 입금액, 필요한 메모와 확인 수 조건을 확인합니다. 블록체인 확인 수가 충분하더라도 점검이나 계정별 확인 절차가 진행될 수 있습니다. 서비스마다 기준이 다르고 바뀔 수 있으므로 다른 거래소의 경험을 그대로 적용하지 않습니다. 입금 주소를 새로 발급받았다면 문제가 된 거래를 보낼 당시의 주소와 기록도 함께 확인합니다.

문의는 재현 가능한 정보로 좁히기

문의 내용은 “돈이 사라졌다”보다 “이 네트워크의 이 해시에서 이 자산이 이 주소로 이동했고, 현재 확인 수는 이 값인데 계정에는 미반영”처럼 적는 편이 조사에 도움이 됩니다. 탐색기의 조회 시각과 거래소가 제공한 접수 번호도 보관합니다. 공개 게시판에서는 전체 계정 기록을 올리지 말고 공식 지원 창구를 이용합니다. 이미 완료된 온체인 거래는 일반적인 결제 취소처럼 되돌릴 수 없으므로, 복구 가능성이나 처리 시간을 확인 없이 단정하지 않습니다.

조사가 끝날 때까지 같은 목적의 송금을 계속 추가하면 원래 거래와 새 거래가 섞입니다. 장부에 각 해시별로 실행 상태, 자산 이동 확인, 서비스 반영 여부를 나누어 표시하면 어떤 단계가 해결됐는지 추적하기 쉽습니다. 이 절차의 목적은 모든 지연을 해결한다고 보장하는 데 있지 않습니다. 네트워크 문제와 앱 표시 문제, 수신 서비스 문제를 구분해 다음 행동을 결정할 근거를 남기는 데 있습니다.

출처

• Ethereum, JSON-RPC 거래 영수증
• Ethereum, 거래 구조와 처리
• Coinbase, 거래 상태 확인