HIP-3'e Derinlemesine Bakış: Bir İnşaatçı Odaklı Perspektif

Hyperliquid İyileştirme Önerisi 3 (HIP-3) [1], Hyperliquid üzerinde sürekli sözleşme (perpetual) piyasalarının nasıl oluşturulduğunu ve ölçeklendirildiğini köklü biçimde değiştirmektedir. Piyasa listeleme sürecini üçüncü taraf geliştiricilere açan HIP-3, listelemeyi isteğe bağlı, platform kontrollü bir eylemden protokol düzeyinde, kurala dayalı bir arayüze dönüştürmektedir.

Ana ağda devreye alınmasından bu yana, geliştirici tarafından oluşturulan piyasalar yaklaşık üç ayda 13 milyar doları aşan işlem hacmi üretmiş; bu da HIP-3'ün piyasa genişlemesinin ölçeklenebilirliğini ve esnekliğini somut biçimde artırabileceğini ortaya koymaktadır. Ancak bu dönüşüm yalnızca gücü merkeziyetsizleştirmekle kalmaz; sorumluluğu da yeniden dağıtır. Daha önce merkezi platform operasyonları tarafından üstlenilen ya da azaltılan riskler artık doğrudan geliştiriciler tarafından taşınmaktadır.

Sonuç olarak, HIP-3 kapsamında temel soru artık bir piyasanın başlatılıp başlatılamayacağı değil, zaman içinde güvenli biçimde işletilip işletilemeyeceğidir. Bu rapor, HIP-3'ü geliştirici merkezli bir perspektiften ele almakta; piyasaların nasıl tanımlandığını ve işletildiğini, geliştiricilerin karşılaştığı riskleri ve özellikle oracle ile ilgili risklerin nasıl azaltılabileceğini incelemektedir.

0x0 Arka Plan

Hyperliquid'in mimarisi [2], yürütme ve risk altyapısını piyasa tanımından ayırarak bu modelden ayrılmaktadır. İki katmanlı tasarım şunlardan oluşmaktadır:

• HyperCore: türev ticareti için optimize edilmiş, amaca özel bir Katman 1 blok zinciri; birleşik eşleştirme, tasfiye ve uzlaşma sağlar.
• HyperEVM: genişletilebilir mantık ve geliştirici etkileşimini mümkün kılan EVM uyumlu uygulama katmanı.

Yürütme ve tasfiye işlemleri protokol düzeyinde tek tip biçimde uygulandığından, yeni piyasalar kritik güvenlik mantığını yeniden uygulamak zorunda kalmadan aynı temel altyapıyı yeniden kullanabilir. Ancak fiyatlandırma tam olarak standartlaştırılamaz. Oracle girdileri, kaldıraç tasarımı ve çalışma zamanı operasyonları kaçınılmaz olarak piyasaya göre farklılık gösterir; bu da fiyatlandırmayı merkeziyetsizleşmenin riskle buluştuğu birincil arayüz haline getirir.

Bu mimariye karşın, Hyperliquid'in yerel sürekli sözleşme piyasaları için listeleme süreci (doğrulayıcı tarafından işletilen perp'ler olarak da anılır) hâlâ geleneksel bir CEX yaklaşımına benzemektedir. Yeni sözleşmelerin listelenmesi büyük ölçüde çekirdek ekip tarafından yürütülürken, listeden çıkarmalar doğrulayıcı oylarıyla belirlenmektedir.

HIP-3, geliştiriciler tarafından oluşturulan sürekli sözleşme piyasalarına olanak tanıyarak bu listeleme sürecini merkeziyetsizleştirmek amacıyla tanıtılmıştır. Geliştiricilerin piyasaları tanımlamasına ve işletmesine izin verirken protokolün katı yürütme ve risk sınırlarını zorlamasıyla piyasa tanımı ile protokol tarafından uygulanan yürütme arasındaki ayrımı resmileştirmektedir. Bu bağlamda HIP-3, tamamen merkeziyetsiz bir perp listeleme sürecine doğru atılmış önemli bir adımı temsil etmektedir.

0x1 Geliştirici Sorumlulukları: Tanım ve Operasyon

HIP-3 kapsamında geliştiriciler, piyasa yaşam döngüsü yönetiminde uçtan uca sorumluluk üstlenir. Bu bölümde önce piyasa başlatma iş akışını ele alıyor, ardından üretimde piyasa istikrarını en doğrudan belirleyen operasyonel kaldıraçlara odaklanıyoruz.

0x1.1 Piyasa Başlatma Akışı: Tanım ve Operasyon

HIP-3 kapsamında bir piyasayı başlatmak tek bir eylem değildir. Aşağıdaki tam piyasa başlatma iş akışında gösterildiği gibi, iki ayrı aşamayı kapsayan bir süreçtir: piyasa tanımı (1'den 4'e kadar olan adımlar) ve piyasa operasyonu (5. adım).

Piyasa tanımı aşamasında, bir geliştiricinin önce ana ağda 500.000 HYPE stake etmesi gerekir. Stake gereksinimini karşıladıktan sonra geliştirici, kendi marj sistemi, emir defterleri ve geliştirici kontrollü ayarlarıyla bağımsız bir işlem alanı oluşturan tek bir sürekli sözleşme DEX'i devreye alabilir. DEX düzeyinde geliştirici, söz konusu DEX'teki tüm piyasalar için teminat olarak kullanılacak bir alıntı varlık seçer. Seçilen alıntı varlığın izinsiz statüsünü koruması gerekir; bu statünün kaybedilmesi ilgili DEX'i devre dışı bırakır. Geliştirici daha sonra oracle spesifikasyonları, sembol ve kaldıraç limitleri gibi sözleşme parametreleri ile marj tabloları dahil olmak üzere temel piyasa parametrelerini tanımlar. İlk üç piyasa doğrudan devreye alınabilirken, ek piyasalar için bir Hollanda açık artırması aracılığıyla slot edinilmesi gerekir.

