Meshtastic vs MeshCore vs Reticulum: which off-grid mesh should you use?

Meshtastic and MeshCore are firmware that turn a LoRa radio board into a node of an off-grid text mesh, while Reticulum is a networking stack that runs on a computer or phone and uses LoRa as one of many possible links. They also disagree about who relays. In Meshtastic every radio can rebroadcast, in MeshCore only dedicated repeaters do, and in Reticulum only instances configured as transport nodes forward traffic.

The table compares them as of October 2026, from each project’s own documentation and repository.

Meshtastic, MeshCore and Reticulum each use a different routing model: Meshtastic floods with care, MeshCore floods once to learn a path and then source-routes, and Reticulum forwards hop by hop along paths learned from announces.

Meshtastic rebroadcasts what it hears up to a hop limit, which defaults to 3 and cannot exceed 7. Before rebroadcasting, a node listens briefly and stays quiet if another node has already relayed the packet, so the mesh avoids repeating everything. Nodes in the ROUTER and ROUTER_LATE roles rebroadcast regardless. Since version 2.6, direct messages start with managed flooding, then remember which neighbours relayed successfully and use them as the next hop.

MeshCore separates clients from infrastructure. Its FAQ is explicit that companion radios do not repeat and that only repeaters, and room servers set to repeat, forward packets. The first message to a contact floods; the reply carries back the list of repeaters it crossed, and later messages embed that path so only those repeaters retransmit. If a path breaks, the client retries 3 times and then floods again by default. Group channels have no path, so they always flood, and repeater operators can cap how far flood traffic travels. Paths name each repeater by the first byte of its public key, which allows up to 64 hops; 2-byte and 3-byte path hashes, added in firmware 1.14, allow 32 and 21.

Reticulum spreads reachability with announces. An announce carries a destination’s hash and public key, and transport nodes forward it under set rules, including a cap on how many times an announce is retransmitted, which the manual sets from a default value of 128. Each transport node then knows only the most direct way to get a packet one hop closer to its destination. Ordinary instances do not forward, because enable_transport defaults to no.

Meshtastic and MeshCore need a supported LoRa board per person or site, while Reticulum needs a host that runs it, plus an RNode board only if you want LoRa links.

• Meshtastic runs on boards built around Nordic nRF52840, Espressif ESP32 and Raspberry Pi RP2040, among others, with Semtech LoRa transceivers. The project strongly recommends the newer SX126x or LR11xx transceivers and says nRF52 devices use less power than ESP32 devices, so they suit solar and handheld use.
• MeshCore runs on 433, 868 and 915 MHz LoRa devices listed in its web flasher, such as RAK WisBlock, Heltec and LilyGo boards. Its repository has board variants for ESP32, nRF52, RP2040 and STM32 parts. Devices such as the LilyGo T-Deck run it standalone with no phone.
• Reticulum runs in userland on any system with Python 3. For LoRa it uses an RNode, which the manual describes as an open platform rather than one product, built on ESP32 or nRF52 boards with SX1262, SX1268, SX1276, SX1278 or SX1280 transceivers. The RNode connects to its host over USB, Wi-Fi or Bluetooth, so the board is a radio modem and the stack runs on the host.

How does LoRa work? covers the radio all three share, and ESP32 mesh options compared places them beside the other meshes an ESP32 board can run.

Reticulum is the strictest, Meshtastic and MeshCore protect direct messages better than channels, and on all three a shared or default channel key means anyone holding it can read that channel.

• Meshtastic encrypts channel messages with AES-CTR under a key per channel. Its documentation states three limits plainly: there is no forward secrecy, AES-CTR provides no integrity so a message can be altered or forged by someone who guesses its content, and anyone with a channel key can claim to be any node. The default primary channel key is published. Direct messages are stronger: since firmware 2.5, the sender combines its private key with the recipient’s public key using X25519 and encrypts with AES-256-CCM.
• MeshCore gives each node an Ed25519 identity and signs its adverts, which carry its name and, optionally, its position. Direct messages are encrypted with AES-128 under a key derived from the two nodes’ keys, with an HMAC-SHA256 tag cut to 2 bytes, according to the payload format and source. Group messages are marked unverified: they carry no sender signature, so any holder of the channel key can choose any sender name, and the FAQ publishes the default public channel’s key. The project’s road map lists new encryption specifications among the topics for a future version 2 protocol.
• Reticulum does not allow unencrypted packets to a destination. It uses X25519 key exchange, Ed25519 signatures, AES-256 in CBC mode and HMAC-SHA256. Links get forward secrecy by default with per-link ephemeral keys, and single packets can get it too by enabling ratchets on a destination.

