보상안이 발표됐다는 말만으로 지급받을 권리가 확정되지는 않습니다. 포럼 초안, 거버넌스 승인, 집행 거래를 나눠 보고, 대상 주소·거래·영향 시간대, 자산별 손실 산식과 환산 시점, 이미 회수된 금액, 청구 기한과 본인 확인(KYC) 여부를 확인해야 합니다. 지급 대상에서 빠졌다면 근거 자료와 이의 신청 창구, 마감일부터 확보합니다.
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 정정 기록
2026년 9월 27일: BIP-455 대상 인원을 기존 2명에서, BIP-443으로 먼저 처리된 1명을 제외한 추가 피해 사용자 4명으로 바로잡았습니다.
- 보상 발표의 법적·기술적 상태를 먼저 본다
프로젝트 팀의 사과문은 보상 의향을 밝힐 수는 있지만, 금고 지출 권한이 DAO에 있다면 투표와 실행이 더 필요합니다.
- 대상 여부를 거래 단위로 판정한다
‘사고 당시 사용자’라는 표현은 너무 넓습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
보상 발표의 법적·기술적 상태를 먼저 본다
프로젝트 팀의 사과문은 보상 의향을 밝힐 수는 있지만, 금고 지출 권한이 DAO에 있다면 투표와 실행이 더 필요합니다. 포럼 글이 의견 수렴 단계인지, 구속력 있는 제안인지, 다중서명 지갑이 이미 지급했는지 상태를 나눠 봅니다. 스냅샷 투표를 통과한 뒤에도 시간 잠금이나 정족수 문제로 실행되지 않을 수 있습니다.
Balancer의 2023년 DNS 사고에서 BIP-443은 피해 지원 방향과 검증 절차를 제안했고, 후속 BIP-455는 BIP-443으로 먼저 처리된 1명을 제외한 추가 피해 사용자 4명에 대한 구체적인 지급안을 다뤘습니다. 첫 제안 날짜를 실제 지급일로 쓰면 안 됩니다. 최종 금고 거래와 수령인을 확인해야 완료를 말할 수 있습니다.
보상 공지의 약속은 출발점이고, 대상 판정과 집행 거래가 이용자가 확인해야 할 종착점입니다.
JOBCOIN 해설
대상 여부를 거래 단위로 판정한다
‘사고 당시 사용자’라는 표현은 너무 넓습니다. 영향을 받은 호스트 이름·계약·함수, 시작과 끝 블록, 악성 지출 권한자, 실패·성공 거래를 목록으로 만듭니다. 접속만 한 주소와 실제로 자산이 빠져나간 주소, 프로토콜 포지션의 가치 하락과 직접 탈취를 같은 손실 유형으로 묶지 않습니다.
주소 목록이 공개됐다면 목록을 만든 조회 조건과 기준 블록을 확인합니다. 피해자가 낸 거래 해시, 공격자 주소 묶음, 반환 거래를 어떤 규칙으로 이었는지 알아야 누락을 따질 수 있습니다. 비공개 전달 경로나 체인 간 이동처럼 자동으로 잡기 어려운 경로에는 따로 증빙 절차가 필요합니다.
| 항목 | 필수 값 | 오류 위험 |
|---|---|---|
| 영향 범위 | 호스트 이름·계약·블록 | 무관한 거래 포함 |
| 원금 | 토큰·수량·해시 | 평가 손익 섞임 |
| 가격 | 시각·시장·통화 | 고점 임의 선택 |
| 회수 | 반환 토큰·수수료 | 중복 보상 |
| 지급 | 자산·분할 지급·세금 | 명목 금액과 실수령액 차이 |
손실 산식과 기준 가격을 공개해야 한다
빠져나간 토큰 수량을 같은 토큰으로 돌려준다면 가격 환산이 필요 없을 수 있습니다. 스테이블코인이나 기본 자산으로 바꿔 준다면 사고 시점, 청구 승인 시점, 지급 시점 가운데 어느 때의 가격인지 정해야 합니다. 탈중앙 거래소 현물가 한 건보다는 사용한 시장, 시간가중평균가격(TWAP) 구간, 고정 가격 이탈 처리, 소수점 반올림을 분명히 적습니다.
회수된 자산, 공격자 반환금, 보험 지급, 프로토콜 부채 상계가 있다면 빼는 순서가 필요합니다. 가스비, 브리지 수수료, 청산 벌금, 기회비용을 넣는지도 항목별로 씁니다. ‘전액 보상’이라는 말은 포함 범위와 지급 자산이 같을 때만 씁니다.
청구 절차에서 비밀정보를 요구하지 않는지 본다
정상적인 청구 절차는 피해 주소를 통제한다는 메시지 서명, 거래 해시, 연락처, 신원 확인을 요구할 수 있습니다. 시드 문구, 개인키, 원격 접속 프로그램 설치는 필요하지 않습니다. 서명 요청에는 도메인, 설명문, 논스, 만료 시각이 있어야 하며, 토큰 승인이나 자산 이전이 섞여 있지 않은지 확인합니다.
공식 도메인과 공지 채널에서 신청서 주소를 확인하고 사건 번호를 보관합니다. 개인정보를 받는다면 처리 주체, 목적, 보관 기간, 국외 이전 여부를 읽어 봅니다. 본인 확인이 지급 조건이라면 어느 관할·금액·대상에 적용되는지 보상안에 미리 알려야 합니다.
- 제안 ID와 현재 단계, 실행 거래 해시를 기록합니다
- 피해 거래 해시·블록·자산 수량을 원본 그대로 보존합니다
- 가격 출처와 기준 시각으로 금액을 다시 계산합니다
- 회수·보험·선지급 차감 내역을 확인합니다
- 청구 접수증과 이의 제기 마감일을 저장합니다
이의 제기는 누락 사유별로 준비한다
주소가 빠졌다면 영향 범위에 드는 거래와 공격 계약 사이의 연결을 보여 줍니다. 금액이 틀렸다면 토큰 소수 자릿수, 내부 이체, 반환 거래, 계산표를 붙입니다. 소유권 확인이 문제라면 수탁 계정 거래내역서나 당시 주소를 통제했다는 증거처럼 요구되는 대체 자료를 확인합니다.
보상 위원회가 판정 이유를 공개하지 않으면 비슷한 사례끼리 일관성이 있는지 검토하기 어렵습니다. 승인·거절 분류, 추가 자료 요청, 이의 심사 담당자, 처리 기한을 요구합니다. 공개 포럼에 신분증이나 전체 계정 내역을 올리지 말고 지정된 보안 채널을 씁니다.
실제 지급과 미청구 잔액을 사후 공시한다
집행 뒤에는 지급 주소·자산·금액·거래 해시, 실패한 전송과 재시도 정책을 공개합니다. 분할 지급형 청구라면 계약 코드, 해제 일정, 남은 재원을 확인합니다. 승인 명단의 총액과 온체인 지급 합계가 다르면 대기·거절·미청구를 나눠 설명합니다.
청구 기간이 끝난 뒤 남은 금고 자금을 피해자에게 다시 나눌지, 프로토콜로 되돌릴지에 대한 거버넌스 결정을 남깁니다. 세금과 회계 처리는 관할마다 달라 보상 공지가 세무 결론을 대신하지 않습니다. 이용자는 지급 당시 원화 환산액과 원래 손실 자료를 함께 보관합니다.
자주 묻는 질문
보상 제안이 통과되면 바로 지급되나요?
항상 그렇지는 않습니다. 시간 잠금과 다중서명 실행, 실제 지급 거래까지 확인해야 합니다.
사고 당시 가격과 현재 가격 중 무엇을 쓰나요?
보상안이 정한 출처와 기준 시각을 따릅니다. 공시가 없다면 산식을 공개해 달라고 요청해야 합니다.
청구를 위해 시드 문구를 제출해야 하나요?
절대 제출하지 않습니다. 주소 통제 여부는 안전한 메시지 서명 같은 방법으로 증명할 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