Hollanda açık artırması: Her tur 31 saat sürer; her seferindeki başlangıç fiyatı bir önceki nihai fiyatın 2 katıdır (son kazanma fiyatı / en düşük fiyat).

Piyasalar canlıya geçtikten sonra geliştirici, piyasa operasyonu aşamasına girer. Bu aşama, setOracle arayüzü aracılığıyla oracle fiyatlarının sürekli güncellenmesini, kaldıraç ve marj yapılandırmalarının sürdürülmesini, likidite ve açık pozisyon (OI) izlenmesini ve gerektiğinde işlemleri durdurma ile pozisyonları kapatma gibi acil durum eylemlerinin gerçekleştirilmesini kapsar.

Uygulamada, HIP-3 kapsamındaki en ciddi başarısızlıkların büyük çoğunluğu piyasa tanımı sırasında değil, zorlu piyasa koşullarında uzun süreli operasyon sırasında meydana gelir. Önemli olan husus, geliştirici sorumluluğunun piyasaları durdurmanın hemen ardından sona ermemesidir. Stake'in geri alınması yalnızca tüm piyasalar tasfiye edildikten sonra mümkündür ve zorunlu stake geri alım süresince stake kesilebilir durumda kalmaya devam eder.

0x1.2 Kritik Odak Alanları: Fiyatlandırma ve Ödeme Gücü

Geliştiriciler, piyasa tanımı ve piyasa operasyonu boyunca birbiriyle bağlantılı iki odak alanıyla karşı karşıyadır: oracle yapılandırması ve fiyat oluşumu ile stres altında piyasa ödeme gücü. Bu iki alan birbirine sıkı sıkıya bağlıdır; çünkü fiyatlandırma hataları, protokol düzeyindeki risk kontrolleri aracılığıyla hızla ödeme gücü baskısına dönüşebilir.

1. Oracle Yapılandırması ve Fiyat Oluşumu

Hyperliquid iki fiyat tanımlar:

• Oracle Fiyatı: Hyperliquid'in iç piyasa verilerinden bağımsız olacak şekilde tasarlanmış, büyük dış borsaların spot orta fiyatlarının ağırlıklı medyanı; öncelikle fonlamayı sabitlemek için kullanılır.
• Mark Fiyatı: oracle fiyatı ve yerel piyasa verileri dahil olmak üzere birden fazla girdiden türetilen iç risk fiyatı; gerçekleşmemiş kâr/zarar (PnL) ve risk kontrolleri için kullanılır.

Kısacası, oracle fiyatı fonlamayı sabitleri; mark fiyatı ise marj kontrollerini, tasfiyelerini ve TP (Kâr Al) ile SL (Zararı Durdur) tetikleyicilerini yönetir.

HIP-3 kapsamında oracle fiyatı ve mark fiyatının rolleri değişmez, ancak hesaplama mekanizması değişir:

a) setOracle girdileri

• oraclePx (zorunlu): HyperCore ile aynı tanım.
• markPx (isteğe bağlı): 0–2 adet harici olarak hesaplanmış mark fiyatı adayı.
• externalPerpPx (zorunlu): ani mark fiyatı sapmasını önlemek için referans değer.

Geliştiriciler genellikle fiyat beslemek için aktarıcı düğümleri devreye alır: oraclePx birden fazla harici kaynaktan hesaplanır, markPx özel bir algoritma ile aktarıcı tarafından hesaplanır ve externalPerpPx birden fazla CEX'in ağırlıklı medyanından elde edilir.

b) Gerçek mark fiyatı

• Yerel mark'ı hesapla: median(en iyi alış, en iyi satış, son işlem).
• Yerel mark ve markPx (0–2 değer) birlikte alınır ve yeni mark fiyatını elde etmek için medyan hesaplanır.

c) setOracle kısıtlamaları

• Güncelleme sıklığı: çağrılar arasında en az 2,5 saniye; markPx 10 saniye güncellenmezse yerel mark fiyatına geri döner.
• Genlik sınırları: markPx güncelleme başına en fazla ±%1 değişebilir; tüm fiyatlar günün başlangıç fiyatının 10 katı içinde sınırlandırılır.

HIP-3'te Varlık Türü Fiyatlandırma Açısından Neden Önemlidir?

HIP-3 kapsamında sürekli sözleşme piyasaları herhangi bir varlık türü için başlatılabilir. Bu varlıklar genel olarak 7/24 varlıklar (her zaman işlem görülebilen) ve 7/24 olmayan varlıklar (yalnızca belirli piyasa saatlerinde işlem gören, bu saatler dışında spot işlem yapılmayan) olarak ikiye ayrılabilir. İşlem saatlerindeki bu farklılık, fiyatların nasıl temin edildiğini ve sürdürüldüğünü temelden belirler.

7/24 varlıklar (örn. BTC) için, CEX'lerden, DEX'lerden veya güvenilir oracle hizmetlerinden veri toplanarak sürekli olarak görece istikrarlı fiyatlar elde edilebilir.

7/24 olmayan varlıklar (örn. hisse senetleri) için, yeterli likidite ve güvenilir harici piyasa fiyatları yalnızca resmi işlem saatlerinde mevcuttur. Bu tür varlıkların HIP-3 üzerinde sürekli işlem görmesini sağlamak için, piyasa dışı saatlerde ayrı bir fiyatlandırma mekanizması kullanılması gerekmektedir.

