HIP-1: standard dei token nativi

HIP-1 è uno standard per token fungibili a offerta limitata. Prevede inoltre book degli ordini spot on-chain tra coppie di token HIP-1.

Il mittente della transazione di genesis del token specificherà quanto segue:

1. name: leggibile, massimo 6 caratteri, senza vincoli di unicità.
2. weiDecimals: il tasso di conversione dall'unità intera minima del token a un numero in virgola mobile interpretabile dall'uomo. Ad esempio, ETH sulle reti EVM ha weiDecimals = 18 e BTC sulla rete Bitcoin ha weiDecimals = 8.
3. szDecimals: il numero minimo di decimali negoziabili sui book degli ordini spot. In altre parole, la dimensione del lotto del token su tutti i book degli ordini spot sarà 10 ** (weiDecimals - szDecimals). È richiesto che szDecimals + 5 <= weiDecimals.
4. maxSupply: l'offerta massima e iniziale. L'offerta può diminuire nel tempo a causa delle commissioni sui book degli ordini spot o di futuri meccanismi di burn.
5. initialWei: saldi di genesis facoltativi specificati dal mittente della transazione. Possono includere una tesoreria multisig, un conio iniziale del bridge, ecc.
6. anchorTokenWei: il mittente della transazione può specificare token HIP-1 esistenti che riceveranno saldi di genesis in modo proporzionale.
7. hyperliquidityInit: parametri per l'inizializzazione dell'Hyperliquidity per la coppia spot USDC. Per ulteriori dettagli, si veda la sezione HIP-2.

La transazione di deploy del token genererà un hash globalmente univoco con cui la logica di esecuzione indicizzerà il token.

Costo del gas per il deploy

Come tutte le transazioni, i costi del gas saranno in ultima istanza pagati nel token nativo Hyperliquid. Attualmente il seguente costo del gas è in HYPE.

1. Il costo del gas del deploy è determinato tramite un'asta olandese della durata di 31 ore. In questo periodo, il gas di deploy diminuisce linearmente da initial_price a 500 HYPE. Il prezzo iniziale è 500 HYPE se l'asta precedente non è andata a buon fine, altrimenti è il doppio dell'ultimo prezzo del gas.
2. La genesis per i detentori dell'anchor token esistente è proporzionale a balance - 1e-6 * anchorTokenMaxSupply al momento della genesis del token deployato. Se questo valore è negativo, non si ricevono token di genesis. In particolare, ciò significa che i detentori di genesis devono detenere almeno lo 0.0001% dell'offerta massima dell'anchor token al momento della genesis per essere inclusi nella genesis del token deployato.
3. Potenziale soluzione alternativa al vincolo (2): una piccola commissione iniziale di gas in USDC (valore da definire) per l'aggiornamento iniziale dello stato di ciascuna coppia (address, token), tramite trading o trasferimento. Ulteriori operazioni e trasferimenti verso ledger inizializzati sono esenti da gas nell'ambito delle consuete condizioni sul tasso di fill di Hyperliquid.

DETTAGLI IMPORTANTI SUL GAS:

L'unica fase del processo sensibile al fattore tempo è la primissima fase di deploy del token, in cui il deployer specifica name, szDecimals e weiDecimals. È in questa fase che il gas viene addebitato e il token viene bloccato. Si raccomanda di dedicare tutto il tempo necessario dopo questa fase per ridurre gli errori. Non vi è alcun limite di tempo una volta pagato il gas.

Il deploy è un processo complesso in più fasi ed è possibile trovarsi in una situazione in cui il proprio deploy è bloccato. Ad esempio, Hyperliquidity e l'offerta totale possono essere incompatibili. È responsabilità del deployer provare prima il deploy esatto su testnet: https://app.hyperliquid-testnet.xyz/deploySpot. Il gas non può essere rimborsato se il deploy si blocca.

Deploy di asset esistenti

Uno schema di deploy comune consiste nell'utilizzare i book degli ordini spot on-chain di HyperCore per negoziare un asset che esiste esternamente. Rientrano in questa categoria, ad esempio, gli asset trasferiti tramite bridge da altre chain o gli RWA tokenizzati come le stablecoin. Questi deployer utilizzano spesso HyperEVM per il conio al fine di sfruttare il bridging multichain collaudato, incluse le seguenti opzioni:

• LayerZero: https://docs.layerzero.network/v2/developers/hyperliquid/hyperliquid-concepts
• Axelar: https://axelarscan.io/resources/chains
• Chainlink: https://docs.chain.link/ccip/tools-resources/network-specific/hyperliquid-integration-guide
• Debridge: https://docs.debridge.com/dmp-details/dmp/protocol-overview
• Wormhole: https://wormhole.com/docs/products/messaging/get-started/

