Reticulum Network Stack: Cryptographic Addressing, Interfaces & Zero-Config

Most wireless communication stacks we use today were designed around centralized authorities. The internet depends on ICANN for IP allocation, regional registries for autonomous systems, and certificate authorities for transport encryption. Even in decentralized radio projects, nodes frequently rely on fixed frequency presets, rigid channel plans, or centralized coordinator nodes.

The Reticulum Network Stack (RNS) throws that paradigm out the window.

Reticulum is a complete, medium-agnostic networking stack built from the ground up for untrusted, high-latency, and zero-infrastructure environments. It treats sub-1GHz LoRa radios, directional microwave Ethernet bridges, serial TNC links, and standard internet UDP sockets as interchangeable interfaces.

If you are building resilient sensor telemetry, off-grid chat networks, or redundant data links, understanding Reticulum’s cryptographic addressing and routing mechanics is one of the most powerful tools in open-source RF engineering.

01 · The Stack Architecture: Medium Independence

Unlike LoRaWAN (which requires specialized gateway concentrators) or Meshtastic (which is tightly coupled to LoRa packet broadcast), Reticulum does not care what physical layer carries its bytes:

[ Application Layer: Sideband / NomadNet / Custom Telemetry ]
                            │
[ Messaging Layer: LXMF (Lightweight Extensible Message Format) ]
                            │
[ Network Layer: Reticulum Network Stack (RNS Cryptographic Routing) ]
                            │
┌───────────────────────────┼───────────────────────────┐
│                           │                           │
▼                           ▼                           ▼
[ RNode (LoRa / SX1262) ]   [ TCP / UDP IP Sockets ]    [ Serial / KISS TNC ]

• RNS Core: Manages end-to-end identity, destination routing, packet packing, and proof of transit.
• Interfaces: Drivers that move raw bytes over physical hardware. An RNS instance can simultaneously bridge traffic across a 915 MHz LoRa RNode, a 2.4 GHz Wi-Fi UDP link, and an encrypted I2P tunnel.
• LXMF: A high-level messaging protocol built on top of Reticulum. It handles asynchronous message composition, delivery receipts, file attachments, and store-and-forward relaying.
• RNode: Open-source firmware running on transceivers like the SX1262 or SX1276 (via ESP32, nRF52, or Raspberry Pi). It exposes the LoRa PHY as a raw framing interface (KISS-compatible) to the RNS host.

02 · Cryptographic Addressing: Zero IP, Zero DNS

In an IP network, your identity is tied to an address assigned by your router (like 192.168.1.50) or ISP. If you unplug your router, your identity evaporates.

In Reticulum, addresses are cryptographic hashes of public keys:

1. Identity Generation: A node generates an asymmetric keypair (using Ed25519 for digital signatures and X25519 for Diffie-Hellman key exchange).
2. Destination Hashing: A destination address is a 16-byte (128-bit) truncated SHA-256 hash of the destination’s public key and application aspect string: $\text{Destination ID} = \text{Truncate}_{16}(\text{SHA-256}(\text{PublicKey} \parallel \text{Aspect}))$
3. No Central Coordination: There is no central server, registrar, or DHCP pool. Two devices created on opposite sides of the planet will never have an address collision.

Because the destination address is derived directly from the key, routing and authentication are mathematically unified. If you know the destination address, you automatically have the mathematical material required to verify that the node responding to you actually owns the private key.

03 · Path Discovery: Cryptographic Announces

Reticulum does not use periodic routing beacons or continuous distance-vector broadcasts that congest low-bandwidth radio channels. Instead, it relies on Announces:

[ Destination Node ] ──( Announce Packet )──► [ Transport Node A ] ──► [ Transport Node B ] ──► [ Client Node ]
   - Ed25519 Signed                              - Caches Next Hop        - Caches Next Hop       - Verifies Signature
   - Ephemeral Key                               - Increments Hop         - Increments Hop        - Derives Route
   - Zero Data Leak                              - Re-signs Path          - Re-signs Path

