IBC 송신 체인에서 거래가 성공했다고 해서 도착 체인의 앱 처리까지 끝난 것은 아닙니다. 패킷 커밋먼트(commitment)가 만들어지고, 중계자(relayer)가 전달하고, 도착 체인이 받아 확인 응답(acknowledgement)을 쓴 뒤, 그 응답이 다시 돌아와야 송신 쪽 상태가 마무리됩니다. 정해 둔 높이나 시각을 넘겼다면 확인 응답을 기다릴 게 아니라 시간 초과(timeout) 증명과 애플리케이션의 환불 처리를 확인해야 합니다.
IBC 전송을 거래 한 번으로 보면 오해가 생깁니다
IBC 패킷에는 출발 포트, 출발 채널, 도착 포트, 도착 채널, 순번(sequence), 데이터, 시간 초과 높이와 시간 초과 타임스탬프가 담깁니다. 송신 체인에서 SendPacket이 처리되면 패킷 커밋먼트가 저장되지만, 도착 체인의 수신 거래는 중계자가 따로 제출합니다. 그래서 첫 거래에 성공 표시가 떴다는 것만으로 도착 체인 잔액을 확정할 수는 없습니다.
중계자는 합의에 참여하는 주체가 아니라 두 체인 사이에서 증거와 메시지를 실어 나르는 역할입니다. 어느 중계자가 멈춰도 다른 중계자가 유효한 증거를 낼 수 있습니다. 다만 채널이 닫혔거나 도착 쪽 앱이 오류 응답을 기록했다면 그냥 다시 보낸다고 풀리지 않습니다.
IBC 전송 상태는 송신, 수신, 응답, 정산이라는 네 가지 증거로 나눠 읽어야 합니다.
JOBCOIN 해설

