AeroNyx Network Stats and Privacy Boundary

AeroNyx public statistics are designed to show protocol progress without exposing user-level activity. The public website and docs may display aggregate counters for encrypted traffic, encrypted protocol packets, protocol health, peer discovery, restart recovery, blind relay readiness, and two-hop path proof status.

The core rule is simple: public stats should prove the protocol is alive without letting anyone reconstruct who used it, where they went, what they sent, or who they talked to.

Public endpoint

text

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

The path contains vpn for backward compatibility. Product surfaces should call the system AeroNyx Privacy Protocol or AeroNyx Privacy Network.

Current primary homepage stats

The main website should keep the first-level status focused:

Stat	Meaning
Encrypted traffic	Total encrypted payload bytes relayed by AeroNyx privacy nodes.
Encrypted packets	Encrypted protocol packets successfully forwarded by live nodes.
Protocol health	Aggregate readiness across node discovery, blind relay foundation, and proof telemetry.

Detailed node counts, ChatRelay, OnionMiddle, restart recovery, MemChain, and two-hop readiness should live in detail panels or docs instead of overcrowding the homepage.

Two-hop path proof aggregate

Two-hop path proof is exposed under:

text

data.protocol_status.protocol_foundation.two_hop_path_proof_history

Important fields:

Field	Meaning
`reported_nodes`	Number of nodes reporting proof history.
`proof_ready_nodes`	Nodes whose latest proof status is fresh and ready.
`recent_success_ready_nodes`	Nodes with a recent accepted proof.
`failure_streak_nodes`	Nodes currently reporting consecutive proof failures.
`status_counts`	Public bucket counts such as `ready`, `attention`, or `stale`.
`latest_outcome_counts`	Public latest outcome buckets such as `accepted` or `rejected`.
`next_action_counts`	Bounded operator guidance buckets.

Example:

json

{
  "reported_nodes": 3,
  "retained_events": 5,
  "attempted": 5,
  "succeeded": 3,
  "failed": 2,
  "success_percent": 60,
  "proof_ready_nodes": 3,
  "recent_success_ready_nodes": 3,
  "failure_streak_nodes": 0,
  "status_counts": {
    "ready": 3
  },
  "latest_outcome_counts": {
    "accepted": 3
  }
}

Historical failed attempts may remain in retained_events, attempted, and failed; the display-ready fields are status_counts, proof_ready_nodes, recent_success_ready_nodes, and failure_streak_nodes.

Privacy boundary

Public statistics may include:

aggregate node counts
aggregate encrypted byte counters
aggregate encrypted packet counters
heartbeat freshness
discovery readiness buckets
proof readiness buckets
packet drops, pps, and bps
capacity and host pressure aggregates

Public statistics must not include:

node private keys
route IDs
raw endpoints in public summaries
encrypted payload bodies
message plaintext
receiver identities
client IPs
DNS contents
packet payloads
domains, URLs, or browsing history
voucher secrets
wallet-level traffic
MemChain plaintext
social graph edges

Frontend display guidance

Use direct, high-signal copy:

AeroNyx Privacy Protocol
Encrypted traffic
Encrypted packets
Protocol health
Two-hop proof ready
Blind relay foundation

Avoid first-screen clutter. Node counts, ChatRelay, OnionMiddle, restart recovery, MemChain, and detailed proof buckets are valuable, but they should be secondary detail views.

Why aggregate-only stats matter

AeroNyx is not trying to prove privacy through secrecy of implementation. It should prove health through public, verifiable, aggregate operational facts while keeping the blind-node invariant intact. This lets users, operators, developers, and AI agents understand network progress without turning observability into surveillance.