AeroNyx Network Stats Endpoint and Privacy Boundary

AeroNyx publishes aggregate network statistics at one public endpoint. The AeroNyx backend computes them from node heartbeats and VPN session reports. They contain counts, totals and status buckets only, never data about individual users, and they are not independently verifiable: they are what the backend reports.

This page explains what each number counts, the known limitations, and what the endpoint never includes.

Endpoint

bash

curl -s https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

No authentication is needed. The path contains vpn for historical reasons; the response covers the VPN and the node protocol layer. Each response has a generated_at timestamp. Read live values from the endpoint rather than from copies.

What each block counts

All blocks are under data.

Block	What it counts
`network`	`total_nodes`: registered nodes marked active. `vpn_nodes`: active VPN nodes. `online_vpn_nodes`: VPN nodes whose last heartbeat is within `health.heartbeat_fresh_seconds` (120 seconds). `public_vpn_candidates`: VPN nodes whose visibility is public, password-protected or unlisted. `regions_count`: distinct region labels.
`sessions`	`active_sessions`, `total_sessions` (all time), `sessions_started_24h` and `completed_sessions_24h` for VPN client sessions.
`encrypted_traffic`	`bytes_in + bytes_out` summed over all VPN client sessions, all time (`source: client_session_vpn_byte_counters`). This is VPN traffic only. It does not include chat relay, discovery or other node-to-node traffic.
`encrypted_message_forwarding`	`count`: the sum, over VPN nodes, of a counter of VPN data packets each node has handled successfully. The backend adds each node's increases, treats a counter reset (for example a restart) as a new start, and discards implausible jumps. `reported_nodes` is how many nodes have reported the counter.
`protocol_public_card`	A summary of the node protocol: overall `status` and `stage`, how many reporting nodes are ready, and cards for protocol health, the verified peer mesh and blind relay readiness.
`protocol_status`	The detailed protocol view: `network_story` (single-hop and two-hop readiness), `local_relay_capability` (ChatRelay configured, advertised and blocked counts), `protocol_foundation` (path-proof and relay evidence), `peer_store` (peer counts, blind relay counters, peer quorum, peer lifecycle) and `memory_chain`.
`protocol_status.memory_chain`	State of the signed commitment ledger, for nodes with a fresh heartbeat only. It reports `network_consensus: "not_claimed"` and the coordinator and witness counts. If no coordinator is producing blocks, the block counters stay flat. See Signed commitment ledger.
`health`	`heartbeat_fresh_seconds` (120), heartbeat samples and valid samples in the last 24 hours, `availability_24h_percent` (valid samples ÷ all samples) and `latest_heartbeat_at`.

Known limitations

Protocol node counts only include nodes that reported in the last 120 seconds. encrypted_message_forwarding, protocol_public_card and protocol_status are built from nodes with a fresh heartbeat, the same set as network.online_vpn_nodes. A node that goes offline drops out of these counts within two minutes. Until October 2026 they also counted the last snapshot of offline nodes.
total_nodes, vpn_nodes and public_vpn_candidates do not check freshness. They count registered active nodes, online or not. Compare them with network.online_vpn_nodes.
Totals cover currently active nodes only. Sessions and bytes are summed over nodes that are active now. When a node is deactivated, its sessions leave the totals, so all-time totals can go down.
"Encrypted traffic" is VPN traffic, reported by nodes per session. It is not a measure of relay or chat volume.
The figures come from the central backend. They are built from what nodes report to it and are not signed or independently verifiable. Use them as an operational overview, not as proof.

Two-hop path proof history

Nodes regularly test a synthetic two-hop path (entry, middle, terminal) and keep their most recent 32 results. The aggregate is at:

text

data.protocol_status.protocol_foundation.two_hop_path_proof_history

Field	Meaning
`reported_nodes`	Nodes that reported proof history
`retained_events`, `attempted`, `succeeded`, `failed`, `success_percent`	Sums over the retained results of all reporting nodes. Old failures stay here until they age out of each node's window.
`min_latest_age_seconds`, `min_latest_success_age_seconds`, `min_latest_failure_age_seconds`	Age of the most recent result, success and failure across nodes
`proof_ready_nodes`	Nodes whose last report said the proof is ready
`recent_success_ready_nodes`	Nodes whose latest result was accepted within 30 minutes of their report
`failure_streak_nodes`	Nodes reporting consecutive recent failures
`freshness_counts`	Nodes per freshness bucket: `fresh_success`, `stale_success`, `recent_failure`, `no_success`, `forming` (no attempts yet), `future_ignored` (clock problem)
`latest_outcome_counts`	Nodes per latest outcome, for example `accepted` or `none`
`latest_reason_counts`	Nodes per latest reason bucket, for example `onion_terminal_delivered`
`proof_scope_counts`	Retained results by scope: `message_delivery` or `control_plane`
`reason_bucket_counts`, `failure_reason_bucket_counts`	Retained results by reason, all and failures only
`path_shape_counts`	Retained results by path shape, for example `entry_middle_terminal`
`candidate_pool_counts`	Retained results by how many middle and terminal candidates were available when the proof ran: `incomplete`, `thin`, `forming` or `healthy`
`ttl_shape_counts`	Retained results by hop TTL layout, for example `entry_ttl_2_onward_ttl_1`
`source`, `privacy_boundary`	Where the data came from and what it excludes

Read the node counts (proof_ready_nodes, recent_success_ready_nodes, freshness_counts) for current readiness, and the event sums for history. Node-level fields only include nodes with a fresh heartbeat, so a node that stopped reporting drops out within two minutes. These are synthetic path proofs, not user messages.

For what the proofs test, see Node discovery and encrypted relay.

Privacy boundary

The public endpoint may include:

aggregate node counts and region counts
aggregate VPN byte and session counters
aggregate packet-forwarding counters
heartbeat freshness and availability
discovery, relay and proof readiness buckets
capacity and host-pressure aggregates

The public endpoint must not include:

node private keys or full node IDs
route IDs or selected hops
raw endpoints in public summaries
encrypted payloads or message plaintext
sender or receiver identities
client IP addresses
DNS contents, domains, URLs or browsing history
packet payloads
voucher secrets
per-user or per-wallet traffic
MemChain plaintext
social graph edges

This boundary applies to the public endpoint. Node operators see more about sessions on their own nodes in Nodeboard, including per-session and per-client-key traffic records; see the Nodeboard operator console guide. For how AeroNyx handles data overall, see the Trust Center.

Frequently asked questions

What does "encrypted traffic" measure?

It is the total of the byte counters that nodes report for VPN client sessions, over all time, on currently active nodes. It does not include chat relay or node-to-node traffic.

Do the node counts include offline nodes?

The protocol and forwarding counts do not: they only include nodes with a heartbeat in the last 120 seconds. network.total_nodes, network.vpn_nodes and network.public_vpn_candidates count registered active nodes whether or not they are online, so compare them with network.online_vpn_nodes.

Can the all-time totals go down?

Yes. Totals are summed over nodes that are currently active, so when a node is deactivated its sessions and bytes drop out.

Can I verify these numbers independently?

No, the AeroNyx backend computes them from node reports and does not sign them. Node operators can check their own nodes locally with the health tools in Run and check an AeroNyx node.

Does the endpoint reveal who uses AeroNyx?

No, it returns only aggregate counts and status buckets. It contains no client IP addresses, client keys, destinations, DNS data or message contents.

AeroNyx network stats and privacy boundary