“비수탁”은 더 이상 정보를 전달하지 못할 만큼 느슨하게 쓰이고 있습니다. 이 주장의 유용한 버전은 좁고 검증 가능합니다: 누가 당신의 자금을 움직일 수 있는지를 설명할 뿐, 당신이 자금을 잃을 수 있는지에 대해서는 아무 말도 하지 않습니다.
요약
비수탁이란 당신의 자금이 당신이 통제하는 계좌를 결코 벗어나지 않는다는 뜻입니다. 하이퍼리퀴드에서는 이것이 에이전트 승인을 통해 구현됩니다: 당신은 특정 에이전트 주소를 승인하고, 이 주소는 당신의 계좌에서 거래 행위 — 주문 개설과 취소, 포지션 개설과 청산 — 에 서명할 권한을 부여받습니다. 에이전트는 출금 권한이 없고, 다른 주소로 자금을 이체할 수 없으며, 계좌 소유권을 변경할 수 없고, 추가 에이전트를 승인할 수 없습니다. 당신의 USDC는 항상 자신의 계좌와 서브계정에 머물며, 승인은 자본을 옮기거나 운영자의 협조를 요구하지 않고 언제든 당신이 철회할 수 있습니다. 비수탁은 제3자가 당신의 자금으로 할 수 있는 일을 제한할 뿐이며, 시장 리스크, 청산 리스크, 실행 리스크를 줄이지는 않습니다.
생각보다 적은 일을 하고 있는 단어
“비수탁”은 기술적 진술이 아니라 신뢰 신호가 되어버렸고, 이는 안타까운 일입니다. 기술적 진술은 정말로 유용한 반면 신뢰 신호는 그렇지 않기 때문입니다. 마케팅으로 읽으면 전반적인 안전성을 시사합니다. 정확하게 읽으면 하나의 구체적인 주장만을 합니다: 어떤 제3자도 당신의 자금을 보유하지 않으므로, 어떤 제3자도 그것을 출금하거나, 동결하거나, 대출로 굴리거나, 파산으로 잃을 수 없다는 것입니다.
그 주장은 가질 가치가 있습니다. 사용자의 잔고가 실제로는 자신의 계좌에 있는 자산이 아니라 다른 누군가의 대차대조표상 부채였음이 드러나며 무너진 중앙화 플랫폼들을 무너뜨린 실패 범주 전체를 제거하기 때문입니다. 하지만 이 주장은 엄격하게 제한적이기도 합니다. 비수탁은 전략이 견실한지, 포지션이 청산될 수 있는지, 실행이 리더와 일치할지, 당신이 돈을 잃을 수 있는지에 대해서는 아무 말도 하지 않습니다. 완전히 비수탁 시스템에서도 잔고 전체를 잃을 수 있습니다. 수탁과 리스크는 서로 다른 축이며, 이 둘을 혼동하는 것이 이 영역에서 가장 흔한 실수입니다.
그러므로 어떤 복사 거래 상품에 대해서든 물어볼 가치가 있는 질문은 그것이 스스로를 비수탁이라 부르는지가 아니라: 이 시스템이 내 계좌로 정확히 무엇을 할 수 있도록 허가받았는가, 그리고 나는 그 허가를 어떻게 철회하는가입니다.
수탁 대 거래 전용 권한
수탁이란 자금을 움직일 수 있는 키를 다른 누군가가 통제한다는 뜻입니다. 당신은 그들이 소유한 주소에 예치하고, 당신의 잔고는 그들의 장부상 항목이 되며, 당신이 취하는 모든 행동은 그들이 승인 여부를 선택하는 요청이 됩니다. 출금은 그들이 부여하는 허가입니다. 그들이 해킹당하거나, 파산하거나, 단순히 출금을 중단하기로 결정하면 당신의 구제 수단은 기술적이 아니라 법적인 것입니다.
거래 전용 권한은 다른 구조입니다. 자금은 당신이 소유권 키를 보유한 계좌에 그대로 남습니다. 위임하는 것은 자산에 대한 통제권이 아니라 특정 부류의 행동 — 이 경우 거래 — 을 수행할 권한입니다. 위임받은 당사자는 당신의 자본이 노출되는 대상을 바꿀 수 있습니다. 당신의 자본이 어디에 있는지는 바꿀 수 없습니다.
이 구분은 실패 사례에서 구체적인 결과를 낳습니다. 거래 전용 권한을 가진 시스템이 해킹당하면, 공격자는 당신의 계좌를 나쁘게 거래할 능력을 물려받습니다. 이는 실제 손실 경로이며 축소해서는 안 됩니다 — 거래 권한을 가진 악의적 행위자는 무모한 포지션을 열어 시장을 통해 자금을 잃게 만들 수 있습니다. 그들이 할 수 없는 것은 당신의 잔고를 자신이 통제하는 주소로 보내는 것입니다. 최악의 경우는 절도가 아니라 시장 결과로 제한되며, 이는 누구의 지급 능력에도 좌우되지 않고 오직 당신 자신의 지급 능력에만 좌우됩니다.
하이퍼리퀴드 에이전트 승인이 실제로 부여하는 것
하이퍼리퀴드는 이 위임을 자체 에이전트 시스템 — 때로는 API 지갑이라고도 불리는 — 을 통해 네이티브로 구현합니다. 당신은 자신의 지갑으로 일회성 승인에 서명하며, 이는 지정된 에이전트 주소가 당신의 계좌를 대신해 서명된 행위를 제출하도록 허가합니다. 승인 자체가 하이퍼리퀴드상의 한 행위이며, 계좌 소유자가 서명하고, 정확히 어떤 주소가 권한을 부여받는지를 명시합니다.
승인이 완료되면 에이전트는 하이퍼리퀴드가 에이전트에게 노출하는 거래 행위 — 주문 개설, 주문 취소, 주문 수정, 포지션 개설 및 청산, 관리하는 포지션의 레버리지 또는 마진 설정 조정 — 에 서명할 수 있습니다. 우리의 경우 이 권한 덕분에 당신이 개별 주문마다 서명하지 않아도 각 격리된 서브계정에서 미러링된 거래가 실행됩니다 — 이는 복사 거래 시스템이 작동할 수 있는 유일한 방법입니다. 리더는 지속적으로 거래하고, 주문마다 수동 승인을 하면 익스포저가 결코 일치하지 않을 것이기 때문입니다.
승인의 두 가지 속성은 정확히 짚어둘 가치가 있습니다. 주소 범위가 지정되어 있다는 것 — 권한은 당신이 승인한 특정 에이전트 주소에 속하며, 다른 어떤 주소도 이를 물려받지 않습니다. 그리고 소유권과 분리되어 있다는 것 — 에이전트 키는 당신의 계좌 키가 아니고, 이를 유도할 수 없으며, 하이퍼리퀴드가 에이전트에게 허용하는 행위 집합을 넘어서는 어떤 권리도 계좌에 대해 갖지 않습니다. 에이전트를 승인하는 것은 당신의 지갑을 넘기는 것이 아니라 — 의도적으로 더 약한 두 번째 서명자를 등록하는 것입니다.
이와 함께 대부분의 사용자가 마주치는 별도의 승인도 있습니다: 빌더 수수료입니다. 이는 미러링된 명목가에 대한 0.1% 수수료를 승인하며, 별도의 상한선을 가진 별개의 권한이지 거래 권한의 구성 요소가 아닙니다. 두 개의 승인, 두 개의 목적, 모두 당신이 명시적으로 서명합니다.
에이전트가 할 수 없는 것
보안 논거는 제외 사항들에 달려 있으므로, 대충 넘어가기보다 명확히 밝힐 가치가 있습니다.
에이전트의 권한 안에 남아있는 것은 정확히 복사 거래 시스템에 필요한 것뿐, 그 이상은 없습니다: 거래를 개설하고 청산하는 능력입니다. 이는 작은 권한이 아닙니다 — 시장을 통한 손실은 충분히 가능합니다 — 하지만 이 기능에 필요한 최소한의 실질적 권한이며, 이것이 시스템을 평가할 올바른 기준입니다.
출금할 수 없습니다. 하이퍼리퀴드에서 외부 체인 주소로의 출금은 계좌 소유자의 서명을 요구합니다. 에이전트 권한은 출금 행위까지 확장되지 않으므로, 어떤 에이전트도 — 우리 것이든 해킹당한 것이든 — 계좌에서 자금을 이동시킬 수 없습니다.
다른 주소로 자금을 이체할 수 없습니다. 당신의 잔고를 제3자에게 보내는 것은 에이전트 행위 집합에 포함되어 있지 않습니다. 자본은 할당 과정의 일부로 당신 자신의 계좌와 서브계정 사이에서는 이동할 수 있지만, 당신이 통제하는 소유권 경계를 벗어날 수는 없습니다.
소유권을 바꾸거나 계좌를 탈취할 수 없습니다. 계좌 키는 당신에게 남습니다. 에이전트는 이를 교체하거나, 바꾸거나, 당신을 잠글 수 없습니다.
추가 에이전트를 승인할 수 없습니다. 위임은 복합적으로 늘어나지 않습니다. 오직 계좌 소유자만 에이전트를 승인할 수 있으므로, 에이전트는 자신의 권한을 넓히거나 두 번째 서명자를 만들 수 없습니다.
당신이 행동하는 것을 막을 수 없습니다. 당신 자신의 키는 항상 완전한 권한을 유지합니다. 언제든지, 우리에게 묻지 않고, 우리를 기다리지 않고, 계좌를 직접 거래하거나, 미러링된 포지션을 수동으로 청산하거나, 출금할 수 있습니다.
철회 가능성이 중요한 이유
일방적으로 철회할 수 없는 권한은 사실상 권한이 아니라 양도입니다. 철회 가능성은 위임을 되돌릴 수 있게 유지하는 요소이며, 이 모델을 원칙상이 아니라 실제로 수탁과 가장 크게 구별짓는 속성입니다.
승인이 당신 자신의 계좌에 대한 온체인 행위이기 때문에, 이를 철회하는 것도 마찬가지입니다. 당신은 자신의 키로 에이전트 권한을 철회합니다. 우리의 협조, 우리의 가동 시간, 우리의 동의가 필요하지 않으며 — 결정적으로, 나가기 위해 자금을 옮길 필요도 없습니다. 수탁 하에서는 떠난다는 것이 출금을 요청하고 누군가 처리해줄 때까지 기다리는 것을 의미하며, 이는 플랫폼이 어려움에 처했을 때 정확히 실패하는 단계입니다. 여기서는 철회가 향후 거래 권한을 즉시 중단시키는 동안 당신의 잔고는 이미 있던 곳에 정확히 그대로 머뭅니다.
정직하게 밝힐 두 가지가 있습니다. 철회는 포지션을 닫지 않습니다: 미결제 미러링 포지션은 당신 또는 시스템이 청산할 때까지 자체 마진과 청산가를 가진 채 열려 있습니다 — 그러므로 목표가 무포지션 상태라면, 철회한 후 청산하거나, 청산한 후 철회하십시오. 그리고 철회는 소급적이지 않습니다. 앞으로의 권한을 끝낼 뿐이며, 이미 실행된 거래를 되돌리지 않습니다. 철회 가능성은 위임된 서명자에게 노출되는 기간을 제한할 뿐, 그 서명자가 이미 한 행동의 결과를 제한하지는 않습니다.
대안들과의 비교
거래소 API 키가 가장 가까운 유사물이며 이 비교는 유용합니다. 출금이 비활성화된 거래 전용 API 키는 비슷한 권력 분리를 달성하며, 합리적인 모델입니다. 차이는 집행과 검증 가능성에 있습니다: API 키의 권한 범위는 이미 그 거래소가 수탁하고 있는 자금에 적용되는, 중앙화된 거래소 시스템의 설정이며, 당신은 그들의 인터페이스를 신뢰함으로써 이를 검증합니다. 하이퍼리퀴드 에이전트 승인은 당신이 소유한 계좌에 대한 온체인 행위이며, 행위 집합은 권한 테이블이 아니라 프로토콜에 의해 집행됩니다. API 키 시스템의 운영자가 해킹당하면 당신의 키가 노출되지만 당신의 자금도 이미 수탁자에게 있습니다. 여기서는 경로 어디에도 수탁자가 전혀 없습니다.
수탁형 복사 거래 플랫폼은 단순히 다른 리스크 범주입니다. 당신이 예치하면, 그들이 보유하고, 그들이 거래하며, 당신은 청구권을 보유합니다. 이는 이미 짊어지고 있는 모든 시장 리스크 위에 카운터파티 리스크, 파산 리스크, 출금 중단 리스크를 추가하며, 이 추가 리스크 중 어느 것도 아무것으로도 보상되지 않습니다. 이들은 순전히 아키텍처의 결과로 존재합니다.
풀링되거나 펀드 형태의 구조는 한 걸음 더 나아갑니다: 당신의 자본은 공유 계좌나 수단 안에서 다른 사용자들의 자본과 섞입니다. 카운터파티 노출을 넘어, 이는 당신의 포지션이 갖는 독립성을 없앱니다 — 당신의 진입가, 청산 리스크, 실현 결과는 다른 참가자들의 흐름과, 넷팅된 계좌에서는 그들의 반대 포지션과도 얽히게 됩니다. 우리 모델은 설계상 정반대 구조입니다: 자본은 당신 자신의 계좌에 머물며, 리더당 하나씩, 각각 별도의 마진과 별도의 청산가를 가진 당신 자신의 격리된 서브계정으로 미러링됩니다. 당신의 포지션은 당신의 것이며, 개별적으로 귀속 가능하고, 다른 누구의 행동에도 영향받지 않습니다.
권한 설계는 리스크 결정입니다
모든 자동화된 거래 시스템은 무언가를 위임할 것을 요구합니다. 위임 없는 자동화는 모순이기 때문입니다. 진짜 문제는 얼마나 위임하는지, 무엇에 의해 집행되는지, 그리고 얼마나 빨리 되찾을 수 있는지입니다. 이는 설계 결정이며, 마케팅 문단이 아니라 레버리지 한도와 포지션 사이징과 같은 대화에 속해야 합니다.
여기서의 모델은 의도적으로 좁습니다: 거래 권한만, 승인된 하나의 에이전트 주소로 범위가 한정되고, 우리의 약속이 아니라 하이퍼리퀴드에 의해 집행되며, 언제든 당신이 철회할 수 있고, 자금은 결코 당신이 소유한 계좌를 벗어나지 않습니다. 이는 수탁 리스크와 카운터파티 리스크를 그림에서 제거합니다. 시장 리스크, 청산 리스크, 실행 슬리피지, 또는 리더가 저조한 성과를 낼 가능성은 제거하지 않으며 — 그렇지 않다고 암시하는 시스템은 권한 모델이 할 수 있는 일을 잘못 표현하는 것입니다.
전체 그림을 원한다면, 문서는 승인 단계와 격리 모델을 상세히 설명하고, 리스크 공시는 이 아키텍처가 무엇으로부터 당신을 보호하지 않는지를 명확히 밝힙니다.
비교
권한 모델 비교
항목
에이전트 승인 (이 모델)
거래 전용 API 키
수탁형 또는 풀링형 플랫폼
자금 보유자
에이전트 승인 (이 모델)당신, 자신의 계좌에서
거래 전용 API 키거래소
수탁형 또는 풀링형 플랫폼플랫폼
출금 권한
에이전트 승인 (이 모델)소유자 키만
거래 전용 API 키설정으로 비활성화
수탁형 또는 풀링형 플랫폼플랫폼
범위 집행
에이전트 승인 (이 모델)프로토콜 수준의 에이전트 행위 집합
거래 전용 API 키거래소 권한 설정
수탁형 또는 풀링형 플랫폼플랫폼 정책
철회
에이전트 승인 (이 모델)온체인, 당신에 의해, 자금은 그대로
거래 전용 API 키거래소에서 키 삭제
수탁형 또는 풀링형 플랫폼출금 요청 후 대기
카운터파티 리스크
에이전트 승인 (이 모델)없음
거래 전용 API 키거래소 지급 능력
수탁형 또는 풀링형 플랫폼플랫폼 지급 능력
포지션 독립성
에이전트 승인 (이 모델)리더당 격리된 서브계정
거래 전용 API 키단일 넷팅 계좌
수탁형 또는 풀링형 플랫폼다른 사용자와 혼합
해킹 시 최악의 경우
에이전트 승인 (이 모델)계좌 내 나쁜 거래
거래 전용 API 키계좌 내 나쁜 거래
수탁형 또는 풀링형 플랫폼자금 손실
레버리지가 적용된 무기한 선물은 원금 전액 손실을 포함한 상당한 리스크가 따릅니다. 과거 성과는 미래를 보장하지 않습니다.
계속 읽기
분산 접근 방식의 구현
위의 구조적 논거가 성립한다면, 흥미로운 질문은 구현입니다: 리더를 어떻게 스코어링하고, 가중치를 어떻게 정하고, 교체를 언제 트리거하는가.