HIP-3(Hyperliquid Improvement Proposal 3)이 메인넷에서 약 3개월 동안 운영되고 있습니다. 출시 이후 타사 맞춤형 마켓플레이스의 누적 거래량은 130억 달러를 넘어섰습니다. 이는 "신제품 등록"이 거래소 내부 프로세스에서 외부 개발자가 직접 호출할 수 있는 인프라 기능으로 전환되고 있음을 의미합니다.

중앙 집중식 거래소에서 "신제품 상장"은 본질적으로 플랫폼의 역량에 달려 있습니다. 어떤 제품을 거래할 수 있는지, 언제 상장될지, 그리고 매개변수를 어떻게 설정할지는 모두 기본적으로 운영 및 위험 관리 프로세스에 의해 결정됩니다. 온체인 무기한 계약조차도 인프라에 크게 의존하는 범주이기 때문에, 종종 몇몇 팀의 배포 및 관리 속도에 제약을 받습니다.

HIP-3의 혁신은 "플랫폼 승인"에서 "개방형 인터페이스"로의 전환에 있습니다. 조건만 충족된다면 제3자는 동일한 거래 및 청산 플랫폼에서 새로운 무기한 계약 시장을 구축할 수 있으며, 신규 계약 상장에 대한 중앙 집중식 권한을 생태계에 체계적으로 위임할 수 있습니다. 이러한 개선은 혁신의 장벽을 낮출 뿐만 아니라 시장 확장성도 향상시킵니다. 그러나 개방형 인터페이스가 가져올 수 있는 잠재적인 보안 위험을 간과할 수 없습니다. 이러한 시장의 규정 준수 운영과 악의적인 행위의 방지는 HIP-3 설계에서 철저한 검토가 필요한 중요한 과제입니다.

0x1 하이퍼리퀴드: HIP-3의 기반

Hyperliquid는 자체 블록체인에서 실행되는 무기한 거래 인프라입니다. HIP-3의 가장 중요한 점은 매칭, 청산 및 결제가 프로토콜 기반에서 균일하게 제공되어 거래 시스템을 처음부터 구축하는 대신 시장 기능을 재사용할 수 있다는 것입니다.

Hyperliquid는 2계층 아키텍처를 사용합니다.

HyperCore: 계약 거래에 최적화된 맞춤형 L1 블록체인으로, 확정적 최종성을 보장하며 초당 20만 건의 주문을 처리할 수 있습니다.

HyperEVM: 스마트 계약을 실행하는 애플리케이션 계층으로 EVM과 호환됩니다.

Hyperliquid의 자체 무기한 계약 시장(검증자 운영 무기한 계약)은 여전히 ​​기존의 중앙 집중식 거래소(CEX) 상장 프로세스와 유사합니다. 공식 플랫폼은 커뮤니티의 요청에 따라 무기한 계약을 상장하고, 상장 폐지는 검증자 노드의 투표를 통해 결정됩니다.

Hyperliquid 프로토콜은 빌더가 배포하는 퍼프(HIP-3)를 지원할 예정이며, 이는 퍼프 목록 작성 프로세스의 완전한 탈중앙화를 향한 중요한 이정표입니다.

Hyperliquid 프로토콜은 빌더가 배포하는 무기한 계약(HIP-3)을 지원할 예정이며, 이는 완전한 탈중앙화된 무기한 계약 상장 프로세스를 달성하는 데 있어 중요한 이정표입니다.

0x2 HIP-3: 개발자 배포용 마켓플레이스

HIP-3의 개념은 간단합니다. Hyperliquid 거래 및 청산 플랫폼을 변경하지 않고, 자격을 갖춘 빌더에게 "무기한 시장 추가" 기능을 제공하는 것입니다. 빌더는 시장의 주요 매개변수와 가격 피드/운영 책임을 정의하고, 프로토콜은 통합 마진 및 청산 엔진을 사용하여 실행 및 위험 관리 경계를 처리합니다. 따라서 "새로운 시장 추가"는 플랫폼 프로세스에서 호출 가능한 표준 인터페이스로 전환됩니다.

요약하자면, 빌더는 HyperCore 엔진을 기반으로 영구 계약 시장을 등록하고, 가격을 입력하고 시장 매개변수를 직접 조정할 수 있습니다.

건설업자의 책임 범위

HIP-3에서 개발자는 가처분 시장에 대해 두 가지 유형의 작업을 수행합니다. 즉, 시장을 정의하고 시장을 운영하는 것입니다.

시장 정의:

공식 문서에서는 이를 Oracle 정의 + 계약 사양으로 요약합니다. 운영 수준에서는 최소한 다음 사항이 포함됩니다.

