HIP-3: perpetual distribuiti dai builder

Il protocollo Hyperliquid supporta i perp distribuiti dai builder in modo permissionless (HIP-3), una tappa fondamentale verso la piena decentralizzazione del processo di listing dei perp.

Il deployer di un mercato perp è responsabile di

1. Definizione del mercato, inclusi la definizione dell'oracle e le specifiche del contratto
2. Gestione del mercato, inclusi l'impostazione dei prezzi dell'oracle, i limiti di leva e il regolamento del mercato se necessario

HIP-3 eredita lo stack HyperCore, inclusi la gestione del margine ad alte prestazioni e i book degli ordini. Ad esempio, l'API per negoziare i perp HIP-3 è unificata con le altre azioni HyperCore. Per negoziare gli asset HIP-3 è sufficiente impostare l'ID dell'asset utilizzando lo schema qui.

Specifiche

1. Il requisito di staking per mainnet sarà di 500k HYPE. Si prevede che tale requisito diminuisca nel tempo con il maturare dell'infrastruttura. Qualsiasi importo in staking superiore al requisito più recente può essere rimosso dallo staking. Il requisito di staking viene mantenuto per un minimo di 183 giorni dopo il deployment del dex.
2. Qualsiasi deployer che soddisfi il requisito di staking può distribuire un perp dex. Come promemoria, ciascun perp dex dispone di gestione del margine, book degli ordini e impostazioni del deployer indipendenti. Un futuro aggiornamento potrebbe supportare più deployment di dex che condividono lo stesso deployer e requisito di staking.
3. Qualsiasi asset di quotazione può essere utilizzato come asset collaterale per un dex. Come promemoria, gli asset che non soddisfano i requisiti degli asset di quotazione permissionless perderanno lo status di asset di quotazione in base al voto on-chain dei validatori. Tale voto disabiliterebbe anche i perp dex che utilizzano questo asset come collaterale. Una disabilitazione dell'asset di quotazione avviata dal deployer non disabilita i perp dex corrispondenti.
4. I deployer HIP-3 non sono soggetti a slashing legato agli asset di quotazione. In un futuro aggiornamento, i dex con asset di quotazione disabilitati supporterebbero la migrazione a un nuovo token collaterale. Non è previsto che ciò avvenga su mainnet, poiché i deployer di token di quotazione hanno condizioni di staking e slashing distinte. In sintesi, la scelta dell'asset di quotazione è rilevante per le commissioni di trading e per considerazioni di prodotto, ma non rappresenta un rischio esistenziale per i deployer HIP-3.
5. I primi 3 asset distribuiti in qualsiasi perp dex non richiedono la partecipazione all'asta. Gli asset aggiuntivi passano attraverso un'asta olandese con gli stessi iperparametri (inclusi frequenza e prezzo minimo) dell'asta HIP-1. L'asta HIP-3 per i perp aggiuntivi è condivisa tra tutti i perp dex. Futuri aggiornamenti supporteranno una migliore ergonomia nella prenotazione degli asset per deployment futuri sensibili al fattore tempo. I deployer ottengono inoltre 7 + 0.2 * n_auction_deployments deployment di riserva che possono essere utilizzati al prezzo d'asta corrente, ma aggirando il timer dell'asta.
6. I mercati HIP-3 incorporano le consuete fonti di sconto sulle commissioni di trading, inclusi sconti sullo staking, ricompense per i referral e sconto sul collaterale allineato. I deployer HIP-3 possono configurare una quota di commissioni aggiuntiva compresa tra 0-300% (0-100% per la growth mode). Se la quota supera il 100%, anche la commissione di protocollo viene aumentata fino a eguagliare la commissione del deployer.
7. Il collaterale in stablecoin allineate riceverà automaticamente commissioni ridotte una volta implementata la condizione di allineamento (che viene aggiornata in base al feedback di utenti e deployer).

Regolamento

Il deployer può regolare un asset utilizzando l'azione haltTrading. Questa annulla tutti gli ordini e regola le posizioni al mark price corrente. La stessa azione può essere utilizzata per riprendere il trading, riutilizzando di fatto l'asset. Può essere impiegata per quotare contratti con scadenza senza partecipare all'asta di deployment per ogni nuovo contratto.

Una volta regolati tutti gli asset, lo stake richiesto del deployer può essere rimosso dallo staking.

Oracle

Sebbene l'oracle sia del tutto generale a livello di protocollo, i perp hanno il maggior senso matematico quando esiste un asset sottostante o un feed di dati ben definito, difficile da manipolare e dotato di rilevanza economica sottostante. La maggior parte degli indici di prezzo non è idonea come fonte oracle per i perp. I deployer devono valutare attentamente i casi limite prima di quotare i mercati, poiché sono soggetti a slashing per tutti i mercati quotati sul proprio DEX.

Slashing

Nota: in tutti gli utilizzi seguenti, per "slashing" si intende esclusivamente il contesto HIP-3.

Per garantire mercati di alta qualità e proteggere gli utenti, i deployer devono mantenere 500k HYPE in staking. In caso di gestione dolosa del mercato, i validatori hanno l'autorità di sottoporre a slashing lo stake del deployer mediante un voto ponderato per stake. Anche se il deployer ha rimosso lo staking e avviato un prelievo di staking, lo stake resta passibile di slashing durante la coda di unstaking di 7 giorni.

