Node Discovery and Verified Encrypted Relay Delivery

AeroNyx nodes now do more than discover one another and run synthetic path probes. On July 17, 2026, a production smoke test sent an authenticated client-originated opaque ChatRelay payload from US1 through Korean1 to Noway1. The terminal stored the pending payload and returned a signed receipt that the source verified. This is scoped evidence for an eligible two-hop ChatRelay path, not a claim that every AeroNyx packet uses onion routing.

Protocol invariant: Relay infrastructure must not receive plaintext or decryption keys. A middle node handles bounded route metadata, proof state, TTL, the next hop, and an opaque ciphertext blob. A terminal node receives only the minimum delivery metadata required for store-and-forward plus ciphertext; it cannot decrypt the payload.

What is live now

The production path supports signed peer descriptors, persistent peer stores, gossip propagation, reachability probes, receipt-capable route preference, authenticated client sessions, terminal pending storage, and signed delivery receipts. US1, Korean1, and Noway1 demonstrated distinct source, middle, and terminal roles in the live test.

Authenticated delivery flow

1. The client sends a signed ClientHello using Ed25519 and an ephemeral X25519 key.
2. The client verifies ServerHello and derives the encrypted session key.
3. The client sends ChatRelay inside an encrypted DataPacket.
4. The source node binds the claimed sender to the authenticated session identity.
5. The route planner selects a fresh receipt-capable middle and terminal that satisfy diversity rules.
6. The middle forwards only the bounded route envelope and opaque payload; the terminal writes it to pending store-and-forward storage.
7. The terminal signs a receipt bound to the route and payload; the source verifies it before counting a client delivery.

authenticated client -> source -> middle -> terminal pending store
                                  <- terminal-signed receipt <-

The terminal receipt is bound to the route ID, exact payload commitment, expected terminal identity, and freshness window. A mismatched or stale receipt is rejected.

Evidence levels

AeroNyx keeps three evidence levels separate so health checks cannot be presented as user delivery:

Route diversity

Source, middle, and terminal must be distinct. Candidate selection rejects peers sharing the same IPv4 /24, IPv6 /48, or normalized DNS host. Malformed endpoints fail closed. These are useful network-prefix controls, but they are not yet ASN or operator-ownership diversity.

Mixed-version compatibility

Receipt-capable routes are preferred. Older peers can remain available as bounded fallback, but a route without a valid terminal receipt never increments verified_client_onion_deliveries and must not be displayed as verified client delivery. Route search continues past stale or incompatible peers instead of stopping at the first candidate.

Public API contract

Read a node's direct card from GET http://<node>:8422/api/discovery/public-card. Read the privacy-safe network aggregate from GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/. The legacy vpn path segment is retained for backward compatibility; the product is the AeroNyx Privacy Protocol.

{
  "real_relay_ready": true,
  "verified_client_onion_deliveries": 1,
  "verified_client_onion_delivery_age_seconds": 42,
  "message_delivery_proof_ready": true,
  "message_delivery_ready": true,
  "message_delivery_evidence_mode": "verified_client_onion_delivery_receipt"
}

Privacy boundary

The public contract exposes aggregate readiness, counts, and evidence age. It does not publish route IDs, endpoints, node keys, payloads, receiver keys, sender signatures, pending records, client addresses, destinations, DNS contents, or social-graph edges. The current implementation is content-blind. It does not yet prove resistance to global traffic analysis, Tor-level anonymity, or complete social-graph unlinkability.

Current limits

• Verified delivery currently covers authenticated client-originated ChatRelay on an eligible two-hop, receipt-capable path.
• It does not mean every privacy-network packet, voice item, media blob, or chat event uses this path.
• The deployed verified path is two-hop; it is not a general three-hop anonymity network.
• Diversity currently covers network prefixes and DNS hosts, not ASN or independently verified operator ownership.
• verified_client_onion_deliveries and its timestamp are process-local freshness signals and reset after node restart; they are not lifetime totals or global consensus.

Product wording

Use Verified client delivery only for verified_client_onion_delivery_receipt. Use Encrypted relay active for opaque_relay_acceptance, and Path probe passed for synthetic_onion_message_delivery_probe. Do not collapse these states into a single success badge.

Related documentation

• AeroNyx Chat Relay Client Integration
• AeroNyx Network Stats and Privacy Boundary
• Blind Relay Abuse Guard