오라클 정의:

여기에는 초기 oraclePx 및 가격 출처 정의가 포함됩니다. 시장을 정의할 때 구축자는 명확하게 정의되고 조작하기 어려우며 경제적 실체가 있는 목표 자산 또는 데이터 소스를 정의해야 합니다. 자산을 등록할 때는 초기 oraclePx를 제공해야 합니다.

계약 사양:

API 인터페이스에서 "자산 기호/최소 주문 단위/최대 레버리지"(coin, szDecimals, maxLeverage 등)와 같은 시장 매개변수를 명시적으로 정의하십시오.

DEX 선택:

빌더는 먼저 고정금리 DEX를 배포합니다(각 DEX는 독립적인 마진, 주문장 및 배포자 설정을 가집니다). 그런 다음 DEX의 담보로 USDC와 같은 모든 시세 자산을 선택할 수 있습니다. 각 고정금리 시장은 하나의 DEX에 대응됩니다.

시장 운영:

공식 목록에는 오라클 가격 설정, 레버리지 한도 설정, 필요한 경우 시장가 설정 등이 포함됩니다. 자세히 살펴보면 다음과 같습니다.

가격 정보 업데이트:

시장의 오라클 가격은 setOracle 인터페이스를 통해 지속적으로 제공됩니다.

레버리지 한도:

최대 레버리지는 자산에 상응하는 마진표를 할당함으로써 제한됩니다. 레버리지 한도는 포지션 규모에 따라 단계별로 설정되어 사용 가능한 레버리지를 미리 설정된 범위로 제한합니다.

필요한 경우 합의가 이루어질 것입니다.

빌더는 haltTrading 인터페이스를 사용하여 시장을 중단하고 결제를 실행할 수 있습니다. 이렇게 하면 모든 주문이 취소되고 현재 기준 가격으로 포지션이 결제됩니다. 동일한 작업을 사용하여 거래를 재개할 수도 있습니다.

현재 HIP-3 시장은 개별 포지션만 지원하지만, 향후 교차 포지션이 지원될 가능성이 있습니다.

시장 출시 프로세스

말뚝

메인넷에서는 빌더가 50만 HYPE를 스테이킹해야 하며, 탈중앙화 거래소(DEX)에서 마켓을 폐쇄하더라도 스테이킹 요건은 30일 동안 유지되어야 합니다.

짓다

스테이킹 임계값이 충족되면 빌더는 퍼프 DEX를 배포할 수 있습니다. 각 퍼프 DEX는 독립적인 거래 도메인으로, 마진, 주문장, 배포자 설정이 모두 독립적입니다.

담보 설정

이 DEX의 담보는 모든 시세 자산이 될 수 있지만, 시세 자산이 (검증자 투표에 의해 결정되는) 허가 없는 시세 자산 상태를 잃게 되면, 해당 자산을 담보로 사용하는 DEX는 비활성화됩니다.

시장을 추가하세요

처음 세 시장은 직접 배포할 수 있습니다.

새로운 시장을 추가할 때는 네덜란드식 경매를 통해 "새로운 할당량"을 확보해야 합니다.

5. 시장을 운영합니다

시장이 활성화되면 건설업체의 역할은 "시장을 안정시키는 것", 즉 시장 운영이 됩니다.

6. 말뚝을 뽑으세요

탈중앙화 거래소(DEX)의 모든 시장 거래가 완료되면 스테이킹된 50만 HYPE가 해제됩니다. 스테이킹 해제를 신청하면 7일간의 대기 기간이 발생하며, 이 기간 동안 스테이킹된 HYPE에는 스테이킹 페널티가 부과될 수 있습니다.

네덜란드식 경매: 현재 경매 주기는 라운드당 31시간이며, 각 입찰의 시작 가격은 이전 최종 가격(낙찰가/최저가)의 2배입니다.

SetOracle: 세 가지 유형의 가격 입력

HyperCore에서 오라클 가격은 주로 기준 가격 및 펀딩 수수료 계산에 사용되는 반면, 마크 가격은 마진콜 및 청산과 같은 위험 관리 시나리오의 기준 가격으로 사용됩니다(또한 TP/SL 등을 트리거하는 데에도 사용됩니다).

현지 시장에서 시장 가격은 단일 가격 지표의 직접적인 결과가 아니라, 계산된 세 가지 가격의 중간값입니다.

oraclePx + EMA(midPx - oraclePx)

중앙값(최고 매수호가, 최고 매도호가, 마지막 거래가)(현지 주문장 가격)

여러 중앙거래소(CEX)의 임페리얼 중간 가격의 가중 중앙값

