Hyperliquid 개선 제안 3 (HIP-3) [1]은 Hyperliquid에서 무기한 선물 시장이 생성되고 확장되는 방식에 근본적인 변화를 도입합니다. 시장 상장 프로세스를 제3자 빌더에게 개방함으로써, HIP-3는 상장을 재량적이고 플랫폼이 통제하는 행위에서 프로토콜 수준의 규칙 기반 인터페이스로 전환합니다.
메인넷 배포 이후, 빌더가 배포한 시장은 약 3개월 만에 130억 달러 이상의 거래량을 창출하며 HIP-3가 시장 확장의 확장성과 유연성을 실질적으로 개선할 수 있음을 입증했습니다. 그러나 이러한 전환은 단순히 권력을 분산시키는 것이 아니라, 책임 또한 재배분합니다. 이전에 중앙화된 플랫폼 운영이 흡수하거나 완화했던 위험은 이제 빌더가 직접 부담하게 됩니다.
결과적으로, HIP-3 하에서 핵심 질문은 더 이상 시장을 출시할 수 있는지 여부가 아니라, 시간이 지나도 안전하게 운영될 수 있는지 여부입니다. 이 보고서는 빌더 중심적 관점에서 HIP-3를 분석하며, 시장이 어떻게 정의되고 운영되는지, 빌더가 직면하는 위험, 그리고 특히 오라클 관련 위험을 어떻게 완화할 수 있는지에 초점을 맞춥니다.
0x0 배경
Hyperliquid의 아키텍처 [2]는 실행 및 위험 인프라를 시장 정의로부터 분리함으로써 이 모델에서 벗어납니다. 이중 레이어 설계는 다음으로 구성됩니다:
- HyperCore: 파생상품 거래에 최적화된 목적 특화 Layer 1 블록체인으로, 통합된 매칭, 청산 및 결제를 제공합니다.
- HyperEVM: 확장 가능한 로직과 빌더 상호작용을 가능하게 하는 EVM 호환 애플리케이션 레이어입니다.
실행과 청산이 프로토콜 수준에서 균일하게 적용되기 때문에, 새로운 시장은 핵심 안전 로직을 재구현하지 않고도 동일한 핵심 인프라를 재사용할 수 있습니다. 그러나 가격 책정은 완전히 표준화될 수 없습니다. 오라클 입력, 레버리지 설계, 런타임 운영은 시장마다 필연적으로 다르기 때문에, 가격 책정이 분산화와 위험이 만나는 주요 인터페이스가 됩니다.
이러한 아키텍처에도 불구하고, Hyperliquid의 네이티브 무기한 선물 시장(검증자 운영 퍼프라고도 함)의 상장 프로세스는 여전히 전통적인 CEX 방식과 유사합니다. 새로운 계약의 상장은 주로 핵심 팀이 주도하며, 상장 폐지는 검증자 투표로 결정됩니다.
HIP-3는 빌더가 배포한 무기한 선물 시장을 가능하게 함으로써 이 상장 프로세스를 분산화하기 위해 도입되었습니다. 빌더가 시장을 정의하고 운영할 수 있도록 하면서 프로토콜이 엄격한 실행 및 위험 경계를 적용함으로써, 시장 정의와 프로토콜 강제 실행 간의 분리를 공식화합니다. 따라서 HIP-3는 완전히 분산화된 퍼프 상장 프로세스를 향한 핵심 이정표를 나타냅니다.
0x1 빌더 책임: 정의 및 운영
HIP-3 하에서 빌더는 시장 생애주기 관리에 대한 엔드-투-엔드 책임을 집니다. 이 섹션에서는 먼저 시장 출시 워크플로우를 살펴보고, 실제 운영에서 시장 안정성을 가장 직접적으로 결정하는 운영 레버에 초점을 맞춥니다.
0x1.1 시장 출시 흐름: 정의 및 운영
HIP-3 하에서 시장을 출시하는 것은 단일 행동이 아닙니다. 아래의 전체 시장 출시 워크플로우에서 보여주듯이, 이는 두 가지 뚜렷한 단계에 걸쳐 진행되는 프로세스입니다: 시장 정의 (1~4단계)와 시장 운영 (5단계).
시장 정의 단계에서, 빌더는 먼저 메인넷에 500,000 HYPE를 스테이킹해야 합니다. 스테이킹 요건을 충족한 후, 빌더는 하나의 무기한 DEX를 배포할 수 있으며, 이는 자체 마진 시스템, 주문서 및 배포자 제어 설정을 갖춘 독립적인 거래 도메인을 형성합니다. DEX 수준에서, 빌더는 해당 DEX의 모든 시장에 담보로 사용될 기준 자산을 선택합니다. 선택된 기준 자산은 퍼미션리스 상태를 유지해야 하며, 이 상태를 잃으면 해당 DEX가 비활성화됩니다. 그런 다음 빌더는 오라클 사양, 심볼 및 레버리지 한도 등의 계약 매개변수, 마진 테이블을 포함한 핵심 시장 매개변수를 정의합니다. 처음 세 개의 시장은 직접 배포할 수 있으며, 추가 시장은 더치 경매를 통해 슬롯을 획득해야 합니다.
더치 경매: 각 라운드는 31시간 동안 지속되며, 매번 시작 가격은 이전 최종 가격(마지막 낙찰 가격 / 최저 가격)의 2배입니다.
시장이 활성화되면, 빌더는 시장 운영 단계에 진입합니다. 이 단계에서는 setOracle 인터페이스를 통해 오라클 가격을 지속적으로 업데이트하고, 레버리지 및 마진 설정을 유지하며, 유동성과 미결 포지션을 모니터링하고, 거래 중단 및 포지션 결제와 같은 긴급 조치를 실행합니다.
실제로 HIP-3 하에서 대부분의 심각한 장애는 시장 정의 중이 아니라, 스트레스가 많은 시장 상황에서의 장기 운영 중에 발생합니다. 중요한 점은, 빌더의 책임이 시장 중단 직후에 끝나지 않는다는 것입니다. 스테이킹 해제는 모든 시장이 결제된 후에만 가능하며, 스테이크는 의무적인 스테이킹 해제 기간 동안 슬래싱될 수 있습니다.
0x1.2 핵심 집중 영역: 가격 책정 및 지급 능력
빌더는 시장 정의와 시장 운영 전반에 걸쳐 두 가지 상호 연관된 집중 영역에 직면합니다: 오라클 구성 및 가격 형성, 그리고 스트레스 상황에서의 시장 지급 능력. 가격 책정 실패가 프로토콜 수준의 위험 제어를 통해 빠르게 지급 능력 스트레스로 전파될 수 있으므로, 이 두 영역은 긴밀하게 연결되어 있습니다.
1. 오라클 구성 및 가격 형성
Hyperliquid는 두 가지 가격을 정의합니다:
- 오라클 가격: Hyperliquid의 내부 시장 데이터와 독립적으로 설계된 주요 외부 거래소의 스팟 중간 가격 가중 중앙값으로, 주로 펀딩을 고정하는 데 사용됩니다.
- 마크 가격: 오라클 가격과 로컬 시장 데이터를 포함한 여러 입력에서 파생된 내부 위험 가격으로, 미실현 손익(PnL) 및 위험 제어에 사용됩니다.
요약하면, 오라클 가격은 펀딩을 고정하고, 마크 가격은 마진 확인, 청산, TP (이익 실현) 및 SL (손절매) 트리거를 구동합니다.
HIP-3 하에서 오라클 가격과 마크 가격의 역할은 변하지 않지만, 계산 메커니즘이 변경됩니다:
a) setOracle 입력
oraclePx(필수): HyperCore와 동일한 정의.markPx(선택 사항): 0~2개의 외부 계산된 마크 가격 후보.externalPerpPx(필수): 갑작스러운 마크 가격 편차를 방지하기 위한 참조 값.
빌더는 일반적으로 가격을 공급하는 릴레이어 노드를 배포합니다:
oraclePx는 여러 외부 소스에서 계산되고,markPx는 맞춤형 알고리즘으로 릴레이어가 계산하며,externalPerpPx는 여러 CEX의 무기한 중간 가격 가중 중앙값에서 가져옵니다.
b) 실제 마크 가격
- 로컬 마크 계산:
median(최우선 매수호가, 최우선 매도호가, 마지막 거래). - 로컬 마크와
markPx(0~2개 값)를 함께 취하여 중앙값을 구해 새로운 마크 가격을 얻습니다.
c) setOracle 제약 조건
- 업데이트 빈도: 호출 간 최소 2.5초;
markPx가 10초 동안 업데이트되지 않으면 로컬 마크 가격으로 폴백합니다. - 진폭 제한:
markPx는 업데이트당 최대 ±1%까지만 변경 가능; 모든 가격은 당일 시작 가격의 10배 이내로 제한됩니다.
HIP-3에서 자산 유형이 가격 책정에 중요한 이유는?
HIP-3 하에서 무기한 선물 시장은 모든 유형의 자산에 대해 출시될 수 있습니다. 이러한 자산은 일반적으로 24/7 자산(24시간 거래 가능)과 비24/7 자산(특정 시장 시간에만 거래 가능하며, 해당 시간 외에는 스팟 거래 없음)으로 나눌 수 있습니다. 거래 시간의 차이는 가격이 어떻게 소싱되고 유지되는지를 근본적으로 결정합니다.
24/7 자산(예: BTC)의 경우, CEX, DEX 또는 신뢰할 수 있는 오라클 서비스에서 데이터를 집계하여 안정적인 가격을 지속적으로 얻을 수 있습니다.
비24/7 자산(예: 주식)의 경우, 충분한 유동성과 신뢰할 수 있는 외부 시장 가격은 공식 거래 시간 중에만 사용 가능합니다. 이러한 자산을 HIP-3에서 계속 거래하기 위해서는 장외 시간 동안 별도의 가격 책정 메커니즘을 사용해야 합니다.
trade.xyz의 주식 무기한 선물 시장을 예로 들면:
- 거래 시간 중, 안정적인 오라클 가격은 Pyth와 같은 외부 오라클 서비스에 의해 제공됩니다.
- 장외 시간 중, 가격은 자산의 마지막 종가를 기반으로 조정되며, 주문서의 내부 매수/매도 압력과 결합됩니다. 마크 가격은 마지막 종가의 ±1 / max_leverage 범위 내에서 변동하도록 제한됩니다 (예: Tesla: 10× 레버리지 → ±10%).
2. 스트레스 상황에서의 시장 지급 능력
Hyperliquid는 시장 지급 능력을 유지하기 위해 청산과 ADL(자동 디레버리징)이라는 두 가지 메커니즘을 채택합니다. HIP-3 하에서 청산과 ADL은 대체로 HyperCore의 설계를 따릅니다. 주요 차이점은 프로토콜 수준의 제한입니다: 프로토콜 금고 역할을 하는 HLP(Hyperliquidity Provider)는 HIP-3 시장에서 위험한 포지션을 인수할 수 없습니다. 결과적으로 HyperCore에서 시장 청산과 ADL 사이의 포지션을 흡수할 수 있는 중간 금고 버퍼가 HIP-3에는 존재하지 않습니다.
스트레스가 심한 시장 상황에서 이 청산-ADL 경로의 중요성을 고려하여, 아래에서 청산과 ADL을 자세히 살펴봅니다. 여기서 논의되는 모든 지급 능력 메커니즘은 HIP-3 시장에서 현재 지원되는 유일한 마진 모드인 격리 마진을 가정합니다.
a) 청산
**포지션의 순 가치(격리 포지션 가치)**가 유지 마진 요건을 충족하기에 불충분할 때 청산이 트리거됩니다. 모든 청산 관련 확인은 특정 실행 가격이 아닌 마크 가격을 기준으로 합니다.
청산 가격 공식은 다음과 같이 정의됩니다:
여기서:
side: 롱 포지션은 1, 숏 포지션은 -1l은 유지 마진 비율입니다
MAINTENANCE_LEVERAGE의 값은 포지션에 해당하는 마진 계층에 의해 결정됩니다. 해당 계층에서 유지 마진 비율 mmr을 얻습니다:
마진 계층이 구성된 경우, 청산 가격에서 포지션의 명목 가치에 해당하는 계층의 mmr을 적용합니다.
- margin_available (격리): isolated_margin - maintenance_margin_required
포지션이 청산 가능해지면, 시스템은 먼저 주문서의 시장가 주문을 통해 청산을 시도합니다. 실행이 위험을 안전한 범위 내로 성공적으로 되돌리면, 남은 마진은 트레이더에게 반환됩니다.
그러나 주문서 깊이 부족이나 가격 갭 사례의 경우, 실제 평균 실행 가격이 마크 가격보다 상당히 나쁠 수 있어 **"청산 부족분"**이 발생할 수 있습니다.
격리 포지션 가치는 현재 마크 가격에서 격리 포지션의 순 가치를 의미하며, 미실현 손익을 고려한 후 해당 포지션에 할당된 마진을 나타냅니다.
b) ADL (자동 디레버리징)
극단적인 시나리오에서, ADL(자동 디레버리징) 메커니즘은 최후의 안전망 역할을 합니다.
ADL은 격리 포지션 가치가 음수로 전환될 때 트리거됩니다. 시스템은 수익성 있는 상대방을 손익과 레버리지 기준으로 순위를 매긴 다음, 이전 마크 가격(ADL이 트리거되기 전에 기록된 마크 가격)에서 이러한 포지션을 강제로 줄이거나 청산합니다. 승자 측의 이익을 사용하여 적자를 상쇄함으로써, 프로토콜은 지급 능력을 유지하고 불량 채무를 발생시키지 않습니다.
정렬 인덱스는 다음과 같이 계산됩니다:
여기서 notional_position은 현재 마크 가격에서 포지션의 절대 시장 가치를 의미하며, |position_size| × mark_price로 계산됩니다. account_value는 마크 가격에서의 계정 자산, 즉 담보 가치에 미실현 손익을 더한 값을 나타냅니다.
예시:
- ADL이 트리거되기 전, 시스템의 마크 가격 = 3,000.
- setOracle 제약으로 인해, 새로운 마크 가격은 **2,970 (−1%)**까지만 업데이트될 수 있습니다.
- 그러나 주문서의 매수 측이 매우 얇습니다. 청산 시장가 주문이 주문서에 도달한 후, 실제 평균 실행 가격 = 2,910 (3,000 대비 −3%).
- 롱 포지션의 손실은 2,910에서 결제되어, 격리 포지션 가치가 0 아래로 떨어지고 부족분이 발생하여 ADL이 트리거됩니다.
- ADL은 반대 측(수익성 있는 숏) 포지션을 선택하여 이전 마크 가격 = 3,000에서 강제로 줄이거나 청산하며, 부족분을 **"승자 측이 수동적으로 덜 벌게 되는 것"**으로 전가합니다.
0x2 빌더 위험 환경
HIP-3 하에서 위험은 빌더에게 더 이상 추상적이거나 순전히 이론적이지 않습니다. 스테이킹과 검증자 거버넌스 슬래싱을 통해, 운영 실패와 잘못된 구성은 직접적인 경제적 페널티로 이어질 수 있습니다. 결과적으로, 슬래싱이 어떻게 트리거되는지, 그리고 어떤 유형의 빌더 행동이 이를 초래할 수 있는지를 이해하는 것이 빌더의 위험 모델의 중심이 됩니다. 따라서 이 섹션에서는 먼저 책임 프레임워크로서의 슬래싱 메커니즘을 설명하고, 그런 다음 HIP-3 하에서 빌더 위험의 두 가지 주요 원인을 분석합니다.
0x2.1 슬래싱 메커니즘 및 책임
HIP-3는 스테이킹과 검증자 거버넌스 슬래싱을 통해 책임을 강제합니다. 슬래싱은 엄격하게 결과 기반입니다. Hyperliquid는 악의적인 행동, 운영 실수, 개인 키 손상 또는 제3자 의존성 실패를 구분하지 않습니다.
스테이크 요건: 메인넷에서 빌더는 500k HYPE를 스테이킹 상태로 유지해야 합니다. 빌더가 모든 시장을 중단하더라도 30일 동안 이를 계속 유지해야 합니다 (거래가 중단되었다고 해서 책임이 즉시 사라지지 않습니다).
빌더의 행동이 유효하지 않은 상태, 장기 다운타임 또는 심각한 성능 저하를 초래하면 슬래싱이 트리거될 수 있습니다. 심각도에 따라 슬래싱은 부분적인 스테이크 감소부터 전체 스테이크 소각까지 범위가 다양합니다. 이 설계는 빌더를 자신의 시장의 전체 런타임 행동에 대해 경제적으로 책임지게 만듭니다.
슬래싱 비율은 검증자 투표로 결정되며, 참조 상한은 다음과 같습니다:
- 유효하지 않은 상태 / 장기 다운타임: 최대 100%
- 단기 다운타임: 최대 50%
- 성능 저하: 최대 20%
슬래싱된 토큰은 소각되며 재배분되지 않습니다.
HIP-3 하에서 빌더 위험은 주로 두 가지 원인에서 비롯됩니다: 내부 매개변수 잘못된 구성과 외부 오라클 의존성. 다음 섹션에서는 이 두 가지 원인을 자세히 검토하고 슬래싱 결과로 이어질 수 있는 방법을 설명합니다.
0x2.2 내부 매개변수 잘못된 구성으로 인한 위험
잘못된 구성 위험에는 유동성이 낮은 시장에서의 과도한 레버리지, 부적절한 마진 테이블 설계, 많은 수의 포지션을 갑자기 청산 가능하게 만드는 갑작스러운 매개변수 변경, 거래 중단과 같은 긴급 제어의 부적절한 사용이 포함됩니다.
이러한 위험은 대체로 결정론적이고 예방 가능합니다. 충분한 주의, 검토 및 운영 규율을 통해 대부분의 내부 구성 오류를 피할 수 있습니다. 중요하지만, HIP-3 하에서 구조적으로 가장 도전적인 위험은 아닙니다.
1. setOracle
오라클 가격은 일반적으로 빌더의 릴레이어 서버에서 오며, 이는 중앙화 위험을 도입합니다. 개인 키가 유출되거나 릴레이어가 DDoS 공격을 받으면, 시장의 오라클 가격이 악의적으로 조작되거나 오랫동안 이탈 상태를 유지할 수 있습니다.
2. haltTrading
빌더는 haltTrading을 통해 시장의 모든 주문을 취소하고 현재 마크 가격에서 포지션을 청산할 수 있습니다. 이 작업은 신중하게 사용해야 합니다. 예를 들어, 시장이 공격자에 의해 악의적으로 조작되고 있다고 감지되어 마크 가격에서 청산하기 위해 haltTrading을 호출하면, 공격자의 미실현 이익을 직접 실현시킬 수 있으며(공격자는 그렇지 않으면 충분한 반대 주문을 찾기 어려울 수 있음), 불량 채무로 이어질 수도 있습니다.
3. setMarginTableIds & InsertMarginTable
- InsertMarginTable: 자산 클래스에 대한 마진 요건과 최대 레버리지를 지정하는 새 마진 테이블을 정의합니다.
- setMarginTableIds: 시장을 지정된
marginTableId에 바인딩합니다.
유동성이 낮거나 시장 조성이 불충분한 시장의 경우, 최대 레버리지를 너무 높게 설정하면 ADL이 트리거될 확률이 높아집니다.
갑작스럽게 marginTableId를 전환하는 것은 사용자 포지션의 유지 마진 비율을 수정하는 것과 동일하며, 많은 계정을 동시에 안전 상태에서 청산 가능 상태로 전환시켜 연쇄 청산을 트리거할 수 있습니다.
4. setMarginModes
HIP-3는 현재 격리 마진만 허용하며, 향후 교차 마진을 지원할 수 있습니다. 유동성이 높은 시장과 낮은 시장을 모두 호스팅하는 DEX 내에서, 교차 마진은 유동성이 낮은 시장의 손실이 유동성이 높은 시장으로 전파되는 위험 전염을 가능하게 할 수 있습니다. 따라서 공식 팀이 성숙한 솔루션을 제공할 때까지, 빌더는 교차 마진을 도입하지 않는 것이 권장됩니다.
0x2.3 외부 오라클 의존성으로 인한 위험
24/7 자산의 경우, 주요 위험은 외부 오라클 서비스의 정확성과 안정성, 그리고 앞서 논의한 릴레이어 서버의 중앙화 위험에 있습니다. 이러한 외부 의존성의 중단, 지연 또는 조작은 가격 책정 무결성과 다운스트림 위험 제어에 직접적으로 영향을 미칠 수 있습니다.
비24/7 자산의 경우, 위험 표면이 훨씬 더 넓으며 주로 비거래 시간 동안 오라클 가격이 어떻게 얻어지거나 계산되는지에 집중됩니다.
trade.xyz를 예로 들면, 장외 기간 동안 가격은 마지막 사용 가능한 외부 오라클 가격과 내부 시장 가격의 조합에서 파생됩니다. 주말에는 주식 무기한 선물 시장이 심각하게 감소된 유동성—주문서가 얇아지고 시장 조성자들이 호가 축소—으로 자주 어려움을 겪으며, 외부 오라클 가격이 앵커링을 제공하기 위해 사용 불가능합니다. 가격 변동에 대한 엄격한 상한선이 부과되더라도(예: 1/max_leverage), 이 제약은 변동성이 낮은 자산에 대해서는 여전히 너무 느슨할 수 있습니다. 이 범위 내의 가격 변동은 그럼에도 불구하고 대규모 청산 또는 ADL 이벤트를 트리거할 수 있습니다.
2025년 12월 14일, trade.xyz의 XYZ100-USDC 시장(NASDAQ-100을 추적하는 무기한 계약)이 조작되었습니다. 공격자는 398 XYZ100(명목 노출 약 $10M USDC)을 공매도하여 심각한 가격 이탈을 일으켰습니다. 많은 수의 롱 포지션이 청산되었으며, 청산 자체가 가격을 더욱 낮추어 결국 약 $13M USDC의 롱 측 청산이 발생했습니다.
this is probably the first such move under the 'growth mode' regime on the weekend. Someone slammed the market, dropping the price of XYZ100 by more than 3% in a minute and liquidating roughly $3M worth of positions pic.twitter.com/XttBHfTB0D
— bart.hl (equity perps era) (@bartdothl) December 14, 2025
한편, 비거래 시간 동안 지속적이고 외부적으로 고정된 오라클 가격의 부재는 시장이 "마지막 외부 가격 + 내부 주문서"로 형성된 제한된 내부 가격 밴드에 의존하도록 강제합니다(예: trade.xyz는 최대 변동을 1/max_leverage로 제한).
가장 중요한 위험은 시장 재개 전환 시에 나타납니다. 외부 시장은 갑자기 명확하고 권위 있는 참조 가격을 제공할 수 있습니다. 이 가격이 내부 장외 가격 대비 상당한 갭을 보인다면, 시스템은 두 가지 불리한 경로에 직면합니다: 가격이 제한된 채로 유지되어 외부 공정 가치와 거래 가능 가격 사이에 심각한 괴리가 발생하거나, 시스템이 외부 앵커링으로 빠르게 전환되어 급격한 재가격 결정을 트리거합니다. 두 시나리오 모두 짧은 시간 창 내에 청산 압력을 집중시키고, 극단적인 경우 ADL 이벤트 급증으로 이어질 수 있습니다.
0x3 빌더 위험 제어
구성 규율만으로는 위험을 제거할 수 없습니다. 가장 효과적인 완화 전략은 오라클 의존성 실패에 대한 노출을 줄이는 데 초점을 맞춥니다.
0x3.1 안정적인 오라클 선택
주식과 같은 비24/7 거래 자산의 경우, 주요 과제는 장외 시간 동안의 가격 책정에 있습니다. 이 기간 동안 안정적이고 외부적으로 고정된 가격 참조가 부족하여, 시장이 조작이나 얇은 유동성 하에서의 내생적 드리프트에 더 취약해집니다.
현재 업계 접근 방식은 일반적으로 두 가지 방향으로 나뉩니다:
- 장외 시간 동안 오라클 업데이트를 중단하고 거래를 제한. 예를 들어, Lighter 프로토콜은 기초 시장이 마감되었을 때 축소 전용 주문만 허용합니다. Ostium과 같은 프로토콜은 장외 시간 동안 최대 레버리지를 추가로 줄이고 새로운 한도를 초과하는 포지션을 강제 청산합니다.
- trade.xyz에서 볼 수 있는 "내부 가격 책정" 메커니즘 채택으로, 외부 데이터가 없을 때 내부 유동성과 가격 책정 알고리즘에 의존하여 프로토콜이 장외 시간에도 계속 운영됩니다.
이 두 접근 방식은 보안과 사용자 경험 간의 근본적인 트레이드오프를 반영합니다. 첫 번째 접근 방식은 엄격한 위험 제어를 우선시하지만 거래 연속성과 사용자 경험을 크게 저하시킵니다. 두 번째 방식은 지속적인 거래를 유지하지만, 외부 참조 부재로 인해 내부 가격이 자산의 기본 가치에서 이탈할 위험이 증가합니다.
장외 기간 동안, 프로토콜 가격 책정은 순수한 내부 가격으로 완전히 퇴화하는 것을 피해야 합니다. 대신 외부 참조 앵커를 도입하면 이탈 및 갭 위험을 줄일 수 있습니다. 가능한 참조는 다음과 같습니다:
- Blue Ocean ATS. 장후/야간 거래 장소로서 마감 기간 동안 어느 정도의 지속적인 가격 참조를 제공할 수 있으며("마지막 종가"보다 더 적시성이 있음), 마감 기간 오라클 가격 생성을 돕거나 이탈에 대한 모니터링 기준선으로 사용할 수 있습니다.
- IG 주말 CFD 호가. 주말 CFD 호가는 "주말 시장 기대"를 반영하는 대체 가격 신호를 제공할 수 있으며, 마감 기간 외부 앵커 또는 모니터링 비교로 적합하여 "시가 갭"의 예상 방향과 크기를 사전에 감지하는 데 도움이 됩니다.
이러한 소스들의 공통적인 특성은 장외 시간 동안 가격 신호를 제공하는 능력입니다. 그러나 기초 스팟 시장과 동일한 시장 구조를 공유하지 않으므로, 무조건적인 대체재보다는 앵커, 참조 또는 조기 경보 신호로 더 적합합니다.
0x3.2 가격 검증
HIP-3 하에서 오라클 가격은 빌더 운영 릴레이어 서버에서 소싱되며, 이는 중앙화에 대한 우려를 도입합니다. 이를 완화하기 위해, 빌더는 모든 사용자 또는 기관이 오프체인에서 가격의 정확성과 공정성을 검증할 수 있는 가격 검증 프레임워크를 구현하도록 권장됩니다—가격과 데이터 소스 및 암호학적 증명을 함께 패키징하는 RedStone과 유사합니다.
1. 데이터 투명성
- 알고리즘 사양: 가격 책정 알고리즘과 계산 로직을 공개합니다.
- 데이터 소스 목록: 모든 소스는 공개되어야 하고, 빌더 조작에 면역이 있어야 하며, 상세한 인터페이스와 매개변수가 문서화되어야 합니다.
- 가격 제출 규칙:
setOracle에 대한 권한, 트리거 조건, 업데이트 빈도 및 변동성 제약.
2. 가격 증명
각 setOracle 호출에 대해 다음을 포함하는 해당 증명을 생성합니다:
- 입력: 샘플링 타임스탬프에서 각 데이터 소스의 원시(또는 정규화된) 응답.
- 계산: 모든 계산 단계의 재현 가능한 중간 값.
- 출력: 온체인에 제출된 오라클 가격.
각 증명은 proofHash로 직렬화되며, oracleUpdater가 서명합니다.
3. 온체인 커밋
- Merkle 트리에서
proofHash항목의 순차 목록을 유지합니다. - 주기적으로(예: 매시간 또는 매일) MerkleRoot를 온체인에 게시합니다.
4. 검증
- 사용자가 시간 범위 또는
setOracle트랜잭션 해시를 입력하는 오픈소스 도구 또는 웹페이지를 제공합니다 - 서명, 타임스탬프 및 MerkleRoot 등을 검증합니다.
- 공개 알고리즘을 사용하여 비교를 위한 오라클 가격을 재계산합니다.
0x3.3 위험 모니터링
가격 검증은 setOracle을 재계산 가능하고 감사 가능하게 만들어, 가격 피드가 신뢰할 수 있는지 여부를 확인합니다. 그러나 실시간 시장 악화로부터 보호할 수는 없습니다. 피드 중단, 가격 이탈 및 유동성 저하—대규모 미결 포지션(OI)과 결합되면—국지적 이상을 연쇄 청산이나 ADL 이벤트와 같은 시스템적 위험으로 쉽게 확대시킬 수 있습니다.
따라서 시장 이상은 최대한 빨리 감지되어 관찰 가능한 신호로 변환되어야 하며, 위험을 관리 가능한 범위 내에 억제하기 위한 시간 창 내에 대처해야 합니다.
모니터링을 단편적이지 않고 실행 가능하게 만들기 위해, 신호를 세 가지 레이어로 구성하며 각각은 별개의 실패 모드와 응답 우선순위에 매핑됩니다.
- 가격 측 모니터링은 오라클 피드 실패와 소스에서 위험 제어를 무효화할 수 있는 이탈을 감지하므로 가장 높은 우선순위로 처리되며, 일반적으로 릴레이어 페일오버, 미결 포지션 한도 및 레버리지 감소를 통해 대처합니다.
- 주문서 측 모니터링은 청산 슬리피지와 부족분 위험을 증폭시키는 유동성 철수와 스푸핑된 깊이를 포착하므로, 개입은 증분 노출 제한과 취약성이 증가할 때 강제 디레버리징에 초점을 맞춥니다.
- 포지션 측 모니터링은 시장을 연쇄에 취약하게 만드는 빠른 미결 포지션 축적과 일방적 집중을 추적하며, 일반적으로 가격 및 유동성 신호보다 낮은 우선순위로, 주로 더 엄격한 한도와 높은 경보를 알리는 조기 경보 레이어 역할을 합니다.
다음 섹션에서는 해당 모니터링 포인트 및 권장 조치와 함께 각 레이어를 차례로 자세히 설명합니다.
1. 가격 측 모니터링
a) 오라클 피드 실패
지표:
- 온체인 관찰 가능 지표를 사용하여 피드가 정지되었는지 판단합니다:
임계값:
- 레벨 1: ( ∆t > 5s ) — 릴레이어 프로세스가 중단되거나 차단되었을 수 있음
- 레벨 2: ( ∆t > 15s ) — 온체인 가격이 심각하게 이탈하여 점점 더 시장 주도적이 될 수 있음
조치:
- 레벨 1: 릴레이어 상태 확인 수행, 백업 릴레이어로 전환, 상태 진단과 함께 경보 발령
- 레벨 2:
setOpenInterestCaps를 호출하여 OI 한도 축소
b) 가격 이탈
지표:
- 신호 A (
d1): 마크 가격과 오라클 가격 간의 편차.
- 신호 B (
d2): 주문서 중간 가격과 오라클 가격 간의 편차.
- 신호 C (
d3): 마크 가격과 중간 가격 간의 편차.
- 신호 D (
ext_diff): 오라클 가격과 외부 참조 가격 간의 편차.
임계값 로직:
- 레벨 1: A, B, D 중 최소 2개가 임계값을 초과.
- 레벨 2: A, B, C, D 중 최소 3개가 X초 동안 임계값을 초과.
조치:
- 레벨 1:
setOpenInterestCaps를 통해 OI 한도 축소. - 레벨 2: 마진 테이블을 점진적으로 업데이트하여 최대 레버리지를 계층별로 줄이고, 릴레이어에서 클램프 메커니즘 활성화.
- 레벨 3: 레벨 2 조건에서 지속적인 경보. 빌더는 그런 다음
haltTrading호출 여부를 평가합니다.
2. 주문서 측 모니터링
a) 유동성 철수
지표:
depth_band(±x%): 중간 가격의 ±x% 내에서 사용 가능한 주문서 유동성.spread = bestAsk - bestBid: 스프레드 확대를 측정하는 가격 스프레드.aggressiveVolume_Δt: Δt 내 테이커 거래량 (거래 측면별 집계).impact_ratio: 시장 취약성 지표 (값이 높을수록 가격 영향 취약성이 더 큼).
위험 패턴:
depth_band가 감소하면서spread와impact_ratio가 증가.
조치:
- 레벨 1:
setOpenInterestCaps를 통해OI 한도 = 현재 OI로 설정하여 증분 포지션 제한. - 레벨 2:
setMarginTableIds를 통해 강제 디레버리징, 고레버리지, 고위험 포지션 청산.
b) 스푸핑된 유동성
위험 패턴:
- 짧은 시간 창 내에
depth_band의 갑작스러운 급등 후 붕괴.
조치:
- 레벨 1: setOpenInterestCaps를 호출하여
OI 한도 = 현재 OI로 설정. - 레벨 2: 심각한 이탈과 결합된 경우, 시장 중단 고려.
3. 포지션 측 모니터링
포지션 측 모니터링은 가격 방향을 예측하려 하지 않습니다. 대신, 균형 잡힌 거래 활동에서 일방적 포지션 축적으로의 전환을 식별합니다. OI가 빠르게 축적되고, 포지션이 매우 집중되며, 다수 측 손익이 극단에 달할 때, 사소한 외생적 충격도 청산 연쇄나 ADL 이벤트를 트리거할 수 있습니다.
결과적으로, 포지션 측 조치는 일반적으로 가격 및 주문서 측 개입보다 낮은 우선순위를 가집니다.
a) 과도한 단기 OI
지표:
OI_notional: 미결 포지션 명목.Volume_24h_notional: 24시간 명목 거래량.
비율이 빠르게 증가하는 것은 활성 회전에서 투기적 포지션 축적으로의 전환을 나타내며, 종종 급격한 변동성에 앞섭니다.
조치:
- 레벨 1: 임계값 초과 시 경보 트리거.
b) 다수 측 손익
다수 측은 관찰 창 내에서 포지션 보유자가 더 많은 측(롱 또는 숏)을 의미합니다.
지표:
avgEntry_major: 다수 측 포지션의 평균 진입 가격.size_major: 다수 측의 총 포지션 크기.equity_major: 다수 측의 총 자산.
다수 측 손익과 그 비율은 다음과 같이 정의됩니다:
조치:
- 레벨 1: 임계값 위반 시 경보.
- 레벨 2: 지속될 경우,
setOpenInterestCaps를 호출하여 OI 한도 축소 고려.
0x4 결론
HIP-3의 핵심 내러티브는 간단합니다. 이는 시장 상장을 소수가 통제하는 재량적 프로세스에서 요건을 충족하는 모든 자격 있는 빌더가 호출할 수 있는 프로토콜 수준의 기능으로 전환합니다. 스테이킹을 통해 빌더는 HyperCore에서 자체 무기한 DEX를 출시하고, 초기 시장 세트를 무료로 상장하며, 경매를 통해 추가 슬롯을 획득할 수 있습니다. 이는 시장 확장을 승인 대기에서 규칙 기반의 퍼미션리스 확장으로 전환합니다.
HIP-3가 위험을 제거하지 않는다는 것도 마찬가지로 명확합니다. 이는 위험을 재배치하고 재형성합니다. 이전에 플랫폼 수준의 위험 제어가 흡수했던 책임은 이제 빌더의 입력과 운영 품질을 통해 주로 빌더가 부담합니다. 여기에는 setOracle을 통한 오라클 가격 책정과 업데이트 주기, markPx의 선택 및 제약, 마진 테이블을 통한 계층형 레버리지 설계, 비24/7 자산의 장외 가격 책정 범위, 그리고 손실을 억제하거나 증폭시킬 수 있는 haltTrading과 같은 강력한 제어가 포함됩니다. 얇은 유동성 하에서 잘못된 구성이나 운영 실패는 청산 연쇄, 갭 손실, 궁극적으로 ADL 이벤트로 증폭될 수 있습니다. 질문은 더 이상 ***"시장을 상장할 수 있는가?"***가 아니라 ***"상장 후에도 안정적으로 유지될 수 있는가?"***입니다.
프로토콜 수준에서 Hyperliquid는 권한을 책임 있는 권한으로 변환함으로써 위험의 이러한 재배분을 해결합니다. 검증자 거버넌스 슬래싱과 결합된 스테이킹은 빌더 오운영에 대한 명확한 경제적 결과를 확립합니다. 클램프, 업데이트 간격, 변동성 한도 및 격리 마진 요건을 포함한 가격 책정과 레버리지에 대한 제약은 가장 위험한 꼬리 위험을 관리 가능한 범위 내에 유지하는 것을 목표로 합니다. 이 프레임에서 HIP-3의 가치 제안이 명확해집니다: 개방성을 통한 확장, 제약을 통한 안전, 검증 가능성과 책임을 통한 장기적 지속 가능성.
HIP-3는 상장을 더 자유롭게 만들지 않습니다. 더 표준화, 배포 가능, 운영 가능하고 슬래싱 가능하게 만듭니다. 이 표준화가 규모에서 운영될 수 있는지는 궁극적으로 오라클 설계, 레버리지 및 위험 매개변수, 런타임 모니터링의 실제 품질에 달려 있습니다. HIP-3 위에 시장 접근 규칙, 매개변수 템플릿, 경보 시스템 또는 비상 워크플로우를 설계하고 있거나, 감사 및 지속적인 보안 지원이 필요한 경우, [email protected]으로 BlockSec에 자유롭게 문의하십시오.
참고문헌
[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals
[2] https://hyperliquid.gitbook.io/hyperliquid-docs
BlockSec 소개
BlockSec은 풀 스택 블록체인 보안 및 암호화폐 컴플라이언스 제공업체입니다. 저희는 고객이 코드 감사(스마트 계약, 블록체인 및 지갑 포함), 실시간 공격 차단, 사고 분석, 불법 자금 추적 및 프로토콜과 플랫폼의 전체 생애주기에 걸쳐 AML/CFT 의무를 이행하는 데 도움이 되는 제품과 서비스를 구축합니다.
BlockSec은 저명한 컨퍼런스에서 여러 블록체인 보안 논문을 발표하고, DeFi 애플리케이션의 여러 제로데이 공격을 보고하며, 2,000만 달러 이상을 구조하기 위한 여러 해킹을 차단하고, 수십억 달러의 암호화폐를 보호했습니다.
-
공식 웹사이트: https://blocksec.com/
-
공식 트위터 계정: https://twitter.com/BlockSecTeam
-
🔗 BlockSec 감사 서비스 : 요청 제출
