Bitcoin을 래핑(Wrapping)하지 않고 담보로 사용하기: BTC 담보 금고(Collateral Vault)의 설계

이것은 월요일의 딥다이브(deep-dive) — 하나의 메커니즘을 면밀히 조사합니다.

트레이딩 에이전트(trading agent)가 담보를 제공해야 하고, 제공하고자 하는 자산이 Bitcoin이라고 가정해 봅시다. 이는 합리적인 요구입니다. BTC는 암호화폐 시장에서 가장 깊고 유동성이 높은 담보 자산이기 때문입니다. 문제는 Bitcoin 체인 자체가 담보화된 포지션(collateralized position)에 필요한 계약 로직을 실행할 수 없다는 점입니다. 표현력이 풍부한 스마트 컨트랙트(smart contracts), 객체(objects), 또는 시간이 지남에 따라 포지션을 감시하는 상태 머신(state machine)이 없습니다. 따라서 담보는 한 체인에 존재하고, 그것이 뒷받침하는 의무는 다른 체인에 존재하게 됩니다.

표준적인 해결책은 Bitcoin을 래핑(wrapping)하는 것입니다. 우리는 더 나은 형태의 해결책이 있다고 생각하며, 이를 주의 깊게 살펴볼 가치가 있습니다.

래핑(Wrapping)이 실제로 치르는 비용

BTC를 래핑한다는 것은 실제 Bitcoin을 보유하고 목적지 체인에서 그에 대한 청구권을 나타내는 토큰을 발행하는 수탁자(custodian), 연합(federation), 또는 브릿지 컨트랙트(bridge contract)에 자산을 넘겨주는 것을 의미합니다. 일단 토큰을 보유하게 되면, 해당 체인의 컨트랙트가 실행되는 어디에서든 이를 담보로 사용할 수 있습니다.

또한 당신은 의도하지 않았을 수도 있는 세 가지 일을 수행하게 됩니다. 첫째, 무기명 자산(bearer asset)을 중개자에 대한 청구권으로 전환했습니다. 둘째, 허니팟(honeypot)을 만드는 데 기여했습니다. 모든 래핑된 토큰을 뒷받침하는 잠겨 있는 BTC 더미는 단일하고 고정된 가치 있는 표적이 됩니다. 셋째, 담보의 무결성(integrity)을 에이전트가 제대로 감사할 방법이 없는 무언가, 즉 실제 코인을 보유한 자의 지속적인 정직성과 지급 능력(solvency)에 의존하게 만들었습니다.

신뢰가 필요 없는 결제 시스템(trustless settlement system) 관점에서 볼 때, 이는 잘못된 거래입니다. 결제를 뒷받침하는 담보 자체가 수탁 방식(custodial)이 되는 순간, 수탁자 없이 결제한다는 핵심 취지는 무색해집니다.

설계: Bitcoin을 Bitcoin에 그대로 두기

담보 금고(collateral vault)는 정반대의 접근 방식을 취합니다. Bitcoin은 다른 체인으로 이동하지 않으며, 발행된 토큰으로 표현되지도 않습니다. 그것은 Bitcoin 체인 자체의 스크립트(script)에 잠긴 네이티브 BTC(native BTC) 상태로 유지됩니다. 체인을 가로질러 이동하는 것은 자산이 아니라, 단 하나의 정보인 비밀값의 해시(hash of a secret)입니다.

그 구조는 다음과 같습니다. Bitcoin 상에서 담보물은 P2WSH 출력(pay-to-witness-script-hash output)에 잠깁니다. 이 출력의 리딤 스크립트(redeem script)는 해시 타임락(hash-time-lock)입니다. 이 스크립트에는 두 가지 지출 경로(spend paths)가 있습니다. 하나는 특정 해시의 프리이미지(preimage)를 제시함으로써 지출할 수 있는 해시락(hashlock) 경로이고, 다른 하나는 블록 높이(block-height) 마감 기한 이후 원래 예치자가 지출할 수 있는 타임락(timelock) 경로입니다. 이는 원자적 스왑(atomic swaps)에 사용되는 것과 동일한 HTLC 구조이며, 여기서는 즉각적인 교환이 아닌 더 장기적인 포지션(position)에 적용되었습니다.

