보상안이 발표됐다는 말만으로 지급 권리가 확정된 것은 아니다. forum 초안, governance 승인, 집행 transaction을 분리하고, 적격 address·transaction·영향 시간대, 자산별 손실 산식과 환산 시점, 이미 회수된 금액, 청구 기한과 KYC 여부를 확인해야 한다. 지급 대상에서 빠졌다면 근거 자료와 이의 신청 창구·마감일을 먼저 확보한다.
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 정정 기록
2026년 9월 27일 : BIP-455 대상 인원을 기존 2명에서, BIP-443으로 먼저 처리된 1명을 제외한 추가 피해 사용자 4명으로 바로잡았습니다.
- 보상 발표의 법적·기술적 상태를 먼저 본다
프로젝트 팀의 사과문은 보상 의향을 밝힐 수 있지만 treasury 지출 권한이 DAO에 있으면 vote와 execution이 추가로 필요하다.
- 적격 대상을 거래 단위로 판정한다
‘사고 당시 사용자’라는 표현은 너무 넓다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
보상 발표의 법적·기술적 상태를 먼저 본다
프로젝트 팀의 사과문은 보상 의향을 밝힐 수 있지만 treasury 지출 권한이 DAO에 있으면 vote와 execution이 추가로 필요하다. forum post가 temperature check인지, binding proposal인지, multisig가 이미 지급했는지 상태를 구분한다. snapshot 통과 뒤에도 timelock·quorum 문제로 실행되지 않을 수 있다.
Balancer의 2023년 DNS 사고에서 BIP-443은 피해 지원 방향과 검증 절차를 제안했고, 후속 BIP-455는 BIP-443으로 먼저 처리된 1명을 제외한 4명의 추가 피해 사용자에 대한 구체 지급안을 다뤘다. 첫 제안 날짜를 실제 지급일로 쓰면 안 된다. 최종 treasury transaction과 recipient를 확인해야 완료를 말할 수 있다.
보상 공지의 약속은 출발점이고, 적격 판정과 집행 거래가 이용자가 확인할 종료점이다.
JOBCOIN 해설
적격 대상을 거래 단위로 판정한다
‘사고 당시 사용자’라는 표현은 너무 넓다. 영향을 받은 hostname·contract·function, 시작·종료 block, 악성 spender, 실패·성공 transaction을 목록화한다. 접속만 한 address와 실제 자산이 이동한 address, protocol position의 가치 하락과 직접 탈취를 같은 손실 유형으로 합치지 않는다.
주소 목록이 공개됐다면 생성 query와 cutoff block을 확인한다. 피해자가 제출한 hash, 공격자 cluster, 반환 거래를 어떤 규칙으로 연결했는지 알아야 누락을 다툴 수 있다. private relay나 cross-chain 이동처럼 자동 탐지가 어려운 경로에는 별도 증빙 절차가 필요하다.
| 항목 | 필수 값 | 오류 위험 |
|---|---|---|
| 영향 범위 | hostname·contract·block | 무관 거래 포함 |
| 원금 | token·수량·hash | 평가손익 혼입 |
| 가격 | 시각·market·통화 | 고점 임의 선택 |
| 회수 | 반환 token·수수료 | 중복 보상 |
| 지급 | 자산·vesting·tax | 명목액과 실수령 차이 |
손실 산식과 기준 가격을 공개해야 한다
직접 유출 token 수량을 같은 token으로 지급하면 가격 환산이 필요 없을 수 있다. stablecoin·native asset로 바꾸면 incident time, claim approval, payout 중 어느 시각의 가격인지 정해야 한다. DEX spot 한 건보다 사용 market, TWAP 구간, depeg 처리와 소수점 반올림을 명시한다.
회수된 자산, attacker 반환금, 보험 지급, protocol debt 상계가 있다면 차감 순서가 필요하다. gas·bridge fee·liquidation penalty·기회비용을 포함하는지도 항목별로 쓴다. ‘전액 보상’은 포함 범위와 지급 자산이 같을 때만 사용한다.
청구 절차에서 비밀정보를 요구하지 않는지 본다
정상적인 claim에는 피해 address를 통제한다는 message signature, transaction hash, 연락처와 신원 확인이 요구될 수 있다. seed phrase·private key·remote access 설치는 필요하지 않다. 서명 요청에는 domain, statement, nonce, expiration이 있어야 하며 token approval이나 asset transfer가 섞이지 않았는지 확인한다.
공식 domain과 announcement channel에서 form URL을 확인하고 case number를 보존한다. 개인정보를 받는다면 처리 주체, 목적, 보관 기간과 국외 이전 여부를 읽는다. KYC가 지급 조건이라면 어느 관할·금액·대상에 적용되는지 보상안에 사전 고지돼야 한다.
- proposal ID와 현재 단계·execution hash를 기록한다
- 피해 hash·block·자산 수량을 원본으로 보존한다
- 가격 source와 cutoff 시각으로 금액을 재계산한다
- 회수·보험·선지급 차감 내역을 확인한다
- claim receipt와 이의제기 마감일을 저장한다
이의 제기는 누락 사유별로 준비한다
주소 누락이면 영향 범위에 들어오는 transaction과 공격 contract의 연결을 제시한다. 금액 오류면 token decimals, 내부 transfer, 반환 transaction과 계산표를 붙인다. 소유권 확인 문제라면 custodial account statement나 당시 address 통제 증거처럼 요구되는 대체 자료를 확인한다.
보상 committee가 판정 이유를 공개하지 않으면 동일 사례의 일관성을 검토하기 어렵다. 승인·거절 category, 추가 자료 요청, appeal reviewer와 처리 기한을 요구한다. 공개 forum에 신분증이나 전체 계정 내역을 올리지 않고 지정된 보안 채널을 사용한다.
실제 지급과 미청구 잔액을 사후 공시한다
집행 뒤에는 지급 address·asset·amount·transaction hash, 실패한 전송과 재시도 정책을 공개한다. vesting claim이면 contract code, unlock schedule과 잔여 재원을 확인한다. 승인 명단 총액과 onchain 지급 합계가 다르면 pending·거절·미청구를 나눠 설명한다.
청구 기간 종료 뒤 남은 treasury를 피해자에게 재배분하는지, protocol로 환수하는지 governance 결정을 남긴다. 세금·회계 처리는 관할별로 달라 보상 공지가 세무 결론을 대신하지 않는다. 이용자는 지급 당시 원화 환산과 원래 손실 자료를 함께 보관한다.
자주 묻는 질문
보상 proposal이 통과되면 바로 지급되나요?
항상 그렇지는 않다. timelock·multisig 실행과 실제 지급 transaction까지 확인해야 한다.
사고 당시 가격과 현재 가격 중 무엇을 쓰나요?
보상안이 정한 source와 기준 시각을 따른다. 공시가 없으면 산식 공개를 요청해야 한다.
청구를 위해 seed phrase를 제출해야 하나요?
절대 제출하지 않는다. 주소 통제는 안전한 message signature 등으로 증명할 수 있다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