HIP-3에서는 오라클 가격과 마크 가격의 기능은 그대로 유지되었지만 계산 메커니즘이 변경되었습니다.

setOracle 입력

a. OraclePx (필수)

핵심 정의는 HyperCore와 일관성이 있습니다.

b. markPx (선택 사항)

후보값을 계산하기 위한 실제 점수로 외부 점수 자료를 0~2세트 제출할 수 있습니다.

c. externalPerpPx (필수)

이는 시장 가격의 기준값 입력으로 사용되어 시장 가격의 급격한 변동을 방지합니다.

건설업체는 가격 정보 제공을 위해 레이어 노드를 자주 배포합니다(OraclePx).

중계기는 포괄적인 계산을 위해 외부 가격 소스를 결합합니다. markPx는 중계기가 자체 알고리즘을 사용하여 계산하며, externalPerpPx는 여러 CEX의 perp 중간 가격의 가중 중앙값입니다.

2. 실제 시장 가격

HIP-3의 마크 가격은 setOracle의 가격 피드를 직접 사용하지 않습니다.

현지 시장 가격 계산: 중앙값(최고 매수 호가, 최고 매도 호가, 마지막 거래가).

지역 가격과 markPx(그룹 0~2)를 결합하고 중앙값을 취하여 새로운 가격 정보를 얻습니다.

3. Oracle 제한 설정

업데이트 빈도: 두 호출 사이에는 최소 2.5초의 간격이 있어야 합니다. markPx가 10초 이내에 업데이트되지 않으면 로컬 시장 가격으로 되돌아갑니다.

변동폭 제한: markPx의 변동은 매번 ±1%를 초과하지 않으며, 모든 가격은 당일 시작 가격의 10배 이내로 제한됩니다.

7x24H와 비7x24H: 가격 책정 방식의 차이점

HIP-3의 무기한 계약 시장은 모든 자산의 상장을 지원하며, 자산은 7x24H 자산(24시간 거래 가능)과 비7x24H 자산(특정 거래 시간에만 거래 가능, 현물 시장은 비거래 시간에는 거래할 수 없음)으로 구분됩니다. 이 두 자산 유형의 거래 시간 특성은 가격 획득 방식의 차이를 결정합니다.

비트코인(BTC)과 같이 24시간 내내 거래되는 자산의 경우, 중앙거래소(CEX)와 탈중앙거래소(DEX)를 조합하거나 신뢰할 수 있는 오라클을 이용하면 안정적인 가격을 얻을 수 있습니다.

주식과 같이 24시간 거래가 불가능한 자산의 경우, 충분한 유동성과 비교적 안정적인 외부 시장 가격은 거래 시간 동안에만 확보할 수 있습니다. HIP-3에서 이러한 자산의 24시간 정상적인 거래를 유지하려면 시장 마감 시간 동안에는 다른 가격 결정 메커니즘을 사용해야 합니다.

Trade.xyz의 주식 무기한 계약 시장을 예로 들어보겠습니다.

주식 시장 거래 시간 동안에는 Pyth와 같은 외부 오라클 서비스를 통해 안정적인 가격 데이터가 제공됩니다.

주식 시장 마감 시, 내부 매수 및 매도 압력을 고려하여 해당 주식의 이전 종가를 기준으로 가격 조정이 이루어집니다. 기준 가격은 이전 종가 변동폭의 1/max_leverage로 제한됩니다(예: 테슬라 10배 -> 10%).

변제

HIP-3 시장은 주로 HyperCore의 청산 로직을 재사용하므로 청산 트리거 로직은 플랫폼을 따릅니다. 즉, 개별 포지션 가치가 유지 증거금 요건을 충족하기에 부족할 경우 청산 상태로 전환됩니다.

청산에 관한 판단은 특정 거래 가격이 아닌 시가에 근거합니다.

청산 가격 산정 공식:

변의 길이 = 1 (긴 쪽), -1 (짧은 쪽)

l: 즉, 유지 마진율입니다.

MAINTENANCE_LEVERAGE 값은 해당 포지션에 해당하는 마진 등급에서 가져옵니다. 먼저, 해당 등급에서 유지 마진율(mmr)을 읽어옵니다.

티어가 있는 경우, 해당 포지션의 명목 가치가 어느 티어에 속하는지에 따라 청산 가격에 해당하는 포지션의 MMR이 사용됩니다.

여유 공간

격리됨: 격리된 여백 - 유지 관리 여백 필요

시스템이 청산 상태에 진입하면 주문장을 통해 시장가 주문을 사용하여 포지션을 청산하는 것을 우선시합니다. 위험을 안전한 범위로 되돌릴 수 있다면 남은 증거금은 여전히 ​​거래자에게 귀속됩니다.