다른 체인 — 즉, 우리의 Move 컨트랙트가 배포된 Sui — 에는 담보가 뒷받침하는 의무(obligation)가 존재합니다. 이는 인도해야 할 선도(forward), 상환해야 할 대출(loan), 또는 다단계 거래의 한 축(leg)입니다. Sui 측 컨트랙트는 해당 의무의 결과에 따라 누가, 언제 프리이미지를 알게 될지를 제어하도록 작성됩니다.

두 체인은 정확히 하나의 공유된 값인 해시(hash)에 의해 결합됩니다. Bitcoin Script는 Sui의 상태(state)를 읽을 수 없고, Sui는 Bitcoin의 UTXO 세트를 읽을 수 없습니다. 하지만 두 체인 모두 사전에 해시에 대해 합의할 수 있으며, 해당 해시의 프리이미지는 양측의 포지션을 동시에 해결하는 단 하나의 키가 됩니다.

결과 경로 (The outcome paths)

금고(vault)는 세 가지 종료 방식을 가지며, 이 세 가지 모두는 기계적으로 작동합니다.

만약 채무 이행자(obligor)가 **이행(performs)**한다면 — 즉, 선도를 인도하거나 대출을 상환한다면 — 프로토콜은 합의된 경로를 따라 프리이미지를 공개하며, BTC는 이행을 통해 권리를 갖게 된 대상에게 정산됩니다. 이 패턴은 '공개를 통한 청구(reveal-to-claim)' 방식입니다. 즉, 한쪽에서 청구하는 행위가 다른 쪽을 해결하는 비밀값을 공개하게 됩니다.

만약 채무 이행자가 **채무 불이행(defaults)**할 경우, 해시락 경로는 합의된 구제책으로서 BTC를 상대방에게 전달합니다. 담보는 담보 본연의 역할을 수행합니다. 즉, 누구도 법원이나 평판을 통해 채무 불이행자를 쫓아다닐 필요 없이 상대방의 손실을 완전히 보전해 줍니다.

만약 아무 일도 일어나지 않는다면 — 즉, 포지션이 단순히 방치된다면 — 타임락 (timelock) 경로를 통해 마감 기한 이후 BTC가 예치자에게 반환됩니다. 그 블록 높이(block height) 이후에는 그 어떤 상대방도, 프로토콜도, 수탁자(custodian)도 코인을 보유할 수 없습니다. 환불은 누군가의 협조가 아닌, Bitcoin 합의 (consensus)에 의해 강제됩니다.

모든 경로에서 BTC는 내내 네이티브 Bitcoin이었으며, 그 어떤 제3자도 이를 일방적으로 이동시킬 수 있는 능력을 가진 적이 없습니다.

금고(Vault)가 의도적으로 수행하지 않는 것

금고는 마진 계정 (margin account)이 아니며, 이 점을 분명히 밝힐 가치가 있습니다. Bitcoin Script는 가격 피드 (price feed)에 접근할 수 없으며, 우리는 설계를 통해 오라클 (oracle)을 몰래 집어넣음으로써 그렇지 않은 척하지 않을 것입니다. 이는 금고가 실시간 마진 콜 (margin call)을 수행할 수 없음을 의미합니다. 즉, 가격을 감시하다가 담보 비율이 깨지는 즉시 청산할 수 없습니다. 금고의 해결 방식은 이산적 (discrete)입니다. 즉, 연속적인 가격에 따라 움직이는 것이 아니라, 성과, 채무 불이행, 또는 마감 기한에 따라 트리거됩니다.

고정된 인도 날짜를 가진 선도 계약 (forward), 정기 대출, 보증된 약정처럼 의무 자체가 이산적인 대다수의 에이전트 간 (agent-to-agent) 사용 사례에서는 이 방식이 적절합니다. 진정으로 연속적인 시가 평가 (mark-to-market)가 필요한 포지션의 경우, 해시 타임락 (hash-time-locked) 금고는 잘못된 도구이며, 우리는 이를 과장해서 판매하기보다 솔직하게 말씀드리고자 합니다.

에이전트에게 이것이 갖는 의미

