Reticulum: A Cryptography-First Mesh Stack for Sovereign, Off-Grid Comms

Reticulum is a cryptography-based networking stack, created by Mark Qvist, that lets anyone build local and wide-area networks over almost any medium — LoRa radio, packet radio, serial cables, TCP/IP, or I2P — with no IP addresses, no DNS, and no central infrastructure. Every node generates its own Ed25519 and X25519 keys, so addressing and end-to-end encryption are self-issued rather than granted by an authority, and the network self-configures and self-heals across multiple hops. For sovereign Bitcoiners, it is a way to keep messaging and coordination alive when the internet is censored, throttled, or simply gone.

What Reticulum Is, and Why It Exists

The Reticulum Network Stack (RNS) describes itself as “the cryptography-based networking stack for building local and wide-area networks with readily available hardware.” It is engineered to keep working “under adverse conditions, such as extremely low bandwidth and very high latency” — the exact conditions you hit on a long-range radio link or a degraded grid. The project’s stated goal is to let “anyone operate their own sovereign communication networks” that “cannot be subjected to outside control, manipulation or censorship.”

That mission rhymes with Bitcoin’s. Where Bitcoin removes the need for a trusted third party to hold and move value, Reticulum removes the need for a trusted third party to hold and move addressing and trust on a network. There is no registrar, no ISP allocation, and no certificate authority in the loop. As the documentation puts it, “there is no central control over the address space in Reticulum — anyone can allocate as many addresses as they need, when they need them.” If you want the broader picture of why this matters, our digital sovereignty hub frames mesh networking alongside self-custody, private identity, and off-grid power.

Reticulum is written in Python 3 and runs entirely in userland — no kernel modules, no root, no special drivers. That makes it practical to run on a Raspberry Pi, an old laptop, an Android phone, or a single-board computer attached to a radio. It is reference software released under a permissive license, and it is the work of independent developer Mark Qvist, who also authors most of the surrounding application and hardware ecosystem. We owe the whole stack to that open-source effort.

Core Concepts: How RNS Actually Works

Reticulum is small but unusual. A handful of primitives do all the heavy lifting, and understanding them is the fastest way to reason about what the network can and cannot do.

Identities

Everything starts with an Identity: a self-generated keyset containing an Ed25519 key for signatures and an X25519 key for ECDH key exchange. An Identity is not necessarily a person — the docs describe it as “an abstraction that can represent any kind of verifiable entity,” such as a sensor, a relay, or a chat account. You create one offline, in milliseconds, with no registration and no permission. This is the same posture that makes a Bitcoin wallet or a Nostr keypair sovereign: the key is the account.

Destinations and Addressing

A Destination is where packets are addressed. Reticulum derives a destination’s address by hashing a human-readable “aspect” path (for example, messenger.user.inbox) together with the owning Identity’s public key, then truncating to a 16-byte (128-bit) value. The documentation calls 16 bytes “a reasonable trade-off between address space and packet overhead.” Because the address is cryptographically derived rather than assigned, no two parties can collide and no authority gatekeeps the namespace.

Announces and Path Discovery

When a node wants to be reachable, it broadcasts an announce — a small signed packet advertising a destination. Announces propagate hop by hop through transport nodes under predictable rules (hop limits and a bandwidth cap per interface) so that “an announce will propagate throughout the network in a predictable way, and make the announced destination reachable in a short amount of time.” Other nodes learn the next hop toward that destination without ever needing a global routing table or a DNS lookup.

Links, Encryption, and Forward Secrecy

For a conversation, two nodes establish a Link: an ephemeral, end-to-end encrypted channel. Reticulum uses X25519 ECDH to derive ephemeral keys, AES-256 in CBC mode (with PKCS7 padding) for symmetric encryption, and HMAC-SHA256 for authentication. Because the session keys are ephemeral, forward secrecy is the default — a compromised long-term key cannot retroactively decrypt past traffic. Establishing a link costs just “3 packets totalling 297 bytes,” and keeping one open costs less than half a bit per second, which is why RNS survives on links that would starve almost anything else.

