Hyperliquid Nonce Management for Parallel Automated Trading

Summary

The document explains how Hyperliquid handles transaction nonces for API wallets, also called agent wallets, and why its scheme differs from Ethereum’s sequential nonce model. Hyperliquid retains the 100 highest nonces per signer, accepts only unused values above the set’s minimum, and constrains timestamps relative to the transaction block time. Because a signer’s nonce state is shared across its activity, parallel processes or subaccounts using one API wallet can collide.

For automated trading, the guidance is to use a separate API wallet for each trading process or subaccount, batch order and cancellation requests periodically, and allocate unique nonces through an atomic counter. It also warns that deregistering or expiring an API wallet, or losing the registering account’s funds, can prune nonce state; reusing that address may therefore enable replay of previously signed actions. These are operational recommendations, not a benchmark or trading strategy, and the stated tolerance for out-of-order transactions is tied to the described setup and proximity to an API server.

Key ideas

• Hyperliquid stores a rolling set of the 100 highest nonces per signer rather than requiring strict sequential inclusion.
• API wallet nonce state is shared by processes that sign with the same wallet.
• Separate API wallets and atomic nonce allocation can reduce collisions in parallel trading.
• Batching orders and cancellations is suggested for automated strategies.
• Pruned nonce state can make reuse of an API wallet address unsafe because old signed actions may be replayed.

Tags

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.