하지만 거래 깊이가 부족하거나 갭이 발생할 경우, 실제 평균 종가는 기준 가격보다 상당히 낮아져 "청산 갭"이 형성될 수 있습니다.

개별 포지션 가치: 현재 시장 가격에서 개별 포지션의 순 가치(포지션의 손익에서 해당 포지션에 묶인 증거금을 뺀 값)를 의미합니다.

ADL:

이 경우, ADL(자동 레버리지 축소) 메커니즘은 극단적인 상황에서 비상 대책으로 사용될 수 있습니다.

고립된 포지션의 가치가 음수가 되면 ADL(고급 포지션 제한)이 작동합니다. 반대 포지션은 미실현 손익 및 레버리지 순으로 정렬되며, 해당 포지션은 이전 평가 가격으로 강제로 축소/청산됩니다. 반대 포지션에서 발생한 수익은 차액을 메우는 데 사용되어 시스템의 불량 채권 발생을 방지합니다.

정렬 기준은 다음 기준에 따라 계산됩니다.

이전 시가: ADL이 발생하기 전에 시스템에 기록된 이전 시가를 의미합니다.

예:

ADL이 작동하기 전 시스템의 기준 가격은 3,000이었습니다.

setOracle의 제약 조건으로 인해 새로운 시장 가격은 최대 2,970(-1%)까지만 업데이트될 수 있습니다.

하지만 당시 호가창의 매수 주문량은 매우 적었습니다. 시장가 주문이 체결된 후 실제 평균 거래 가격은 2,910이었으며, 이는 3,000 대비 -3% 하락한 수치입니다.

롱 포지션 손실은 2,910에서 정산되며, 이로 인해 해당 포지션의 개별 가치가 0 아래로 떨어져(갭 발생) 적응형 한도(ADL)가 작동될 수 있습니다.

그런 다음 ADL은 반대편(수익성 있는 공매도 포지션)에서 포지션을 선택하고 이전 기준 가격인 3,000에서 강제로 포지션을 청산하여 차익을 "수익성 있는 쪽이 수동적으로 더 적은 수익을 얻도록" 이전합니다.

0x3 위험 개요: 책임 제약 및 주요 위험

사형: 가해자에게 책임을 묻는 합법적인 수단

HIP-3는 "새로운 제품을 추가하고 운영할 권한"을 개발자에게 위임하는 동시에, 시행 가능한 스테이킹 규칙을 통해 프로토콜 내에 책임을 명시합니다. 개발자는 HYPE를 스테이킹해야 하며, 부적절하게 운영된다고 판단될 경우 검증자는 투표를 통해 스테이킹된 HYPE를 소각할 수 있습니다.

서약 요건

메인넷에서는 빌더가 50만 HYPE를 지분으로 유지해야 하며, 빌더가 모든 시장 활동을 중단하더라도 30일 동안은 이 지분을 유지해야 합니다(거래 중단으로 인해 책임이 즉시 면제되지 않습니다).

트리거링 및 투표

악의적인 시장 조작이 발생할 경우, 검증자는 건설자의 지분을 삭감할지 여부를 결정하기 위해 지분 가중 투표를 시작하고 실행할 수 있습니다.

판단 원칙

공식 성명에 따르면 벌금 및 몰수는 "악의적인 의도/능력 부족/개인 키 도난"과 같은 사유를 구분하지 않고, 개발자의 행위로 인해 시스템이 잘못된 상태에 빠지거나, 가동이 장시간 중단되거나, 성능이 저하되었는지 여부에 초점을 맞출 것이라고 명시되어 있습니다.

벌금 및 몰수 범위

벌점 비율은 검증자들의 투표로 결정되며, 기준 상한선이 있습니다.

시스템 오류 또는 장시간 다운타임을 유발함: 최대 100%

짧은 가동 중단 시간: 최대 50%

성능 저하: 최대 20%

몰수된 스테이킹 토큰은 해당 사용자에게 보상되지 않고 소각됩니다.

매개변수 구성 위험

setOracle

오라클 가격은 일반적으로 빌더의 릴레이 서버에서 생성되므로 중앙 집중화 위험이 있습니다. 개인 키가 유출되거나 DDoS 공격이 발생할 경우, 시장의 오라클 가격이 악의적으로 조작되거나 장기간 불안정한 상태로 유지될 수 있습니다.

거래 중지

빌더는 haltTrading을 통해 시장의 모든 주문을 취소하고 현재 시장 가격으로 마감할 수 있습니다.

