Do relays need to stay online? The full exploit surface analyzed · content/relay-networks-and-exploits.md

Relay Networks — availability, offline behaviour, and the full exploit surface

Date: 2026-09-15 · Founder's questions: "Do relays have to remain online? What are potential network exploits?"

1. Do relays have to remain online?

No. Relays can go offline at any time. The system degrades gracefully.

What happens when a relay goes offline:

The key insight: the sender always keeps the plaintext

Sender encrypts message → sends to relay → relay goes down
                        ↓
              Sender STILL HAS the plaintext + the encryption key
              They can re-send through any other relay
              The message isn't "lost" — it's just "not yet delivered"

This is fundamentally different from email (where a dead SMTP server means bounced mail) or a dead hard drive (where data is gone). The relay is a CACHE, not a source of truth.

The multi-relay architecture (already implemented and tested):

Sender ──┬──► Relay 1 (superlocal :8830)     ──┐
         ├──► Relay 2 (cachyos-x8664 :8840)  ──┤──► Recipient polls ALL of them
         └──► Relay 3 (compute provider :8851) ──┘     (deduplicates by envelope ID)

• Send to one relay (primary), fallback to others if it fails
• Receive from ALL relays (poll every one, deduplicate)
• If ANY relay is up, messages flow
• If ALL relays are down, messages spool and retry

The offline ferry (the extreme case):

When even multi-relay doesn't work (no internet at all, air-gapped machines):

# On machine A (has the message):
qalchat.py export-env --to bob > /usb/messages.dat

# Carry USB to machine B:
qalchat.py import-env < /usb/messages.dat
# → Machine B now has the encrypted envelopes
# → Decryption happens locally (keys never left the devices)
# → Anchors spool until the chain is reachable

This is tested and working. The relay is a convenience, never a dependency.

Relay uptime SLA (what we actually run):

2. The full exploit surface (honest threat analysis)

Level 1: Network-level attacks

Level 2: Envelope-level attacks

Level 3: Identity-level attacks

Level 4: Chain-level attacks

Level 5: Economic attacks

The exploit hierarchy summary:

HARDEST TO EXPLOIT (essentially impossible):
  ├── Double-spend (Move VM prevents it)
  ├── Cap bypass (bytecode enforcement)
  ├── Reserve drain (on-chain invariant)
  └── Envelope forgery (ed25519 signatures)

HARD TO EXPLOIT (defences in depth):
  ├── Identity theft (2s revocation + caps + Stronghold)
  ├── Envelope replay (hash chain + dedup)
  └── Key substitution (QR pins + proof-of-possession)

MEDIUM (mitigated but requires vigilance):
  ├── Relay flooding (rate limits + multi-relay)
  ├── Traffic analysis (multiple relays, future: mix-net)
  ├── Sybil attacks (graduated tiers + caps)
  └── Eclipse (multi-relay + offline ferry)

ACKNOWLEDGED LIMITATIONS (honest):
  ├── Relay metadata visibility (who talks to whom)
  ├── Relay storage exhaustion (48h TTL caps it)
  └── Validator concentration (Phase 1: we are the validators)

3. The relay evolution (how attacks get harder over time)