Viết bài: Blocksec
HIP-3 (Hyperliquid Improvement Proposal 3) đã ra mắt mainnet được khoảng 3 tháng, kể từ khi ra mắt, khối lượng giao dịch của thị trường tùy chỉnh bên thứ ba đã vượt qua 13 tỷ USD, điều này có nghĩa là việc “ra mắt” đang từ một quy trình nội bộ của sàn giao dịch trở thành một hạ tầng cơ bản có thể được các nhà phát triển bên ngoài trực tiếp gọi đến.
Trong các sàn giao dịch tập trung, việc “ra mắt” vốn dĩ là quyền lực của nền tảng: các loại tài sản có thể giao dịch, thời điểm ra mắt, tham số như thế nào, đều do quy trình vận hành và kiểm soát rủi ro quyết định. Ngay cả trên chuỗi, các loại hợp đồng vĩnh viễn (perp) – một loại hạ tầng nền tảng nặng – cũng thường bị hạn chế bởi nhịp độ triển khai và quản trị của một số nhóm nhỏ.
Sự đổi mới của HIP-3 nằm ở chỗ biến việc này từ “phê duyệt của nền tảng” thành “mở giao diện”: chỉ cần đáp ứng điều kiện, bên thứ ba có thể triển khai thị trường hợp đồng vĩnh viễn mới trên cùng một nền tảng giao dịch và thanh toán, để quyền ra mắt tập trung được hệ thống hóa và giao phó cho hệ sinh thái. Cải tiến này không chỉ giảm ngưỡng sáng tạo mà còn tăng khả năng mở rộng của thị trường. Tuy nhiên, việc mở giao diện cũng mang lại các rủi ro an ninh tiềm ẩn không thể bỏ qua, làm thế nào để đảm bảo các thị trường này vận hành hợp pháp và không có hành vi độc hại vẫn là vấn đề then chốt cần xem xét kỹ trong thiết kế của HIP-3.
0x1 Hyperliquid: Nền tảng của HIP-3
Hyperliquid là hạ tầng giao dịch vĩnh viễn chạy trên chuỗi riêng của nó. Đối với HIP-3, điểm quan trọng nhất là: việc khớp lệnh, thanh toán và quyết toán đều do nền tảng hợp đồng cung cấp thống nhất, khả năng thị trường có thể tái sử dụng, thay vì phải xây dựng một hệ thống giao dịch từ đầu.
Hyperliquid sử dụng kiến trúc hai lớp:
HyperCore: chuỗi khối tùy chỉnh tối ưu cho hợp đồng, xử lý tới 200,000 lệnh mỗi giây, có tính xác định cuối cùng.
HyperEVM: lớp ứng dụng, có thể chạy hợp đồng thông minh, tương thích EVM.
Thị trường perp nguyên bản của Hyperliquid (validator-operated perps) vẫn còn giống quy trình của các sàn CEX truyền thống: chính thức dựa theo ý muốn cộng đồng để ra mắt hợp đồng vĩnh viễn; việc hủy bỏ sẽ do các nút xác thực bỏ phiếu quyết định.
The Hyperliquid protocol will support builder-deployed perps (HIP-3), một cột mốc quan trọng hướng tới việc phi tập trung hoàn toàn quá trình niêm yết hợp đồng vĩnh viễn.
Hợp đồng Hyperliquid sẽ hỗ trợ các nhà xây dựng triển khai hợp đồng vĩnh viễn (HIP-3), đây là bước quan trọng để hoàn toàn phi tập trung quá trình ra mắt hợp đồng.
0x2 HIP-3: Thị trường do nhà phát triển triển khai
Ý tưởng của HIP-3 rất đơn giản: không cần thay đổi nền tảng giao dịch và thanh toán Hyperliquid, mở khả năng “thêm thị trường vĩnh viễn mới” cho các builder đủ điều kiện. Builder chịu trách nhiệm xác định các tham số chính của thị trường và trách nhiệm cung cấp giá/ vận hành, còn hợp đồng sẽ dùng hệ thống ký quỹ và engine thanh toán, kiểm soát rủi ro chung; từ đó, “ra mắt” chuyển từ quy trình của nền tảng thành một giao diện chuẩn có thể gọi.
Nói đơn giản: builder có thể niêm yết một thị trường hợp đồng vĩnh viễn dựa trên engine HyperCore, tự định giá và điều chỉnh tham số thị trường.
Phạm vi trách nhiệm của builder
Trong HIP-3, builder đảm nhận hai loại công việc với một thị trường perp: xác định thị trường và vận hành thị trường.
Xác định thị trường (Market definition):
Phần này của chính thức tóm gọn là oracle definition + contract specifications. Trên thực tế, ít nhất bao gồm:
Định nghĩa oracle:
Bao gồm định nghĩa oraclePx ban đầu và nguồn giá. Khi xác định thị trường, builder cần rõ ràng xác định một tài sản hoặc nguồn dữ liệu rõ ràng, khó thao túng và có giá trị kinh tế thực; khi đăng ký tài sản, cần cung cấp oraclePx ban đầu.
Thông số hợp đồng:
Trong API, xác định rõ các tham số như “ký hiệu tài sản / đơn vị nhỏ nhất / đòn bẩy tối đa” (coin, szDecimals, maxLeverage, v.v.).
Lựa chọn DEX:
Builder sẽ triển khai trước một perp DEX (mỗi DEX có ký quỹ riêng, sổ lệnh, cài đặt của deployer), đồng thời có thể chọn bất kỳ tài sản báo giá nào làm tài sản thế chấp (ví dụ USDC), mỗi thị trường perp sẽ tương ứng với một DEX.
Vận hành thị trường (Market operation):
Chính thức liệt kê là setting oracle prices / leverage limits / settling the market nếu cần, cụ thể:
Cập nhật giá feed:
Thông qua API setOracle để liên tục feed giá oracle cho thị trường.
Giới hạn đòn bẩy:
Thông qua việc phân bổ ký quỹ (margin table) cho tài sản, giới hạn đòn bẩy tối đa – đòn bẩy tối đa theo phân cấp theo quy mô vị thế, hạn chế đòn bẩy trong phạm vi đã định.
Thanh lý khi cần thiết:
Builder có thể dùng API haltTrading để tạm dừng thị trường, kích hoạt thanh lý – hủy tất cả lệnh, thanh toán vị thế theo giá mark hiện tại; hành động này cũng có thể dùng để khôi phục giao dịch.
Hiện tại, thị trường HIP-3 chỉ hỗ trợ chế độ cách biệt (isolated-only), trong tương lai có thể hỗ trợ toàn bộ (cross).
Quy trình ra mắt thị trường
- Stake
Yêu cầu mainnet builder phải đặt cọc 500k HYPE; ngay cả khi tạm dừng tất cả thị trường của mình trên DEX, yêu cầu đặt cọc vẫn phải duy trì trong 30 ngày.
- Build
Sau khi đáp ứng yêu cầu đặt cọc, builder có thể triển khai một perp DEX. Mỗi perp DEX là một vùng giao dịch độc lập: ký quỹ riêng, sổ lệnh riêng, cài đặt của deployer riêng.
- Đặt cọc tài sản thế chấp
Tài sản thế chấp của DEX có thể chọn bất kỳ tài sản báo giá nào, nhưng nếu tài sản báo giá đó mất tư cách là “tài sản báo giá không giới hạn” (do bỏ phiếu của validator), thì perp DEX dùng tài sản đó làm collateral sẽ bị vô hiệu.
- Thêm thị trường
Ba thị trường đầu tiên có thể triển khai trực tiếp;
Khi muốn thêm thị trường mới, cần tham gia đấu giá Hà Lan (Dutch auction) để lấy “chỗ mới”.
- Vận hành thị trường
Sau khi thị trường ra mắt, công việc của builder là “đảm bảo thị trường hoạt động ổn định”, tức là vận hành thị trường.
- Rút staking
Khi tất cả các thị trường trên DEX đã thanh lý, mới có thể rút 500k HYPE đã đặt cọc, sau khi gửi yêu cầu unstake sẽ vào hàng đợi unstaking 7 ngày, trong thời gian này vẫn có thể bị phạt hoặc mất phần đặt cọc.
Đấu giá Hà Lan: chu kỳ hiện tại là 31 giờ một vòng, giá khởi điểm bằng 2 lần giá cuối cùng (giá giao dịch / giá thấp nhất).
SetOracle: Ba loại đầu vào giá
Trong HyperCore, giá oracle chủ yếu dùng để neo và tính phí funding, còn giá mark dùng để ký quỹ và kiểm soát rủi ro (cũng để kích hoạt TP/SL).
Trong thị trường nguyên bản, giá mark không phải là kết quả trực tiếp của feed giá, mà là trung vị của ba giá:
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade) (giá trong sổ lệnh địa phương)
Giá trung bình có trọng số của nhiều CEX perpetual mid prices (perp mid prices)
Tới HIP-3, vai trò của oracle price và mark price không thay đổi, nhưng cơ chế tính toán đã thay đổi:
setOracle đầu vào
a. oraclePx (bắt buộc )
Định nghĩa chính xác phù hợp HyperCore.
b. markPx (tùy chọn)
Có thể gửi 0–2 bộ giá mark bên ngoài làm các giá trị đề xuất cho giá mark thực sự.
c. externalPerpPx (bắt buộc)
Là giá tham khảo cho một giá mark, nhằm tránh giá mark đột ngột lệch.
Builder thường triển khai node relayer để feed giá, oraclePx
được tính dựa trên nguồn giá bên ngoài tổng hợp; markPx do relayer tùy chỉnh thuật toán tính; externalPerpPx lấy trung vị có trọng số của nhiều giá trung bình của các CEX perp mid prices.
- Giá mark thực tế
Giá mark của HIP-3 không trực tiếp dùng feed của setOracle:
Tính local mark: median(best bid, best ask, last trade).
Lấy trung vị của local mark và các bộ giá mark (0–2), ra giá mark mới.
- Giới hạn setOracle
Tần suất cập nhật: ít nhất cách nhau 2.5 giây giữa hai lần gọi, nếu sau 10 giây không cập nhật markPx sẽ tự động trở về local mark.
Giới hạn biên độ: biến động của markPx mỗi lần không quá ±1%; tất cả giá đều bị giới hạn trong phạm vi 10× của giá mở cửa ngày.
7×24H & Không 7×24H: Cơ chế định giá khác nhau
Trong HIP-3, thị trường hợp đồng vĩnh viễn hỗ trợ ra mắt bất kỳ tài sản nào, có thể phân thành tài sản 7×24H (giao dịch suốt ngày đêm) và không 7×24H (chỉ trong khung giờ nhất định, ngoài giờ giao dịch thị trường spot không thể giao dịch). Tính chất thời gian giao dịch của hai loại này quyết định cách lấy giá khác nhau.
Với tài sản 7×24H (ví dụ BTC), có thể lấy giá ổn định từ CEX/DEX hoặc các oracle đáng tin cậy:
Với tài sản không 7×24H (ví dụ cổ phiếu), chỉ có thể lấy giá từ thị trường bên ngoài khi mở cửa, để duy trì hoạt động liên tục 24/7 trong HIP-3, cần dùng cơ chế định giá khác trong thời gian nghỉ.
Ví dụ thị trường hợp đồng vĩnh viễn cổ phiếu trên trade.xyz:
Trong giờ mở cửa, dùng feed giá ổn định từ các oracle như Pyth.
Trong giờ nghỉ, dựa trên giá đóng cửa lần trước của cổ phiếu, kết hợp áp lực mua bán nội bộ để điều chỉnh giá. Giá mark bị giới hạn trong phạm vi ±1 của giá đóng cửa (ví dụ Tesla 10x -> 10%).
Thanh lý
Thị trường HIP-3 chủ yếu tái sử dụng logic thanh lý của HyperCore, do đó, quy trình kích hoạt thanh lý vẫn theo nền tảng: khi giá trị vị thế ròng (isolated position value) không đủ để duy trì ký quỹ, sẽ chuyển sang trạng thái có thể thanh lý.
Các quyết định liên quan đến thanh lý dựa trên giá mark, chứ không phải giá giao dịch.
Công thức tính giá thanh lý:
side = 1 (long), -1 (short)
l: tỷ lệ ký quỹ duy trì
Giá thanh lý = giá theo công thức dựa trên tỷ lệ ký quỹ và vị thế, thường là dựa trên giá mark hoặc giá trung vị của các nguồn giá.
Nếu có phân cấp (tiers), giá thanh lý sẽ dựa trên mức phù hợp của vị thế trong phân cấp đó, dùng mức mưỡng của tier đó.
margin_available
isolated: isolated_margin - maintenance_margin_required
Sau khi vào trạng thái có thể thanh lý, hệ thống sẽ ưu tiên dùng lệnh thị trường để đóng vị thế; nếu có thể đưa rủi ro về mức an toàn, phần ký quỹ còn lại sẽ trả cho trader.
Tuy nhiên, trong trường hợp thiếu độ sâu hoặc có gap, giá thực tế thực hiện có thể thấp hơn nhiều so với giá mark, gây ra “khoảng trống thanh lý”.
Isolated position value: giá trị ròng của vị thế isolated tại giá mark hiện tại (bao gồm lãi lỗ vị thế trừ đi ký quỹ liên kết).
ADL:
Lúc này, cơ chế Auto-Deleveraging (ADL) có thể dùng để xử lý trong các tình huống cực đoan:
Khi giá trị vị thế isolated trở thành âm, kích hoạt ADL, từ các vị thế đối thủ theo thứ tự lãi lỗ chưa thực hiện và đòn bẩy, buộc giảm hoặc đóng vị thế tại giá mark trước đó (previous mark price), bù đắp khoản thiếu hụt bằng lợi nhuận của các đối thủ, đảm bảo hệ thống không bị nợ xấu.
Tiêu chuẩn sắp xếp:
previous mark price: giá mark trước khi kích hoạt ADL.
Ví dụ:
Trước khi kích hoạt ADL, giá mark hệ thống ghi nhận là 3,000.
Do hạn chế của setOracle, giá mark mới tối đa chỉ thể cập nhật đến 2,970 (-1%).
Lúc này, sổ lệnh mua rất mỏng, sau khi lệnh thị trường thanh lý được đưa vào, giá trung bình thực tế thực hiện là 2,910 (-3%).
Lỗ của vị thế long sẽ tính theo 2,910, có thể làm giá trị ròng của vị thế isolated âm dưới 0 (khoảng trống), dẫn đến kích hoạt ADL.
ADL sẽ chọn các vị thế của các đối thủ có lãi (short) để thanh lý/bù đắp, theo giá mark trước đó là 3,000, nhằm chuyển khoản thiếu hụt thành lợi nhuận của bên thắng.
0x3 Rủi ro tổng quan:
Các rủi ro và giới hạn trách nhiệm
Cơ chế phạt (Slashing): quyền hạn có thể bị truy cứu trách nhiệm
HIP-3 giao quyền “ra mắt và vận hành” cho builder, đồng thời quy định rõ trách nhiệm qua một bộ quy tắc phạt có thể thực thi: builder phải đặt cọc HYPE, nếu bị xác định vận hành không đúng, validator có thể bỏ phiếu phạt và tiêu hủy (burn) phần đặt cọc đó.
Yêu cầu đặt cọc
Mainnet yêu cầu builder phải giữ 500k HYPE làm ký quỹ, ngay cả khi builder tạm dừng tất cả thị trường, vẫn phải duy trì trong 30 ngày (trách nhiệm không chấm dứt ngay lập tức khi ngưng hoạt động).
Quy trình bỏ phiếu và quyết định
Khi phát hiện hành vi thao túng thị trường, validator có thể khởi xướng và thực thi bỏ phiếu theo trọng số ký quỹ để quyết định có phạt builder hay không.
Nguyên tắc đánh giá
Chính thức rõ ràng: phạt không phân biệt “độc hại / thiếu năng lực / bị đánh cắp khoá riêng”, mà dựa trên hành vi của builder có gây ra trạng thái vô hiệu, downtime kéo dài hoặc giảm hiệu năng hay không.
Mức phạt
Tỷ lệ phạt do validator bỏ phiếu quyết định, tham khảo giới hạn:
Gây vô hiệu hoặc downtime dài hạn: tối đa 100%
Downtime ngắn hạn: tối đa 50%
Giảm hiệu năng: tối đa 20%
Token ký quỹ bị phạt sẽ bị tiêu hủy, không hoàn trả cho người dùng bị ảnh hưởng.
Rủi ro về tham số cấu hình
setOracle
Giá oracle thường lấy từ relayer của builder, có nguy cơ tập trung, nếu khoá riêng bị lộ hoặc bị tấn công DDoS, giá oracle trong thị trường có thể bị thao túng hoặc mất liên kết lâu dài.
haltTrading
Builder có thể dùng haltTrading để hủy tất cả lệnh trong thị trường và đóng vị thế theo giá mark hiện tại.
Chức năng này cần dùng thận trọng, ví dụ trong các trường hợp:
Khi phát hiện thị trường bị thao túng, gọi haltTrading để đóng theo giá mark, sẽ thực hiện lỗ của vị thế của attacker(, có thể khiến đối thủ khó tìm đủ lệnh đối ứng), dễ gây nợ xấu.
setMarginTableIds / InsertMarginTable
InsertMarginTable: định nghĩa một bảng ký quỹ mới, trong đó xác định yêu cầu ký quỹ và đòn bẩy tối đa của một loại tài sản.
setMarginTableIds: liên kết một thị trường với marginTableId cụ thể.
Thị trường thanh khoản thấp hoặc khả năng tạo lập thị trường yếu, đặt max leverage quá cao sẽ làm tăng khả năng kích hoạt ADL.
Chuyển đổi đột ngột marginTableId như thay đổi tỷ lệ ký quỹ duy trì của người dùng, có thể khiến nhiều tài khoản chuyển từ trạng thái an toàn sang có thể thanh lý cùng lúc, gây ra chuỗi thanh lý.
setMarginModes
Hiện tại HIP-3 chỉ cho phép margin cách biệt (isolated), trong tương lai có thể hỗ trợ margin toàn bộ (cross). Một DEX có thể có thị trường thanh khoản cao và thấp, chế độ cross margin có thể truyền rủi ro từ thị trường ít thanh khoản sang thị trường thanh khoản cao. Do đó, trước khi có giải pháp hoàn chỉnh, không khuyến khích builder dùng chế độ cross margin.
Rủi ro oracle
Với tài sản 7×24H, rủi ro chính nằm ở độ chính xác và ổn định của oracle bên ngoài, cùng với rủi ro tập trung của relayer.
Với tài sản không 7×24H, rủi ro lớn hơn nằm ở việc lấy hoặc tính giá oracle trong thời gian không giao dịch.
Ví dụ trade.xyz, trong thời gian nghỉ, dùng giá cuối cùng từ oracle bên ngoài và giá nội bộ để tính giá, trong khi thị trường cổ phiếu không có thanh khoản trong ngày cuối tuần (sổ lệnh mỏng, nhà tạo lập ít), không có giá oracle để neo. Dù đã đặt giới hạn biến động (1/max_leverage), nhưng giới hạn này vẫn có thể quá cao đối với tài sản ít biến động, gây ra thanh lý hàng loạt hoặc ADL.
Ngày 14/12/2025, trade.xyz xảy ra thao túng thị trường với cổ phiếu XYZ100-USDC (, tạo ra vị thế short 398 XYZ100 (~10 triệu USD), làm giá lệch khỏi liên kết, nhiều long bị thanh lý, giá tiếp tục giảm, cuối cùng khoảng 13 triệu USD long bị thanh lý.
Ngược lại, trong thời gian nghỉ, thiếu giá oracle ổn định liên tục, thị trường chỉ dựa vào “giá cuối cùng từ oracle + sổ lệnh nội bộ” để tạo ra một phạm vi định giá nội bộ hạn chế (ví dụ, trade.xyz giới hạn biến động 1/max_leverage).
Rủi ro xuất hiện tại điểm mở cửa lại: thị trường bên ngoài có thể cung cấp một giá rõ ràng, nếu khác biệt lớn so với giá nội bộ trong thời gian nghỉ, hệ thống sẽ bị giới hạn hoặc giá sẽ điều chỉnh nhanh, gây ra áp lực thanh lý lớn trong thời gian ngắn, thậm chí dẫn đến ADL.
0x4 Chiến lược kiểm soát rủi ro
- Giá oracle ổn định
Với tài sản không giao dịch suốt ngày đêm như cổ phiếu, khó khăn chính là định giá trong thời gian nghỉ: thiếu giá ổn định từ oracle bên ngoài, dễ bị thao túng hoặc tự trôi dạt.
Các giải pháp phổ biến hiện nay gồm hai hướng:
Tạm dừng cập nhật giá oracle, hạn chế hoặc tạm thời cấm giao dịch trong thời gian đó (ví dụ Lighter chỉ cho phép giảm vị thế trong thời gian nghỉ). Các protocol như Optium còn giảm đòn bẩy tối đa trong thời gian nghỉ, bắt buộc thanh lý các vị thế vượt quá giới hạn.
Sử dụng cơ chế định giá nội bộ như trade.xyz, dựa vào thanh khoản nội bộ và thuật toán của protocol để duy trì hoạt động khi thiếu dữ liệu từ oracle bên ngoài.
Hai phương án này phản ánh rõ ràng sự đánh đổi giữa an toàn và trải nghiệm của thiết kế protocol. Phương án thứ nhất kiểm soát rủi ro chặt chẽ hơn nhưng làm giảm trải nghiệm giao dịch; phương án thứ hai duy trì liên tục, nhưng dễ lệch khỏi giá thực của tài sản do thiếu tham chiếu bên ngoài.
Trong thời gian nghỉ, cần tránh để giá của protocol hoàn toàn trở thành “giá nội bộ thuần túy”, mà nên có tham chiếu từ oracle bên ngoài để giảm thiểu rủi ro lệch giá hoặc trượt giá. Các nguồn tham khảo có thể là:
Blue Ocean ATS
Là sàn giao dịch sau giờ / đêm, cung cấp giá liên tục trong thời gian nghỉ, hỗ trợ tạo giá oracle hoặc làm chuẩn theo dõi rủi ro.
IG weekend CFD quotes
Giá CFD cuối tuần cung cấp dự báo thị trường cuối tuần, dùng làm giá neo hoặc cảnh báo rủi ro, giúp phát hiện sớm các khả năng “nhảy giá” khi mở cửa.
Hai nguồn này đều cung cấp tín hiệu giá trong thời gian nghỉ, nhưng không hoàn toàn giống thị trường cổ phiếu, phù hợp hơn làm tham chiếu hoặc cảnh báo rủi ro, chứ không thay thế hoàn toàn.
2( Xác thực giá
Giá oracle của HIP-3 lấy từ relayer do builder cài đặt, có thể gây tranh cãi về tính trung tâm. Để khắc phục, đề xuất builder xây dựng cơ chế xác thực giá, cho phép bất kỳ người dùng hoặc tổ chức nào cũng có thể xác minh tính xác thực và công bằng của giá ngoài chuỗi)tương tự RedStone, đóng gói giá cùng nguồn dữ liệu và chữ ký chứng thực lên chuỗi).
Dữ liệu công khai
Thuật toán chuẩn: công khai chi tiết thuật toán và quy trình.
Danh sách nguồn dữ liệu: mỗi nguồn đều công khai, không bị builder can thiệp, và rõ ràng về API, tham số.
Quy chuẩn đẩy giá: quyền, tần suất kích hoạt, giới hạn biến động của setOracle.
b. Chứng thực giá
Mỗi lần setOracle sẽ tạo ra một chứng thực tương ứng (Proof), gồm:
Inputs: phản hồi gốc của từng nguồn tại thời điểm đó (hoặc sau chuẩn hoá), kèm timestamp.
Tính toán: các trung gian có thể tính lại, kết quả trung gian của từng bước.
Outputs: giá oracle được đưa lên chuỗi lần này.
Chuyển Proof thành dạng tuần tự, tạo proofHash, và ký bằng khóa của oracleUpdater.
c. Đưa chứng thực lên chuỗi
Duy trì danh sách, mỗi ProofHash theo thứ tự thời gian, ghi vào Merkle tree.
Định kỳ (ví dụ mỗi giờ / mỗi ngày), phát hành MerkleRoot và đưa lên chuỗi.
d. Xác thực
Cung cấp công cụ mã nguồn mở hoặc trang web, nhập thời gian hoặc tx hash của setOracle, lấy tất cả dữ liệu trên.
Xác thực chữ ký, timestamp, MerkleRoot, v.v.
So sánh giá oracle tính theo thuật toán công khai.
- Giám sát rủi ro
Xác thực giá giúp biến quá trình setOracle thành “có thể tính lại, có thể kiểm toán”, giải quyết vấn đề độ tin cậy của feed giá; nhưng không thể ngăn thị trường mất kiểm soát trong quá trình vận hành – gián đoạn feed, lệch giá, giảm độ sâu, đặc biệt khi có khối lượng chưa đóng lệnh lớn (OI), dễ dẫn đến các chuỗi thanh lý hoặc ADL, gây rủi ro hệ thống. Do đó, cần sớm phát hiện các bất thường của thị trường thành tín hiệu quan sát được, và kích hoạt xử lý trong thời gian phù hợp để kiểm soát rủi ro.
- Về giá
a. Mất feed oracle
Chỉ số giám sát:
Dùng các dữ liệu có thể quan sát trên chuỗi để đánh giá xem feed có bị tắc nghẽn không:
Ngưỡng phân cấp:
Hành động:
Level 1: kiểm tra sức khỏe relayer, chuyển sang relayer dự phòng; gửi cảnh báo kèm báo cáo sức khỏe và thông tin các relayer.
Level 2: gọi setOpenInterestCaps giảm OI cap:
b. Lệch giá
Chỉ số giám sát:
Ngưỡng:
Level 1: ≥ 2 trong các A, B, D vượt ngưỡng
Level 2: ≥ 3 trong các A, B, C, D vượt ngưỡng liên tục X giây
Hành động:
Level 1: gọi setOpenInterestCaps giảm OI limit
Level 2: trong thời gian lệch dài, cập nhật dần margin table, giảm dần max leverage theo phân cấp; relayer bật chế độ clamp.
Level 3: liên tục cảnh báo trong Level 2, cuối cùng do builder quyết định có gọi haltTrading dừng thị trường hay không.
- Về sổ lệnh
a. Rút sâu
Giám sát:
depth_band(±x%): lượng lệnh thực trong vùng giá ±x% quanh mid.
spread = bestAsk - bestBid: chênh lệch giá, đo độ “đứt quãng” của sổ lệnh.
aggressiveVolume_Δt: lượng khớp lệnh chủ động trong Δt (taker volume), tổng hợp theo side.
impact_ratio = aggressiveVolume_Δt / depth_band: tỷ lệ hấp thụ.
Phân tích:
Khi xuất hiện các tổ hợp sau, rủi ro tăng:
depth_band giảm, kèm spread và impact_ratio tăng.
Hành động:
Level 1: gọi setOpenInterestCaps giảm OI limit = hiện tại OI, hạn chế tăng vị thế.
Level 2: gọi setMarginTableIds giảm đòn bẩy, tránh vị thế đòn bẩy cao sinh ra rủi ro, đồng thời buộc thanh lý các vị thế đòn bẩy cao, rủi ro cao.
b. Lệnh ảo
Giám sát:
depth_band tăng rồi đột ngột giảm trong thời gian ngắn.
Hành động:
Level 1: gọi setOpenInterestCaps giảm OI limit.
Level 2: nếu kèm lệch giá nghiêm trọng, xem xét tạm dừng thị trường.
- Về vị thế
Mục tiêu giám sát vị thế không phải “dự đoán hướng”, mà là nhận diện thị trường chuyển từ giao dịch sang chiến lược giữ vị thế: khi OI tăng nhanh, vị thế tập trung cao, và đa số lãi lỗ gần cực trị, mọi dao động ngoại lai đều dễ bị phóng đại thành chuỗi thanh lý / ADL. Do đó, các hành động về vị thế thường có độ ưu tiên thấp hơn giá và sổ lệnh.
a. OI quá nặng trong ngắn hạn
Giám sát:
OI_notional: quy mô chưa đóng.
Volume_24h_notional: khối lượng giao dịch 24h.
Tỷ lệ = OI_notional / Volume_24h_notional, tăng đột biến cho thấy thị trường chuyển từ vị thế ngắn hạn sang chiến lược giữ vị thế, dự báo có thể xuất hiện biến động lớn.
Hành động:
Level 1: cảnh báo khi đạt ngưỡng.
b. Lãi lỗ đa số
Giám sát:
Majority Side: bên có nhiều vị thế hơn trong khoảng thời gian thống kê (Long hoặc Short).
avgEntry_major: giá mở vị thế trung bình của đa số.
size_major: quy mô vị thế của đa số.
Lãi lỗ của đa số:
Tỷ lệ lãi lỗ của đa số:
Hành động:
Level 1: cảnh báo khi đạt ngưỡng.
Level 2: liên tục đạt ngưỡng, xem xét giảm OI limit bằng setOpenInterestCaps.
0x5 Kết luận
Cốt lõi của HIP-3 chính là: chuyển “ra mắt” từ quy trình do ít người quyết định thành khả năng của giao thức theo tiêu chuẩn – builder chỉ cần đặt cọc là có thể khởi chạy DEX perp của riêng mình trên HyperCore, niêm yết miễn phí một số thị trường ban đầu, rồi qua đấu giá để mở rộng thêm chỗ, biến quá trình mở rộng thị trường từ “chờ phê duyệt” thành “theo quy tắc mở rộng”.
Nhưng rõ ràng, HIP-3 không loại bỏ rủi ro, chỉ thay đổi vị trí và dạng thức của rủi ro. Các phần vốn đã do kiểm soát rủi ro của nền tảng đảm bảo giờ đây phần lớn chuyển sang chất lượng đầu vào và vận hành của builder: feed giá setOracle và tần suất, lựa chọn và giới hạn markPx, phân cấp đòn bẩy trong margin table, cơ chế định giá trong thời gian nghỉ của tài sản không 7×24H, và quyền dừng lỗ như haltTrading – có thể vừa cắt lỗ vừa làm tăng tổn thất. Bất kỳ xử lý sai nào cũng có thể làm nhỏ giọt thành các chuỗi thanh lý tập trung, gây ra các khoản thiếu hụt và ADL – vấn đề không còn là “có thể ra mắt” hay không, mà là “ra mắt rồi có thể vận hành ổn định hay không”.
Phương thức chính của giao thức để đối phó với dạng “rủi ro giao phó” này là chuyển quyền thành quyền có thể truy cứu trách nhiệm: đặt cọc + bỏ phiếu của validator để phạt và tiêu hủy, giúp builder có trách nhiệm rõ ràng; đồng thời, các giới hạn về giá và đòn bẩy (clamp, tần suất cập nhật, giới hạn biến động, cách biệt từng phần) nhằm thu hẹp các tình huống nguy hiểm nhất trong phạm vi kiểm soát. Do đó, mục tiêu thực sự của HIP-3 là: mở rộng để phát triển, an toàn để kiểm soát, và lâu dài dựa trên khả năng xác minh và trách nhiệm giải trình.