trade.xyz üzerindeki hisse senedi sürekli sözleşme piyasalarını örnek olarak ele alalım:

• Piyasa saatlerinde, Pyth gibi harici oracle hizmetleri tarafından istikrarlı oracle fiyatları sağlanmaktadır.
• Piyasa dışı saatlerde, fiyatlar varlığın son kapanış fiyatı temel alınarak, emir defterindeki iç alım/satım baskısıyla birleştirilerek ayarlanmaktadır. Mark fiyatı, son kapanış fiyatının ±1 / maks_kaldıraç oranında dalgalanmakla sınırlandırılmıştır (örn. Tesla: 10x kaldıraç → ±%10).

2. Stres Altında Piyasa Ödeme Gücü

Hyperliquid, piyasa ödeme gücünü korumak için tasfiye ve ADL (otomatik kaldıraç azaltma) olmak üzere iki mekanizma benimser. HIP-3 kapsamında hem tasfiye hem de ADL büyük ölçüde HyperCore'un tasarımını takip eder. Temel fark, protokol düzeyindeki bir kısıtlamadan kaynaklanmaktadır: Protokol kasası olarak görev yapan HLP (Hyperliquidity Provider), HIP-3 piyasalarında riskli pozisyonları devralamaz. Sonuç olarak, HyperCore'da piyasa tasfiyesi ile ADL arasındaki pozisyonları emebilen ara kasa tamponu HIP-3'te mevcut değildir.

Zorlu piyasa koşullarında bu tasfiyeden ADL'ye geçiş yolunun önemi göz önüne alındığında, aşağıda tasfiye ve ADL'yi ayrıntılı olarak inceliyoruz. Burada ele alınan tüm ödeme gücü mekanizmaları, HIP-3 piyasalarında şu anda desteklenen tek marj modu olan izole marjı varsaymaktadır.

a) Tasfiye

Tasfiye, pozisyonun net değeri (izole pozisyon değeri) bakım marjı gereksinimini karşılamaya yetmediğinde tetiklenir ve pozisyon tasfiye edilebilir hale gelir. Tasfiyeyle ilgili tüm kontroller, belirli bir yürütme fiyatına değil, mark fiyatına dayalı olarak gerçekleştirilir.

Tasfiye fiyatı formülü aşağıdaki şekilde tanımlanmaktadır:

Burada:

• side: uzun pozisyonlar için 1, kısa pozisyonlar için -1
• l, bakım marjı oranıdır

MAINTENANCE_LEVERAGE değeri, pozisyona karşılık gelen marj kademesiyle belirlenir. Bu kademeden bakım marjı oranı mmr elde edilir:

Marj kademeleri yapılandırıldığında, tasfiye fiyatındaki pozisyonun nominal değerine karşılık gelen kademenin mmr'sini uygulayın.

• margin_available (izole): izole_marj - gerekli_bakım_marjı

Bir pozisyon tasfiye edilebilir hale geldiğinde, sistem önce onu emir defterindeki piyasa emirleri aracılığıyla kapatmaya çalışır. Yürütme başarılı biçimde riski güvenli sınırların içine çekerse, kalan marjın tamamı yatırımcıya iade edilir.

Ancak yetersiz emir defteri derinliği veya fiyat boşlukları durumlarında, gerçek ortalama yürütme fiyatı mark fiyatından önemli ölçüde kötü olabilir ve bu durum "tasfiye açığına" yol açabilir.

İzole pozisyon değeri, mevcut mark fiyatı üzerinden bir izole pozisyonun net değerini ifade eder; gerçekleşmemiş kâr/zarar hesaba katıldıktan sonra bu pozisyona tahsis edilen marjı temsil eder.

b) ADL (Otomatik Kaldıraç Azaltma)

Aşırı senaryolarda ADL (otomatik kaldıraç azaltma) mekanizması son güvence olarak devreye girer.

ADL, bir izole pozisyon değerinin negatife dönmesi durumunda tetiklenir. Sistem kârlı karşı tarafları kâr ve kaldıraç oranına göre sıralar, ardından bu pozisyonları önceki mark fiyatı üzerinden (ADL tetiklenmeden önce kaydedilen önceki mark fiyatı) zorla azaltır ya da kapatır. Kazanan tarafın kârlarını açığı telafi etmek için kullanarak protokol ödeme gücünü korur ve kötü borç oluşumunu engeller.

Sıralama endeksi şu şekilde hesaplanır:

Burada notional_position, mevcut mark fiyatında pozisyonun mutlak piyasa değerini ifade eder; |pozisyon_büyüklüğü| × mark_fiyatı olarak hesaplanır. account_value, mark fiyatındaki hesap özkaynaklarını, yani teminat değeri artı gerçekleşmemiş kâr/zararı ifade eder.

Örnek:

