Hyperliquid Nonces and Replay Protection
Hyperliquid uses nonces to make signed actions single-use and time-bounded, preventing a valid signed request from being replayed indefinitely.
A signed trading or transfer message would be dangerous if anyone who captured it could submit it repeatedly. Hyperliquid tracks nonces for signing addresses so an accepted action cannot simply be replayed. The nonce model is especially important for API wallets because trading systems often submit many actions concurrently and may rotate or deregister signers.
Nonce windows
Current documentation keeps a bounded set of recent nonces per signer and requires them to fall within a defined time window around current time. Timestamp-like nonces are therefore convenient, but they also depend on reasonably synchronized clocks.
A machine with badly skewed time can produce rejected requests even when its private key and signature logic are correct.
Concurrency
Two processes using one API wallet can accidentally generate colliding or out-of-order nonces. Treat nonce allocation as shared mutable state or give independent processes separate approved signers.
A retry must not blindly create ambiguity about whether the original action was accepted.
API-wallet pruning
The protocol can prune API-wallet nonce state in documented cases such as deregistration. Reusing a key after pruning can create replay hazards if old signed messages still exist and their nonces become acceptable under the new state.
The safest operational practice is not to recycle API-wallet private keys.
Invalidating an in-flight nonce
The Exchange endpoint includes a noop-style action that marks a nonce as used. This can be useful when a signed in-flight action needs to be neutralized, subject to the live protocol behavior.
It should be treated as an emergency control with clear audit logging, not an ordinary cancellation substitute for every request.