이 작업은 다음과 같은 상황에서와 같이 주의해서 사용해야 합니다.

시장이 공격자에 의해 악의적으로 조작되고 있다는 것이 감지되면, haltTrading이 호출되어 해당 포지션을 기준 가격에 직접 청산합니다. 이는 공격자의 미실현 이익(공격자가 원래 충분한 거래 상대방 주문을 확보하는 데 어려움을 겪었을 수 있음)을 직접 실현시키고, 결과적으로 부실 채권을 발생시킬 수 있습니다.

setMarginTableIds/InsertMarginTable

InsertMarginTable: 특정 자산 클래스에 대한 마진 요구 사항 및 최대 레버리지를 지정하는 새 마진 테이블을 정의합니다.

setMarginTableIds: 지정된 marginTableId에 시장을 연결합니다.

유동성이 낮거나 시장 조성 능력이 부족한 시장에서 최대 레버리지를 너무 높게 설정하면 ADL(자동 거래 제한)이 발생할 확률이 높아집니다.

marginTableId를 갑자기 변경하는 것은 사용자의 포지션 유지 증거금 비율을 수정하는 것과 같으며, 이로 인해 다수의 계정이 동시에 안전 상태에서 청산 상태로 전환되어 연쇄 청산이 발생할 수 있습니다.

setMarginModes

현재 HIP-3는 개별 마진 거래만 허용하지만, 향후 교차 마진 거래가 지원될 가능성이 있습니다. 하나의 탈중앙화 거래소(DEX)에는 유동성이 높은 시장과 낮은 시장이 모두 존재할 수 있으며, 교차 마진 거래는 유동성이 낮은 시장의 위험을 유동성이 높은 시장으로 전가할 가능성이 있습니다. 따라서 공식적인 해결책이 마련될 때까지는 빌더들이 교차 마진 거래 기능을 도입하지 않는 것이 좋습니다.

오라클 리스크

24시간 연중무휴로 운영되는 자산의 경우, 주요 위험은 자산이 의존하는 외부 Oracle 서비스의 정확성과 안정성, 그리고 앞서 언급한 중계 서버와 관련된 중앙 집중식 위험에 있습니다.

24시간 내내 거래되지 않는 자산의 경우, 거래가 이루어지지 않는 시간에 오라클 가격을 얻거나 계산하는 것이 더 큰 위험입니다.

trade.xyz를 예로 들면, 비거래 시간에는 마지막 외부 오라클 가격과 내부 시장 가격을 조합하여 가격이 계산됩니다. 주말에는 무기한 주식 시장의 유동성이 부족하고(주문장이 얇아지고 시장 조성자가 호가를 낮춤), 가격을 고정할 외부 오라클 가격도 없습니다. 가격 변동폭에 엄격한 상한선(최대 레버리지의 1)을 설정하더라도, 변동성이 낮은 자산의 경우 이 한도는 여전히 너무 높습니다. 이 범위 내의 가격 변동조차도 대규모 청산이나 미수금 발생(ADL)으로 이어질 수 있습니다.

2025년 12월 14일, 공격자들은 trade.xyz에서 거래되는 XYZ100-USDC(나스닥100에 연동)를 조작했습니다. 공격자들은 398개의 XYZ100(약 1천만 USDC)에 해당하는 공매도 포지션을 구축하여 가격을 심각하게 왜곡시켰습니다. 이와 동시에 다수의 매수 포지션이 청산되었고, 이로 인해 가격이 지속적으로 하락하여 결국 약 1천3백만 USDC 규모의 매수 포지션이 청산되었습니다.

https://x.com/bartdothl/status/2000292798755684839

반면, 비거래 시간에는 지속적이고 기준이 될 수 있는 안정적인 오라클 가격이 부족하여 시장은 종종 "최근 외부 가격 + 내부 주문장"에 의존하여 제한적인 내부 가격 범위를 형성해야 합니다(예: trade.xyz는 최대 변동 범위를 1/max_leverage로 제한합니다).

위험은 시장 재개 시점에 발생합니다. 외부 시장은 즉시 명확한 외부 가격을 제공합니다. 시장 폐쇄 중 내부 가격과 외부 가격 사이에 상당한 차이가 발생할 경우, 시스템은 계속해서 가격 조정을 하지 않아 외부 가격과 거래 가격 간의 심각한 편차가 발생하거나, 외부 기준 가격으로 다시 전환될 때 급격한 가격 재조정이 발생할 수 있습니다. 두 경우 모두 단기간에 집중적인 청산 압력을 유발하여 극단적인 경우 ADL(자동 거래 손실) 발생 건수가 증가할 수 있습니다.