• ADL tetiklenmeden önce sistemin mark fiyatı = 3.000.
• setOracle kısıtlamaları nedeniyle yeni mark fiyatı yalnızca 2.970 (−%1) olarak güncellenebilir.
• Ancak emir defterinin alış tarafı oldukça sığdır. Tasfiye piyasa emirleri deftere isabet ettikten sonra, gerçek ortalama yürütme fiyatı = 2.910 (3.000'e göre −%3) olur.
• Uzun pozisyonlardaki kayıplar 2.910 üzerinden kapatılır; bu durum izole pozisyon değerini sıfırın altına düşürerek açık yaratabilir ve ADL'yi tetikler.
• ADL daha sonra karşı taraftaki (kârlı kısa) pozisyonları seçer ve bunları zorla önceki mark fiyatı = 3.000 üzerinden azaltır/kapatır; böylece açığı "kazanan tarafın pasif olarak daha az kazanması" biçimine dönüştürür.

0x2 Geliştirici Risk Ortamı

HIP-3 kapsamında risk, geliştiriciler için artık soyut ya da tamamen teorik değildir. Stake ve doğrulayıcı tarafından yönetilen kesme (slashing) mekanizması aracılığıyla, operasyonel başarısızlıklar ve yanlış yapılandırmalar doğrudan ekonomik yaptırımlara dönüşebilir. Bu nedenle, kesmenin nasıl tetiklendiğini ve hangi tür geliştirici davranışlarının buna yol açabileceğini anlamak, geliştiricinin risk modelinin merkezine yerleşmektedir. Buna göre bu bölüm, önce hesap verebilirlik çerçevesi olarak kesme mekanizmasını açıklamakta, ardından HIP-3 kapsamındaki iki birincil geliştirici riski kaynağını incelemektedir.

0x2.1 Kesme Mekanizması ve Hesap Verebilirlik

HIP-3, hesap verebilirliği stake ve doğrulayıcı tarafından yönetilen kesme aracılığıyla uygular. Kesme kesinlikle sonuç odaklıdır. Hyperliquid, kötü niyetli davranış, operasyonel hatalar, özel anahtar ele geçirilmesi ya da üçüncü taraf bağımlılık hatası arasında ayrım yapmaz.

Stake gereksinimi: Ana ağda, geliştiricilerin 500.000 HYPE stake etmesi gerekir. Bir geliştirici tüm piyasalarını durdursa bile, 30 gün boyunca bu gereksinimi karşılamaya devam etmesi gerekir (işlemler durdurulduğunda sorumluluk hemen ortadan kalkmaz).

Bir geliştiricinin eylemleri geçersiz durum, uzun süreli çevrimdışılık veya önemli performans düşüşüne yol açarsa kesme tetiklenebilir. Ciddiyete bağlı olarak kesme, kısmi stake azaltımından tam stake yakımına kadar uzanabilir. Bu tasarım, geliştiricileri piyasalarının tüm çalışma zamanı davranışından ekonomik olarak sorumlu kılar.

Kesme yüzdesi, aşağıdaki referans üst sınırlar göz önünde bulundurularak doğrulayıcı oylamasıyla belirlenir:

• Geçersiz durum / uzun süreli çevrimdışılık: %100'e kadar
• Kısa süreli çevrimdışılık: %50'ye kadar
• Performans düşüşü: %20'ye kadar

Kesilen tokenlar yakılır, yeniden dağıtılmaz.

HIP-3 kapsamında geliştirici riski öncelikle iki kaynaktan kaynaklanmaktadır: dahili parametre yanlış yapılandırması ve harici oracle bağımlılıkları. Aşağıdaki bölümler bu iki kaynağı ayrıntılı olarak incelemekte ve bunların nasıl kesme sonuçlarına dönüşebileceğini açıklamaktadır.

0x2.2 Dahili Parametre Yanlış Yapılandırmasından Kaynaklanan Riskler

Yanlış yapılandırma riskleri arasında düşük likidite piyasalarında aşırı kaldıraç, uygunsuz marj tablosu tasarımı, çok sayıda pozisyonu tasfiye edilebilir hale getiren ani parametre değişiklikleri ve işlemleri durdurma gibi acil durum kontrollerinin uygunsuz kullanımı sayılabilir.

Bu riskler büyük ölçüde belirleyici ve önlenebilir niteliktedir. Yeterli özen, inceleme ve operasyonel disiplinle dahili yapılandırma hatalarının büyük çoğunluğundan kaçınılabilir. Önemli olmakla birlikte, HIP-3 kapsamındaki en yapısal açıdan zorlu riskler bunlar değildir.

1. setOracle

Oracle fiyatları genellikle geliştiricinin aktarıcı sunucularından gelir; bu durum merkezileşme riski yaratır. Özel anahtarın sızdırılması veya aktarıcının DDoS saldırısına uğraması halinde, piyasanın oracle fiyatı kötü niyetle manipüle edilebilir ya da uzun süre sapmalı kalabilir.

2. haltTrading

Geliştirici, haltTrading aracılığıyla piyasadaki tüm emirleri iptal edebilir ve pozisyonları mevcut mark fiyatı üzerinden kapatabilir. Bu işlem temkinli kullanılmalıdır. Örneğin, piyasanın bir saldırgan tarafından kötü niyetle manipüle edildiği tespit edilirse ve mark fiyatı üzerinden kapatmak için haltTrading çağrılırsa, bu durum saldırganın gerçekleşmemiş kârını doğrudan realize edebilir (saldırganın normalde yeterli karşı emir bulmakta zorlanabileceği durumlarda) ve kötü borca da yol açabilir.

3. setMarginTableIds ve InsertMarginTable

• InsertMarginTable: bir varlık sınıfı için marj gereksinimlerini ve maksimum kaldıracı belirterek yeni bir marj tablosu tanımlar.
• setMarginTableIds: bir piyasayı belirtilen marginTableId'ye bağlar.

Düşük likidite / yetersiz piyasa yapıcılığına sahip bir piyasada, maksimum kaldıracın çok yüksek ayarlanması ADL tetiklenme olasılığını artırır.

marginTableId'nin aniden değiştirilmesi, kullanıcı pozisyonlarının bakım marjı oranını değiştirmekle eşdeğerdir; bu durum aynı anda birçok hesabı güvenli durumdan tasfiye edilebilir duruma getirebilir ve zincirleme tasfiyeleri tetikleyebilir.

4. setMarginModes

HIP-3 şu anda yalnızca izole marjı desteklemekte olup gelecekte çapraz marjı destekleyebilir. Hem yüksek hem de düşük likidite piyasalarına ev sahipliği yapan bir DEX içinde çapraz marj, likit olmayan piyasalardaki kayıpların likit piyasalara yayılmasına neden olarak risk bulaşmasına zemin hazırlayabilir. Bu nedenle, resmi ekip olgun bir çözüm sunana kadar geliştiricilerin çapraz marj uygulamasına geçmesi önerilmez.

0x2.3 Harici Oracle Bağımlılıklarından Kaynaklanan Riskler

7/24 varlıklar için birincil risk, harici oracle hizmetlerinin doğruluğu ve istikrarı ile daha önce ele alınan aktarıcı sunucularının merkezileşme risklerinde yatmaktadır. Bu harici bağımlılıklardaki her türlü kesinti, gecikme veya manipülasyon, fiyatlandırma bütünlüğünü ve aşağı yönlü risk kontrollerini doğrudan etkileyebilir.

7/24 olmayan varlıklar için risk yüzeyi çok daha geniştir ve ağırlıklı olarak işlem dışı saatlerde oracle fiyatlarının nasıl elde edildiğine veya hesaplandığına yoğunlaşmaktadır.

trade.xyz örneğinden yola çıkarsak, piyasa dışı dönemlerde fiyatlar en son mevcut harici oracle fiyatı ile iç piyasa fiyatlarının kombinasyonundan türetilmektedir. Hafta sonları hisse senedi sürekli sözleşme piyasaları çoğunlukla ciddi ölçüde azalmış likiditeyle karşı karşıya kalır; emir defterleri incelir, piyasa yapıcılar fiyat tekliflerini azaltır ve harici bir oracle fiyatı çapalama sağlamak için mevcut olmaz. Fiyat hareketine sıkı bir üst sınır uygulanmasına (örn. 1/maks_kaldıraç) karşın, bu kısıtlama düşük volatiliteli varlıklar için hâlâ çok gevşek kalabilir. Bu aralık içindeki fiyat hareketleri büyük ölçekli tasfiyeleri hatta ADL olaylarını tetikleyebilir.

14 Aralık 2025'te, trade.xyz üzerindeki XYZ100-USDC piyasası (NASDAQ-100'ü takip eden bir sürekli sözleşme) manipüle edildi. Bir saldırgan 398 XYZ100 (yaklaşık 10 milyon USDC nominal değerde) kısa pozisyon açarak ciddi fiyat sapmasına neden oldu. Çok sayıda uzun pozisyon tasfiye edildi ve bu tasfiyeler fiyatları daha da aşağı itti; sonuç olarak uzun tarafta yaklaşık 13 milyon USDC tutarında tasfiye gerçekleşti.

