Babylon | Bitcoin UTXO는 쪼갤 수 없는데 부분 청산은 어떻게 할까?

일반적인 DeFi 담보는 필요한 만큼만 잘라 청산할 수 있습니다.
예를 들어 1만 달러어치 담보 중 3천 달러만 청산하면 된다면 스마트컨트랙트는 필요한 수량만 liquidator에게 넘기고 나머지는 사용자 포지션에 남길 수 있습니다.
하지만 Babylon Trustless Bitcoin Vault는 다릅니다.
각 Vault가 하나의 Bitcoin UTXO이기 때문입니다. Bitcoin UTXO는 일부만 잘라서 지출할 수 없습니다. 한 번 사용하면 해당 UTXO 전체가 소비됩니다.
따라서 Babylon의 Aave v4 연동에서는 청산이 발생할 때 Vault 일부가 아니라 Vault 전체를 단위로 압류하는 Full-vault liquidation이 적용됩니다. 대신 여러 Vault를 하나의 포지션에 넣고 필요한 Vault만 가져가는 방식으로 포지션 전체에서는 부분 청산을 구현합니다.
Full-vault와 Full-position은 다른 개념이다
Babylon 문서에서는 두 표현을 명확히 구분합니다.
Full-vault liquidation은 개별 Vault 하나가 청산될 경우 그 안의 BTC 전체가 이동한다는 의미입니다.
반면 Full-position liquidation은 사용자의 대출 포지션 전체가 청산되는 상황입니다.
하나의 Vault만 담보로 사용했다면 둘은 사실상 같은 결과가 됩니다. 포지션의 Health Factor가 1.0 아래로 내려가 청산이 시작되면, 해당 Vault 전체가 압류되고 포지션도 종료될 수 있습니다.
하지만 여러 Vault를 담보로 제공했다면 이야기가 달라집니다.
프로토콜은 사용자가 등록한 Vault 목록을 앞에서부터 확인하면서, Health Factor를 목표 수준으로 회복하는 데 필요한 최소 개수의 Vault만 가져갑니다. 뒤에 남은 Vault들은 계속 사용자의 담보로 유지됩니다.
즉, Vault는 항상 전체 단위로 청산되지만 포지션 전체는 부분적으로 청산될 수 있습니다.
여러 Vault를 만들면 청산 범위를 조절할 수 있다
예를 들어 사용자가 1 BTC를 하나의 Vault에 넣었다고 가정해 보겠습니다.
포지션을 다시 건강하게 만들기 위해 0.3 BTC 상당만 청산하면 충분하더라도 해당 Vault는 1 BTC짜리 하나의 UTXO입니다. 프로토콜은 Vault의 30%만 잘라서 가져갈 수 없습니다.
반면 동일한 1 BTC를 여러 Vault로 나눠 담보로 사용했다면 필요한 일부 Vault만 압류할 수 있습니다.
Babylon 문서는 이를 활용해 현재 테스트넷 앱에서 여러 Vault를 조합하는 방식을 제안합니다. 특히 앞쪽에는 청산 시 먼저 가져갈 sacrificial vault, 뒤쪽에는 가능한 한 유지할 protected vault를 배치하는 방식입니다. 실제 Vault 크기는 앱이 현재 포지션과 테스트넷 파라미터를 기준으로 계산합니다.
중요한 점은 청산 순서를 프로토콜이 무작위로 고르는 것이 아니라 사용자가 Vault 순서를 관리할 수 있다는 것입니다.
청산이 시작되면 목록의 앞쪽 Vault부터 연속해서 가져가며, 필요한 담보 가치에 도달하면 나머지는 그대로 남습니다.
문제는 필요한 금액보다 더 많이 가져갈 수 있다는 것이다
Vault를 전체 단위로만 압류하면 새로운 문제가 생깁니다.
가령 포지션을 회복시키기 위해 실제로 필요한 청산 담보가 0.25 BTC인데 가장 앞쪽 Vault가 0.3 BTC라면, 프로토콜은 0.3 BTC Vault 전체를 가져가야 합니다.
사용자는 실제 필요량보다 0.05 BTC 상당을 더 압류당하게 됩니다.
Babylon은 이를 over-seizure, 즉 초과 압류로 설명합니다.
Bitcoin의 UTXO 구조 때문에 발생하는 문제이므로 Vault를 native BTC 상태로 유지하면서는 완전히 없애기 어렵습니다. 대신 Babylon은 초과된 가치를 사용자에게 돌려주기 위해 Fairness Mechanism을 적용합니다.
부분 포지션 청산에서는 초과분만큼 부채를 줄인다
첫 번째 경우는 청산 이후에도 사용자에게 남은 Vault와 부채가 존재하는 Partial-position liquidation입니다.
청산 과정에서 필요한 금액보다 더 많은 BTC 가치가 압류됐지만 사용자의 대출 부채가 여전히 남아 있다면, 프로토콜은 초과분을 별도의 WBTC로 바로 지급하는 대신 남은 부채를 줄이는 데 사용합니다.
이를 Fairness debt repayment라고 합니다.
예를 들어 청산 목표보다 500달러 상당의 담보가 추가로 압류됐다면, 조건에 따라 사용자의 남은 부채가 그 가치만큼 줄어드는 방식입니다.
이 방법은 추가적인 토큰 지급 없이 사용자의 경제적 손실을 보상하면서, 남아 있는 대출 포지션의 Health Factor도 함께 개선할 수 있습니다.
Babylon 문서는 이것이 여러 Vault를 가진 포지션에서 발생하는 가장 일반적인 Fairness 처리 방식이라고 설명합니다.
포지션 전체가 청산되면 WBTC로 돌려준다
두 번째 경우는 모든 Vault가 압류되고 부채도 전부 정리되는 Full-position liquidation입니다.
이 상황에서는 줄여줄 남은 부채가 없습니다. 따라서 초과 압류된 가치가 존재한다면 사용자에게 WBTC로 Fairness payment를 지급합니다.
왜 native BTC가 아니라 WBTC일까요?
청산 자체는 Ethereum의 Aave 환경에서 먼저 처리되는 반면, 실제 native BTC Vault의 Bitcoin 측 정산에는 별도의 시간이 필요하기 때문입니다. Fairness Mechanism은 빠른 Ethereum 청산과 느린 Bitcoin 정산 사이에서 사용자의 초과 담보 가치를 Ethereum 측에서 보상합니다.
다만 초과분을 단순히 현재 BTC 시장가격 그대로 계산해서 지급하는 것은 아닙니다.
Babylon은 실제 청산에서 적용된 부채와 압류 담보의 교환 비율을 이용해 Fairness 값을 조정합니다. 공식 문서의 예시에서는 2만5천 달러 상당의 담보를 압류해 2만4천 달러의 부채를 정리했다면, Fairness 계산에서도 압류 담보 1달러를 약 0.96달러 가치로 평가합니다.
이는 Fairness payment만 시장가격 100%로 계산해 일반 liquidator보다 더 유리한 조건을 사용자에게 제공하지 않도록 하기 위한 구조입니다.
청산은 누군가의 판단이 아니라 Health Factor로 결정된다
Whole-vault 구조 때문에 “어떤 Vault를 가져갈지 운영자가 선택하는 것 아니냐”는 의문이 생길 수 있습니다.
현재 Babylon의 Aave v4 연동에서는 포지션의 Health Factor가 1.0 아래로 내려가면 청산이 가능해집니다. 청산 시점 자체를 Babylon 직원이나 Vault Provider가 임의로 결정하는 것은 아닙니다.
Health Factor는 담보의 위험조정 가치와 부채를 비교해 계산합니다.
BTC 가격이 하락하거나, Aave 대출 이자가 누적돼 부채가 증가하면 Health Factor가 낮아질 수 있습니다. 현재 공개 테스트넷 문서에서는 BTC 담보에 78%의 collateral factor가 적용되고 있지만, 이는 테스트넷 파라미터이므로 향후 메인넷이나 거버넌스 과정에서 변경될 수 있습니다.
청산이 시작되면 프로토콜은 사용자가 정한 Vault 순서대로 필요한 최소 prefix를 계산합니다.
즉, 청산 여부는 포지션 상태가 결정하고, 압류 대상은 사전에 정렬된 Vault 목록과 알고리즘이 결정합니다.
실제 BTC 정산과 Ethereum 청산은 서로 다른 속도로 진행된다
또 하나 중요한 점은 Aave에서 청산이 발생했다고 해서 native BTC가 즉시 liquidator 지갑으로 이동하는 것은 아니라는 것입니다.
Bitcoin Vault의 실제 redemption에는 Bitcoin 측 증명과 Challenge 절차가 필요합니다.
Babylon은 이 시간차를 해결하기 위해 Liquidation Liquidity Provider, LLP 구조를 사용합니다. Permissionless liquidator가 Ethereum에서 사용자의 부채를 상환하면 LLP가 WBTC를 즉시 지급하고, 압류된 Vault는 에스크로에 들어갑니다. 이후 등록된 Arbitrageur가 Vault를 인수하고 Bitcoin에서 실제 native BTC 반환 절차를 진행합니다.
별도의 App Keeper가 직접 Vault를 redemption하는 경로도 존재합니다.
따라서 Whole-vault liquidation은 Bitcoin UTXO의 특성만으로 끝나는 문제가 아닙니다. 빠르게 반응해야 하는 Ethereum 대출시장과 시간이 필요한 Bitcoin 정산을 연결하는 유동성 구조까지 함께 필요합니다.
Vault 크기 자체가 리스크 관리 도구가 된다
일반적인 DeFi에서는 사용자가 담보 토큰의 수량을 조절하는 것이 핵심입니다.
Babylon TBV에서는 여기에 Vault를 몇 개로 나누고 어떤 순서로 배치할 것인가라는 새로운 요소가 추가됩니다.
큰 Vault 하나만 사용하면 관리가 간단하지만, 청산이 발생했을 때 전체 Vault를 잃을 가능성이 있습니다.
반대로 여러 Vault로 나누면 청산 범위를 더 세밀하게 제한할 수 있습니다. 그러나 Vault 생성과 관리가 복잡해지고, 각각의 Bitcoin UTXO와 관련된 비용도 고려해야 합니다.
따라서 Vault granularity 자체가 담보 관리 전략이 됩니다.
Bitcoin의 제약을 없애는 대신 그대로 반영한다
Babylon은 Bitcoin UTXO를 Ethereum ERC-20처럼 자유롭게 분할 가능한 자산으로 바꾸지 않습니다.
각 Vault는 끝까지 하나의 native Bitcoin UTXO로 남습니다. 그 결과 개별 Vault를 부분적으로 압류할 수 없다는 제약도 그대로 유지됩니다.
대신 여러 Vault를 하나의 포지션에 연결해 Partial-position liquidation을 구현하고, 필요한 양보다 많이 압류된 경우 Fairness debt repayment 또는 WBTC Fairness payment를 통해 초과 가치를 돌려줍니다.
결국 Babylon의 청산 구조는 Bitcoin의 제약을 숨기는 것이 아니라, 그 제약을 DeFi 대출시장 안에서 관리할 수 있도록 변환한 방식입니다.
Vault 하나는 항상 통째로 움직이지만, 여러 Vault를 조합하면 포지션은 부분적으로 청산할 수 있습니다. 그리고 불가피하게 발생하는 초과 압류는 Fairness Mechanism으로 보정합니다.
댓글 0개


2026.10.07 09:42:52