1. When a node wants to be reachable, it broadcasts an Announce packet. The announce contains its public key, an ephemeral key, and an Ed25519 cryptographic signature proving ownership.
2. Intermediate nodes with transport_enabled = True receive the announce, cache the incoming interface and reverse hop count, increment the hop counter, and rebroadcast it according to strict rate-limiting rules.
3. When a remote client receives the announce, it now knows exactly how many hops away the destination is and which local interface will reach it.
4. When the client sends data to that destination, it encrypts the packet using X25519 ECDH and AES-256-CBC with an ephemeral key. Only the owner of the destination’s private key can decrypt it. Intermediate transport nodes inspect the 16-byte destination hash, look up the next hop in their routing table, and forward the opaque ciphertext.

04 · LXMF Store-and-Forward: Propagation Nodes

Direct mesh messaging requires both the sender and receiver to be online at the exact same moment. If your friend turns off their radio to swap batteries, a direct message fails.

To solve this, Reticulum includes LXMF Propagation Nodes:

• A Propagation Node is a designated RNS server that advertises a mailbox service.
• When you send an LXMF message to an offline peer, your client deposits the encrypted message envelope onto a reachable Propagation Node.
• The message remains stored in ciphertext on the server.
• When the recipient powers up their radio, their client connects to the Propagation Node, requests pending message syncs, downloads the encrypted envelope, and decrypts it locally.
• The server never has access to the encryption keys and cannot read message content.

05 · FCC Part 15 Realities and the Part 97 Encryption Conflict

Reticulum’s flexibility across physical hardware creates distinct legal considerations under US radio law:

1. Unlicensed Operation under Part 15 (§15.247)

When connecting RNodes over the 902–928 MHz band:

• RNS software does not dictate RF legality; the transceiver hardware and firmware do.
• RNode builds typically tune to 125 kHz, 250 kHz, or 500 kHz bandwidths.
• Just as with other sub-1GHz systems, operating on a fixed frequency without 50-channel hopping means you cannot claim the 1-Watt conducted ceiling under §15.247(a)(1). Conducted power must remain within certified module limits (typically +14 to +20 dBm).
• Payload encryption is 100% lawful under FCC Part 15 unlicensed rules.

2. The Part 97 Amateur Radio Incompatibility Trap

Amateur radio experimenters frequently ask whether they can run Reticulum over 70cm (430–440 MHz) or 33cm (902–928 MHz) amateur allocations to take advantage of higher power limits (up to 1,500 Watts PEP).

Under 47 CFR §97.113(a)(4):

“No amateur station shall transmit… messages encoded for the purpose of obscuring their meaning…”

Because Reticulum’s core routing protocol requires end-to-end encryption for multi-hop packet transport and delivery proofs, standard Reticulum cannot be lawfully operated under Part 97 amateur privileges.

While Reticulum supports an experimental “Plaintext” destination mode for local broadcasts, plain destinations cannot be routed across multi-hop transport nodes. If you are building a Reticulum mesh, keep your transceivers configured for lawful FCC Part 15 unlicensed spectrum (902–928 MHz or 2.4 GHz) where AES-256 encryption is fully authorized.

06 · Field Checklist: Deploying a Multi-Interface Reticulum Node

• Flash Verified RNode Firmware: Use the official rnodeconf utility to flash firmware onto supported transceivers (LilyGO T-Beam, Heltec V3, or custom SX1262 boards) with verified SPI pin definitions.
• Calibrate LoRa PHY Settings: Set bandwidth, spreading factor, and coding rate matching your local link budget (e.g., 905.0 MHz, 250 kHz BW, SF9, CR 4/7 for a solid balance of speed and range).
• Configure Interface Buffers: In ~/.reticulum/config, ensure tx_power matches the hardware module grant and verify antenna SWR with a vector network analyzer before keying up.
• Segregate Transport Roles: Keep transport_enabled = False on battery-powered mobile clients. Set transport_enabled = True only on mains- or solar-powered fixed infrastructure.
• Deploy a Local Propagation Node: For reliable team messaging, spin up an LXMF propagation daemon on an inexpensive Raspberry Pi or Linux SBC at your base station to cache messages while field nodes are moving.