Öte yandan, işlem dışı saatlerde sürekli ve harici olarak çapalanmış bir oracle fiyatının yokluğu, piyasaları "son harici fiyat + iç emir defteri" tarafından oluşturulan kısıtlanmış bir iç fiyatlandırma bandına (örn. trade.xyz maksimum dalgalanmayı 1/maks_kaldıraç ile sınırlar) güvenmeye zorlar.

En kritik risk, piyasa yeniden açılış geçişinde ortaya çıkar. Harici piyasalar aniden net ve yetkili bir referans fiyatı sunabilir. Bu fiyat, işlem dışı saatlerdeki iç fiyatlandırmaya kıyasla önemli bir boşluk sergilediğinde, sistem iki olumsuz seçenekle karşı karşıya kalır: ya fiyatlar sınırlandırılmış kalır ve harici adil değerle işlem yapılabilir fiyatlar arasında ciddi bir sapma oluşur ya da sistem hızla harici çapalamaya geri döner ve ani yeniden fiyatlandırmayı tetikler. Her iki senaryo da tasfiye baskısını kısa bir zaman dilimine yoğunlaştırabilir ve aşırı durumlarda ADL olaylarında ani artışa yol açabilir.

0x3 Geliştirici Risk Kontrolleri

Yapılandırma disiplini tek başına riski ortadan kaldıramaz. En etkili azaltma stratejileri, oracle bağımlılığı hatalarına maruziyeti azaltmaya odaklanır.

0x3.1 Kararlı Oracle'lar Seçmek

Hisse senetleri gibi 7/24 işlem görmeyen varlıklar için birincil zorluk, piyasa dışı saatlerde fiyatlandırma konusunda yatmaktadır. Bu dönemlerde kararlı ve harici olarak çapalanmış fiyat referansları kıt olduğundan, piyasalar ince likidite altında manipülasyona veya endojen sapmaya daha yatkın hale gelir.

Şu anda sektördeki yaklaşımlar genel olarak iki yönde yoğunlaşmaktadır:

• Piyasa dışı saatlerde oracle güncellemelerini askıya almak ve işlemleri kısıtlamak. Örneğin Lighter protokolü, dayanak piyasa kapalıyken yalnızca pozisyon azaltma emirlerini kabul etmektedir. Ostium gibi protokoller, piyasa dışı saatlerde maksimum kaldıracı daha da düşürür ve yeni limitleri aşan pozisyonları zorla tasfiye eder.
• Trade.xyz'de görüldüğü üzere harici verinin mevcut olmadığı durumlarda iç likidite ve fiyatlandırma algoritmalarına dayanan "iç fiyatlandırma" mekanizması benimsemek.

