Response drift: hyperliquid — allMids keys are #<encoding> not @{outcomeId}, getMidForOutcome always returns undefined

[realfishsam]

Exchange

hyperliquid

Severity

HIGH

What Our Normalizer Expects

utils.ts:61 defines toMidKey(outcomeId) which returns @${outcomeId}.
fetcher.ts:401-402 and normalizer.ts:342 look up mid prices via mids[toMidKey(outcomeId)] — e.g. mids["@1033"].

// utils.ts:61
const toMidKey = (outcomeId: number) => `@${outcomeId}`;
// fetcher.ts:401-402
const mid = mids[toMidKey(outcome.outcome)];

What The Live API Returns

POST https://api.hyperliquid.xyz/info with {"type":"allMids"} returns a flat object keyed by coin notation — e.g. #10330, #10331 — where the encoding is 10 * outcomeId + side per config.ts:8-13 (the same toCoinNotation() encoding used everywhere else in the adapter).

No @-prefixed keys are present anywhere in the live response.

Impact

HIGH: mids[toMidKey(outcomeId)] always evaluates to undefined — no key of the form @N exists in the live allMids map. The fallback at normalizer.ts:212 substitutes 0.5, so every Hyperliquid outcome price is silently hardcoded to 50% regardless of actual market probability. No error is thrown and no warning is emitted.

Suggested Fix

Update toMidKey to produce keys in the #<encoding> format that the live API actually uses. For a binary outcome with ID N, the Yes coin is #${10*N} and the No coin is #${10*N+1}:

// utils.ts — proposed replacement
const toYesMidKey = (outcomeId: number) => `#${10 * outcomeId}`;
const toNoMidKey  = (outcomeId: number) => `#${10 * outcomeId + 1}`;

Update fetcher.ts:401-402 to look up both keys and average (or pick the appropriate side) when constructing the normalized mid price.

---

Found by automated response shape drift audit