What is it?

Reticulum is a cryptography-based networking stack for wide-area networks built on readily available hardware, and can operate even with very high latency and extremely low bandwidth. Reticulum allows you to build very wide-area networks with off-the-shelf tools, and offers end-to-end encryption, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable packet acknowledgements and more.

No kernel modules or drivers are required. Reticulum runs completely in userland, and can run on practically any system that runs Python 3.

Reticulum is very well suited to built advanced networked applications running on simple hardware such as 1200-baud packet modems (OpenModem, 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 is easy to utilise IP (with TCP or UDP) as the underlying carrier for Reticulum. It is therefore trivial to tunnel Reticulum over the Internet or private IP networks. Reticulum is 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 systems in use today share a common limitation, namely that they require large amounts of coordination and trust to work, and to join the networks you need approval of gatekeepers in control. This need for coordination and trust inevitably leads to an environment of central control, where it’s very easy for infrastructure operators or governments to control or alter traffic, and censor or persecute unwanted actors.

Reticulum aims to require as little coordination and trust as possible. In fact, the only “coordination” required is to know the characteristics of physical medium carrying Reticulum traffic.

Since Reticulum is completely 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 for development and testing is using LoRa radio modules with an open source firmware (see the section Reference System Setup), connected to a small computer like a Raspberry Pi. As an example, the default reference setup provides a channel capacity of 5.4 Kbps, and a usable direct node-to-node range of around 15 kilometers (indefinitely extendable by using multiple hops).


To be as widely usable and easy to implement as possible, the following goals have been used to guide the design of Reticulum:

  • Fully useable as open source software stack
    Reticulum must be implemented with, and be able to run using only open source software. This is critical to ensuring the availability, security and transparency of the system.
  • Hardware layer agnosticism
    Reticulum shall be fully hardware agnostic, and shall be useable over a wide range physical networking layers, such as data radios, serial lines, modems, handheld transceivers, wired ethernet, wifi, or anything else that can carry a digital data stream. Hardware made for dedicated Reticulum use shall be as cheap as possible and use off-the-shelf components, so it can be easily replicated.
  • Very low bandwidth requirements
    Reticulum should be able to function reliably over links with a transmission capacity as low as 1,000 bps.
  • Encryption by default
    Reticulum must use encryption by default where possible and applicable.
  • Unlicensed use
    Reticulum shall be functional over physical communication mediums that do not require any form of license to use. Reticulum must be designed in a way, so it is usable over ISM radio frequency bands, and can provide functional long distance links in such conditions, for example by connecting a modem to a PMR or CB radio, or by using LoRa or WiFi modules.
  • Supplied software
    Apart from the core networking stack and API, that allows a developer to build applications with Reticulum, a basic communication suite using Reticulum must be implemented and released at the same time as Reticulum itself. This shall serve both as a functional communication suite, and as an example and learning resource to others wishing to build applications with Reticulum.
  • Ease of use
    The reference implementation of Reticulum is written in Python, to make it easy to use and understand. A programmer with only basic experience should be able to use Reticulum in their own applications.
  • Low cost
    It shall be as cheap as possible to deploy a communication system based on Reticulum. This should be achieved by using cheap off-the-shelf hardware that potential users might already own. The cost of setting up a functioning node should be less than $100 even if all parts needs to be purchased.

Where can I learn more?

The current reference implementation is a fully functional beta release, and can be found on GitHub and PyPi. The documentation is available in the Reticulum Manual.

If you just want to have a look at a program written with Reticulum, go check out Nomad Network.

21 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.

  4. Hi, this is a great project. Do you think it would be possible to eventually support Android/iOS? Or do these platforms make it impossible to configure the Wi-Fi for such purposes? Could it be accomplished on the new Linux phones (Pinephone, Librem 5)? Thank you.

    1. Yes, Android and iOS support is something that I am aiming for down the line. Whether it will be possible to use a mobile devices internal WiFi radio will probably be quite device-dependent. As far as I know it’s currently not possible on iOS, but on some Android devices it is. Although I have not yet had the pleasure of tinkering with any of the new Linux phones yet, I’d be willing to bet that it’s much easier on those. A shame it’ll probably be a while before we have a phone with full access to the baseband chips 😉

      But, realistically speaking, the first way it will be possible to use Reticulum on mobile devices will probably be by using an external radio (RNode for example) connected to the phone over bluetooth, or by having a Reticulum node on your local network that the phone app just transports packets through.

      As an example, I currently have a Reticulum node set up that is connected to both my local network, a LoRa interface and a VHF packet radio interface. This means that any device on the network can also communicate over LoRa and VHF packet, since Reticulum will transparently transport data over the correct interfaces, and conversely, I can reach Reticulum peers on my local network from afar using VHF.

  5. Hi Mark. First of all, I’m in love with RNS and the associated hardware interfaces you have developed, and I’m really excited about all of it. Now on to my question 🙂

    I have a RNS instance running on a couple RaspberryPi’s (it’s so easy to get up and running!), and I am able to setup a link (thank you for including some examples). I will try to lay out my situation below.

    Node A: create a RNS.Destination using a known destination hash, and call RNS.Transport.requestPath()
    Node B: responds to path request
    Node A: Request a RNS.Link to Node B
    Node B: Accept and prove link with Node A

    So the link is established, and I am able to send messages. However, looking at the link attributes on both ends:

    Node A: Link.owner = Node A hash, Link.destination = Node B hash (this looks ok)
    Node B: Link.owner = Node B hash, Link.destination = Node B hash (who called??)

    How does Node B know who the link request came from if Link.owner and Link.destination refer to itself? I read through your Reticulum Overview again, and the line ‘Only the intended destination will know “who called”, so to speak.’ made me think that Node B’s Link.destination should be the hash for Node A, so it knows who the link is associated with.

    It looks like RNS.Link.validateRequest() is explicitly setting the link destination to the link request packet destination (which would be the node receiving the request, instead of the node sending the request), which would make sense with what I’m seeing for the node receiving the link request (Node B in this example). However, it looks to me like the RNS.Link constructor (when self.initiator is True) is only setting self.request_data to the link public key (Lk), which doesn’t seem to align with the description of the content of the link request packet from the Overview document: “The link request packet contains the destination hash Hd, and an asymmetrically encrypted part containing the following data: The source hash Hs, a symmetric key Lk, a truncated hash of a random number Hr, and a signature S of the plaintext values of Hd, Hs, Lk and Hr.”. Which would mean the information about who is requesting the link isn’t being included in the link request packet in the first place. Let me know if I’m off-base here, and there is another explanation.

    Keep up the great work with all of this! I love the vision, and I’m very excited about implementing a network with RNS, RNode, and now OpenModem!

    1. Hi Howard

      Yes, that is not very clearly written. I guess the overview document could really do with an update in some areas. Thanks for pointing it out! Since writing that, I actually changed the underlying mechanisms of link establishment to achieve some things that were not possible in the first implementation.

      First, I moved the link encryption to much more efficient and stronger ephemeral Elliptic Curve DH scheme, which also provides forward secrecy. Second, I wanted link establishment to be possible with initiator anonymity, so any node can establish a link to a destination without _having_ to identify or reveal it’s own identity or location in the network.

      It should still be _possible_ to identify though, but I haven’t yet sat down and thought it through completely how that will be best implemented. If it’s an important feature to you though, I’d be happy to move that up the list of priorities, since it’s going to be relatively simple implementation-wise. It’s more a case of having to get it right from the get start 😉

      The third reason is that the current implementation is much better suited to the delay tolerance features that I’m currently working on. When these are implemented, Reticulum will support DTN modes for both single packets, links and resource transfers, which means you will be able to ask the network to handle a transfer reliably for you, even if some intermediate hops are temporarily offline. Data will be able to “queue” up so to speak, and move along when suitable hops become available, or find alternative paths.

      The destination you are seeing is actually the link id. It’s a hash of link request packet. When the link has been established, it becomes the “destination” that either node refers to to pass data to it’s remote end.

      I’ll update the overview document soon, it’s very much due for a revision, since a lot have happened since the last one.

      Thank you so much for your encouraging words! I am very pleased to hear that you enjoy experimenting with Reticulum! Please just write me a mail if you have any questions or other matters you wish to discuss.

      Kind regards,

    1. Yes, and I intend to do so once the Python implementation is complete 🙂

    1. Yes, it is. If one path through the network disappears, another one can take it’s place dynamically. The speed at which this happens could be improved though, and I’m planning on implementing a “search” operation, sort of a “reverse announce”, that can remap transport tables on-demand, if a node detects that the expected path has disappeared.

  6. Thank you for answering my previous question, Mark.

    I’d like to ask a few more things if you don’t mind. First, how does Reticulum compare to other open-source non-IP routing projects? The only one that comes to mind right now is BATMAN; the most glaring differences would be that it uses MAC addressing and non-encrypted communication. Beside that, how does Reticulum differ from BATMAN (and any others if there are), regarding scalability, topology, latency, overheads, simplicity, overall design…? (I prefer Reticulum much more, but I’d like your take nevertheless.)

    Also, do you think that Reticulum could ever support high-bandwidth low-latency communication, or is there anything in its design that will prevent this use case in the future (even for small networks)? Would it be just a matter of using high-end devices? And how much can Reticulum scale (how many nodes can it support)?

    Thanks again for your time, hope the project is going well. Cheers!

    1. Yes. The full API documentation and protocol-stable beta is very near release. And some actual real-world software built on Reticulum 🙂 Stay tuned.

Leave a Reply

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