Bu iki yaklaşım, güvenlik ile kullanıcı deneyimi arasındaki temel bir ödünleşimi yansıtmaktadır. Birinci yaklaşım sıkı risk kontrollerini ön plana alır, ancak işlem sürekliliğini ve kullanıcı deneyimini önemli ölçüde bozar. İkinci yaklaşım sürekli işlemi korur; ancak harici referansların yokluğu nedeniyle iç fiyatların varlığın temel değerinden sapma riskini artırır.

Piyasa dışı dönemlerde protokol fiyatlandırması, tamamen salt iç fiyata dönüşmekten kaçınmalıdır. Bunun yerine harici referans çapaları sunmak, sapma ve boşluk risklerini azaltabilir. Olası referanslar şunlardır:

• Blue Ocean ATS. Mesai sonrası/gecelik bir işlem platformu olarak, kapanış dönemlerinde belirli düzeyde sürekli fiyat referansı sağlayabilir ("son kapanış"tan daha güncel), kapanış dönemi oracle fiyatı oluşturmaya yardımcı olabilir ya da sapma için izleme tabanı işlevi görebilir.
• IG Hafta Sonu CFD Kotasyonları. Hafta sonu CFD kotasyonları, "hafta sonu piyasa beklentilerini yansıtan alternatif bir fiyat sinyali" sağlayabilir; kapanış dönemlerinde harici bir çapa veya izleme karşılaştırması olarak kullanılmaya uygundur ve "açılış boşluğunun" muhtemel yönünü ve büyüklüğünü önceden tespit etmeye yardımcı olabilir.

Bu kaynakların ortak özelliği, piyasa dışı saatlerde fiyat sinyali sunabilmeleridir. Ancak dayanak spot piyasayla aynı piyasa yapısını paylaşmadıklarından, koşulsuz alternatifler olarak değil, çapa, referans veya erken uyarı sinyali olarak kullanılmaları daha uygundur.

0x3.2 Fiyat Doğrulama

HIP-3 kapsamında oracle fiyatları geliştirici tarafından işletilen aktarıcı sunucularından temin edilmekte; bu durum merkezileşme endişelerini beraberinde getirmektedir. Bunu azaltmak amacıyla geliştiricilerin, herhangi bir kullanıcı veya kurumun fiyatlandırmanın doğruluğunu ve adaletini zincir dışında doğrulamasına olanak tanıyan bir fiyat doğrulama çerçevesi uygulamaları teşvik edilmektedir; bu yaklaşım, fiyatları veri kaynakları ve kriptografik kanıtlarla bir araya getiren RedStone'a benzer.

1. Veri Şeffaflığı

• Algoritma spesifikasyonu: fiyatlandırma algoritmalarını ve hesaplama mantığını kamuya açık biçimde duyurun.
• Veri kaynağı listesi: tüm kaynaklar kamuya açık, geliştirici manipülasyonundan muaf olmalı; ayrıntılı arayüzler ve parametrelerle belgelenmelidir.
• Fiyat gönderim kuralları: setOracle için izinler, tetikleyici koşullar, güncelleme sıklığı ve volatilite kısıtlamaları.

2. Fiyat Kanıtları

Her setOracle çağrısı için aşağıdakileri içeren bir kanıt oluşturun:

• Girdiler: örnekleme zaman damgasında her veri kaynağından alınan ham (veya normalleştirilmiş) yanıtlar.
• Hesaplama: her hesaplama adımında yeniden üretilebilir ara değerler.
• Çıktılar: zincir üstüne gönderilen oracle fiyatı.

Her kanıt bir proofHash'e serileştirilir ve ardından oracleUpdater tarafından imzalanır.

3. Zincir Üstü Taahhütler

• Bir Merkle ağacında sıralı proofHash girişleri listesini sürdürün.
• Düzenli aralıklarla (örn. saatlik veya günlük) MerkleRoot'u zincir üstünde yayınlayın.

4. Doğrulama

• Kullanıcıların bir zaman aralığı veya setOracle işlem hash'i girebildiği açık kaynaklı araçlar ya da bir web sayfası sağlayın.
• İmzaları, zaman damgalarını ve MerkleRoot'u vb. doğrulayın.
• Karşılaştırma için oracle fiyatlarını kamuya açık algoritmayı kullanarak yeniden hesaplayın.

0x3.3 Risk İzleme

Fiyat doğrulama, setOracle'ı yeniden hesaplanabilir ve denetlenebilir kılarak fiyat beslemelerinin güvenilir olup olmadığını ortaya koyar. Ancak canlı piyasanın bozulmasına karşı koruma sağlayamaz. Besleme kesintileri, fiyat sapmaları ve likidite bozulması; yüksek açık pozisyonla (OI) birleştiğinde yerel anormallikleri kolayca zincirleme tasfiyeler veya hatta ADL olayları gibi sistemik risklere dönüştürebilir.

Bu nedenle piyasa anormallikleri mümkün olan en kısa sürede tespit edilmeli ve gözlemlenebilir sinyallere dönüştürülmeli; riskin yönetilebilir sınırlar içinde tutulması için bir zaman penceresi içinde müdahale edilmelidir.

İzlemeyi parçalı değil eyleme geçirilebilir kılmak için sinyalleri üç katmana ayırıyoruz; her biri farklı bir hata moduna ve müdahale önceliğine karşılık gelir.

