Kiến trúc
Hypercall sử dụng mô hình thực thi lai (hybrid execution model): khớp lệnh off-chain để đạt tốc độ cao, kết hợp với thanh toán và quản lý tài khoản on-chain để đảm bảo bảo mật.
Ranh giới tin cậy
Off-Chain (Backend của Hypercall)
Trách nhiệm:
- Khớp và thực thi lệnh
- Quản lý sổ lệnh
- Kiểm tra ký quỹ trước giao dịch
- Điều phối thanh lý
- Dữ liệu thị trường và định giá
- Luồng WebSocket
Giả định tin cậy: Người dùng tin tưởng backend của Hypercall trong việc:
- Khớp lệnh công bằng (ưu tiên theo giá-thời gian)
- Thực thi kiểm tra ký quỹ chính xác
- Giám sát tài khoản và kích hoạt thanh lý khi cần
- Cung cấp dữ liệu thị trường chính xác
Hạn chế: Các hoạt động off-chain chưa thể xác minh đầy đủ bằng mật mã trong giai đoạn Mainnet Alpha. Người dùng phải tin tưởng đơn vị vận hành backend về khớp lệnh, tiếp nhận dữ liệu thị trường, kiểm tra ký quỹ và phát hành lệnh RSM.
Hướng phát triển: Hypercall đang hướng tới phi tập trung hóa RSM và các đảm bảo phi tin cậy (trustlessness) mạnh mẽ hơn. Lộ trình sẽ nêu rõ cách các cam kết trạng thái (state commitment), vai trò của người ký (signer), cơ chế giải quyết tranh chấp và quyền kiểm soát của đơn vị vận hành trở nên dễ xác minh hơn theo thời gian. Mainnet Alpha là giai đoạn đầu tiên với các ràng buộc, không phải là mô hình tin cậy cuối cùng.
On-Chain (Hợp đồng thông minh)
Trách nhiệm:
- Quyền sở hữu tài khoản và quyền kiểm soát của manager
- Nạp và rút tiền
- Đấu giá thanh lý (chuyển giao vị thế)
- Lệnh RSM (các hoạt động quản lý rủi ro)
- Đăng giá thanh toán
- Tích hợp Hyperliquid (lệnh perp qua ActionCaster)
Giả định tin cậy: Các hoạt động on-chain có thể xác minh bằng mật mã. Người dùng có thể xác minh mã hợp đồng và trạng thái.
Bảo mật: Quyền sở hữu tài khoản không thể thay đổi nếu không có giao dịch on-chain. Việc thanh lý yêu cầu đấu giá on-chain.
Luồng thực thi lệnh
1. Gửi lệnh
Hành động của người dùng: Gửi lệnh qua POST /order với chữ ký EIP-712.
Xác thực từ backend:
- Xác minh chữ ký (EIP-712)
- Kiểm tra ký quỹ trước giao dịch (dựa trên kịch bản)
- Chấp nhận lệnh (tier, ngày đáo hạn, giới hạn tần suất)
Kết quả: Lệnh được chấp nhận (ACKED) và đưa vào hàng đợi để khớp, hoặc bị từ chối kèm lý do.
2. Khớp lệnh
Quy trình: Các lệnh được khớp trên sổ lệnh theo nguyên tắc ưu tiên giá-thời gian.
Thực thi: Khi các lệnh được khớp, các fill được tạo và vị thế được cập nhật trong cơ sở dữ liệu backend.
Không on-chain: Các lần khớp lệnh riêng lẻ không được ghi lại on-chain. Trạng thái tài khoản được đồng bộ qua các cập nhật margin root.
3. Cập nhật vị thế
Quy trình: Vị thế được theo dõi trong cơ sở dữ liệu backend và cập nhật theo thời gian thực.
Truy cập của người dùng: Truy vấn vị thế qua GET /portfolio hoặc kênh WebSocket portfolio.
Đồng bộ on-chain: Margin root (cam kết mật mã đối với trạng thái tài khoản) được cập nhật on-chain định kỳ và khi có các sự kiện quan trọng.
4. Thanh toán
Thanh toán khi đáo hạn: Quyền chọn đáo hạn tại thời điểm đáo hạn của hợp đồng và được thanh toán bằng tiền mặt dựa trên giá thanh toán. SPCX trên mạng chính đáo hạn lúc 4:00 chiều giờ ET; testnet hiện đáo hạn lúc 08:00 UTC.
Giá thanh toán: TWAP 30 phút của giá chỉ số Hyperliquid Oracle, được đăng on-chain qua SimpleOracle.setExpiryPrice().
Quy trình:
- Oracle tính TWAP 30 phút kết thúc tại thời điểm đáo hạn
- Giá thanh toán được đăng on-chain
- Giá trị nội tại được tính cho từng vị thế
- Số dư tiền mặt được cập nhật
- Các vị thế được đóng
Quản lý tài khoản
Tạo tài khoản
Quy trình: Tài khoản được tạo khi nạp tiền lần đầu hoặc khi có yêu cầu rõ ràng.
On-chain: Hợp đồng tài khoản được triển khai dưới dạng BeaconProxy (mẫu minimal proxy tiết kiệm gas).
Manager: Mỗi tài khoản có một manager (EOA), người kiểm soát tài khoản và có thể ủy quyền cho các agent.
Nạp và rút tiền
Nạp tiền:
- USDC: Được chuyển đến Exchange qua HyperCore
- Option ERC20: Được nạp qua hợp đồng Exchange
Rút tiền:
- Phải vượt qua các kiểm tra rủi ro off-chain (đủ ký quỹ sau khi rút)
- Được thực thi on-chain qua hợp đồng Account
- Yêu cầu chữ ký của manager
Ranh giới tin cậy: Việc nạp và rút tiền diễn ra on-chain và có thể xác minh.
Thanh lý
Việc thanh lý sử dụng một máy trạng thái (state machine) với thời gian ân hạn trước khi đấu giá:
| Trạng thái | Mô tả | Thời lượng |
|---|---|---|
| Healthy | Vốn chủ sở hữu > MM yêu cầu | - |
| PreLiquidation | Vốn chủ sở hữu < MM, thời gian ân hạn đang hiệu lực | 60 giây |
| InLiquidation | Đấu giá Dutch đang diễn ra | Cho đến khi khớp |
| Liquidated | Vị thế đã được chuyển giao | - |
Thanh lý một phần vs Thanh lý toàn bộ
| Loại | Điều kiện | Hành vi |
|---|---|---|
| Một phần | ≤ 5 vị thế | Thanh lý các vị thế cụ thể cho đến khi trở lại trạng thái an toàn |
| Toàn bộ | > 5 vị thế | Thanh lý toàn bộ tài khoản |
Cơ chế đấu giá
Đấu giá khi còn khả năng thanh toán (Vốn chủ sở hữu > 0): Giá khởi điểm = vốn chủ sở hữu × (1 - phạt), giảm dần theo thời gian. Các liquidator đặt giá để tiếp nhận vị thế.
Đấu giá khi mất khả năng thanh toán (Vốn chủ sở hữu < 0): Quỹ bảo hiểm cung cấp phần thưởng để khuyến khích các liquidator tiếp nhận các vị thế âm vốn.
On-chain: Việc thực thi đấu giá và chuyển giao vị thế diễn ra on-chain qua hợp đồng Exchange.
Xem Thanh lý để biết chi tiết đầy đủ.
Tích hợp Hyperliquid
HIP-3 Perps
Tài khoản Hypercall có thể thực thi lệnh perp trên Hyperliquid qua ActionCaster:
Luồng: Hợp đồng Account → ActionCaster → Hyperliquid L1
Trường hợp sử dụng:
- Phòng hộ delta cho các vị thế quyền chọn
- Ký quỹ liên sàn (các vị thế perp được tính vào ký quỹ danh mục)
Cross-Margin
Các vị thế perp trên HyperCore được thiết kế để được tính vào các phép tính ký quỹ danh mục, cho phép các chiến lược phòng hộ hiệu quả về vốn. Portfolio Margin bị vô hiệu hóa cho người dùng phổ thông trong giai đoạn Mainnet Alpha.
Lệnh RSM
RSM (Risk & Settlement Manager): Thành phần backend phát hành các lệnh on-chain để quản lý rủi ro.
Các lệnh bao gồm:
- Lệnh chỉ giảm vị thế (reduce-only, buộc đóng vị thế)
- Trả nợ (buộc rút tiền để bù đắp số dư âm)
- Thực thi thanh toán
On-chain: Các lệnh RSM được ký bởi RSM signer và thực thi qua hợp đồng Account. Người dùng có thể xác minh địa chỉ RSM signer và tất cả các lần thực thi lệnh on-chain.
Lộ trình phi tập trung hóa: RSM signer hiện tại do đơn vị vận hành kiểm soát. Lộ trình trong tương lai sẽ công bố cách vai trò này được phi tập trung hóa hoặc giảm thiểu yêu cầu tin cậy theo cách khác.
Những gì bạn có thể xác minh
On-Chain (Có thể xác minh)
- Quyền sở hữu tài khoản (địa chỉ manager)
- Triển khai hợp đồng tài khoản
- Nạp và rút tiền
- Các phiên đấu giá thanh lý và kết quả
- Giá thanh toán (oracle đăng on-chain)
- Lệnh Hyperliquid (thực thi on-chain)
- Lệnh RSM (thực thi on-chain)
Off-Chain (Cần tin cậy)
- Tính công bằng của việc khớp lệnh
- Các phép tính ký quỹ
- Độ chính xác của việc theo dõi vị thế
- Độ chính xác của dữ liệu thị trường
- Thời điểm kích hoạt thanh lý
Mô hình bảo mật
Nguyên tắc chính: Các hoạt động quan trọng (quyền sở hữu tài khoản, nạp tiền, thanh lý, giá thanh toán) diễn ra on-chain và có thể xác minh. Hiệu quả vận hành (khớp lệnh, kiểm tra ký quỹ) diễn ra off-chain.
Đánh đổi: Khớp lệnh off-chain mang lại tốc độ và hiệu quả nhưng hiện tại đòi hỏi sự tin cậy vào đơn vị vận hành backend. Các hoạt động on-chain có thể xác minh nhưng chậm hơn và tốn kém hơn. Lộ trình phi tập trung hóa RSM là con đường từ mô hình Mainnet Alpha hiện tại hướng tới tính phi tin cậy mạnh mẽ hơn.
Xem thêm:
- Thanh toán & Đáo hạn - Quy trình thanh toán và vòng đời
- Thanh lý - Máy trạng thái và cơ chế thanh lý
- Hợp đồng - Tài liệu hợp đồng thông minh