0x4 위험 관리 전략

1) 안정적인 오라클 가격

주식처럼 24시간 거래가 불가능한 자산의 경우, 주요 과제는 시장 마감 시간 동안의 가격 책정에 있습니다. 안정적인 외부 시세가 부족하여 시장이 조작되거나 저점에서 표류할 가능성이 높아집니다.

현재 업계에서 일반적으로 사용되는 솔루션은 크게 두 가지 범주로 나뉩니다.

이는 오라클 가격 업데이트를 직접 중단하거나, 해당 기간 동안 거래를 일시 중지 또는 제한할 수 있습니다(예: Lighter 프로토콜은 시장 마감 시에만 포지션 축소를 허용합니다). Optium과 같은 프로토콜은 시장 마감 시 최대 레버리지를 낮추고 한도를 초과하는 포지션을 강제로 청산할 수도 있습니다.

이 플랫폼은 trade.xyz와 유사한 "내부 가격 책정" 메커니즘을 채택하여 외부 데이터가 부족할 때에도 프로토콜 내의 시장 유동성과 알고리즘에 의존하여 운영을 유지합니다.

이 두 가지 접근 방식은 보안과 사용자 경험 측면에서 프로토콜 설계 시 발생하는 절충점을 명확히 보여줍니다. 첫 번째 접근 방식은 더욱 엄격한 위험 관리 메커니즘을 사용하지만, 사용자 거래 경험이 크게 저하되는 단점이 있습니다. 두 번째 접근 방식은 거래 연속성을 유지하지만, 외부 참조가 부족하여 내부 가격과 기초 자산의 실제 가치 간에 편차가 발생하기 쉽습니다.

시장 폐쇄 기간 동안 협상된 가격이 순전히 내부 가격으로 전락하는 것을 방지하는 것이 매우 중요합니다. 대신, 가격 분리 및 가격 격차의 위험을 완화하기 위해 참조 가능한 외부 기준점을 도입해야 합니다. 가능한 참조 대상은 다음과 같습니다.

블루 오션 ATS

시간외/야간 거래와 관련된 거래소로서, 시장 마감 시간 동안 일정 수준의 지속적인 가격 기준점(‘최종 종가’보다 더 시의적절한)을 제공할 수 있으며, 이는 시장 마감 오라클 가격 생성에 도움을 주거나 가격 분리 모니터링 벤치마크로 사용될 수 있습니다.

IG 주말 CFD 시세

주말 CFD 시세는 "주말 시장 기대치"에 대한 대안적인 가격 신호를 제공할 수 있으므로 시장 마감 시간 동안 외부 기준점 또는 모니터링 참조 자료로 적합하며, "잠재적인 개장 갭"의 방향과 규모를 사전에 파악하는 데 도움이 됩니다.

이 두 가지 정보원은 모두 "시장 마감 시 가격 신호를 제공한다"는 공통점을 가지고 있지만, 기초 주식 현물 가격과 동일한 시장 구조를 갖고 있지는 않습니다. 따라서 무조건적인 대체재라기보다는 기준점/비교 수단 및 위험 경고 신호로 더 적합합니다.

2) 가격 검증

HIP-3의 오라클 가격은 개발자가 설정한 릴레이어 서버에서 제공되므로 중앙 집중식 분쟁이 발생할 수 있습니다. 따라서 개발자는 모든 사용자 또는 기관이 오프체인에서 가격의 진위와 공정성을 검증할 수 있는 가격 검증 메커니즘을 구축하는 것이 좋습니다(레드스톤처럼 가격 값과 데이터 소스, 서명 증명을 블록체인에 패키징하는 방식과 유사).

공개 데이터

알고리즘 명세: 상세한 알고리즘 및 처리 메커니즘을 공개하십시오.

데이터 소스 목록: 각 데이터 소스는 공개되어야 하며 개발자의 개입 대상이 되어서는 안 되며, 상세한 인터페이스와 매개변수를 제공해야 합니다.

가격 푸시 사양: Oracle 호출 권한, 트리거 빈도 및 변동 한도.

b. 가격 증명

각 `setOracle` 호출에 대해 다음을 포함하는 해당 증명을 생성합니다.

입력: 해당 시점의 각 데이터 소스의 원시 응답(또는 정규화된 필드) 및 샘플링 타임스탬프.

계산: 계산 가능한 중간량, 각 계산 단계의 중간 결과.

출력: 이번에 블록체인에 기록된 오라클 가격.

증명(Proof)은 직렬화되어 proofHash를 얻고, oracleUpdater는 proofHash에 서명합니다.

c. 체인상의 증명