• Fiyat tarafı izleme, risk kontrollerini kaynağında geçersiz kılabilecek oracle besleme hatalarını ve sapmaları tespit eder; bu nedenle en yüksek öncelik olarak ele alınır ve genellikle aktarıcı yük devretme, açık pozisyon sınırlamaları ve kaldıraç azaltmaları aracılığıyla giderilir.
• Emir defteri tarafı izleme, tasfiye kaymasını ve açık riskini artıran likidite çekilmesini ve sahte derinliği yakalar; bu nedenle müdahaleler kırılganlık arttığında artımlı maruziyeti sınırlamaya ve zorla kaldıraç azaltmaya odaklanır.
• Pozisyon tarafı izleme, piyasaları zincirleme olaylara karşı savunmasız kılan hızlı açık pozisyon birikimini ve tek taraflı yoğunlaşmayı takip eder; genel olarak fiyat ve likidite sinyallerinden daha düşük önceliklidir ve öncelikle daha sıkı sınırlar ve yükseltilmiş uyarılar için bilgi sağlayan erken uyarı katmanı olarak hizmet eder.

Aşağıdaki bölümler her katmanı sırasıyla, ilgili izleme noktaları ve önerilen eylemlerle birlikte ayrıntılı olarak ele almaktadır.

1. Fiyat Tarafı İzleme

a) Oracle Besleme Hatası

Metrikler:

• Beslemanin durma noktasına gelip gelmediğini değerlendirmek için zincir üstü gözlemlenebilirleri kullanın:

Eşikler:

• Seviye 1: ( ∆t > 5s ) — aktarıcı süreci durmuş veya bloke olmuş olabilir
• Seviye 2: ( ∆t > 15s ) — zincir üstü fiyatlar ciddi biçimde sapmış ve giderek piyasa odaklı hale gelmiş olabilir

Eylemler:

• Seviye 1: aktarıcı sağlık kontrolleri gerçekleştirin, yedek aktarıcılara geçin ve sağlık tanılama bilgileriyle uyarı verin
• Seviye 2: OI sınırını azaltmak için setOpenInterestCaps çağrısı yapın

b) Fiyat Sapması

Metrikler:

• A sinyali (d1): mark fiyatı ile oracle fiyatı arasındaki sapma.

• B sinyali (d2): emir defteri orta fiyatı ile oracle fiyatı arasındaki sapma.

• C sinyali (d3): mark fiyatı ile orta fiyat arasındaki sapma.

• D sinyali (ext_diff): oracle fiyatı ile harici referans fiyatı arasındaki sapma.

Eşik Mantığı:

• Seviye 1: A, B, D'den en az 2'si eşikleri aşıyor.
• Seviye 2: A, B, C, D'den en az 3'ü X saniye boyunca eşikleri aşıyor.

Eylemler:

• Seviye 1: setOpenInterestCaps aracılığıyla OI sınırını azaltın.
• Seviye 2: maksimum kaldıracı kademeli olarak azaltmak için marj tablolarını kademeli biçimde güncelleyin ve aktarıcılarda sınırlama mekanizmalarını etkinleştirin.
• Seviye 3: Seviye 2 koşulları altında kalıcı uyarılar. Geliştirici ardından haltTrading'i çağırıp çağırmamayı değerlendirir.

2. Emir Defteri Tarafı İzleme

a) Likidite Çekilmesi

Metrikler:

• depth_band(±x%): orta fiyatın ±x% içinde mevcut emir defteri likiditesi.
• spread = bestAsk - bestBid: spread genişlemesini ölçmek için fiyat aralığı.
• aggressiveVolume_Δt: Δt içindeki taker hacmi (işlem tarafına göre toplanmış).
• impact_ratio: piyasa kırılganlığı göstergesi (yüksek değerler daha büyük fiyat etkisi savunmasızlığına işaret eder).

Risk Örüntüleri:

• depth_band azalırken spread ve impact_ratio artıyor.

Eylemler:

• Seviye 1: artımlı pozisyonları sınırlandırmak için setOpenInterestCaps aracılığıyla OI sınırı = mevcut OI olarak ayarlayın.
• Seviye 2: setMarginTableIds aracılığıyla zorla kaldıraç azaltma yapın; yüksek kaldıraçlı, yüksek riskli pozisyonları tasfiye edin.

b) Sahte Likidite

Risk Örüntüleri:

• depth_band'de ani artış ve ardından kısa bir zaman penceresi içinde çöküş.

Eylemler:

• Seviye 1: OI sınırı = mevcut OI olarak ayarlamak için setOpenInterestCaps çağrısı yapın.
• Seviye 2: ciddi sapmayla birleşirse, piyasayı durdurmeyi değerlendirin.

3. Pozisyon Tarafı İzleme

Pozisyon tarafı izleme, fiyat yönünü tahmin etmeye çalışmaz. Bunun yerine dengeli işlem aktivitesinden tek taraflı pozisyon birikimine geçişleri tespit eder. OI hızla biriktiğinde, pozisyonlar yüksek oranda yoğunlaştığında ve çoğunluk tarafı kâr/zararı uç noktalara ulaştığında, küçük bir dış şok bile tasfiye zincirleri veya ADL olaylarını tetikleyebilir.

Sonuç olarak, pozisyon tarafı eylemler genellikle fiyat ve emir defteri tarafı müdahalelerden daha düşük önceliğe sahiptir.

a) Aşırı Kısa Vadeli OI

Metrikler:

• OI_notional: açık pozisyon nominal değeri.
• Volume_24h_notional: 24 saatlik nominal hacim.

Hızla artan bir oran, aktif cirodan spekülatif pozisyon birikimine geçişi gösterir ve çoğunlukla keskin volatiliteden önce gelir.

Eylemler:

• Seviye 1: eşikler aşıldığında uyarı tetikleyin.

