What is it?

Reticulum is a cryptography-based networking stack for low-bandwidth, high-latency, wide-area networks built on cheap and readily available hardware. Reticulum allows you to build very wide-area networks with cheap off-the-shelf tools, and offers end-to-end encryption, cryptographically backed multi-hop transport, efficient addressing, resource caching, unforgeable packet acknowledgements and much more.
Reticulum is very well suited to built advanced networked applications running on simple hardware such as 1200-baud packet modems (MicroModem, for example), data radios, LoRa-based radios (RNode, for example), or even ad-hoc WiFi or ethernet networks.
Reticulum is a complete networking stack, and does not use IP or higher layers, although it can be easily tunnelled through conventional IP networks. This frees up a lot of overhead, that has been utilised to implement a networking stack built directly on cryptographic principles, allowing resilience and stable functionality in open and trustless networks.


The primary motivation for designing and implementing Reticulum has been the current lack of reliable, functional and secure minimal-infrastructure modes of digital communication. It is my belief that it is highly desirable to create a cheap and reliable way to set up a wide-range digital communication network that can securely allow exchange of information between people and machines, with no central point of authority, control, censorship or barrier to entry.
Almost all of the various networking stacks in wide use today share a common limitation, namely that they require large amounts of coordination to work. You can’t just plug in a bunch of ethernet cables to the same switch, or turn on a number of WiFi radios, and expect such a setup to provide a reliable platform for communication. The designers of the Internet Protocol had the foresight to create a protocol that powers the modern Internet, and works brilliantly in world very different from when it was conceived, but networks using the traditional IP stack needs large amounts of coordination from the people involved, and without central actors in ultimate control of network segments, it is very easy for a single person to render the platform unusable for everyone else. These limitations are inherent to the design principles of IP, and during the design of IP, this was a very reasonable tradeoff indeed.
Reticulum aims to require as little coordination and trust as possible. In fact, the only “coordination” required is to know how to get connected to a Reticulum network. Since Reticulum is medium agnostic, this could be whatever is best suited to the situation. In some cases, this might be 1200 baud packet radio links over VHF frequencies, in other cases it might be a microwave network using off-the-shelf radios. At the time of release of this document, the recommended setup is using cheap LoRa radio modules with an open source firmware (see the chapter Reference System Setup), connected to a small computer like a Raspberry Pi. The reference setup provides a channel capacity of 4.8 Kbps, and a usable direct node-to-node range of around 15 kilometers (indefinitely extendable by using multiple hops).


The current reference implementation of Reticulum is written in Python, and can be imported into any program to allow it to communicate over a Reticulum network. The API is very simple to use, and has been designed to allow even beginner programmers to build applications using the Reticulum stack.
Furthermore, Reticulum comes with a few basic communication utilities, such as messaging and network diagnostics provided. These make it easier to get started, either as a user of the network or as a developer.

Encryption and amateur radio?

Many countries ban the use of encryption when operating under an amateur radio license. Reticulum offers several encryptionless modes, while still using cryptographic principles for station verification, link establishment, data integrity verification, acknowledgements and routing. It is therefore perfectly possible to include Reticulum in amateur radio use, even if your country bans encryption.


The first alpha release of Reticulum will be in early 2019. The entire project is open source.

Where can I learn more?

If you want to learn more about the details of Reticulum, you can read the current overview document, it is available as a PDF or for reading online. You can also browse the current codebase at the GitHub repository.

9 thoughts on “Reticulum Network Stack

  1. Hi I saw your yt video and the repo looking good..have you done any distance tests? for 9600 baud?

    1. Hi Kerry! The videos on my youtube page are very old, hope to get some new ones up soon with info on Reticulum. Just wanted to say that the current version of the modem and software is a bit nicer than what is in those old videos 😉
      I’ve been running quite a few tests over 1200 baud with a couple of MicroModems attached to Yaesu radios. Been doing file transfer over 30 kilometers distance from base station to a moving vehicle at highway speed and it performed great 🙂 I don’t have any legacy 9600 baud TNCs to test with, but there’s nothing stopping that from working. I’ll be running some tests with Direwolf TNC in 9600 baud mode soon.
      I’ve also done a bit of testing with the prototypes of RNode (a LoRa based packet radio, it’ll be available here very soon). RNode has data rates from about 1000 bps to 37.5 kbps, and works great with Reticulum as well.
      If you’re interested in the project I hope you will keep an eye on the blog and the repo, and please ask any questions that comes to mind, I will be more than happy to discuss!

    1. Ah well, as you might be able to infer from the calendar, that date has come and passed. I thought I had updated this page with a more realistic estimate, but apparently not, so thanks for the reminder.
      This being more or less a one-man show means a limited amount of resources, and I had to prioritise other projects first, namely RNode and it’s software.

  2. I’ve got some APRS projects I”m working on with your excellent aprslib and micro_modem designs. Once I get my head a little better around the inner working of the APRS network I’ll have to look into this. Any change it will be/can be/already is made workable with micropython? I’d love to plug this into an ESP8266 or something similar.

    1. Yes, the plan is to make it micropython compatible. Almost everything is already, but a few external dependencies are not supported on micropython by default, and I’ll be working on porting those over. Right now though, I’m putting the finishing touches on my new hardware project OpenModem, so I won’t make much progress on this before OpenModem is released.

  3. Wondering what can I do to help and if their is a update on Reticulum? Also in the paper it is not clear how you plan to switch frequency (lora to 1200) can you explain more?

    1. I’d very much appreciate help, especially if you are good with Python or other core aspects of the project. Lately I’ve had to put Reticulum on pause, because of life intervening. I’ve moved both my home and my entire workshop and business, which has taken up lots of time and resources, so I needed to focus on the work that pays the bills 😉 I’ll probably be able to return more or less full time to finishing Reticulum before the end of the year, and when the first reference implementation is done, and I have finalised the specification for the protocol, it’ll be much easier to use, test and develop further. I hope you will have just a little more patience with me 🙂
      Currently Reticulum supports multiple mediums like LoRa and 1200-baud AFSK at the same time, or individually. You can easily make a network that cross-connects the two different modulations, simply by adding a LoRa interface and an 1200-baud interface to the same Reticulum node. The internal routing stack will automatically transport packets from one medium to another if needed.

      1. Would definitely like to help. Something of this sort is not yet done (no tcp/ip). We need to get more people involved and have a direct plan (solving certain situations). What can we do to help? Also I do think that their is place for servers that can transmit longer distances and store messages of a user is not present this can be optional but does provide more of a backbone.

Leave a Reply

Your email address will not be published. Required fields are marked *