목록을 유지하고 각 ProofHash를 시간 순서대로 머클 트리에 기록합니다.

MerkleRoot는 정해진 간격(예: 시간별/일별)으로 게시되어 블록체인에 업로드됩니다.

d. 검증

해당 기간 또는 특정 SETOracle 작업의 트랜잭션 해시를 입력하여 위의 모든 데이터를 검색할 수 있는 오픈 소스 도구 또는 웹페이지를 제공하십시오.

서명, 타임스탬프, MerkleRoot 등을 확인하십시오.

공개적으로 이용 가능한 알고리즘을 사용하여 계산된 Oracle 가격을 비교하십시오.

3) 위험 모니터링

가격 검증을 통해 setOracle 프로세스는 "재계산 및 감사 가능"해지므로 가격 피드의 신뢰성을 확보할 수 있습니다. 그러나 가격 검증만으로는 시장이 통제 불능 상태로 치닫는 것을 막을 수는 없습니다. 가격 피드 중단, 가격 변동, 거래량 감소 등이 대규모 미결제약정(OI)과 결합될 경우, 국지적인 이상 현상이 연쇄 청산이나 ADL(대체 한도)과 같은 시스템적 위험으로 쉽게 확대될 수 있습니다. 따라서 시장 이상 현상은 가능한 한 빨리 감지 가능한 신호로 포착되어야 하며, 위험을 통제 가능한 수준으로 되돌릴 수 있는 기회의 창에 즉시 대응해야 합니다.

1. 가격 측면

a. 오라클 가격 피드 오류

모니터링 지표:

온체인 관측값을 사용하여 가격 피드가 차단되었는지 직접 확인합니다.

임계값 등급 분류:

행동:

레벨 1: 해당 계층에 대한 상태 점검을 수행하고 백업 계층 노드로 전환합니다. 모든 계층 노드에 대한 상태 보고서 및 정보를 포함하는 경고를 발행합니다.

2단계: setOpenInterestCaps 함수를 호출하여 미수금 한도를 낮춥니다.

b. 가격 고정 해제

모니터링 지표:

한계점:

1단계: A, B, D 중 최소 두 개가 기준치를 초과합니다.

2단계: A, B, C, D 중 최소 3개가 임계값을 초과하고 X초 동안 지속됩니다.

행동:

1단계: setOpenInterestCaps를 사용하여 미수금 한도를 낮추십시오.

레벨 2: 편차가 장기간 지속될 경우, 마진 테이블이 점진적으로 업데이트되고 최대 레버리지가 단계별로 점진적으로 감소합니다. 릴레이어는 클램프 메커니즘을 활성화합니다.

레벨 3: 레벨 2 모드에서와 같이 계속 경고를 발행하며, 최종적으로 건설업체가 haltTrading 명령을 호출하여 시장을 중단할지 여부를 결정합니다.

2. 배팅 배당률 쪽

a. 깊은 거리감

감시 장치:

depth_band(±x%): 중간값을 기준으로 ±x% 가격 범위 내의 실제 주문량입니다.

스프레드 = 최적 호가 - 최적 매수호가: 가격 차이로, 주문장이 "불완전"한지 여부를 측정하는 데 사용됩니다.

aggressiveVolume_Δt: Δt 기간 내 테이커 거래량(거래 측별 집계).

충격 비율 = 공격적 부피 변화량 / 깊이 밴드: 베어링 비율

판단: 다음과 같은 조합 패턴이 나타날 경우 위험도가 증가합니다.

depth_band는 감소하는 반면, spread와 impact_ratio는 증가합니다.

행동:

레벨 1: `setOpenInterestCaps`를 호출하여 현재 미결제약정(OI)만큼 미결제약정 상한선을 낮추고 포지션 규모 증가를 제한합니다.

레벨 2: `setMarginTableIds`를 호출하면 레버리지가 강제로 감소하여 고레버리지 포지션 생성을 방지하고 고레버리지, 고위험 포지션을 강제로 청산할 수 있습니다.

b. 가짜 주문

감시 장치:

depth_band 값이 잠시 상승했다가 갑자기 하락합니다.

행동:

레벨 1: setOpenInterestCaps를 호출하여 미수금 상한을 현재 미수금으로 낮춥니다.

2단계: 심각한 가격 불일치가 동반될 경우, 시장 거래 중단을 고려하십시오.

3. 측면 위치 지정

