AeroNyx Node Discovery and Encrypted Multi-Hop Relay

Evidence-led capability boundary

Source implemented

Reviewed node source verifies signed, expiring peer descriptors; stores and recovers bounded peer state; rate-limits and policy-gates gossip; selects fresh, routeable candidates; opens only one onion layer per relay hop; forwards the remaining opaque blob; and binds a terminal receipt to the route, payload commitment, terminal identity, and freshness window. Source also contains a three-hop policy and probe path.

Automated tests verified

Thirty-five targeted relay tests passed: 11 core blind-relay tests, 23 server onion tests, and one three-hop probe test that records success only after a verified terminal receipt. Coverage includes signatures, tamper and wrong-key rejection, TTL, bounded codecs, routeable KEM candidates, two-hop readiness, three-hop policy, per-hop peeling, terminal delivery before acknowledgement, real ciphertext delivery, key rotation, and receipt-gated probe success.

Current fleet verified

The privacy-safe public snapshot at 2026-08-31 09:03 UTC reported six two-hop-proof-ready nodes and four message-delivery-proof nodes, but zero real_relay_ready nodes. It does not verify that three-hop policy is deployed, that every node has the same revision, or that the pending release-specific relay-smoke completed. Those items remain awaiting verification.

Meaning of multi-hop

The source can construct bounded paths with more than one relay hop. The current fleet claim is narrower: a fresh aggregate two-hop proof is a path-health signal, not proof that all application traffic used that path. Synthetic proof, opaque relay acceptance, and terminal-receipt delivery must stay separate.

Public status exposes only aggregate counts, freshness, coarse outcomes, and capability buckets. It excludes endpoints, node identities, route IDs, payloads, recipients, client addresses, DNS, and social-graph edges.