The Problem: Why Traditional Networks Fail in Real-World Environments
Most modern communication networks are designed around a shared set of assumptions: that infrastructure is stable, topology is predictable, connectivity is continuous, and some form of trusted central coordination exists. In civilian and enterprise environments, these assumptions generally hold well enough that their structural limitations remain largely invisible. The network works, services remain reachable, and routing converges as expected.
In operational environments, however, those assumptions break down.
Disaster response zones, remote industrial operations, unmanned systems, field deployments, and contested or denied environments all exhibit similar constraints. Infrastructure may be damaged, degraded, or entirely absent. Communication links may be intermittent, asymmetric, or bandwidth-constrained. Nodes may be mobile, intermittently powered, or operating at the edge of radio coverage. Central coordination, if it exists at all, may be delayed, unreachable, or intentionally disrupted.
Under these conditions, conventional networking architectures do not fail because radios stop transmitting. They fail because the network layer itself assumes continuity that no longer exists. Protocols designed for stable paths and persistent end-to-end connectivity struggle when links fragment, routes oscillate, or segments of the network become temporarily isolated.
The core challenge, therefore, is not simply extending radio range or increasing throughput. It is ensuring survivability under fragmentation — maintaining meaningful communication when the network is unreliable, partitioned, or only partially connected by design.
The Reticulum networking protocol was created specifically to address this problem. It is a decentralised, cryptography-native architecture built to operate under adverse conditions, where instability is normal rather than exceptional, and where resilience must be engineered into the network layer itself.
What Is Reticulum?
Reticulum is a cryptography-based networking stack designed to build both local and wide-area networks across heterogeneous physical mediums. It is not tied to any specific radio, hardware platform, or transport layer. Instead, it provides a self-contained networking layer that can operate independently of traditional IP infrastructure while remaining capable of interoperating with it when required.
At its core, Reticulum is hardware agnostic and transport agnostic. It does not depend on fixed infrastructure and does not assume the presence of central coordination. Most importantly, it is identity-based rather than address-based. Communication is anchored to cryptographic identities instead of IP or MAC addresses, allowing endpoints to remain reachable even as their physical connectivity or network attachment changes.
Reticulum can operate over a wide range of physical and logical transports. These include long-range radio systems such as LoRa and packet radio, custom physical layers, serial links, WiFi, Ethernet, and standard TCP or UDP over IP networks. It is equally capable of functioning across hybrid paths that combine several of these mediums simultaneously. A single Reticulum node may bridge radio, wired, and IP segments into a unified mesh without requiring reconfiguration at higher layers.
Although Reticulum does not require IP to function, it can encapsulate over IP when convenient. This allows it to operate natively over radios or serial connections while also tunnelling across the public Internet or private IP networks where appropriate.
The protocol is engineered to function over links as slow as 5 bits per second, assuming a physical-layer MTU of approximately 500 bytes. This unusually low baseline requirement is not incidental; it reflects Reticulum’s foundational design philosophy. Communication must remain possible even under extreme bandwidth constraints and high-latency conditions.
Rather than optimising for peak throughput or minimal latency under ideal conditions, Reticulum prioritises reliable delivery in degraded, intermittent, and partitioned environments. Its design choices reflect the assumption that instability is normal, not exceptional.
How the Reticulum Network Protocol Works, at a High Level
Reticulum uses cryptographic identities to represent endpoints, services, and applications. Rather than routing data to static IP addresses, the network dynamically discovers and maintains paths to identities as connectivity allows.
Routing paths are established opportunistically and updated as the network changes. When direct communication is not possible, data can be forwarded through intermediate nodes. Messages may be stored and forwarded when links are intermittent, allowing communication to continue even when the network becomes temporarily partitioned.
End-to-end encryption is a default property of Reticulum, not an optional feature layered on top. Trust is derived from cryptographic identity rather than network position.
Reticulum does not prioritise maximum throughput or low latency above all else. Instead, it prioritises reliable delivery across uncertain and degraded network conditions.
Reticulum Architecture: Identity, Routing, and Scalability
To understand why Reticulum behaves differently from traditional mesh networking systems, it is important to examine its architectural foundations.
Identity and Addressing
Reticulum does not use IP addresses or ports.
Instead, it uses destinations — 16-byte (128-bit) hashes derived by truncating a SHA-256 hash of identifying characteristics. A destination may appear as:
13425ec15b621c1d928589718000d814
Destinations are named in dotted notation (e.g., app.remotesensor.temperature), but only the truncated hash is transmitted. Long names do not increase packet size.
For single destinations, Reticulum automatically appends the public key before hashing. This guarantees uniqueness even when multiple nodes use identical logical names.
Routing is therefore to cryptographic identity, not network location.
Node Roles: Instances and Transport Nodes
Every device running Reticulum operates as a Reticulum Instance. An instance is capable of creating identities, sending and receiving packets, establishing links, and participating in the network at an endpoint level. However, not every instance is required to forward traffic for others.
Some systems may be explicitly configured as Transport Nodes by enabling the enable_transport = Yes directive. These nodes are typically fixed, stable, or intended to remain available for extended periods. Their role is to forward traffic on behalf of other nodes and to participate in multi-hop routing across the mesh.
Only Transport Nodes take part in forwarding packets between peers that are not directly connected. Regular instances rely on these transport-capable systems to extend connectivity beyond their immediate neighbours. This deliberate separation of roles is central to Reticulum’s scalability. By restricting forwarding responsibilities to designated nodes, the protocol reduces routing overhead, limits broadcast amplification, and avoids forcing every participant to maintain global routing knowledge. As a result, large and sparse meshes can scale without overwhelming lightweight or intermittently connected devices.
The Announce Mechanism
Reachability in Reticulum is established through a mechanism known as the announce. When a node wishes to make one of its destinations reachable across the network, it transmits an announce packet containing the destination hash, the associated public key, optional application-specific data, a random nonce to ensure uniqueness, and an Ed25519 signature verifying authenticity.
Announces propagate outward through the mesh according to a defined set of rules designed to balance convergence speed with bandwidth discipline. If an identical announce has already been received, it is ignored. When a Transport Node receives a new announce, it records the neighbour from which it was received and the associated hop count. Each retransmission increments this hop count, and propagation ceases once a configurable maximum—128 hops by default—is reached.
To prevent routing traffic from overwhelming the network, announce retransmissions are bandwidth-limited on a per-interface basis, typically capped at approximately two percent of available capacity. Announces with lower hop counts are prioritised, ensuring that local connectivity converges before more distant segments of the mesh. If retransmission does not appear to propagate successfully, limited retries may occur.
Importantly, no node in the network ever maintains a complete end-to-end path. Each Transport Node stores only the next hop toward a destination. Paths effectively build outward from the originating node as announces propagate through the network. Even in complex deployments operating near the 128-hop limit, full end-to-end reachability can converge in roughly one minute, provided sufficient bandwidth exists to process announce traffic.
Path Requests (On-Demand Discovery)
Reticulum does not rely solely on proactive announce propagation to maintain reachability across the entire mesh. While announces gradually establish paths outward from each destination, the protocol does not require full global convergence before communication can occur.
If a node has data to send to a destination for which it does not currently know a path, it can generate a Path Request. This request is forwarded by Transport Nodes through the network. When the destination itself, or any node that already has a valid route to it, receives the request, it generates a response. That response then propagates back toward the origin, establishing the necessary next-hop state along the way.
This mechanism enables routing to be discovered on demand rather than requiring constant global synchronisation. Control traffic is reduced because routing information does not need to be continuously flooded across the network when it is not being used. Communication can begin even in partially converged meshes where some announces have not yet propagated to every segment.
As a result, routing state in Reticulum is built incrementally and locally. Nodes maintain only the information required to reach active destinations, rather than maintaining a fully synchronised global routing table. This design significantly improves scalability and efficiency in large, sparse, or intermittently connected networks.
Packet Format and Wire Efficiency
Reticulum is engineered for environments where bandwidth is limited and overhead must be tightly controlled. Its wire format is compact, deterministic, and designed around the assumption of a physical-layer MTU of approximately 500 bytes.
A Reticulum packet consists of a two-byte header, followed optionally by an Interface Access Code (IFAC) field ranging from 0 to 64 bytes when interface authentication is enabled. This is followed by one or two 16-byte address fields, a one-byte context field, and a data payload of up to 465 bytes.
The two-byte header encodes multiple pieces of routing and processing information within a minimal footprint. It specifies whether interface authentication is present, the propagation type (broadcast or transport), the destination type (single, group, plain, or link), and the packet type (such as data, announce, link request, or proof). The second header byte carries the hop count, allowing propagation limits to be enforced without additional routing structures.
The compactness of the protocol is reflected in its on-wire sizes. Excluding any optional IFAC field, a Path Request occupies approximately 51 bytes. An Announce packet is roughly 167 bytes. A Link Request requires about 83 bytes, and a Link Proof approximately 115 bytes. Establishing a fully encrypted and verified link therefore requires only three packets totalling around 297 bytes. Once established, maintaining an open link consumes roughly 0.45 bits per second in keepalive traffic.
These figures are not incidental; they are foundational to the protocol’s ability to operate over extremely constrained links. By minimising structural overhead and keeping control traffic tightly bound, Reticulum remains viable on low-data-rate radios, high-latency channels, and bandwidth-limited mesh segments where traditional IP-based protocols would struggle to converge or remain stable.
Interface Access Codes (IFAC)
Reticulum provides a mechanism for creating logically segmented or access-controlled network segments through the use of Interface Access Codes (IFAC). This feature enables named virtual networks and passphrase-protected interfaces without requiring central infrastructure or external authentication servers.
When IFAC is enabled on an interface, each outbound packet includes a signature derived from a shared Ed25519 identity associated with that interface. Upon reception, the interface verifies this signature before the packet is accepted into the local Reticulum instance. Packets that fail verification are discarded immediately, before they participate in routing, announce processing, or link establishment.
This mechanism enables practical network segmentation within an otherwise open mesh. Nodes can be configured to accept traffic only from peers that possess the correct interface identity or shared secret, effectively creating whitelisted trust domains. Authentication occurs at the interface boundary, reducing unnecessary processing and preventing unauthorised traffic from consuming routing state or bandwidth.
Importantly, this capability is achieved without centralised control, certificate authorities, or external key distribution systems. Interface authentication remains consistent with Reticulum’s broader design philosophy: decentralised, cryptographically enforced trust boundaries established directly between participating nodes.
Encryption and cryptographic foundations
Reticulum is cryptography-native by design. Security is not an optional layer applied above the network stack; it is embedded directly into the protocol’s core behaviour. Identity, routing, encryption, and verification are all rooted in modern elliptic-curve cryptography.
All traffic addressed to single destinations is encrypted by default. When a node sends a packet, it generates a fresh ephemeral key pair and performs an Elliptic Curve Diffie–Hellman (ECDH) exchange using X25519 with the destination’s public key. Because that public key has already been learned through the announce mechanism, the sender can perform this key exchange locally, without requiring any additional handshake traffic before transmission. The resulting shared secret is passed through a key-derivation process to produce symmetric encryption keys specific to that packet.
A new ephemeral key is generated for every packet. This provides forward secrecy at the packet level: even if a long-term private key were compromised at some later time, previously captured traffic would remain unreadable.
For sustained communication, Reticulum supports links — persistent encrypted channels established between two destinations. A link is created through a lightweight three-packet exchange totalling approximately 297 bytes on the wire. During this process, both sides generate new X25519 key pairs, perform an ECDH exchange, and derive a shared symmetric channel key. Once established, the link provides authenticated, bidirectional communication across any number of hops with minimal overhead, including a keepalive cost measured in fractions of a bit per second.
Reticulum also provides a cryptographic proof-of-delivery mechanism. When enabled, a receiving destination can compute the SHA-256 hash of a received packet and sign that hash with its Ed25519 private key. This signed proof is then routed back through the network toward the sender. Upon receipt, the sender verifies the signature against the known public key of the destination. This mechanism allows delivery confirmation to be verified end-to-end without relying on trusted intermediaries, central servers, or transport-layer acknowledgements. Delivery assurance becomes a cryptographic property rather than a by-product of infrastructure trust.
The protocol relies on a concise and well-defined primitive suite. Ed25519 is used for digital signatures, including announce authentication and delivery proofs. X25519 is used for ECDH key exchange. HKDF is employed for key derivation. Symmetric encryption uses AES-256 in CBC mode with PKCS7 padding, and message authentication is provided by HMAC-SHA256. Hashing operations utilise SHA-256 and SHA-512 where appropriate.
Consistent with its privacy-oriented architecture, Reticulum packets do not include source addresses. Intermediate nodes forward packets based solely on destination identity and locally maintained routing state. As a result, the initiator of communication is not automatically exposed to the wider network, preserving initiator anonymity even in multi-hop scenarios.
Store-and-forward and delay tolerance
In unstable networks, loss of a route does not necessarily mean loss of data. When a destination is temporarily unreachable, Reticulum can buffer packets and retry delivery once connectivity is restored. Rather than immediately discarding traffic because an end-to-end path is not currently available, the protocol tolerates interruption and resumes transmission when conditions permit.
This behaviour places Reticulum closer in spirit to Delay-Tolerant Networking (DTN) architectures than to conventional MANET designs. In traditional IP-based meshes, a broken route typically results in dropped packets and failed sessions. In contrast, Reticulum treats partition as a normal operating condition. Short-term fragmentation does not automatically translate into communication failure.
By allowing messages to persist across temporary disconnections, Reticulum enables communication to survive in environments where links fluctuate, nodes move in and out of range, or segments of the network become briefly isolated.
Resource abstraction for large transfers
While Reticulum is highly efficient for small, message-oriented exchanges, it is not limited to minimal payloads. For larger data transfers, the protocol provides a higher-level construct known as a Resource. Resources operate over established links and provide a reliable mechanism for transferring substantial amounts of data across multi-hop paths.
The Resource mechanism abstracts away the complexity typically associated with large transfers in constrained or unreliable networks. Data is automatically divided into appropriately sized chunks, sequenced, and transmitted over the encrypted link. Integrity verification ensures that corrupted or missing segments are detected. When necessary, retransmission occurs automatically to recover lost data. On the receiving side, chunks are reassembled transparently into the original payload. Optional compression may be applied to improve efficiency over bandwidth-limited links.
From an application developer’s perspective, this significantly reduces implementation complexity. Rather than manually handling fragmentation, ordering, acknowledgement, and recovery logic, an application can invoke the Resource mechanism and rely on Reticulum to manage the transfer lifecycle. This allows anything from small configuration payloads to large files to be transmitted reliably across multi-hop meshes, even when links are intermittent or high latency.
Why Reticulum support 128+ hops
Most conventional MANET protocols begin to degrade beyond approximately 10 to 30 hops. As network diameter increases, routing tables grow in proportion to the number of nodes and links, control traffic expands through repeated flooding, and link-state synchronisation mechanisms consume increasing bandwidth. In large or highly mobile topologies, this overhead can destabilise routing, introduce oscillations, or make convergence impractically slow.
Reticulum avoids these limitations through a fundamentally different architectural approach. Instead of relying on address-based routing with globally synchronised topology information, it uses identity-based routing with compact, per-destination next-hop state. Each Transport Node stores only the information required to forward traffic one hop closer to a given destination. No node maintains a full map of the network.
Path discovery is performed on demand, either through announce propagation or through explicit Path Requests when necessary. Announce traffic itself is tightly controlled, with bandwidth caps and prioritisation rules that prevent uncontrolled flooding. Because routing state is constructed incrementally and locally, rather than through global link-state synchronisation, the amount of state maintained by any individual node remains bounded and proportional to active destinations rather than total network size.
The default maximum hop count is 128, and this limit is configurable. In practice, the protocol’s compact state model and controlled propagation mechanisms allow it to operate across large, sparse, or intermittently connected meshes where traditional MANET designs would encounter scaling limits.
Comparison with OLSR, BATMAN, and IP-Based MANETs
Traditional MANET protocols such as OLSR (Optimized Link State Routing) and BATMAN (Better Approach To Mobile Ad-hoc Networking) are fundamentally address-based systems. Nodes are identified by IP or MAC addresses, and routing decisions are made by constructing and maintaining tables that map those addresses to next hops.
OLSR is a link-state protocol that relies on periodic dissemination of topology control information throughout the network. It uses Multi-Point Relays (MPRs) to reduce broadcast redundancy, but it still depends on regular topology floods to maintain a global view of the network. Even when no application data is flowing, control traffic continues in order to keep routing state synchronised. As the number of nodes increases, the amount of routing information that must be distributed and maintained grows accordingly.
BATMAN takes a different approach, using originator messages (OGMs) to build a gradient toward each node rather than distributing full link-state information. Later versions, such as BATMAN V, operate closer to the MAC layer and improve mobility handling. However, the system remains address-based and assumes that reasonably stable connectivity exists between participating nodes. While it can perform well in moderately sized or quasi-static meshes, it is still optimised primarily for efficient IP routing rather than survivability under severe fragmentation.
Both OLSR and BATMAN are designed to route IP traffic. They assume that end-to-end connectivity will usually be present and that links, while possibly lossy, are sufficiently stable for routing convergence. They do not natively provide end-to-end encryption as a mandatory property of the protocol. Initiator anonymity is not a design goal; source addresses are embedded in packet headers. Nor do these protocols implement store-and-forward or delay-tolerant behaviour as intrinsic features of the routing layer.
Reticulum differs at a foundational level. It is identity-based rather than address-based. Packets do not carry source addresses, preserving initiator anonymity. Encryption is not optional but built into the protocol’s default operation. Routing state is compact and local, maintained per destination rather than as a globally synchronised topology map. Path discovery occurs on demand through announces and Path Requests rather than through constant topology floods. The protocol also incorporates delay-tolerant behaviour, allowing communication to persist across temporary partitions. Finally, Reticulum is transport agnostic, operating natively over radios, serial links, or IP without assuming any particular lower-layer technology.
Reticulum does not attempt to maximise IP routing efficiency under ideal conditions. Instead, it prioritises survivability under adversarial, degraded, and fragmented network conditions. Where traditional MANET protocols optimise for throughput and convergence speed in moderately stable meshes, Reticulum is designed to continue functioning when connectivity is intermittent, trust is limited, and infrastructure cannot be assumed.
Problems Solved by Reticulum Mesh Networking
This architecture directly addresses common failure modes in real-world communication systems.
When infrastructure is unavailable or denied, Reticulum does not rely on central servers or base stations. Networks can form organically from available nodes.
When topology changes due to mobility or interference, routing adapts dynamically.
When connectivity is intermittent, communication does not simply fail. Messages traverse the network as opportunities arise.
When trust relationships are unclear, cryptographic identity provides a secure foundation without requiring centralised authorities.
These properties distinguish Reticulum from traditional IP-based networks, cellular systems, and many mesh implementations that assume stable, continuous paths.
Why Beechat Uses Reticulum
Beechat’s design philosophy centres on decentralisation, resilience, and operational sovereignty. We build communication systems intended to function when conditions are constrained, degraded, or contested.
Reticulum aligns closely with these principles. Its resilience-first architecture matches the environments in which Beechat systems operate. Its transport-agnostic design allows support for multiple radios and bands without redesigning the network layer. Its open architecture ensures long-term viability without dependence on proprietary control.
Rather than building a proprietary networking protocol, Beechat chose to build on Reticulum because it is grounded in these principles and proven across diverse deployments. This allows us to focus on hardware robustness, secure radio design, and operational integration while relying on a mature networking foundation.
As global reliance on connectivity increases, systems that assume ideal conditions represent growing operational risk.
Resilient, decentralised networking offers an alternative path. By designing for failure as a normal condition rather than an exception, it becomes possible to build communication systems that continue functioning when conditions deteriorate.
Beechat builds on open foundations such as Reticulum because we believe this approach is essential for long-term resilience, independence, and real-world reliability. We use Reticulum-rs, a Rust implementation optimised for low size, weight, and power (SWaP) hardware. Our presentation at FOSDEM 2026 provides a deeper technical overview of this implementation and the design considerations behind running Reticulum on constrained embedded platforms.
Sources
Our FOSDEM 26 presentation
https://www.youtube.com/watch?v=_EaoPjlTHT
Reticulum Manual – Official Protocol Documentation
https://reticulum.network/manual/
Reticulum Rust implementation
https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
Reticulum Network Stack – Reference Implementation (GitHub)
https://github.com/markqvist/Reticulum
The Zen of Reticulum – Foundational Philosophy