Currently the meta endpoint only flags an asset with isDelisted after the fact. However, delistings on Hyperliquid are decided by validator votes that are publicly announced days in advance (e.g. the MAV/MAVIA/MEW/... vote announced ahead of May 5) — so the information already exists on-chain/off-chain before it takes effect.
For automated traders this gap is painful: bots keep opening positions in an asset right up until it disappears, and there is no machine-readable way to know it was scheduled to go. Centralized venues expose this (Binance GET /sapi/v1/spot/delist-schedule, Bitget offTime/limitOpenTime in the contracts catalog), which lets trading systems automatically stop opening and wind down positions in advance. Hyperliquid is currently the only venue in our stack where this protection cannot be automated.
Proposal: either
add an optional scheduledDelistTime (ms) field to the universe entries in meta / metaAndAssetCtxs once a delisting vote passes, or
add a dedicated info request, e.g. {"type": "delistSchedule"} → [{"coin": "...", "delistTime": ...}].
Either shape would let API consumers block new entries and unwind positions before the deadline, exactly as the validator-vote announcements intend. Thanks!
Currently the meta endpoint only flags an asset with isDelisted after the fact. However, delistings on Hyperliquid are decided by validator votes that are publicly announced days in advance (e.g. the MAV/MAVIA/MEW/... vote announced ahead of May 5) — so the information already exists on-chain/off-chain before it takes effect.
For automated traders this gap is painful: bots keep opening positions in an asset right up until it disappears, and there is no machine-readable way to know it was scheduled to go. Centralized venues expose this (Binance GET /sapi/v1/spot/delist-schedule, Bitget offTime/limitOpenTime in the contracts catalog), which lets trading systems automatically stop opening and wind down positions in advance. Hyperliquid is currently the only venue in our stack where this protection cannot be automated.
Proposal: either
add an optional scheduledDelistTime (ms) field to the universe entries in meta / metaAndAssetCtxs once a delisting vote passes, or
add a dedicated info request, e.g. {"type": "delistSchedule"} → [{"coin": "...", "delistTime": ...}].
Either shape would let API consumers block new entries and unwind positions before the deadline, exactly as the validator-vote announcements intend. Thanks!