Sebbene lo slashing sia in ultima istanza deciso dal quorum dei validatori, le linee guida del protocollo sono state elaborate a partire da un'attenta analisi su testnet, dal feedback degli utenti e da quello dei deployer. Il principio guida è che lo slashing serve a prevenire comportamenti che compromettono la correttezza, la disponibilità o le prestazioni del protocollo. Una regola pratica utile è che qualsiasi comportamento passibile di slashing dovrebbe essere accompagnato da una correzione di bug nell'implementazione del protocollo. Pertanto, HIP-3 non dovrebbe richiedere lo slashing nel suo stato finale. Lo slashing resta tuttavia un importante meccanismo di sicurezza per un'introduzione pratica di questo ampio insieme di funzionalità.

Lo slashing è di natura tecnica e non distingue tra comportamento doloso e incompetenza. Analogamente, lo slashing non distingue tra

1. Un deployer che si discosta da una specifica di contratto ben progettata
2. Un deployer che segue fedelmente una specifica di contratto mal progettata
3. Un deployer le cui chiavi private sono compromesse

Il fattore determinante è l'effetto delle azioni del deployer sul protocollo. Si noti che eventuali bug individuati sono generosamente coperti dal programma bug bounty, a condizione che tali scoperte soddisfino i termini del programma, inclusa la divulgazione responsabile senza sfruttamento. Queste segnalazioni sono molto apprezzate.

Anche i tentativi di input dolosi da parte del deployer che non causano problemi al protocollo sono passibili di slashing. Analogamente, gli input che causano problemi al protocollo ma non sono irregolari non sono passibili di slashing. In particolare, i bug durante il funzionamento normale non correlati agli input del deployer non rientrano nell'ambito dello slashing. L'interpretazione degli input "irregolari" è determinata dal voto dei validatori e include gli input che sfruttano casi limite o scappatoie che aggirano i limiti del sistema. Tutte le transazioni del deployer sono on-chain e possono essere analizzate in modo indipendente da qualsiasi parte interessata.

Alcuni comportamenti dolosi sono validi per definizione del protocollo, ma scorretti secondo determinate interpretazioni soggettive. Il principio dello slashing stabilisce che il protocollo non debba intervenire su questioni soggettive. La motivazione è che, sebbene le blockchain proof-of-stake potrebbero effettuare un hard fork su transizioni di stato indesiderate, lo fanno molto raramente. La neutralità della piattaforma è una caratteristica estremamente importante da preservare. Analogamente, lo stake sottoposto a slashing del deployer viene bruciato invece di essere distribuito agli utenti interessati. Anche questo si basa sui principi del proof-of-stake e previene alcune forme di incentivi disallineati tra utenti e deployer. Sebbene il livello di protocollo non imponga irregolarità soggettive, possono farlo i livelli applicativi e sociali a valle. In ultima analisi, la reputazione del deployer e il suo successo futuro sono sempre in gioco.

L'importo sottoposto a slashing in un dato caso è in ultima istanza la mediana ponderata per stake dei voti dei validatori. Come indicazione generale, tuttavia, gli input irregolari che causano transizioni di stato non valide o un'interruzione prolungata della rete possono essere soggetti a slashing fino al 100%. Gli input irregolari che causano brevi interruzioni della rete possono essere parzialmente soggetti a slashing fino al 50%. Gli input non validi che causano degradazione della rete o problemi di prestazioni possono essere parzialmente soggetti a slashing fino al 20%.

Infine, le condizioni di slashing sono indipendenti dalla composizione degli staker. Pertanto, gli operatori LST dovrebbero valutare attentamente i deployer. Gli operatori LST dovrebbero inoltre comunicare in modo chiaro e accurato i rischi di slashing ai propri utenti. Un requisito di self-bonding per i deployer potrebbe risultare opportuno.

Nello scenario più probabile, lo slashing non si verifica mai su mainnet. Un ingente lavoro tecnico è stato dedicato a rendere HIP-3 un sistema autonomo e tecnicamente solido. Salvo problemi di implementazione, HIP-3 eredita le garanzie matematiche di solvibilità accuratamente progettate di Hyperliquid.

Margine incrociato

IMPORTANTE: l'attivazione del margine incrociato su un asset è irreversibile. I deployer devono valutare attentamente le condizioni riportate di seguito prima di attivarlo.

Nonostante la protezione a livello di sistema, gli utenti assumono comunque un rischio maggiore quando utilizzano il margine incrociato tra DEX con deployer diversi. Per proteggere meglio gli utenti, i validatori di mainnet imporranno che i deployer HIP-3 attivino il margine incrociato solo su asset che soddisfano standard di idoneità definiti, tra cui: liquidità osservabile sufficiente, una fonte oracle esterna affidabile e resilienza alla manipolazione dei prezzi. In particolare, ogni volta che `externalPerpPx` di un asset si muove di oltre il 50% rispetto al prezzo di inizio giornata, i validatori effettueranno una verifica per determinare se il deployer debba essere soggetto a slashing per manipolazione. Gli asset per cui sono previsti movimenti giornalieri del 50% più di una volta al mese non sono idonei al margine incrociato e sono soggetti a slashing del deployer.

Liquidatore di backstop

Ciascun DEX HIP-3 è associato a una strategia completamente on-chain all'indirizzo 0x400..00 + {dex_index} che rileva le posizioni liquidabili di backstop dal DEX HIP-3 designato. I liquidatori di backstop on-chain accettano solo asset con margine incrociato attivato, rendendo tali asset significativamente meno soggetti ad ADL in futuro durante eventi di elevata volatilità. Il liquidatore di backstop on-chain di ciascun DEX è un utente indipendente e ricorre all'ADL per garantire matematicamente la solvibilità del DEX.

Non è richiesta alcuna azione agli utenti. Una volta estesi, i liquidatori di backstop assorbiranno le posizioni sotto-collateralizzate evitando al contempo debiti inesigibili e riducendo la necessità di ADL.