2026-06-27 · Hyperliquid · 2 条相关讨论
checked 21-06-2025 and it was Saturday - you are saying that these occur weekly, so it matches weekly network upgrades which pause the chain
checked 21-06-2025 and it was Saturday - you are saying that these occur weekly, so it matches weekly network upgrades which pause the chain
Thanks for checking! The weekly timing does fit — but in these windows the chain doesn't actually pause; trades keep happening, they're just missing from the exported archive. Two clear signs: 1. The fills are retrievable from the live API right now, timestamped inside the "gap". A chain pause would have none. 2. The archive contradicts itself — it contains post-gap fills whose startPosition requires earlier fills that are absent from the same archive. Reproducible example (userFillsByTime, wallet 0x2e21358ecf609d76867ff3c6d2edc3b6cb26c098, coin FARTCOIN, 2025-06-21): In the S3 archive, FARTCOIN jumps from a fill at 09:16:14 (startPos 459.8, buy 21 → position 480.8) straight to the next at 09:31:24 (startPos 426.8). 480.8 ≠ 426.8 with no fill in between — the archive can't explain its own position. The live API fills that gap with 6 trades the archive lacks: 09:22:05 (startPos 480.8, oid 104594473517), 09:23:02, 09:24:45, 09:27:48, 09:28:24, 09:30:21 — each chains perfectly back to the 09:31:24 fill (480.8 → … → 426.8). Their oids increase monotonically across the window, so orders were being sequenced the whole time. Across all wallets, ~530 fills are missing from the archive in just this one window. So it looks like the archival/export node restarts and resumes at the live tip without backfilling, while the chain + API keep running — the gap is in the export, not the chain. Any chance those block ranges could be re-exported from a full archival node? Happy to share more windows.
Thanks for checking! The weekly timing does fit — but in these windows the chain doesn't actually pause; trades keep happening, they're just missing from the exported archive. Two clear signs: 1. The fills are retrievable from the live API right now, timestamped inside the "gap". A chain pause would have none. 2. The archive contradicts itself — it contains post-gap fills whose startPosition requires earlier fills that are absent from the same archive. Reproducible example (userFillsByTime, wallet 0x2e21358ecf609d76867ff3c6d2edc3b6cb26c098, coin FARTCOIN, 2025-06-21): In the S3 archive, FARTCOIN jumps from a fill at 09:16:14 (startPos 459.8, buy 21 → position 480.8) straight to the next at 09:31:24 (startPos 426.8). 480.8 ≠ 426.8 with no fill in between — the archive can't explain its own position. The live API fills that gap with 6 trades the archive lacks: 09:22:05 (startPos 480.8, oid 104594473517), 09:23:02, 09:24:45, 09:27:48, 09:28:24, 09:30:21 — each chains perfectly back to the 09:31:24 fill (480.8 → … → 426.8). Their oids increase monotonically across the window, so orders were being sequenced the whole time. Across all wallets, ~530 fills are missing from the archive in just this one window. So it looks like the archival/export node restarts and resumes at the live tip without backfilling, while the chain + API keep running — the gap is in the export, not the chain. Any chance those block ranges could be re-exported from a full archival node? Happy to share more windows.