-
링크복사
-
공유
-
댓글
Babylon | 내 BTC는 정말 안전한 담보일까? SCRIPT 6가지 위험 평가 기준
비트코인을 담보로 대출을 받는 서비스는 점점 많아지고 있습니다. 하지만 모두 같은 방식으로 BTC를 보관하고, 같은 수준의 위험을 가지는 것은 아닙니다.
어떤 서비스는 사용자의 BTC를 중앙화된 수탁기관에 맡기고, 다른 서비스는 브리지나 멀티시그를 통해 wrapped BTC를 발행합니다. 또 다른 방식은 사용자의 BTC를 Bitcoin 네트워크에 그대로 둔 상태에서 담보로 활용합니다.
Babylon은 이러한 Bitcoin 담보 구조를 비교하기 위해 SCRIPT라는 위험 평가 프레임워크를 공개했습니다. SCRIPT는 Babylon이 자체 native BTC 담보 프로토콜을 설계할 때 내부적으로 사용해 온 기준으로, Babylon뿐 아니라 다른 Bitcoin 담보 솔루션에도 적용할 수 있도록 만들어졌습니다.
SCRIPT는 총 6가지 기준으로 구성됩니다.
Sovereignty · Clarity · Reuse Prohibited · Isolation · Permissionless · Transparency
1. Sovereignty — 내 BTC에 대한 통제권을 유지하는가
첫 번째 기준은 Sovereignty, 즉 BTC 소유자가 자산에 대한 실질적인 통제권을 유지하는지입니다.
중앙화된 대출 서비스에 BTC를 보내면 사용자는 사실상 자산을 서비스 사업자에게 넘기게 됩니다. 이후 출금이나 청산 과정 역시 해당 사업자의 시스템과 지급 능력에 의존합니다.
Babylon의 SCRIPT는 이상적인 Bitcoin 담보 구조에서는 사용자가 미리 정해진 청산 조건이 발생하기 전까지 BTC에 대한 통제권을 유지해야 한다고 설명합니다. 제3자에게 BTC를 완전히 이전하는 방식은 상대방 위험뿐 아니라 회계·세무·규제 측면에서도 추가적인 문제를 만들 수 있습니다.
Babylon TBV에서는 BTC가 Bitcoin의 개별 UTXO와 Taproot Script 안에 잠기며, Vault가 만들어질 때 가능한 지출 경로가 사전에 정해집니다. 특정 운영자가 임의의 주소로 BTC를 옮길 수 있는 구조가 아닙니다.
2. Clarity — 청산과 상환 규칙이 미리 정해져 있는가
두 번째는 Clarity입니다.
사용자의 BTC가 어떤 조건에서 반환되고, 어떤 상황에서 청산되며, 누가 해당 절차를 실행할 수 있는지가 사전에 명확해야 한다는 의미입니다.
특히 담보 시스템에서 위험한 것은 운영자가 상황에 따라 규칙을 바꿀 수 있는 경우입니다. 출금 조건이나 청산 방식이 계약 체결 이후 변경되거나, 특정 주체가 예외적으로 규칙을 무시할 수 있다면 사용자는 실제로 어떤 조건을 받아들인 것인지 알기 어렵습니다.
SCRIPT는 상환·청산·압류 등 담보의 처분 규칙이 사전에 공개되고 객관적인 조건으로 고정돼야 한다고 봅니다. 업그레이드가 가능한 시스템이라면 변경 절차 역시 명확해야 합니다.
Babylon TBV에서도 Vault 생성 시 가능한 Bitcoin 지출 경로가 미리 만들어지고 서명됩니다. 이후 특정 운영자가 새로운 BTC 지출 경로를 임의로 추가할 수 없습니다.
3. Reuse Prohibited — 내 동의 없이 담보를 다시 빌려주지 않는가
세 번째는 Reuse Prohibited, 즉 재담보화 여부입니다.
금융기관이 고객의 담보를 다시 다른 거래에 사용하면 동일한 자산을 두고 여러 채권자가 권리를 주장할 수 있습니다. 이를 재담보화, 즉 rehypothecation이라고 합니다.
정상적인 시장에서는 사용자가 이러한 구조를 이해하고 동의할 수도 있습니다. 문제는 담보가 본인의 동의 없이 다른 대출이나 투자에 다시 사용되는 경우입니다.
SCRIPT는 Bitcoin 담보가 다른 포지션에 재사용되거나 제3자의 청구권에 노출되는 경우 이를 명확히 공개하고 사용자의 동의를 받아야 한다고 설명합니다. 가장 보수적인 구조는 애초에 재담보화를 허용하지 않는 것입니다.
Babylon TBV의 공개 문서에서는 Vault에 잠긴 BTC를 다른 대출에 재사용하거나 외부 상품으로 이동시키는 프로토콜 경로가 존재하지 않는다고 명시합니다. 각 Vault는 특정 애플리케이션 하나에 연결되며 자유롭게 이동할 수 없습니다.
4. Isolation — 다른 사용자의 BTC와 섞이지 않는가
네 번째는 Isolation입니다.
여러 사용자의 BTC가 하나의 큰 풀에 섞이면 개별 담보와 대출 포지션 사이의 연결이 불분명해질 수 있습니다.
예를 들어 특정 BTC가 이후 규제나 자금세탁 관련 문제의 대상이 됐을 경우, 같은 풀에 들어 있던 다른 사용자의 자산까지 운영상 영향을 받을 가능성이 있습니다. 특정 대출의 담보가 실제로 어떤 BTC인지 확인하기도 어려워질 수 있습니다.
SCRIPT는 각 사용자의 담보가 가능한 한 독립적으로 식별되고 개별 포지션에 귀속돼야 한다고 설명합니다.
Babylon에서는 각각의 Vault가 하나의 Bitcoin UTXO로 존재합니다. 다른 사용자의 BTC와 하나의 공용 담보 풀에 합쳐지는 것이 아니라, 각 Vault를 Bitcoin에서 직접 추적할 수 있습니다.
이 구조는 이후 청산 방식에도 영향을 줍니다. Vault 하나가 하나의 UTXO이기 때문에 Babylon의 청산 역시 개별 Vault 단위로 이뤄집니다.
5. Permissionless — 운영자가 거래를 막을 수 있는가
다섯 번째 기준은 Permissionless입니다.
비트코인을 담보로 제공할 수 있는지, 대출금을 갚은 뒤 BTC를 돌려받을 수 있는지, 청산 조건이 충족됐을 때 담보를 처리할 수 있는지에 대해 특정 중앙 운영자의 승인이 반드시 필요하다면 검열 위험이 존재합니다.
SCRIPT는 담보의 전체 생명주기에서 한 주체가 사용자의 행동을 일방적으로 막을 수 없어야 한다고 설명합니다.
Babylon의 TBV에도 Vault Provider나 App Keeper, Universal Challenger 같은 운영 참여자가 존재합니다. 그러나 공식 문서는 이들이 사용자 BTC를 수탁하는 주체는 아니라고 설명합니다.
예를 들어 정상적인 BTC 반환 과정에서 Vault Provider가 응답하지 않더라도 사용자는 자신이 보관한 키와 자료로 Self-claim을 진행할 수 있습니다. 잘못된 Claim이 발생하면 사용자 스스로 Challenge 경로를 실행할 수도 있습니다. 활성화가 중단된 Vault는 현재 공개 테스트넷 기준 2,016 Bitcoin 블록의 timelock 이후 직접 환불하는 경로도 존재합니다.
즉, 운영자가 편의성과 자동화를 제공하더라도 사용자의 BTC 회수 자체가 특정 운영자의 선의에만 의존하지 않도록 설계하는 것입니다.
6. Transparency — 담보를 누구나 확인할 수 있는가
마지막 기준은 Transparency입니다.
담보 대출 서비스가 “충분한 BTC를 보유하고 있다”고 주장하더라도 실제 담보를 외부에서 확인할 수 없다면 사용자는 사업자의 내부 장부를 믿어야 합니다.
SCRIPT는 대출 포지션마다 실제 native BTC 담보가 존재하는지 투명하게 확인할 수 있어야 한다고 설명합니다. 그렇지 않으면 부족한 담보나 depeg, bad debt 문제가 뒤늦게 발견될 수 있습니다.
Babylon TBV에서는 각 Vault가 Bitcoin의 독립적인 UTXO이기 때문에 해당 담보가 실제 Bitcoin 네트워크에 존재하는지 추적할 수 있습니다. Ethereum 쪽에서는 이를 DeFi 애플리케이션이 담보로 인식할 수 있도록 별도의 collateral record가 만들어지지만, 이는 거래 가능한 wrapped BTC가 아니라 실제 Vault와 연결된 내부 기록입니다.
‘Native BTC’라는 말만으로 안전한 것은 아니다
SCRIPT에서 중요한 점은 특정 기술 이름보다 실제 통제 구조를 확인해야 한다는 것입니다.
어떤 서비스가 native BTC라고 홍보하더라도 사용자가 BTC에 대한 통제권을 포기해야 하거나, 운영자가 담보를 재사용할 수 있고, 포지션별 담보를 확인하기 어렵다면 SCRIPT 기준에서는 추가적인 위험이 존재합니다.
반대로 브리지나 수탁기관을 사용하지 않는다고 해서 위험이 완전히 사라지는 것도 아닙니다.
Babylon TBV 역시 Bitcoin과 Ethereum 네트워크, Aave 같은 연결 애플리케이션의 스마트컨트랙트와 오라클, ZK 증명 시스템, BABE 구조 등에 의존합니다. 공식 문서 역시 스마트컨트랙트 오류, 오라클 조작, Bitcoin reorg, ZK 시스템의 soundness 문제 등을 위험 요인으로 명시하고 있습니다.
즉, SCRIPT가 평가하려는 것은 “완전히 무위험한가”가 아니라 어떤 상대방과 운영자를 신뢰해야 하며, 그 위험을 얼마나 줄였는가입니다.
Bitcoin 담보를 볼 때는 수익률보다 구조부터 확인해야 한다
BTC 담보 상품은 높은 대출 한도나 낮은 금리, 추가 수익률을 강조하기 쉽습니다.
하지만 담보가 실제로 어떻게 보관되는지, 청산 시 누가 자산을 통제하는지, 담보를 다른 곳에서 재사용할 수 있는지에 따라 사용자가 부담하는 위험은 크게 달라집니다.
Babylon의 SCRIPT는 이를 여섯 가지 질문으로 정리합니다.
내 BTC에 대한 통제권을 유지하는가? 청산 규칙은 사전에 정해져 있는가? 동의 없이 재담보화되지 않는가? 다른 사용자의 담보와 분리돼 있는가? 특정 운영자가 사용과 반환을 막을 수 없는가? 실제 담보를 외부에서 확인할 수 있는가?
BTCFi가 커질수록 중요한 것은 “비트코인을 담보로 사용할 수 있다”는 사실 자체보다, 그 과정에서 어떤 새로운 신뢰와 상대방 위험이 생기는지를 확인하는 것입니다.
댓글 0개
2026.10.07 09:41:03