Repository navigation
Hyperliquid figures on production said half a day was a whole one - #2869
Merged
Merged
Conversation
… it as a whole one (#2814) Reported as "our stats don't match CoinMarketMan, sometimes +50% diff". They do not, and the cause is upstream. Hyperliquid's per-builder fills export stops partway through each day. Trust Wallet (0x5af1…5f71), last fill in the published file: 10 Sep 23:59:57 whole 21 Sep 23:59:54 whole 22 Sep 12:27:11 truncated 25 Sep 12:13:31 truncated 30 Sep 12:11:42 truncated 2 Oct 12:10:58 truncated Every day since 22 September ends within three minutes of 12:11 UTC. The file is stable across re-downloads (identical md5), so this is the published artefact and not a partial fetch. Checked against the live info API for one user on 2 October: the CSV holds 953 fills, the API 1,299 carrying a builder fee, and every CSV fill is present in the API with none the other way. The export is a strict subset. Both sides imply the same 0.0950% fee rate, which is Trust Wallet's, so the extra fills are its own and not another builder's. By hour: 04-11 kept 100%, hour 12 kept 47%, hours 13-15 kept nothing. So our figures were a faithful read of an upstream that had quietly halved. Fees and volume were understated together, the rates stayed right, and nothing in the pipeline could tell. This publishes the coverage instead of hiding it. The cohort's furthest fill per day is already collected during the pass that builds the windows, so the check costs no extra parsing: one builder going quiet in the evening proves nothing, the whole cohort going quiet at the same minute is the feed being cut short. hl_frontend_day_coverage_hours_v2 hours the headline day reached hl_frontend_day_truncated_v2 1 when it is under 23 hl_frontend_truncated_days_window_v2 such days inside the 30-day window Figures stay published. The answer to a truncated upstream is to say so, not to drop the day and let the window silently shorten. The node is not an alternative: it is running on SGP but has not advanced since 3 October 09:10, looping on "could not read abci state: early eof", with 10 of 24 hours for that day and nothing for the 4th.
#2864) Hyperliquid's public per-builder export cuts days off around 12:10 UTC, and intermittently rather than from one clean break: 15, 16 and 18 September were already short while 17, 19, 20 and 21 ran to 23:5x, and 3 October ran full in the middle of an unbroken run of short days. Seventeen of the thirty days ending 6 October were short. On the days it did carry in full, the hours before 13:00 hold 43% of the notional and 44% of the fees. Nothing on the page said so, and three things followed from that. The biggest day was wrong rather than low. A maximum over days of unequal length ranks coverage: fomo's peak published as 21 September at $72,233 because 21 September is one of the few whole days in the window, while 28 September carried more than that before noon alone and summed to $47,480. CoinMarketMan, on a complete feed, puts the peak on 6 October. The scan now skips days the feed cut short and the card says "Biggest complete day", since a short day's total is a lower bound and not comparable to a whole one. The window sums were right arithmetic on an incomplete feed and read as half the answer. fomo's 30d volume is $1.489B against CoinMarketMan's $2.823B, and day-by-day correction brings it to $2.409B, which accounts for the gap bar 15%. Those figures stay as measured rather than scaled to a guess: what changes is that /hyperliquid and the #hl section now carry the coverage above them. A null coverage reading discloses too, because "we did not measure it" and "the feed is whole" are different claims. The truncated-day count itself understated the problem. It only looked at days whose files were still inside the mirror window and skipped the rest, so it reported 12 of 30 where the archive held 17. Coverage is now recorded per day in state and kept after the files go away, with a companion gauge for how many days were actually measured so the note never invents a denominator. Also the timeframe control the leaderboard was missing: the harness has published 24h, 7d and 30d all along and the hub only ever read 30d. "24h" is labelled "feed day" because it is the last complete UTC day, not a rolling window. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hyperliquid's export cuts a day at one instant for the whole cohort, so the per-builder last fills cluster inside a few minutes. Measured across the archive: on 6 October 2026 every qualifying builder's file ends between 11:58 and 12:09, on 23 September between 12:01 and 12:13, on 21 September between 23:31 and 23:59. The day's coverage was taken as the maximum of those. The reasoning was sound as far as it went, one builder going quiet in the evening proves nothing about the feed, but a maximum is maximally sensitive to an outlier in the other direction: a single file reaching past the cutoff lifts the day over the 23h threshold and the day reads whole. 23 September recorded 19.9 hours and 8 September recorded 24 exactly that way, and the window count came out at 12 short days where the median finds 18. So the reduction is now the median over builders with at least 100 fills that day, which leaves 29 to 53 samples a day in the archive. It is robust in both directions: a few quiet builders cannot drag it down, and one straggler cannot lift it. Under 8 samples it falls back to the max, which can only call a short day whole and never the reverse. The disclosure note reads the gauge, so it corrects itself. The figures it sits above do not change: they were always the sum of what the feed published. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cherry-picks #2814, #2864 and #2866 from
devontomain. This is the page the boss flagged: openchainbench.com/products/fomo#hl.Hyperliquid's public per-builder export cuts days off at roughly 12:10 UTC, intermittently since 8 September and on all but one day since 22 September. 18 of the 30 days ending 6 October are short. On the whole days, the hours before 13:00 UTC carry 43% of the notional and 44% of the fees, so each short day sums to well under half its real size. Nothing on the page said so.
FOMO against CoinMarketMan, 30d:
Correcting each short day by the measured share closes it to 0.85x; the residual 15% is the unattributed share MetaMask's documented second address is the known case of. CoinMarketMan's own page disagrees with itself here, $2.82B in the tile against $1.94B in Coin Volume Distribution.
The biggest day was wrong, not merely low. A maximum over days of unequal length ranks coverage rather than activity: FOMO's peak published as 21 September at $72,233 because 21 September is one of twelve whole days in the window, while 28 September carried more before noon alone and summed to $47,480. The scan now skips short days and the card reads "Biggest complete day".
The window sums stay as measured, not scaled to a guess. What changes is that
/hyperliquid, the#hldashboard and its fallback grid carry the coverage above them, and a null coverage reading discloses too: "we did not measure it" and "the feed is whole" are different claims.Plus the timeframe control. The harness has published 24h/7d/30d all along and the hub only ever read 30d, which is the "locked at 30D" complaint. "24h" is labelled "feed day" because it is the last complete UTC day, not a rolling window.
The harness on the VPS is already running this code; these commits bring
main's source in line with what is deployed. Verified live:hl_frontend_truncated_days_window_v2= 18,hl_frontend_coverage_days_measured_v2= 30.Checks
go test ./...in the harness,bun test src/464 pass,pnpm validate246 specs,tsc --noEmit,pnpm build🤖 Generated with Claude Code