Two more properties matter for censorship resistance. End-to-end encryption is automatic for normal destinations and cannot be accidentally switched off for messaging (Reticulum does define a PLAIN destination type, but it is reserved for special cases, not ordinary traffic). And Reticulum “does not use source addresses”: packets carry no information about the machine or person that originated them, giving the initiator a meaningful degree of anonymity by design.

Transport Nodes, Self-Healing Routing, and Resources

Any node can be promoted to a transport node that forwards traffic for others. Crucially, a transport node only ever knows the most direct next hop toward a destination — never the complete end-to-end path — and the network re-derives paths automatically when a link drops, making routing self-configuring and self-healing. For payloads larger than a single packet, the Resource mechanism handles “breaking the data into individual packets, sequencing the transfer, integrity verification and reassembling” the result. The minimum usable physical-layer MTU is 500 bytes, and RNS remains functional on any medium offering more than about 5 bits per second of throughput.

Transports and Interfaces: Run It Over Anything

Reticulum’s defining trick is that it is medium-agnostic. The same Identity and the same encrypted Link work whether the underlying carrier is a radio, a cable, or the public internet. The stack ships with a wide set of interfaces, including:

• RNodeInterface — controls a LoRa transceiver (an “RNode”) with full parameter management; the primary way to run RNS over long-range, license-free radio.
• KISSInterface and AX25KISSInterface — packet-radio modems and TNCs, including amateur-radio AX.25 encapsulation for licensed operators.
• SerialInterface and PipeInterface — direct serial links and program-driven virtual interfaces.
• TCPClientInterface, TCPServerInterface, and UDPInterface — tunnel Reticulum across the existing internet to bridge distant pockets of mesh.
• I2PInterface — carry RNS over the Invisible Internet Protocol for an added layer of network privacy.
• AutoInterface and BackboneInterface — zero-configuration discovery over local Ethernet/Wi-Fi, and high-throughput backhaul between sites.

Because interfaces can be mixed freely, a realistic deployment might bridge a neighbourhood LoRa mesh to a friend’s node across the country over TCP, then out to a packet-radio link in a dead zone — all transparently, all encrypted, with no gateway holding plaintext.

The Application Layer: LXMF, Sideband, and Nomad Network

RNS is plumbing; you talk to people through applications built on top of it. The most important is LXMF (the Lightweight Extensible Message Format), a messaging protocol that the project describes as “a simple and flexible messaging format and delivery protocol… using as little bandwidth as possible.” LXMF inherits Reticulum’s zero-config routing, end-to-end encryption, and forward secrecy.

LXMF supports two delivery styles. Opportunistic delivery embeds a short message in a single Reticulum packet for direct hand-off. For recipients who are offline, LXMF Propagation Nodes “offer a way to store and forward messages,” forming an encrypted, distributed message store that nodes synchronize among themselves — the same store-and-forward resilience that lets email survive an offline mailbox, but without any company owning the servers. User-facing clients built on LXMF include:

• Sideband — a desktop and Android messenger for everyday encrypted conversations over any Reticulum interface.
• Nomad Network — a terminal-based environment for messaging, pages, and file sharing across the mesh.
• MeshChat — a community web-based client for LXMF messaging.

This is where Bitcoin-adjacent use cases get concrete: coordinating a remote mining site, relaying a payment request, or passing a signed message when the internet is down. If your goal is moving value rather than chat, pair RNS with the broader off-grid playbook in sending Bitcoin over mesh networks and our guide to Bitcoin signing devices, which sign transactions fully offline before you ever touch a radio.

Hardware and Bandwidth Realities

The most popular radio for Reticulum is an RNode — open firmware, also by Mark Qvist, that turns a low-cost, widely available LoRa development board into a Reticulum-native transceiver. You flash the firmware, attach the board to any host over USB or serial, and RNS drives it directly. RNodes can also operate as standalone repeaters.

Be realistic about throughput. LoRa trades speed for range through its spreading factor (7 through 12, “7 being the fastest and 12 having the longest range”) and channel bandwidth. In practice a LoRa link delivers on the order of a few hundred bits per second up to several kilobits per second — enough for text, signed messages, sensor data, and small files, but not for video or web browsing. Our LoRa protocol explainer covers frequencies, spreading factors, and duty-cycle limits in depth. Reticulum is built precisely for this regime: a Link’s sub-bit-per-second keepalive and 500-byte MTU mean the protocol overhead barely registers against the radio’s own constraints.

