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 (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 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 current reference implementation is fully functional, and can be found on GitHub. I am currently writing more substantial application examples and API documentation. At this point wire format and API is still subject to change, but the protocol is functional as is.

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.

19 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!

Leave a Reply

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