AeroNyx Node Discovery, Blind Relay, and Two-Hop Path Proof

AeroNyx Rust privacy nodes now maintain a signed peer store, recover peer state after restart, publish privacy-safe discovery readiness, and report two-hop path proof telemetry. This is the protocol foundation for multi-hop encrypted message routing, future onion-style relay paths, encrypted service routing, and agent-to-agent encrypted protocol services.

The current production claim is precise:

nodes can discover and remember signed peers
nodes can recover a bounded peer store after restart
nodes can gate relay behavior on routeability evidence
nodes can operate as blind relays for opaque encrypted envelopes
nodes can prove a synthetic entry -> middle -> terminal route path across the live fleet
public surfaces can show aggregate readiness without exposing private routing metadata

This does not mean that every end-user chat payload is already forced through multi-hop routing. The Rust foundation is live; the client-side multi-hop message builder is the next product adoption step.

Current fleet status

As of 2026-06-29, the live Rust privacy node fleet reports:

json

{
  "reported_nodes": 3,
  "proof_ready_nodes": 3,
  "recent_success_ready_nodes": 3,
  "failure_streak_nodes": 0,
  "status_counts": {
    "ready": 3
  },
  "latest_outcome_counts": {
    "accepted": 3
  }
}

Public aggregate source:

text

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/
data.protocol_status.protocol_foundation.two_hop_path_proof_history

The API path still contains the legacy vpn namespace for compatibility. Product language should refer to AeroNyx Privacy Protocol or AeroNyx Privacy Network.

What two-hop path proof means

Two-hop path proof is a synthetic protocol-health check. A node verifies that it can reason about a route shaped like:

text

entry node -> middle relay -> terminal node

The check is deliberately privacy-safe. It records only bounded outcome buckets such as accepted, rejected, ready, stale, or attention. It does not publish route IDs, endpoints, node public keys, payloads, receivers, client IPs, DNS contents, domains, URLs, Memory Chain plaintext, or social graph edges.

Rust node components

Component	Role
Signed peer store	Stores verified node descriptors, freshness, routeability, and restart-recovery state.
Peer summary gossip	Lets nodes learn that other signed nodes exist without exchanging user data.
Blind relay handler	Forwards opaque encrypted envelopes without parsing content.
Rotating onion key	Separates node identity from per-hop onion decryption material.
Two-hop path proof history	Keeps bounded proof events and display-ready health status.
Backend observability	Aggregates public-safe fleet counters for docs, website, and nodeboard.

Display-ready fields

Rust nodes expose a two-hop path proof history object with fields designed for product surfaces:

Field	Meaning
`status`	`forming`, `ready`, `attention`, `stale`, or `idle`.
`proof_ready`	Whether the latest proof state is fresh enough for product display.
`recent_success_ready`	Whether a recent accepted proof exists inside the freshness window.
`failure_streak_active`	Whether recent proof attempts are failing consecutively.
`stale_after_seconds`	The freshness window before a successful proof becomes stale.
`next_action`	Operator-facing guidance generated by the Rust node.

nodeboard and the public website should prefer these fields over raw discovery inference.

Blind-node invariant

The most important protocol rule is that relay nodes and Memory Chain coordinators must be blind.

They may handle:

signed peer counts
valid peer counts
gossip freshness
peer-cache persistence status
routeability evidence
proof outcome buckets
aggregate capacity signals
packet drops, pps, bps, and host pressure counters

They must not handle or expose:

message plaintext
packet payloads
DNS contents
destinations, domains, URLs, or browsing history
social graph edges
Memory Chain plaintext
private keys
voucher secrets
wallet-level or per-user traffic

This invariant is more important than any single feature. If a relay node can read content or reconstruct who communicates with whom, AeroNyx would become a set of trusted middleboxes instead of a privacy protocol.

Why this matters

Multi-hop routing cannot be added as a user-facing promise until the foundation is observable and stable. A commercial privacy protocol needs to answer:

Do nodes know that other signed nodes exist?
Can nodes recover peer state after restart?
Are relay candidates fresh enough to use?
Are proof attempts succeeding or failing?
Can operators understand health without seeing user data?

The current two-hop path proof work answers those foundation questions for the live Rust fleet.

Next engineering step

The full /api/discovery/status object is a diagnostic endpoint and can be large. Frontends and backend polling should use a future compact endpoint, for example:

text

GET /api/discovery/summary

The summary endpoint should include only protocol stage, peer counts, blind relay readiness, two-hop proof status, latest proof outcome, and generation time. It must exclude raw descriptors, endpoints, public keys, route IDs, payloads, receivers, client IPs, DNS contents, Memory Chain plaintext, and social graph data.

2026-06-30 implementation status: two-hop path proof

AeroNyx now has a working aggregate two-hop path proof signal across the Rust node fleet.

The current public status is:

Signal	Current value
Reporting Rust privacy nodes	3
Two-hop path proof ready nodes	3
Retained proof events	70+
Accepted proof events	50+
Proof success rate	about 74%
Failure-streak nodes	0

The proof is reported by Rust PeerStore as peer_store.two_hop_path_proof_history, aggregated by the backend under protocol_status.protocol_foundation.two_hop_path_proof_history, and displayed in:

nodeboard node detail: Discovery -> Two-hop path proof
nodeboard Services: Protocol Foundation -> Two-hop proof
official website homepage: Protocol Health

What the proof means

Two-hop path proof is an aggregate readiness signal showing that live nodes can observe an entry -> middle -> terminal shaped relay path. It is a foundation for future multi-hop and onion-style routing work. It does not mean the public protocol has enabled production onion routing for all traffic yet.

Public API contract

The public website reads this from:

text

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

Relevant fields:

json

{
  "protocol_status": {
    "protocol_foundation": {
      "two_hop_path_proof_ready_nodes": 3,
      "two_hop_path_proof_history": {
        "reported_nodes": 3,
        "retained_events": 70,
        "attempted": 70,
        "succeeded": 52,
        "failed": 18,
        "success_percent": 74,
        "proof_ready_nodes": 3,
        "failure_streak_nodes": 0,
        "freshness_counts": {
          "fresh_success": 1,
          "unknown": 2
        }
      }
    }
  }
}

Privacy boundary

The public fields are aggregate protocol health only. They must not expose node public keys, endpoint URLs, route IDs, encrypted payloads, receiver identities, client public IPs, DNS contents, packet payloads, domains, URLs, Memory Chain plaintext, wallet-level traffic, or social graph edges.