Reticulum vs Meshtastic: A Neutral Comparison

Reticulum and Meshtastic are often mentioned together, and both are excellent open-source projects worth supporting. They solve overlapping problems with different architectures, and many people run both. The table below lays out the factual differences — not a verdict.

A useful way to hold both in mind: Meshtastic is exceptionally easy to deploy on dedicated LoRa hardware, while Reticulum offers a unified, end-to-end-encrypted address space that spans many mediums at once. They complement each other more than they compete. For Bitcoiner-specific context, see Meshtastic getting started and why Bitcoin and mesh networks are the same fight.

Where Reticulum Fits a Bitcoin Sovereignty Stack

Reticulum does not replace your other tools — it sits underneath them as a censorship-resistant transport. A few patterns worth thinking through:

• Keep coordination alive when the ISP drops. A LoRa-backed RNS mesh can carry messages between your home node, a remote miner, and an off-site relay even with no internet at all, as explored in keeping your node and miner online when the ISP drops.
• Sign offline, transmit over radio. Build and sign a transaction air-gapped with a dedicated signing device, then move the small signed payload over LXMF for a peer to broadcast.
• Layer privacy on privacy. Reticulum’s lack of source addresses pairs naturally with sovereign identity systems; if you also run Nostr, our Nostr NIPs reference shows where key-based identity overlaps with RNS’s self-issued keys.
• Build on open data. Hardware planning — radios, power, miners — can lean on the machine-readable datasets in our open data hub.

Two companion guides shipping alongside this one round out the off-grid money stack: Nostr Wallet Connect for remote Lightning control, and Cashu and Fedimint ecash for bearer payments that work over thin links. Reticulum is the transport; those are the payments and control layers that ride on top.

Frequently Asked Questions

Does Reticulum need the internet to work?

No. Reticulum needs no internet, no IP addresses, and no DNS. It can run entirely over LoRa radio, packet radio, or serial links between machines that have never touched the public internet. It can also tunnel over the internet (via TCP, UDP, or I2P) when that is convenient, but the internet is just one optional medium among many.

Is Reticulum traffic encrypted by default?

Yes. End-to-end encryption is always on, using X25519 key exchange, AES-256 symmetric encryption, and HMAC-SHA256 authentication, with ephemeral keys providing forward secrecy. Encryption is automatic for normal destinations and cannot be accidentally turned off for messaging, and packets carry no source address, so the originating node is not identified in the data it sends.

What hardware do I need to start?

At minimum, a computer that runs Python 3 — a Raspberry Pi, a spare laptop, or an Android phone. To go off-grid over radio, add an RNode: open firmware flashed onto a common, inexpensive LoRa development board, connected over USB. Two nodes within radio range can then form a private, encrypted link with no other infrastructure.

How fast is a Reticulum network?

It depends entirely on the slowest medium in the path. Over TCP or local Wi-Fi it is fast; over LoRa it ranges from a few hundred bits per second to several kilobits per second, depending on spreading factor and bandwidth. Reticulum stays usable on any link above roughly 5 bits per second, which is why it suits text, signed messages, and small files rather than streaming.

How is Reticulum different from Meshtastic?

Meshtastic is a turn-key LoRa messenger that runs as firmware on dedicated radios; it secures each channel with a shared key and, since firmware 2.5, also encrypts direct messages with per-node public keys. Reticulum is a general-purpose networking stack that runs over many mediums at once, gives every node a self-issued cryptographic address, and provides end-to-end encryption with forward secrecy between individual endpoints. Many sovereign setups run both, and the projects complement rather than compete.

Can I send Bitcoin over Reticulum?

Reticulum itself is a transport, not a wallet. You sign a transaction offline on a dedicated device, then use an LXMF-based app like Sideband or Nomad Network to relay the small signed payload to a peer who broadcasts it to the Bitcoin network. The radio link moves bytes; your signing device and wallet still enforce the rules. See our companion guides on mesh Bitcoin transmission for working patterns.