자율 에이전트 (autonomous agent)에게 위에서 언급한 그 어떤 것도 수동으로 관리되어서는 안 됩니다. P2WSH 출력을 감시하고, 블록 시간이 매우 다른 두 체인 간의 타임락을 조정하며, 해시락 (hashlock) 경로를 소비하는 데 필요한 위트니스 (witness)를 구성하는 작업 — 이것이야말로 정확히 툴 콜 (tool call) 뒤에 있어야 할 종류의 작업입니다. 우리의 MCP 서버 (hashlock-tech/mcp, 6개의 도구로 구성)는 에이전트가 배관 작업(plumbing)이 아닌 포지션 자체를 추론할 수 있도록 존재합니다. 에이전트는 해시에 약속하고, 한 축에 자금을 공급하며, 상태를 확인하고, 프로토콜이 스크립트 수준의 메커니즘을 처리하도록 맡깁니다. MCP는 Anthropic이 모델을 외부 시스템에 연결하기 위해 도입한 개방형 프로토콜이며, 금고는 그 표면 위에서 실행되는 또 다른 툴 콜 세트일 뿐입니다.

솔직한 한계

이것은 하나의 설계이며, 이에 대해 솔직한 현황 보고를 하는 것이 마땅합니다. Bitcoin P2WSH HTLC는 Bitcoin의 테스트 네트워크인 signet에서 검증되었으며, 메인넷(mainnet) 적용은 아직 대기 중입니다. Sui 컨트랙트(contracts)는 배포되어 CLI 테스트를 마쳤으며, 게이트웨이(gateway) 배선 작업이 진행 중입니다. 오늘날 원자적 결제(atomic settlement)가 엔드 투 엔드(end-to-end)로 실제로 작동하는 유일한 곳은 Ethereum 메인넷뿐입니다. 따라서 BTC 담보 금고(collateral vault)는 우리가 향후 구축해 나갈 설계이지, 오늘 아침 바로 누를 수 있는 버튼이 아닙니다. 우리는 이를 모호하게 표현하기보다 명확하게 밝히고자 합니다.

제품이 출시된 이후에도 트레이드오프(tradeoffs)는 실재합니다. Bitcoin의 약 10분 단위 블록 생성 주기는 타임아웃(timeout) 윈도우를 거칠게 만듭니다. 빠른 체인(fast chain)에서 할 수 있는 것처럼 엄격하고 정밀한 마감 시간을 설정할 수 없으며, 크로스체인 타임아웃 조정(cross-chain timeout coordination) — 즉, 목적지 체인의 마감 시간이 Bitcoin의 마감 시간 안에 안전하게 포함되어야 한다는 점 — 은 구조적으로 보수적일 수밖에 없습니다. 담보는 포지션이 유지되는 동안 잠긴 채로 유휴 상태가 됩니다. 또한 이 모델은 해시 함수(hash function)가 유효하다는 것을 전제로 합니다. 이것들은 수탁자(custodian)를 제거함으로써 발생하는 비용입니다. 우리는 금고가 의도하는 포지션 유형에 대해서는 이 비용을 지불할 가치가 있다고 생각합니다. 그럼에도 이것들은 여전히 비용입니다.

질문

Wrapped BTC는 어디에서나 수탁 방식(custodial)을 채택함으로써 Bitcoin을 어디서든 사용할 수 있게 만들었습니다. 담보 금고의 이면에 있는 베팅은, 코인 대신 해시(hash)를 이동시킴으로써 수탁자 없이도 그 유용성의 대부분을 유지할 수 있다는 것입니다. 즉, Bitcoin이 실제로 이를 추론할 수 있는 체인 위에서 의무(obligation)를 뒷받침하게 만드는 것입니다.

따라서 에이전트 측 담보 로직(agent-side collateral logic)을 구축하는 모든 이들에게 다음과 같은 질문을 던집니다. 당신의 에이전트가 Bitcoin을 담보로 제출할 때, 그 코인을 누가 움직일 수 있는지 정확히 알고 있습니까? 그리고 그 정직한 답변이 "오직 에이전트뿐이며, 오직 에이전트가 사전에 동의한 경로를 따라서만 움직인다"입니까?

Hashlock Markets — 에이전트 경제를 위한 원자적 결제(atomic settlement). 밀봉 입찰(Sealed-bid) RFQ + HTLC 결제가 하나의 작업으로 융합되었습니다. 브릿지(bridges)도, 수탁자(custodians)도 없습니다.

• 프로토콜: [https://hashlock.markets?utm_source=devto&utm_medium=referral&utm_campaign=2026-05-25-btc-collateral-vaults]
• MCP 서버 (출처): [https://github.com/Hashlock-Tech/hashlock-mcp]
• 기반 메커니즘 설계는 SSRN의 워킹 페이퍼에 작성되었습니다: [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722]