Hyperliquid node disk filling up: EVM checkpoints and how to prune them

After the 25 October 2026 hardfork, Hyperliquid non-validator nodes on hl-node binary 115 keep a full EVM state checkpoint every 10000 blocks and never delete the old ones. That is about 15 GB of extra disk an hour, on top of the node's normal output. This page shows how to check for it, which checkpoints are safe to delete and the hourly script we run.

The short version#

• Where: ~/hl/hyperliquid_data/evm_db_hub_slow/checkpoint/<height>/, one directory every 10000 blocks.
• Size: about 3 GB of new data each, roughly five an hour.
• Keep: the height in cp_checkpoint_height, the newest three, anything written in the last 30 minutes.
• Delete: everything older, every hour.

1. Check the checkpoints#

D=~/hl/hyperliquid_data/evm_db_hub_slow
ls $D/checkpoint | wc -l                  # how many
du -sh $D/checkpoint                      # how much
cat $D/cp_checkpoint_height               # the one the node uses
ls -lt --time-style=+%F_%T $D/checkpoint | head -5   # newest first

A healthy node after pruning has a handful of directories. An unpruned node gains about 120 a day. Old checkpoints from earlier state downloads can also sit there for months.

2. Why it grows#

The node writes a checkpoint of the HyperEVM state each time it passes a height divisible by 10000. That happens about every 12 minutes at current block times. Each start that downloads state from a peer also receives a checkpoint bundle and writes it to the same directory. Nothing in the node deletes old checkpoints, and cleanup jobs written before binary 115 do not know about the directory.

3. What is safe to delete#

• Never the directory whose name matches evm_db_hub_slow/cp_checkpoint_height. That is the node's current base.
• Keep the newest three. A restart or a peer asking for state may want a recent one.
• Skip anything modified in the last 30 minutes. It may still be written.
• Skip anything with an open file. lsof +D <dir> tells you.
• Everything else can go.

4. Pruning script#

Run it with --dry-run first. It lists what it would delete and the space it would free.

#!/bin/bash
# prune-evm-checkpoints.sh [--dry-run]
set -euo pipefail
CP_DIR=/root/hl/hyperliquid_data/evm_db_hub_slow/checkpoint
KEEP=3
DRY=false; [ "${1:-}" = "--dry-run" ] && DRY=true
IN_USE=$(tr -dc '0-9' 2>/dev/null < "$CP_DIR/../cp_checkpoint_height" || true)

find "$CP_DIR" -mindepth 1 -maxdepth 1 -type d -regex '.*/[0-9]+' -printf '%f\n' \
  | sort -n | head -n -"$KEEP" | while read -r h; do
    d="$CP_DIR/$h"
    [ "$h" = "$IN_USE" ] && continue
    [ -n "$(find "$d" -mmin -30 -print -quit)" ] && continue
    lsof +D "$d" >/dev/null 2>&1 && continue
    if $DRY; then echo "would delete $h ($(du -sh "$d" | cut -f1))"; else rm -rf "$d"; echo "deleted $h"; fi
  done

5. Run it every hour#

# root crontab: prune at minute 0, log the result
0 * * * * /opt/node/prune-evm-checkpoints.sh >> /var/log/prune-evm-checkpoints.log 2>&1

Keep the job name and path free of the node's binary names. The supervisor scans running processes at startup and panics when another command line contains them. The node guide covers that error.

6. Numbers#

• 149 checkpoints had built up on one node, 119 of them in the first day after the hardfork.
• du reported 450 GB for the directory. Pruning to the rule above freed about 430 GB.
• Before pruning, free space on the data disk fell by about 30 GB an hour.
• The hourly job then deletes about five checkpoints, roughly 25 GB, per run.

Questions#

Related guides#

• How to run a Hyperliquid non-validator node
• Hyperliquid node crash after the October 2026 hardfork: missing node_metadata.json

References#

• hyperliquid-dex/node. Node README, data directories and binaries.
• Hyperliquid docs: Nodes. Official node documentation.
• ironflowsh/hyperliquid-node-kit. Our open-source node cleanup and watchdog scripts.