포지션 측 모니터링의 목표는 "시장의 방향을 예측하는 것"이 ​​아니라 시장이 거래 주도형에서 포지션 기반 투기형으로 전환되고 있는지 파악하는 것입니다. 미결제약정(OI)이 빠르게 누적되고, 포지션이 고도로 집중되며, 대다수 투자자의 손익이 극단적인 값에 근접할 때, 외부 가격 변동은 청산 폭포/ADL(Advanced Liquidation Drought, 심각한 청산 가뭄)로 이어질 가능성이 더 커집니다. 따라서 포지션 측 조치는 일반적으로 가격 측 및 주문장 측 조치보다 우선순위가 낮습니다.

a. 단기적인 온라인 식별(OI)에 대한 과도한 강조

감시 장치:

OI_notional: 미결제 약정

Volume_24h_notional: 24시간 거래량

OI_notional / Volume_24h_notional 비율을 계산하세요. 이 비율의 급격한 증가는 시장이 단기 보유에서 장기 투기로 전환하고 있음을 나타내며, 이는 일반적으로 급격한 시장 변동을 예고합니다.

행동:

레벨 1: 상한값에 도달하면 알림을 발생시킵니다.

b. 대다수 이익 및 손실

감시 장치:

다수측: 통계적 범위 내에서 보유자(롱 또는 숏)가 더 많은 쪽.

avgEntry_major: 대부분의 포지션의 평균 개시 가격

size_major: 다수석의 크기

대다수 이익 및 손실:

대다수 이익/손실 비율:

행동:

레벨 1: 상한값에 도달하면 알림을 발생시킵니다.

2단계: 한도가 지속적으로 초과되는 경우, `setOpenInterestCaps`를 호출하여 미수금 한도를 낮추는 것을 고려하십시오.

0x5 결론

HIP-3의 핵심 아이디어는 "신제품 업데이트" 프로세스를 소수의 사람들이 결정하는 방식에서, 특정 기준만 충족하면 누구나 접근할 수 있는 프로토콜 기능으로 바꾸는 것입니다. 빌더는 스테이킹을 통해 HyperCore에서 자체적인 영구 DEX를 구축하고, 처음에는 소수의 마켓을 무료로 운영한 후, 경매를 통해 더 많은 슬롯을 확보하기 위해 경쟁할 수 있습니다. 이를 통해 시장 확장이 "승인 대기"에서 "규칙에 따른 확장"으로 전환됩니다.

하지만 HIP-3가 위험을 완전히 제거한 것은 아니라는 점도 분명합니다. 단지 위험의 위치와 형태만 바꿨을 뿐입니다. 이전에는 플랫폼 위험 관리로 다루어졌던 부분들이 이제는 구축자의 투입과 운영 품질에 더욱 의존하게 되었습니다. 즉, `setOracle`의 가격 피드 및 빈도, `markPx`의 선택 및 제약 조건, 마진 테이블의 단계별 레버리지, 24시간 거래가 불가능한 자산 시장의 거래 마감 시 가격 책정을 위한 "내부 범위", 그리고 손실을 막을 수도 있고 증폭시킬 수도 있는 `haltTrading` 기능의 효력 등이 여기에 해당합니다. 이러한 영역 중 어느 하나라도 잘못 처리하면 거래량이 적은 상황에서 집중적인 청산으로 이어져 갭과 ADL(자동 거래 중단)을 더욱 악화시킬 수 있습니다. 이제 문제는 "가능한가?"가 아니라 "실행 후 안정적으로 운영될 수 있는가?"입니다.

프로토콜 수준에서 이러한 "위험 전가" 문제를 해결하는 핵심은 권한을 책임 있는 권한으로 전환하는 것입니다. 스테이킹과 검증자 투표 페널티는 빌더의 "운영상 부정행위"에 명확한 비용 부담을 부여합니다. 동시에 가격 및 레버리지 제약(클램프, 업데이트 간격, 변동성 상한, 격리 마진)은 가장 위험한 극단적인 시나리오를 통제 가능한 범위 내로 유지하려고 합니다. 따라서 HIP-3의 진정한 목표는 확장은 개방성에, 보안은 제약에, 그리고 장기적인 지속가능성은 검증 가능성과 책임성에 달려 있다는 것입니다.

HIP-3는 새로운 배포를 더욱 유연하게 만드는 것이 아니라 표준화를 강화하여 배포, 운영 및 책임성을 향상시킵니다. 그러나 표준화가 진정으로 원활하게 작동하려면 Oracle/레버리지/위험 제어 매개변수 및 런타임 모니터링의 구현 품질이 매우 중요합니다. HIP-3를 기반으로 시장 접근, 매개변수 템플릿, 알림 및 비상 대응 프로세스를 설계하거나 감사 및 지속적인 보안 지원이 필요한 경우 BlockSec에 문의하십시오.