장애 공지와 보상 확정 공지는 같은 문서가 아닐 수 있습니다. 먼저 거래소가 인정한 incident의 서비스·지역·상품·시간대를 확인하고, 자신의 주문이 eligible 조건에 들어가는지 주문 ID·요청 시각·상태 변화로 입증합니다. 손실은 공지의 기준가격·기준시각·상계·한도에 따라 재계산하고, 청구 접수 번호와 심사 결과, 실제 계정 credit를 별개 상태로 추적해야 합니다.
장애 사실과 보상 약속을 분리해 읽습니다
상태 페이지에 degraded performance나 outage가 기록됐다는 사실은 서비스 이상을 뒷받침하지만 모든 손실의 보상을 약속하지는 않습니다. 장애 해결 공지에 고객지원 문의 안내가 있어도 보상 대상·산식·기한이 명시되지 않았다면 개별 심사 창구가 열린 상태로 읽습니다.
Bybit의 서버 이상 해설은 영향 서비스와 원인을 설명하고 부당한 영향을 받았다고 보는 이용자에게 라이브챗·웹폼 문의를 안내합니다. 공개 문서에 정액·정률 산식이 없다면 이를 전원 보상 또는 지급 확정으로 바꾸어 말하지 않습니다.
장애 인정, 청구 자격, 손실 인정, 지급 확정은 네 개의 다른 상태입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 장애 사실과 보상 약속을 분리해 읽습니다
상태 페이지에 degraded performance나 outage가 기록됐다는 사실은 서비스 이상을 뒷받침하지만 모든 손실의 보상을 약속하지는 않습니다 .
- 공식 incident 창과 개인 영향 창을 겹칩니다
상태 페이지에서 최초 탐지, 조사, 서비스 복구, 모니터링 완료 시각과 영향 component를 UTC로 기록합니다.
- eligible order 정의를 주문 단위로 적용합니다
보상 공지는 특정 상품, 계정 유형, 주문 상태나 장애 기능만 포함할 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
공식 incident 창과 개인 영향 창을 겹칩니다
상태 페이지에서 최초 탐지, 조사, 서비스 복구, 모니터링 완료 시각과 영향 component를 UTC로 기록합니다. 자신의 주문에는 client send time, exchange receive time, acknowledgement, 체결·취소·거절 시각을 붙입니다. PC 화면 시각만으로 서버 수신 여부를 확정하지 않습니다.
공식 장애가 10:02~10:18 UTC이고 취소 요청이 10:06에 서버에 접수돼 10:20에 처리됐다면 겹침은 입증할 수 있습니다. 반면 09:58에 거절된 주문은 같은 날이라는 이유만으로 incident에 포함하지 않고 사유 코드와 상품 상태를 별도로 확인합니다.
| 증거 | 입증하는 것 | 입증하지 못하는 것 |
|---|---|---|
| 상태 페이지 | 공식 장애 시간·component | 개별 주문 손실 |
| 주문·체결 내역 | 서버 상태 변화·가격·수량 | 클라이언트 미전송 요청 |
| API 로그 | 요청·응답·오류 코드 | 공지상 보상 자격 |
| 포지션·청산 원장 | 실현 손익·수수료 | 기회비용 인정 |
| 지원 티켓·credit | 접수·승인·지급 | 다른 계정의 동일 처리 |
eligible order 정의를 주문 단위로 적용합니다
보상 공지는 특정 상품, 계정 유형, 주문 상태나 장애 기능만 포함할 수 있습니다. 웹과 API 중 한 경로만 영향을 받았거나 취소 불가 주문만 대상일 수도 있습니다. 주문 ID마다 상품·side·type·수량·접수 경로·장애 전 상태와 최종 상태를 표로 만듭니다.
Coinbase 거래 규칙은 체결이 원칙적으로 최종이며 중대한 기술 오류 같은 제한된 경우 복원 노력을 할 수 있다고 설명합니다. 개별 사건의 자동 보상을 뜻하지 않으므로 사고 공지·약관·심사 결과를 함께 봅니다.
- incident ID와 공식 시작·복구 시각을 UTC로 저장합니다.
- 영향 서비스·상품·지역·계정 유형을 청구 조건과 대조합니다.
- 주문 ID별 요청·응답·체결·취소·청산 이벤트를 정렬합니다.
- 실현 손실·수수료·기회비용을 섞지 않고 분류합니다.
- 청구 마감의 시간대와 필수 첨부물, 접수 번호를 확인합니다.
손실 산식을 공지 변수로 다시 계산합니다
보상액은 실제 체결가 차이, 기준가격, 인정 수량, 수수료, 상계 이익과 계정별 한도에 따라 달라질 수 있습니다. 공지가 산식을 제시하면 변수별 출처를 붙이고, 제시하지 않으면 스스로 계산한 금액을 예상 청구액으로만 표시합니다.
예를 들어 2 ETH가 3,000달러에 매도되고 공지가 3,080달러를 기준가격으로 인정하면 총 차이는 160달러입니다. 반대 주문 이익 40달러를 상계하고 인정 수수료 4달러를 더한다면 예상액은 124달러입니다. 상계 규정이 없다면 적용하지 않습니다.
기회비용과 실현 손실을 섞지 않습니다
주문을 넣지 못해 얻지 못한 가상 수익, 더 좋은 가격에 거래할 기회를 놓친 금액과 실제 강제 체결·청산 손실은 증거 구조가 다릅니다. 공지가 ‘direct loss’만 인정한다면 가상 최고가를 기준으로 청구액을 키우지 않습니다.
미체결 주문은 서버 접수 증거가 있어도 실제 체결 가격·수량을 확정하기 어렵습니다. order book 깊이, 우선순위와 부분 체결을 고려해야 합니다. 제외 항목에는 비대상 사유를 붙여 사건 원장과 계산표를 연결합니다.
원본 증거를 보존하고 민감정보를 분리합니다
주문 CSV·API 응답·상태 페이지·공지의 원본과 SHA-256, 내려받은 시각을 보존합니다. 로그 시간대를 UTC로 정규화하되 원본 timestamp를 지우지 않습니다. 화면 캡처만 제출하지 말고 가능한 경우 공식 내보내기와 주문 ID를 함께 사용합니다.
API key, secret, 세션 cookie, 지갑 seed는 증거가 아니므로 공유하지 않습니다. 거래 내역은 공식 보안 경로에 필요한 범위로 제출하고 공개 글의 주문·티켓 번호와 개인정보를 마스킹합니다.
청구 상태를 접수부터 지급까지 추적합니다
웹폼 제출 화면은 발송 시도일 수 있습니다. ticket ID, 자동 수신 확인, 추가자료 요청, eligibility 결정, 산정액 제안, 수락과 실제 credit를 별도 필드로 기록합니다. 마감 전 제출한 증거는 원본 파일과 확인 메일로 보존합니다.
credit가 들어오면 자산·금액·시각·거래 유형을 확인하고 명세서에서 추적합니다. 쿠폰, fee credit, 현금성 자산은 경제적 성격과 사용기한이 다릅니다. 공지의 ‘up to’ 한도나 재량 심사를 확정 지급액으로 인식하지 않습니다.
사고 뒤 운영 통제를 고칩니다
보상은 재발 방지 통제를 대신하지 않습니다. 거래소 status component, websocket heartbeat, 주문 acknowledgement 지연과 REST 오류율을 모니터링하고, 일정 임계 이후 신규 위험 증가 주문을 멈추는 조건을 둡니다. 취소 요청도 고유 client order ID로 재시도해 중복 주문을 막습니다.
거래소가 cancel-only나 trading halt를 선언하면 주문 정책이 바뀝니다. 장애 때 무조건 재주문하지 말고 시장 상태와 기존 주문의 서버 상태를 먼저 동기화합니다.
최종 보고는 확인된 범위만 말합니다
내부 보고서에는 공식 incident, 개인 영향 주문, 청구액 산식, 제출일·티켓, 심사 상태와 지급액을 나란히 둡니다. ‘피해 접수 완료’를 ‘보상 완료’로 줄이지 않습니다. 거래소가 원인을 공개하지 않았다면 로그만으로 서버 결함을 단정하지 않습니다.
공식 문서가 수정될 수 있으므로 공지 URL과 확인일, 상태 페이지 이벤트 시각을 기록합니다. 후속 안내가 산식이나 마감을 바꾸면 버전별 차이를 남기고 새 조건으로 청구표를 재계산합니다. 다른 이용자의 지급 사례는 자신의 자격을 보장하는 규칙으로 사용하지 않습니다.
자주 묻는 질문
상태 페이지에 장애가 기록되면 자동으로 보상받나요?
아닙니다. 장애 증거와 보상 자격은 별개입니다. 해당 사고의 eligible 조건과 청구·심사 결과를 확인해야 합니다.
손실액을 장애 중 최고가로 계산해도 되나요?
공지가 그 기준을 명시한 경우에만 가능합니다. 기준가격·시각·인정 수량·상계·한도를 공식 산식대로 적용하세요.
지원 웹폼 제출 화면이면 접수가 끝난 것인가요?
ticket ID나 수신 확인을 확보하세요. 제출, 접수, 승인과 지급은 서로 다른 상태입니다.
API 로그 전체를 지원팀에 보내도 되나요?
비밀키·세션·불필요한 개인정보를 제거하고 공식 보안 채널로 필요한 요청시각·주문 ID·응답 코드만 제출하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