그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- IBC 전송을 거래 한 번으로 보면 오해가 생깁니다
IBC 패킷에는 출발 포트, 출발 채널, 도착 포트, 도착 채널, 순번(sequence), 데이터, 시간 초과 높이와 시간 초과 타임스탬프가 담깁니다.
- 확인 응답이 알려 주는 것
도착 체인의 애플리케이션은 패킷을 처리한 다음 확인 응답을 남길 수 있습니다.
- 시간 초과 높이와 타임스탬프의 차이
시간 초과 높이는 도착 체인의 합의 높이를, 시간 초과 타임스탬프는 도착 체인의 합의 시각을 기준으로 삼습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
확인 응답이 알려 주는 것
도착 체인의 애플리케이션은 패킷을 처리한 다음 확인 응답을 남길 수 있습니다. 흔한 동기 방식에서는 받는 즉시 결과나 오류를 적고, 비동기 앱은 나중에 응답을 기록하기도 합니다. IBC 코어는 응답 바이트가 업무상 무슨 뜻인지 대신 정해 주지 않으므로, 쓰고 있는 앱의 인코딩 규칙을 확인해야 합니다.
확인 응답이 송신 체인으로 돌아오면 원래 애플리케이션이 그 결과에 맞춰 상태를 정리합니다. 토큰 전송 앱은 성공 응답과 오류 응답을 서로 다르게 처리합니다. 탐색기에 응답 이벤트가 떠 있다는 데서 멈추지 말고 결과(result)와 오류(error) 중 어느 쪽인지 확인하세요.
시간 초과 높이와 타임스탬프의 차이
시간 초과 높이는 도착 체인의 합의 높이를, 시간 초과 타임스탬프는 도착 체인의 합의 시각을 기준으로 삼습니다. 설정해 둔 조건 가운데 하나라도 채워지면 송신 쪽에서 시간 초과 절차를 밟을 수 있습니다. 내 컴퓨터 시계로 시간이 지났다고 해서 패킷이 저절로 환불되지는 않습니다.
| 단계 | 확인할 기록 | 아직 증명하지 못하는 것 |
|---|---|---|
| 송신 | SendPacket 이벤트와 커밋먼트 | 도착 체인 앱 처리 |
| 수신 | RecvPacket과 도착 체인 상태 변화 | 응답이 송신 체인에 전달됐는지 |
| 응답 | WriteAcknowledgement와 AcknowledgePacket | 모든 앱에서 같은 성공 의미 |
| 시간 초과 | 만료 조건과 미수신 증명, TimeoutPacket | 마음대로 하는 즉시 환불 |
탐색기에서 멈춘 지점을 찾는 법
먼저 송신 거래에서 채널과 순번을 적어 둡니다. 도착 체인의 같은 채널에서 같은 순번의 RecvPacket을 찾고, 이어서 WriteAcknowledgement가 있는지 봅니다. 마지막으로 송신 체인에서 AcknowledgePacket이나 TimeoutPacket을 확인합니다. 체인마다 탐색기 용어가 달라도 이 식별자 조합은 그대로입니다.
예를 들어 순번 42의 송신은 성공했는데 도착 체인 수신 기록이 없고 시간 초과 타임스탬프도 지났다고 해 봅니다. 그러면 중계자가 미수신 증명을 담은 시간 초과 메시지를 내야 합니다. 거꾸로 도착 체인이 이미 받았다면 같은 패킷의 시간 초과는 받아들여지면 안 됩니다. 이해를 돕기 위한 흐름일 뿐이고, 실제 환불 결과는 앱 구현과 채널 상태에 달려 있습니다.
- 송신 거래에서 출발 채널과 순번을 복사합니다
- 도착 체인에 RecvPacket이 있는지 확인합니다
- 확인 응답이 결과인지 오류인지 해독합니다
- 송신 체인의 AcknowledgePacket이나 TimeoutPacket을 찾습니다
- 지원팀에 문의할 때는 두 체인의 거래와 채널·순번을 함께 알립니다
다시 보내기 전에 따져 볼 위험
도착이 늦다고 같은 자산을 또 보내면 별개의 새 순번이 생기고, 두 전송이 모두 처리될 수 있습니다. 기존 패킷 상태부터 추적하고, 지갑의 재시도 버튼이 중계 재요청인지 새 송신인지 가려 보세요. 새 거래 해시가 생기는 동작이라면 금액과 수수료를 다시 살펴봅니다.
채널의 상대편 정보가 어긋나거나 앱 버전 협상이 다른 경로로 보내면 화면에 뜨는 자산의 경로 기록(denom trace)도 달라질 수 있습니다. 기호가 같아도 경로가 다르면 다른 바우처이니 최종 denom과 채널을 함께 보세요.
운영자와 이용자가 남겨야 할 기록
이용자는 송신·수신 체인, 양쪽 채널, 순번, 시간 초과 조건, 두 체인의 거래 해시를 남깁니다. 운영자는 중계자 대기열, 클라이언트 만료 여부, 채널 상태, 가스 부족, 응답 오류를 나눠서 보고합니다. 'IBC 장애'라는 한 문장만으로는 어디까지 영향을 받았는지 판단할 수 없습니다.
시간 초과와 확인 응답은 전달 실패를 안전하게 정산하려고 둔 상태 기계의 한 부분입니다. 특정 브리지나 토큰의 경제적 안전성, 가격, 발행자의 상환 능력까지 보증하지는 않습니다. 실시간 체인 상태를 확인하지 않은 설명을 개별 전송이 끝났다는 근거로 쓰지 마세요.
자주 묻는 질문
송신 체인에서 성공이면 목적지 입금도 성공인가요?
아닙니다. 송신 성공은 커밋먼트가 만들어졌다는 뜻입니다. 도착 체인의 RecvPacket과 확인 응답, 송신 체인의 정산 기록까지 차례로 확인해야 합니다.
시간 초과 시점이 지나면 자동 환불되나요?
대개는 자동이 아닙니다. 만료 조건과 도착 체인 미수신을 증명하는 시간 초과 메시지가 송신 체인에서 처리돼야 합니다.
같은 전송을 다시 누르면 안전한가요?
새 패킷이 만들어지면 두 건이 모두 처리될 수 있습니다. 기존 순번의 상태와 그 버튼이 실제로 어떤 메시지를 보내는지부터 확인하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.



