hyperliquid-dex / node

Running a node Machine Specs | Role | vCPUs | RAM | Storage | | ------------- | ----- | ------ | ---------- | | Validator | 32 | 128 GB | 1 TB SSD | | Non-Validator | 16 | 64 GB | 500 GB SSD | Currently only Ubuntu 24.04 is supported. Ports 4001 and 4002 are used for gossip and must be open to the public. Otherwise, the node IP address will be deprioritized by peers in the p2p network. For lowest latency, run the node in Tokyo, Japan. --- Setup Configure Chain For testing, configure your chain as follows: • **Testnet**: • **Mainnet**: Download the Visor Binary The visor binary spawns and manages the child node process. • **Testnet**: • **Mainnet**: --- Verify Signed Binaries Binaries are signed for extra security. The public key is found at in this repo. • **Import the Key:** • **Verify the Binary:** Signatures are located at . • **Testnet**: • **Mainnet**: will also verify automatically and will not upgrade on verification failure. **Important:** The public key must be imported as shown above. Optionally, sign the key using to avoid warnings when verifying its signatures. --- Running Non-Validator To start a non-validator node: It may take a while as the node navigates the network to find an appropriate peer to stream from. Logs such as indicate that the node is streaming live data. > **Note:** The same command is used regardless of whether your chain is set to Testnet or Mainnet (as configured in ). --- Reading L1 Data The node writes data to . With default settings, the network will generate around 100 GB of logs per day, so it is recommended to archive or delete old files. For more information about examples and all the data types that can be written, refer to docs. • **Transaction Blocks:** Blocks parsed as transactions are streamed to: • **State Snapshots:** State snapshots are saved every 10,000 blocks to: To translate the state to JSON for examination: • **Testnet**: • **Mainnet**: To compute L4 book snapshots (full onchain order information) from a state snapshot file: --- Flags When running validators or non-validators, you can use the following flags. The data schemas for the output data are documented here. • : Streams trades to . • : Streams fills in the API fills format to . Also streams TWAP statuses to . This overrides if both are set. The field is included for HIP-3 fills. • : Writes every L1 order status to . Note that orders can be a substantial amount of data. • : Writes every L1 order diff to . Note that raw book diffs can be a substantial amount of data. • : Writes every HIP-3 deployer oracle update action to . • : Writes miscellaneous event data to . See docs for more details. • : Writes CoreWriter and HyperCore to HyperEVM transfer data indexed by HyperEVM tx hash and a unique system nonce to . • : Writes the above files with one block per line instead of one event per line. The batched data schema is , where is a list. • : Writes events as they are processed instead of once per block, but uses the same data schema as to include block metadata. • : Configures what is written to . Options: • (default) – only actions • – both actions and responses • – only preserves the two latest height files • : Flush each line immediately when writing output files. This reduces latency but leads to more disk IO operations. • : Enables the EVM RPC (see next section). • : Enables local HTTP server to handle info requests (see next section). For example, to run a non-validator with all flags enabled: > **Note:** These flags work independently of the chain setting. Just ensure that your is configured for Testnet or Mainnet as needed. --- EVM and Info servers Enable the EVM JSON-RPC by adding the flag: Once running, you can send RPC requests. For example, to retrieve the latest block: Similarly, enables a local server at to handle info requests with the API request/response format. See docs for more details. Running a local info server can help with rate limits and reduces trust assumptions on external operators. Currently the local server only supports a subset of requests that are entirely a function of local state. In particular, historical time series queries and websockets are not currently supported. The flags on the node can be used for historical and streaming purposes. The currently supported info requests on the local server are The info server also supports requests that writes down large local snapshot data to a file. This can be a better way to get snapshot data if an info server is running, because it uses the latest state instead of an older snapshot file. The info request format is: format is: Some info requests such as are not currently supported, as they are only indexed by a small number of assets and can be easily polled or subscribed to within the standard rate limits. To ensure that the server information is up to date, can be pinged periodically to compare L1 and local timestamps. The server information can be ignored when the L1 timestamp returned is sufficiently stale. > **This applies for both Testnet and Mainnet.** --- Delegation The native token on Testnet is **HYPE** with token address: **Delegation Process (applies to both chains):** • **Staking Deposit:** Transfer tokens from your spot balance into the staking balance: • **Testnet:** • **Mainnet:** • **Delegate Tokens:** Delegate tokens to a validator: • **Testnet:** • **Mainnet:** Optionally, add to undelegate from the validator. • **View Delegations:** • **Testnet:** • **Mainnet:** Use the corresponding API endpoint for mainnet (if available). • **Staking Withdrawal:** Initiate a staking withdrawal (subject to a 5-minute unbonding period): • **Testnet:** • **Mainnet:** The withdrawal will reflect in the exchange balance automatically once the unbonding period ends. --- Running a Validating Node _Note: The non-validating node setup above is a prerequisite for running a validating node._ Generate Config Generate two wallets: • **Validato…