Per distribuire un token ERC-20 coniato su HyperEVM ai fini del trading su HyperCore, il deployer deve pagare il costo del gas di deploy nell'asta olandese HIP-1 permissionless su HyperCore descritta sopra. Il costo del gas copre gli stati del book degli ordini e dei token HyperCore, che sono addebitati al deployer anziché ai futuri utenti. Il ticker è un identificatore on-chain univoco, ma come tutti i dati on-chain, i frontend possono visualizzare un nome diverso.

Per la configurazione più semplice, durante la fase di genesis il deployer può collocare l'offerta massima (oppure 2^64-1 per la massima flessibilità) nell'indirizzo di sistema. Si veda qui per le modalità con cui l'indirizzo di sistema è determinato in base all'indice del token HyperCore. Di norma i deployer di asset trasferiti tramite bridge scelgono di non utilizzare Hyperliquidity, configurabile tramite il campo noHyperliquidity.

Una volta collegati il token HyperCore e l'indirizzo ERC-20 su HyperEVM, i trasferimenti all'indirizzo di sistema su HyperEVM si rifletteranno nel saldo HyperCore del mittente e viceversa. Si raccomanda vivamente di testare la configurazione esatta su testnet.

USDC

USDC è attualmente utilizzato per tutto il margining dei perpetual. Con HIP-1, USDC diventa anche un token spot con trasferimento atomico tra i wallet perpetual e spot in USDC. USDC spot ha szDecimals = weiDecimals = 8 per consentire un'ampia gamma di prezzi dei token HIP-1.

Trading spot

I token HIP-1 vengono negoziati su book degli ordini parametrizzati da token base e quote, dove gli ordini limite sono impegni a scambiare sz * 10 ** (weiDecimalsBase - szDecimalsBase) unità del token base per px * sz * 10 ** (weiDecimalsQuote - szDecimalsQuote) unità del token quote. Qualsiasi token HIP-1 verrà inizializzato con un book degli ordini spot nativo in cui il token quote è Spot USDC. In futuro potrà essere abilitato il trading di coppie arbitrarie di token nativi.

Commissioni di trading

I book degli ordini spot nativi e i perpetual condividono lo stesso schema di commissioni basato sul volume per ciascun indirizzo. Le commissioni riscosse in token nativi HIP-1 diversi da USDC vengono inviate al deployer, ossia la quota di commissioni del deployer è pari al 100% per impostazione predefinita. Il deployer del token base può impostare questa percentuale nell'intervallo [0, 100%], ma solo a un valore inferiore a quello precedente. La parte delle commissioni sul token base non dirottata al deployer viene bruciata. Per i token quote diversi da USDC, le commissioni vengono inviate all'Assistance Fund. I deployer di token quote non possono configurare una quota delle commissioni di trading.

Per i token legacy distribuiti prima dell'introduzione della quota di commissioni del deployer, i deployer possono aumentare la quota una sola volta da zero a un valore positivo. Dopo questa modifica una tantum, la quota può solo diminuire. La quota di commissioni del deployer per i token legacy non può essere riportata esattamente a zero dopo essere stata impostata su un valore positivo.

Conversione dello spot dust

Il dusting dello spot avviene una volta al giorno alle 00:00 UTC. Tutti i saldi spot inferiori a 1 lot size con valore nozionale <= 1 USD vengono convertiti in dust. In questo contesto, il valore nozionale è calcolato come il mid price prevalente del token rispetto a USDC, moltiplicato per il saldo del token. Il dust di tutti gli utenti relativo a un token viene aggregato e un ordine di vendita a mercato viene inviato automaticamente al book. Se il dust aggregato è inferiore a una lot size, tale dust viene bruciato. Altrimenti, l'USDC derivante dal dust convertito con successo viene riassegnato a tutti gli utenti oggetto di dusting in modo ponderato, in cui la ponderazione è pari alla frazione del dust aggregato attribuibile all'utente.

Il dusting non avviene se 1) il book è unilaterale oppure 2) l'importo del dust nozionale è troppo elevato tale da incidere sul book con questa operazione. Per PURR, tale soglia è 10000 USDC; per tutti gli altri token, è 3000 USDC. Nota: l'importo di USDC ricevuto può essere inferiore all'importo nozionale calcolato dal mid a causa dello slippage sostenuto durante il dusting o dell'insufficiente liquidità per convertire il dust totale di tutti gli utenti.