Metadata is a separate question. Meshtastic sends packet headers in the clear so that nodes can relay what they cannot decrypt, and MeshCore paths name the repeaters a message crossed. For what any encryption leaves visible, see what can go wrong with mesh messaging encryption.

Meshtastic is GPL-3.0, MeshCore’s firmware is MIT, and Reticulum’s protocol is public domain while its reference implementation uses the custom Reticulum License.

• Meshtastic: the firmware and the Android and Apple apps are GPL-3.0 on GitHub.
• MeshCore: the routing library and firmware are MIT. Its FAQ says everything is open source except the T-Deck firmware and the native mobile apps, which are free to use, and that some optional features are unlocked for a fee. The web client and JavaScript library are MIT.
• Reticulum: the protocol was dedicated to the public domain in 2016. The reference implementation’s licence grants broad rights but forbids use in systems designed to harm people and in AI training datasets, and the README warns against machine-generated derivative implementations. RNode firmware is GPL-3.0.

For a group of friends, Meshtastic is usually the quickest; for a town-wide network, MeshCore’s repeater design is built for it; for a product, the licence and the shape of the product decide.

• A group of friends or a club. Meshtastic lets every radio relay, so a handful of handhelds form a mesh with no infrastructure, and its open-source apps cover Android, Apple devices and the web. With MeshCore, handhelds do not relay, so the group would need at least one repeater.
• A town or region. MeshCore was designed for repeater networks: clients stay quiet, direct messages follow learned paths, and operators can cap flood traffic, all of which save airtime on a busy shared channel. In Meshtastic any node can rebroadcast, and the ROUTER roles are meant for well-placed infrastructure nodes that always relay.
• A product. MeshCore’s MIT firmware is the easiest to embed in closed hardware, and its README pitches it at custom embedded solutions. Meshtastic’s GPL-3.0 carries copyleft obligations for firmware you ship. Reticulum suits a product that must route across LoRa, Wi-Fi and IP together, provided its licence terms fit.

Of the three, only Reticulum works with phones alone, and only over links phones already have, such as a shared Wi-Fi network or the internet. Meshtastic and MeshCore need a LoRa radio: a phone is a client of its own radio, connected over Bluetooth LE, USB or Wi-Fi, and phones do not relay for each other. Reticulum runs on Android in Sideband, and its AutoInterface finds peers on a local Wi-Fi or Ethernet segment with no router or DHCP server, so phones on one network can reach each other without a LoRa board. Long range still needs a radio such as an RNode.

Setting up a first node takes about the same three steps for each: put the software on a device, set the radio for your region, and connect a client.

1. Meshtastic. Attach the antenna first, since the project warns that powering a radio without one can damage it. Flash the firmware from flasher.meshtastic.org, set the LoRa region so the radio is allowed to transmit, then pair the Android or Apple app, or open the web client.
2. MeshCore. Flash Companion, Repeater or Room Server firmware from the MeshCore web flasher, choose the radio preset for your region, then connect the MeshCore app over Bluetooth LE or the web app over USB. Repeaters are configured through the web config tool or remotely from the app.
3. Reticulum. Install it with pip install rns and run rnsd as a service, or start with Sideband on Android. For LoRa, flash an RNode with rnodeconf --autoinstall and add it as an interface.

Offline Protocol answers the phones-alone question differently. Its mesh SDK runs inside apps on the phones people already carry, which relay for each other over Bluetooth LE and the local network with no LoRa radio, under MLS end-to-end encryption. LoRa reaches much further per hop than the Bluetooth LE and Wi-Fi radios in a phone, so the two suit different distances and densities, as Offline Protocol vs Meshtastic explains.

Reticulum is one of the SDK’s five transports, disabled by default. The SDK ships the device half: an app attaches to a Reticulum gateway daemon over the SDK’s gateway contract, and that daemon is a deployment you run, not something the SDK includes. The SDK has no Meshtastic or MeshCore transport.