아키텍처
Hypercall은 하이브리드 실행 모델을 사용합니다. 속도를 위해 매칭은 오프체인에서 처리하고, 보안을 위해 결제와 계정 관리는 온체인에서 처리합니다.
신뢰 경계
오프체인 (Hypercall 백엔드)
담당 영역:
- 주문 매칭 및 체결
- 호가창 관리
- 거래 전 증거금 확인(모든 퍼프 주문에 앞서 수행되는 포트폴리오 확인 포함)
- 청산 조율
- 시장 데이터 및 가격 산정
- WebSocket 스트림
신뢰 가정: 위의 모든 항목에 대해 운영자를 신뢰하게 됩니다. 신뢰 모델을 참고하십시오.
온체인 (스마트 컨트랙트)
담당 영역:
- 계정 소유권 및 매니저 통제
- 입금 및 출금
- RSM 명령(리스크 관리 작업)
- 옵션 토큰(OptionRegistry 및 OptionToken 컨트랙트)
- 퍼프 주문을 위한 빌더 승인(Account에서 1회
approveZeroFeeBuilder실행)
신뢰 가정: 온체인 작업은 Hyperliquid에 기록되며 운영자 단독으로는 변경할 수 없습니다. 컨트랙트를 업그레이드할 수 있는 주체는 신뢰 모델에서 다룹니다.
주문 체결 흐름
1. 주문 제출
사용자 동작: EIP-712 서명과 함께 POST /order로 주문을 제출합니다.
백엔드 검증:
- 서명 검증(EIP-712)
- 거래 전 증거금 확인(시나리오 기반)
- 주문 접수 심사(티어, 만기, 요청 한도)
결과: 주문이 수락(ACKED)되어 매칭 대기열에 들어가거나, 사유와 함께 거부됩니다.
2. 주문 매칭
프로세스: 주문은 가격-시간 우선순위에 따라 호가창에서 매칭됩니다.
체결: 주문이 매칭되면 체결 내역이 생성되고 엔진 상태의 포지션이 갱신됩니다. 모든 상태 변경은 확인 응답 전에 엔진의 영구 저널에 기록되며, 데이터베이스 테이블은 이 저널에서 파생됩니다.
온체인 아님: 개별 옵션 매칭은 온체인에 기록되지 않습니다.
3. 포지션 갱신
프로세스: 옵션 포지션과 현금은 엔진 상태에서 추적되며 실시간으로 갱신됩니다. 퍼프 포지션은 Hyperliquid에 있는 계정의 HyperCore 원장에 존재합니다.
사용자 조회: GET /portfolio 또는 WebSocket portfolio 채널로 포지션을 조회할 수 있습니다.
4. 결제
만기 결제: 옵션은 만기 시 Hyperliquid 오라클에서 도출한 결제가격을 기준으로 현금 결제됩니다. 엔진은 결제가격을 저널에 기록하고, 각 포지션의 내재가치를 계산한 뒤 현금 잔고를 갱신하고 포지션을 종료합니다.
기초자산별 만기 시각, 결제가격 산정 방식, 데이터가 부족할 때의 처리는 결제와 오라클을 참고하십시오.
계정 관리
계정 생성
프로세스: 매니저 지갑이 소액의 HYPE 생성 예치금과 함께 Factory의 createAccount를 호출합니다. 퍼프 또는 Portfolio Margin을 활성화하면 앱이 이 과정을 대신 처리합니다. 온보딩(컨트랙트)을 참고하십시오.
매니저: 각 Account에는 이를 통제하는 매니저(EOA)가 있으며, 매니저는 주문과 취소에 서명할 API 지갑을 승인할 수 있습니다.
입금 및 출금
입금:
- USDC: HyperEVM에서 Exchange 컨트랙트(
depositUsdcFor)로 전송되며, 이 컨트랙트가 이를 Exchange의 HyperCore 잔고로 브리지합니다. Hypercall은 HyperCore 입금이 확인되면 이를 반영합니다. - 옵션 ERC20: Exchange 컨트랙트를 통해 입금되며, 컨트랙트가 토큰을 소각하고 포지션을 반영합니다.
출금:
- Hypercall의 증거금 확인을 통과해야 합니다(출금 후에도 증거금이 충분해야 함)
- 사용자 지갑으로 서명합니다. 일반 USDC 출금은 RSM 디렉티브를 통해 Exchange의 잔고에서 HyperCore로 지급됩니다. Portfolio Margin 출금은 HyperCore에서 사용자 Account가 매니저 서명으로 전송하는 방식입니다.
신뢰 경계: 입금과 출금은 온체인에서 이루어지며 검증 가능합니다.
청산
계정의 자산가치가 유지증거금 요건 아래로 떨어지면 사전 청산 상태에 들어갑니다.
- 리스크를 늘리는 주문은 차단되며, 포지션을 줄이는 주문은 계속 허용됩니다.
- 청산자는 증거금을 회복시키기 위해 부분 청산 주문을 집행하며, 청산자 보너스는 시간이 지남에 따라 증가합니다.
- 에스컬레이션 기간 내에 계정이 회복되지 않으면 전체 청산으로 넘어가며, 이는 Hypercall 엔진이 수행합니다.
자세한 내용은 청산을 참고하십시오.
Hyperliquid 연동
퍼프
Hypercall은 xyz dex의 HIP-3 마켓을 포함해 퍼프 주문을 Hyperliquid로 라우팅합니다. 모든 퍼프 주문은 먼저 사용자의 전체 포트폴리오 증거금 계정을 기준으로 확인됩니다. 그 이후에는 두 가지 경로가 있습니다. 앱은 기본적으로 TEE를 사용하며 스마트 컨트랙트 경로는 고급 설정으로 제공합니다. API 클라이언트는 호출하는 엔드포인트로 경로를 선택합니다.
스마트 컨트랙트 경로(앱의 고급 설정): 사용자가 주문에 서명 → Hypercall 엔진이 전체 포트폴리오 증거금 계정을 기준으로 확인 → 주문이 사용자의 계정 컨트랙트를 거쳐 온체인으로 HyperCore에 전달 → Hyperliquid가 매칭
TEE 경로(앱 기본값, API에서는 옵트인): 사용자가 주문에 서명 → 엔진이 확인 → 계정의 Hyperliquid 거래 키를 보관하는 보안 엔클레이브(TEE)가 네이티브 주문에 서명 → Hyperliquid가 매칭
엔클레이브를 거치는 것은 TEE 경로의 주문뿐입니다. 이 주문에는 Hypercall의 빌더 주소가 포함되므로 계정은 빌더를 한 번 승인(Enable trading)해야 하며, 엔클레이브는 엔진이 승인한 주문, 취소, 레버리지 변경에만 서명합니다. Hypercall의 퍼프를 참고하십시오.
활용 사례:
- 옵션 포지션의 델타헤지
- 교차 증거금: 퍼프 포지션이 포트폴리오 증거금에 반영됩니다
교차 증거금
HyperCore 퍼프 포지션은 포트폴리오 증거금 계산에 포함되며, 증거금 요건은 포트폴리오 증거금 결과와 Hyperliquid 자체 증거금 중 큰 값으로 정해집니다. Portfolio Margin은 모든 계정에 열려 있습니다. Portfolio Margin 온보딩을 참고하십시오.
RSM 명령
RSM: 엔진의 복제 상태 머신(replicated state machine)입니다. 엔진 상태에 온체인 작업(입금 반영, 출금, 청산 단계, 복구 주문)이 필요해지면 RSM 서명자가 디렉티브에 서명하고 Hypercall의 시퀀서가 이를 제출합니다. 옵션 만기 결제는 RSM 디렉티브가 아니며, 엔진 상태의 현금에 직접 적용됩니다. 각 디렉티브로 할 수 있는 일은 RSM 디렉티브에 정리되어 있습니다.
검증 가능한 항목
온체인 (검증 가능)
- 계정 소유권(매니저 주소)
- 입금 및 출금
- Hyperliquid 주문 및 퍼프 포지션(Hyperliquid 상)
- RSM 명령(온체인 실행)
오프체인 (신뢰 필요)
- 주문 매칭의 공정성
- 증거금 계산
- 결제가격 산정(Hyperliquid 오라클 입력값은 공개됨)
- 포지션 추적의 정확성
- 시장 데이터의 정확성
- 청산 개시 시점
신뢰 모델
Mainnet Alpha는 운영자가 운영합니다. 공정한 주문 매칭(가격-시간 우선), 정확한 시장 데이터 수집, 증거금과 결제가격의 올바른 산정, 적시 청산 발동, 올바른 RSM 디렉티브만의 발행, 장애 대응에 대해 Hypercall을 신뢰하게 됩니다. 이 중 어느 것도 아직 암호학적으로 검증할 수 없으며, 오프체인 매칭은 이 신뢰를 대가로 속도를 얻습니다. 나머지는 체인이 강제합니다. 계정 소유권, 입금, 출금은 온체인에서 이루어지고, Account는 매니저, 자신의 API 지갑 또는 등록된 RSM 서명자가 서명한 디렉티브만 실행하며, 컨트랙트는 RSM 디렉티브를 입금 반영, 출금, 청산 상태, 제약된 복구 작업으로 제한합니다. TEE 경로(앱 기본값)의 퍼프 주문은 엔진이 승인한 주문만 받아들이는 증명된(attested) 엔클레이브 내부에서 서명됩니다. RSM 서명자, 시퀀서, 컨트랙트 관리자 키와 업그레이드 키는 운영자가 통제하며, Account 업그레이드 한 번은 모든 Account에 적용됩니다. 정확한 권한, 역할, 주소는 신뢰 및 권한에 있습니다. RSM 탈중앙화 로드맵에서 상태 커밋먼트, 서명자 역할, 이의 제기 경로, 운영자 통제를 어떻게 검증 가능하게 만들지 제시할 예정입니다. Mainnet Alpha는 제약된 첫 단계이며 최종 신뢰 모델이 아닙니다.
함께 보기: