비상기금이나 안전 모듈(safety module)에 잔액이 많다고 해서 이용자 손실을 모두 자동으로 메워 준다는 뜻은 아닙니다. 자산별 시장가치와 당장 처분할 수 있는 금액, 기금이 어떤 네트워크·풀·위험 사건을 덮는지, 거버넌스 결정이나 자동 슬래싱(slashing) 발동 조건, 청구 자격과 우선순위를 확인해야 합니다. 프로토콜의 부실채권(bad debt)을 메우는 장치와 개인 지갑 해킹을 보상하는 상품도 따로 봐야 합니다.
보험이라는 이름부터 계약 구조로 풀어 읽습니다
프로토콜이 보험기금이라고 부르는 준비금은 규제받는 보험회사의 보험계약과 다를 수 있습니다. 프로토콜 금고가 재량으로 내주는 예비금, 스테이커 자산을 깎아 손실을 메우는 후순위 장치, 미리 보장 상품을 산 회원끼리 나누는 청구 풀은 권리도 절차도 서로 다릅니다. 이름보다 누가 자금을 소유하고 누가 지급을 결정하는지 봅니다.
Nexus Mutual 문서는 자본 풀(Capital Pool)을 회원이 함께 소유한 자산으로 설명합니다. 보장료가 이 풀로 들어오고, 유효한 청구는 ETH·USDC·cbBTC 기준으로 지급된다고 밝힙니다. 그렇다고 풀 잔액만 있으면 어떤 사고든 보장된다는 말은 아닙니다. 지급 범위는 구매한 보장 약관과 청구 심사가 정합니다.
기금 규모는 지급 능력을 이루는 한 요소일 뿐입니다. 보장 약속은 발동 조건과 계약·거버넌스 절차가 함께 갖춰져야 성립합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 보험이라는 이름부터 계약 구조로 풀어 읽습니다
프로토콜이 보험기금이라고 부르는 준비금은 규제받는 보험회사의 보험계약과 다를 수 있습니다.
- 장부상 잔액과 실제로 손실을 흡수할 힘을 나눕니다
기금 지갑의 토큰을 시가로 더하면 자체 거버넌스 토큰이나 얕은 유동성 공급 포지션이 크게 잡힐 수 있습니다.
- Aave 엄브렐라(Umbrella)는 자산별 적자를 메우는 장치입니다
Aave 문서에 따르면 엄브렐라는 Aave v3 풀의 부실채권 보전을 자동화합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
장부상 잔액과 실제로 손실을 흡수할 힘을 나눕니다
기금 지갑의 토큰을 시가로 더하면 자체 거버넌스 토큰이나 얕은 유동성 공급 포지션이 크게 잡힐 수 있습니다. 사고가 났을 때 이를 팔면 가격 충격이 커지고 담보가치도 함께 떨어질 수 있습니다. 스테이블 자산, 체인 기본 자산, 프로토콜 토큰, 처분이 어려운 투자 자산을 나누고 할인율(haircut)과 청산에 걸리는 시간을 공시해야 합니다.
자본 풀은 청구 지급뿐 아니라 토큰 가치 뒷받침과 투자에도 쓰입니다. 투자 전략에 묶였거나 환매 요구와 겹치는 자산까지 전부 바로 지급할 수 있다고 보기는 어렵습니다. 온체인 잔액과 부채, 현재 유효한 보장 노출액을 같은 기준일로 맞춰야 합니다.
| 항목 | 확인값 | 오해 방지 |
|---|---|---|
| 총자산 | 토큰별 수량·가격 | 명목 합계 |
| 유동자산 | 할인율·시장 깊이 | 즉시 동원액 |
| 책임 | 유효 보장·부실채권 | 중복 청구 |
| 범위 | 네트워크·풀·자산 | 무관한 사고 제외 |
| 집행 | 자동 계약·투표·심사자 | 지급 시점 |
Aave 엄브렐라(Umbrella)는 자산별 적자를 메우는 장치입니다
Aave 문서에 따르면 엄브렐라는 Aave v3 풀의 부실채권 보전을 자동화합니다. 스테이킹된 에이토큰(aToken)은 해당 네트워크에서 같은 자산의 적자를 덮습니다. 예를 들어 aUSDC 스테이킹은 그 배포의 USDC 적자와 연결됩니다. 금고 하나가 모든 Aave 시장과 모든 토큰을 아우른다고 읽으면 안 됩니다.
정해 둔 적자 상쇄 한도를 넘으면 UmbrellaCore가 슬래싱을 실행해 스테이킹 지분 가치를 낮출 수 있습니다. 손실을 본 이용자에게 현금을 하나하나 지급하는 방식이라기보다 프로토콜 회계에 쌓인 부실채권을 상쇄하는 구조입니다. 지갑 피싱이나 가격 하락, 이용자 청산까지 자동으로 보장된다는 결론은 나오지 않습니다.
발동 조건과 결정권은 지금 버전에서 확인합니다
예전 안전 모듈은 손실 처리에 거버넌스 개입이 필요했지만, 엄브렐라는 특정 적자 조건에서 자동 로직을 씁니다. 과거 공지에 나온 최대 슬래싱 비율이나 적용 네트워크를 현재 설정처럼 인용해서는 안 됩니다. 계약 주소, 상쇄 한도, 최소 자산 하한, 소유자 권한을 배포마다 확인하세요.
보장 상품이라면 사고 정의, 대기 기간, 보장 금액과 만기, 손실 증빙, 심사자 투표를 읽어야 합니다. 같은 해킹이라도 보장을 산 시각이나 대상 프로토콜·체인이 조건에 맞지 않으면 청구가 거절될 수 있습니다. 준비금이 있다는 사실과 내 주소가 청구 자격을 갖췄는지는 따로 기록합니다.
- 기금 계약과 기준 블록을 확인합니다
- 토큰별 유동성 할인율을 계산합니다
- 보호 대상 네트워크·풀·자산을 적습니다
- 발동 조건·상쇄 한도·투표·소유자 권한을 확인합니다
- 개인 청구인지 부실채권 상쇄인지 구분합니다
기금을 쓰면 비용이 다른 이해관계자에게 넘어갑니다
후순위로 손실을 떠안는 스테이커는 보상을 받는 대신 슬래싱 위험을 집니다. 사고 때 스테이킹 자산이 줄어 공급자 쪽 적자를 메우면 그 비용은 스테이커에게 옮겨 갑니다. 금고 준비금을 쓰면 토큰 보유자의 미래 예산이 줄어들 수 있습니다. ‘무료 보험’이라는 말은 누가 첫 손실을 떠안는지를 가립니다.
기금이 모자라면 비율대로 나눠 주거나 청구 대기열을 세우고, 거버넌스가 토큰을 더 발행하거나 미지급 채무를 남길 수도 있습니다. 우선순위와 기금 소진 규칙, 여러 사고가 한꺼번에 났을 때의 합산 한도를 공개해야 합니다. 건당 최대 청구액만 보여 주고 누적 노출을 감추면 지급 능력을 부풀려 보게 됩니다.
사고 뒤에는 실제 자금 흐름을 맞춰 봅니다
손실 사건이 선언되면 적자를 잰 블록, 적용한 상쇄 한도, 슬래싱 금액과 Collector로의 이동, 회계상 상쇄를 거래 단위로 추적합니다. 보장 청구라면 접수, 심사자 결정, 지급 거래 해시를 확인합니다. 발표한 금액과 실제로 지급한 자산·수량이 다르면 가격 변동과 수수료로 차이를 설명해야 합니다.
분기 공시는 기초 잔액, 유입액, 청구·슬래싱 유출액, 기말 잔액이 서로 이어져야 합니다. 홍보 문구보다 이 대사 작업이 더 중요합니다. 적용 범위가 바뀌면 이전 설명을 최신 문서로 갈아 끼웁니다.
이용자는 기금 밖의 위험을 스스로 관리합니다
프로토콜에 준비금이 있어도 개인 키 유출, 엉뚱한 네트워크로 보낸 송금, 사칭 웹 화면 피해는 보장 밖일 수 있습니다. 이용자는 보장 약관과 프로토콜 공시를 보관하고, 사고 전 포지션과 거래 증거를 남겨 두세요. 보장받을 거라 믿고 담보 여유를 줄이는 행동은 피하는 편이 좋습니다.
공시에는 현재 기준으로 바로 쓸 수 있는 자금, 보장 중인 노출액, 시나리오별 부족액이 담겨야 합니다. 미래 거버넌스가 지급을 택할 수도 있다는 가능성은 확정된 권리가 아닙니다.
자주 묻는 질문
보험기금 잔액보다 피해액이 작으면 전액 보상되나요?
자동으로 그렇게 되지는 않습니다. 사고 유형, 대상 시장, 발동 조건, 청구 자격과 다른 책임을 함께 확인해야 합니다.
Safety Module은 개인 해킹 피해도 지급하나요?
대개는 프로토콜 손실을 메우는 후순위 장치입니다. 개인 지갑 손실이 보장되는지는 별도 보장 상품의 조건을 봐야 합니다.
기금의 프로토콜 토큰도 현금과 같은가요?
아닙니다. 매도할 유동성, 가격 충격, 동반 하락 위험을 반영해 가치를 깎아 봐야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
