Skip to main content

Overview

Firedancer provides an optional HTTP WebSocket API for consumers to subscribe to validator information. It primarily exists to support the Firedancer GUI and provides real-time streaming of validator state, performance metrics, and blockchain data.
The API is not currently stable, is not versioned, may not exist for long, may break or start producing incorrect data at any moment, and should not generally be used for production applications without extreme caution.

Connecting

Configuration

First, configure the GUI tile in your config.toml:
config.toml

JavaScript Client

Create a WebSocket client connection:
client.js

Message Format

All data is encoded in JSON with a containing envelope:
string
required
The high-level category of the message (e.g., summary, slot, gossip, peers).
string
required
The specific data type within the topic (e.g., version, cluster, ping).
any
required
The actual data payload. Can be a string, number, object, or array depending on the message type.

Compression

The server can optionally compress messages larger than 200 bytes using Zstandard compression.

Enabling Compression

Specify the compress-zstd subprotocol in the opening WebSocket handshake:
client.js
Compressed messages are sent as binary WebSocket frames (opcode=0x2), while regular messages are sent as text frames (opcode=0x1).

Message Frequencies

Each message is published with a specific frequency:

Queries

Some messages are published on-demand in response to client requests.

Request Format

string
required
The topic to query.
string
required
The query method to call.
number
required
An unsigned integer (must fit in u64) that will be echoed back in the response.
object
Request-specific parameters documented for each query.

Response Format

If the requested data is not available, the value will be null:
If the client issues a malformed request, it will be forcibly disconnected.

Topics

Summary Topic

High-level informational fields about the validator.

summary.version

Frequency: Once The current version of the running validator.

summary.cluster

Frequency: Once + Live Indicates the cluster that the validator is running on.
Possible values: mainnet-beta, devnet, testnet, pythtest, pythnet, development, or unknown.

summary.identity_key

Frequency: Once + Live The public identity key assigned to the running validator, encoded in base58.

summary.vote_state

Frequency: Once + Live The current vote status of the validator.
Possible values:
  • voting - Validator is actively voting
  • non-voting - Validator is not voting
  • delinquent - Last vote is 150+ slots behind

summary.root_slot

Frequency: Once + Live The last slot that was rooted. Rooted slots are fully confirmed and irreversible.

summary.completed_slot

Frequency: Once + Live The highest completed slot on the current fork choice of the validator.

summary.estimated_tps

Frequency: Once + Live The estimated number of transactions per second (moving average from prior 150 slots, ~1 minute).

summary.skip_rate

Frequency: Once + Live The skip rate for the current epoch.

summary.ping

Frequency: Request Application-level ping/pong (not a WebSocket control frame). Request:
Response:

Slot Topic

Information about blockchain slots and block production.

Slot Levels

Slots progress through five levels:
level
The slot does not exist yet or is still being replayed.
level
The slot has been fully received and successfully replayed.
level
The slot has been replayed and more than two-thirds of stake have voted to confirm it.
level
The validator has rooted the slot and considers it final (32 subsequent slots built on top).
level
The validator has rooted the slot and more than two-thirds of stake has rooted it.

slot.update

Frequency: Live Published whenever a slot’s state changes.

slot.query

Frequency: Request Query information about a specific slot. Request:
Response:

Epoch Topic

Information about epochs and leader schedules.

epoch.new

Frequency: Once + Live Published for each new epoch (current and next epoch on connection).

Gossip Topic

Information about the validator’s gossip network connectivity.

gossip.network_stats

Frequency: Once + 300ms Aggregate statistics about gossip network health and connectivity.

Peers Topic

Information about validator peers from the cluster.

peers.update

Frequency: Once + 60s Peer validator information from gossip, accounts database, and on-chain config.

Backpressure and Connection Management

The server does not drop information, slow down, or stop publishing if a client cannot keep up. A client that reads too slowly will have its connection forcibly closed by the server.

Best Practices

  1. Process messages asynchronously - Don’t block the message handler with heavy computation
  2. Use compression - Enable Zstandard compression for large messages
  3. Monitor connection health - Implement reconnection logic
  4. Filter topics - Only subscribe to the data you need (if supported)

Error Handling

Connection Errors

Common Issues

  • Connection forcibly closed - Client cannot keep up with message rate
  • Malformed request - Invalid JSON or missing required fields in query
  • Null response - Requested data does not exist or is not available

Additional Resources

  • For complete field definitions and data structures, see the full WebSocket API specification
  • For monitoring and observability, use the Metrics API
  • For production deployments, consider using the RPC API instead of WebSocket for stability