b) Çoğunluk Tarafı Kâr/Zarar

Çoğunluk tarafı, gözlem penceresi içinde daha fazla pozisyon sahibine sahip olan tarafı (Uzun veya Kısa) ifade eder.

Metrikler:

• avgEntry_major: çoğunluk tarafı pozisyonların ortalama giriş fiyatı.
• size_major: çoğunluk tarafının toplam pozisyon büyüklüğü.
• equity_major: çoğunluk tarafının toplam özkaynak değeri.

Çoğunluk tarafı kâr/zarar ve oranı şu şekilde tanımlanır:

Eylemler:

• Seviye 1: eşik ihlalinde uyarı verin.
• Seviye 2: devam ederse OI sınırını azaltmak için setOpenInterestCaps çağrısını değerlendirin.

0x4 Sonuç

HIP-3'ün temel anlatısı açıktır. Piyasa listelemeleri, birkaç kişinin kontrolündeki isteğe bağlı bir süreçten, gereksinimlerin karşılandıktan sonra herhangi bir nitelikli geliştiricinin çağırabileceği protokol düzeyinde bir kapasiteye dönüştürülür. Stake ederek geliştiriciler, HyperCore üzerinde kendi perp DEX'lerini başlatabilir, başlangıçta ücretsiz olarak bir dizi piyasayı listeleyebilir ve açık artırma yoluyla ek slot edinebilir. Bu durum, piyasa genişlemesini onay bekleme sürecinden kurala dayalı, izinsiz ölçeklendirmeye doğru kaydırır.

Aynı derecede açık olan husus, HIP-3'ün riski ortadan kaldırmadığıdır. Riski yeniden konumlandırır ve yeniden biçimlendirir. Daha önce platform düzeyindeki risk kontrolleri tarafından üstlenilen sorumluluklar artık büyük ölçüde geliştiriciler tarafından, onların girdileri ve operasyonel kaliteleri aracılığıyla taşınmaktadır. Bu sorumluluklar arasında setOracle aracılığıyla oracle fiyatlandırması ve güncelleme kadansı, markPx'in seçimi ve kısıtlamaları, marj tabloları aracılığıyla kademeli kaldıraç tasarımı, 7/24 olmayan varlıklar için piyasa dışı fiyatlandırma aralıkları ve kayıpları içerebilecek ya da artırabilecek haltTrading gibi güçlü kontroller yer almaktadır. İnce likidite altında yanlış yapılandırma veya operasyonel başarısızlık, tasfiye zincirlerine, boşluk kayıplarına ve nihayetinde ADL olaylarına dönüşebilir. Soru artık ''Bir piyasa listelenebilir mi?'' değil, ''Listelendikten sonra istikrarlı kalabilir mi?'' olarak değişmiştir.

Protokol düzeyinde Hyperliquid, bu risk yeniden dağıtımını izinleri hesap verebilir izinlere dönüştürerek ele almaktadır. Doğrulayıcı tarafından yönetilen kesmeyle birleşen stake, geliştirici yanlış operasyonu için net ekonomik sonuçlar ortaya koyar. Fiyatlandırma ve kaldıraçtaki kısıtlamalar; sınırlamalar, güncelleme aralıkları, volatilite limitleri ve izole marj gereksinimleri dahil olmak üzere, en tehlikeli kuyruk risklerini yönetilebilir sınırlar içinde tutmayı hedefler. Bu çerçevede HIP-3'ün değer önerisi netleşir: açıklık yoluyla ölçeklendirme, kısıtlamalar yoluyla güvenlik ve doğrulanabilirlik ve hesap verebilirlik yoluyla uzun vadeli sürdürülebilirlik.

HIP-3, listeleri daha özgür yapmaz. Onları daha standart, devreye alınabilir, işletilebilir ve kesilebilir hale getirir. Bu standardizasyonun ölçekli olarak çalışıp çalışamayacağı, nihayetinde oracle tasarımının, kaldıraç ve risk parametrelerinin ve çalışma zamanı izlemenin gerçek dünya kalitesine bağlıdır. HIP-3 üzerine piyasa erişim kuralları, parametre şablonları, uyarı sistemleri veya acil durum iş akışları tasarlıyorsanız ya da denetim ve sürekli güvenlik desteğine ihtiyaç duyuyorsanız, BlockSec ile [email protected] adresinden iletişime geçmekten çekinmeyin.

Referans

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

BlockSec Hakkında

BlockSec, tam yığın blok zinciri güvenliği ve kripto uyum sağlayıcısıdır. Müşterilerin kod denetimi yapmasına (akıllı sözleşmeler, blok zincirleri ve cüzdanlar dahil), saldırıları gerçek zamanlı olarak engellenmesine, olayları analiz etmesine, yasa dışı fonları takip etmesine ve protokollerin ile platformların tüm yaşam döngüsü boyunca AML/CFT yükümlülüklerini yerine getirmesine yardımcı olan ürün ve hizmetler geliştiriyoruz.

BlockSec, saygın konferanslarda birden fazla blok zinciri güvenliği makalesi yayımlamış, DeFi uygulamalarına yönelik çeşitli sıfır gün saldırılarını bildirmiş, 20 milyon doların üzerinde değeri kurtarmak amacıyla birden fazla saldırıyı engellemiş ve milyarlarca dolarlık kripto para birimini güvence altına almıştır.

• Resmi web sitesi: https://blocksec.com/

• Resmi Twitter hesabı: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Denetim Hizmeti : Talep gönderin

• 🔗 Phalcon Güvenlik Uygulaması: Demo rezervasyonu yapın

• 🔗 Phalcon Uyum