API servers

The API servers are permissionless, other than the validating nodes allowing direct connectivity via RPC. Essentially the API servers act as non-validating proxies to the network. The design allows anyone with access to a node RPC (which will ultimately be public) to spin up arbitrary sets of API servers with their own properties for load balancing.

A single API server is simple in design. It listens to block updates and maintains a processed version of the blockchain state to serve to clients. On requests, it forwards those to the nodes and relays the response back to the client.

The API server’s in-memory representation of the blockchain state allows Hyperliquid to serve an API that is familiar to automated traders on centralized exchanges. Furthermore, the permissionless API server model solves the issue of load balancing and DDOS protection much like sentry nodes in other network designs.

REST vs WS

The API serves two sources of data, REST and Websocket. Under the hood, orders and cancels are relayed to the consensus RPC, which gossips the transactions to all the nodes and respond to the original request once it's included in the block and that block is committed.

Websocket is maintained by a replica state that runs parallel to consensus and pushes updates when the blocks are created. Both systems handle load differently, since the consensus is running as a separate process on each node machine, but the websocket process is running in the same process as the state machine updates. Therefore it's not guaranteed that the timestamps from interleaving the two sources will be consistent.

Last updated