Blind Relay Abuse Guard

The Blind Relay Abuse Guard is the set of limits an AeroNyx node applies before it forwards encrypted relay traffic for another node. It contains abusive or unstable peers using only signed routing metadata and local counters. It never parses ciphertext, keeps route histories or exposes who talks to whom.

Scope

The blind-node rule

A relay may authenticate routing metadata, apply bounded policy, forward an opaque envelope and return a signed receipt. It must never inspect the payload or expose metadata that could rebuild a route, a user identity or a relationship. In particular, relays do not record or expose:

• message, packet, media or memory plaintext
• DNS queries, destinations, domains, URLs or browsing history
• route IDs, complete paths, endpoint URLs or client IP addresses
• full public keys, receiver identities, message IDs or social-graph edges
• private keys, voucher secrets, wallet-level traffic or decryption material

Admission pipeline

Each request passes these checks before it can use forwarding capacity. Steps 1 to 6 run in this order. In step 7, a request addressed to this node goes to its own terminal or onion handling, while a request for another node is reserved after its next hop is resolved.

1. request gate: process-wide admission window and in-flight limit (64 requests)
2. crypto admission: a free slot for signature and onion work, or Backpressure
3. authenticate the signed previous hop and envelope
4. previous-hop rate limit and quarantine check
5. envelope metadata: size, age and future-skew limits
6. self-loop check
7. route loop, TTL and next-hop descriptor checks, plus the route replay reservation
8. forward the opaque ciphertext, or peel the terminal layer and deliver

Every decision uses signed routing metadata and local aggregate state, never decrypted content.

Runtime limits

These are the current defaults in the node source. They are operating values, not permanent protocol promises.

Previous-hop rate limiting and quarantine

Rate limits are keyed by the signed identity of the previous hop. More than 120 requests from one previous hop within 60 seconds starts a five-minute local quarantine for that hop. A separate failure score starts the same quarantine after 12 scored failures within five minutes. Only these reasons count toward the score:

invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted

Transport timeouts, lost acknowledgements, duplicate retries and replay conflicts do not add to the score, so a healthy peer is not quarantined for network trouble. The bucket store is bounded, and idle buckets are evicted, so the guard cannot grow into a long-term communication graph.

Route replay and retries

Every relay request carries a route ID. When the node's chat relay store is enabled ([memchain.chat_relay] enabled = true), route reservations and completed responses are kept in its SQLite database, so replay protection survives a restart. Otherwise the node uses an in-memory registry with the same capacity and window. If all 8192 slots hold live routes, new routes are rejected with replay_capacity until slots expire.

A repeated route ID has one of four outcomes:

The last outcome applies to the durable store. Signed receipts are only valid as fresh evidence, so the node does not replay one after 120 seconds.

When forwarding to the next hop fails with a timeout, a connection error or a request error, the node retries up to three attempts in total. The short delay before each retry is derived from the route ID, next hop and attempt number. Failures that the downstream node reports as definite rejections are not retried.

Crypto admission (operator capacity note)

Signature checks, onion peeling and receipt signing are CPU-bound, so each node process limits them:

• Total slots: half the CPU threads the host reports, rounded up, never fewer than 4 and at most 8, so even a one- or two-thread host gets 4 slots.
• Inbound requests: one slot fewer than the total, so outbound route creation and receipt completion can always make progress. On the smallest hosts, inbound requests therefore get 3 slots.
• When all slots are busy: the request is rejected immediately with HTTP 429 and the backpressure reason. It does not wait in a queue.

On a small host, a relay therefore sheds load early under bursts. A rising backpressure_dropped counter means the node needs more CPU or less relay traffic.

Aggregate runtime counters

Nodes report coarse cumulative counters and freshness timestamps in their heartbeat under:

system_stats.discovery_status.peer_store.runtime.blind_relay
system_stats.discovery_status.peer_store.blind_relay_quality
system_stats.discovery_status.peer_store.peer_health_summary

These counters describe node operation. They are not message logs or billing data, and they do not prove that any particular conversation took place.

Evidence quality

The quality summary keeps four kinds of evidence apart: accepted opaque relay work, synthetic reachability probes, synthetic two-hop probes and terminal-signed receipts for client-originated deliveries. real_relay_ready requires a fresh, authenticated client delivery receipt. Synthetic evidence is never reported as user traffic.

proof_scope names the strongest evidence seen: client_message_delivery, relay_acceptance, message_delivery, control_plane, single_hop_control_plane, attempted or none.

Peer health without traffic relationships

peer_health_summary lets operators find a failing or quarantined peer without seeing who communicates with whom.

Included: a shortened node ID prefix, coarse health and descriptor state, gossip and route-success freshness, aggregate route success and failure counts, quarantine state, time remaining and coarse reason buckets.

Never included: full node public keys, route IDs, endpoint lists, encrypted blobs or payload hashes, message IDs, receiver identities, client IP addresses, destinations, DNS data or social-graph edges.

Source map

The node software is open source under AGPL-3.0 at github.com/AeroNyxNetwork/AeroNyx. See Node discovery and encrypted multi-hop relay for how routes are built.

Frequently asked questions

Can a relay node read or log the traffic it forwards?

No. A relay checks signed routing metadata and forwards an opaque envelope. It keeps only aggregate counters, never payloads, route histories or receiver identities.

What happens when a node retries the same route?

If the first attempt has finished, the node replays its stored response and does not deliver anything a second time. If the first attempt is still running, the node returns a retryable route_in_flight. A different request under the same route ID is rejected as replay_conflict.

Does replay protection survive a node restart?

Yes, when the node's chat relay store is enabled. Route reservations and completed responses are then kept in SQLite. Without that store, the node uses an in-memory registry that is cleared on restart.

Why is a peer quarantined?

A peer is quarantined for five minutes after sending more than 120 requests in 60 seconds, or after 12 scored validation failures in five minutes. Timeouts, lost acknowledgements and duplicate retries do not count as failures.

Why does my node return backpressure under load?

All of its relay crypto slots were busy. A node allows about half its CPU threads (never fewer than 4, at most 8) for signature and onion work and rejects excess requests immediately instead of queuing them.