Meshtastic vs MeshCore: Routing, Roles, and Which to Pick

Meshtastic and MeshCore are both open-source firmware projects that build text-messaging mesh networks on LoRa radios, often on the same hardware, but they route messages differently and cannot talk to each other. In short: Meshtastic lets nearly every node help relay traffic using “managed flooding,” while MeshCore keeps ordinary user devices from relaying at all and sends direct messages along learned paths through dedicated repeaters.

This comparison is drawn from each project’s own documentation. LoRa Mesh Atlas is independent and not affiliated with either project, and this site has not run side-by-side field tests.

Quick comparison

	Meshtastic	MeshCore
Who relays	Most roles relay; CLIENT_MUTE does not (Device config)	Only repeaters (and room servers with repeat on); companions never relay (FAQ)
Broadcast routing	Managed flooding with SNR-weighted delays	Flooding through repeaters (FAQ 5.5)
Direct message routing	Next-hop routing since 2.6, with flooding fallback	Flood first, then a learned path embedded in each packet
Hop limit	Default 3, maximum 7 (LoRa config)	Up to 64 hops with the default 1-byte path hashes; 32 with 2-byte and 21 with 3-byte hashes (firmware 1.14+) (FAQ)
Radio settings	Named presets, Long Fast as the long-standing default	Community-suggested presets from the app’s server
Firmware license	GPL-3.0 (firmware repo)	MIT (README)
Apps	Official Android, Apple, web, Python CLI	Mobile app by Liam Cottle (freemium, the core team calls it the official app), web app, CLI tools
Internet bridging	Built-in MQTT module	No MQTT feature documented in the sources reviewed

How Meshtastic routes messages

Meshtastic is built around flooding with a twist. Per the Overview and Mesh Broadcast Algorithm pages:

• A node that hears a new packet with hops remaining waits a short random delay, weighted so that nodes with weaker signal (usually farther away) go first.
• If it hears another node rebroadcast that packet during the wait, it usually cancels its own copy. ROUTER and ROUTER_LATE relay regardless.
• Every relay uses up one hop. The default hop limit is 3.
• Since firmware 2.6, direct messages first flood; then each node along the way learns which neighbor successfully relayed and addresses only that “next hop” on later messages. If a node doesn’t hear its next hop relay, its last retry falls back to flooding.

The upside is resilience: any node in the right place can carry a message, which suits moving groups. The cost is airtime. The project’s own blog acknowledges that large meshes on the default Long Fast preset can congest, and it recommends faster presets for big networks (see our presets guide).

How MeshCore routes messages

MeshCore’s README describes it as “a lightweight, portable C++ library that enables multi-hop packet routing for embedded projects,” and notes that “Companion” nodes do not repeat messages “to prevent adverse routing paths from being used.” The FAQ fills in the details:

• Clients don’t repeat. “MeshCore clients do not repeat. This is the core of MeshCore’s messaging-first design.” Only repeaters, and room servers with set repeat on, relay.
• Path learning for direct messages. The first message to a contact floods. The recipient sends back a delivery report listing the repeaters it passed through, and that path is embedded in later packets. A repeater retransmits a direct packet only if its address matches the next hop in the path.
• Fallback. If a known path breaks, the app retries on the old path and, by default, floods on the last retry.
• Group channels always flood, because there is no single destination. Repeater operators can limit flood traffic by hop count with set flood.max.
• Adverts. Nodes announce their name, position, and public key in a signed “advert.” Clients advertise only when the user taps the button; repeaters send a flood advert every 12 hours by default.

The packet format carries the path as a list of short hashes (the first byte or bytes of each repeater’s public key), which is how repeaters check whether a packet is meant for them.

Node types and roles

Meshtastic has one firmware with selectable roles: CLIENT, CLIENT_MUTE, CLIENT_BASE, ROUTER, ROUTER_LATE, TRACKER, SENSOR, TAK roles, and others. The docs strongly recommend leaving most nodes as CLIENT, CLIENT_MUTE, or CLIENT_BASE. See Meshtastic roles explained.

MeshCore uses separate firmware builds, chosen at flash time:

• Companion (BLE, USB serial, or Wi-Fi) to connect a phone or computer app.
• Repeater to extend coverage.
• Room server, a simple bulletin-board server that stores posts so users can catch up later.
• Sensor and other example builds for developers.

Our MeshCore guide explains each type.

Encryption at a glance

Both projects encrypt payloads, with different designs.

• Meshtastic encrypts channel messages with AES using a pre-shared key; the default channel key is public. Direct messages (since 2.5) use X25519 key exchange and AES-256-CCM. Firmware 2.8, still an alpha release as of October 2026, adds signed broadcasts (Encryption docs).
• MeshCore identifies nodes by Ed25519 public keys and signs adverts. Messages carry a short cipher MAC, and the source code encrypts with AES-128 using a shared secret. The payloads doc notes that group messages carry no sender signature, so “any channel-key holder can choose any sender name.” The default public channel key is published in the FAQ.

In both systems, anything sent on the default public channel should be treated as public.

Apps and cost

Meshtastic’s official clients are free. MeshCore’s FAQ says the radio firmware is free and open source, while the native Android/iOS app by Liam Cottle uses a freemium model (an in-app purchase removes a wait timer on remote repeater management), and the T-Deck firmware offers a paid registration for extra features like deeper map zoom. The FAQ also says the T-Deck firmware and the native mobile apps are not open source.

Can MeshCore talk to Meshtastic?

No. Neither project documents interoperability, and their documented packet structures differ: Meshtastic uses a 16-byte cleartext routing header (Overview), while MeshCore uses a 1-byte header followed by an encoded path (Packet Format). Their radio settings also differ by default. A Meshtastic user and a MeshCore user can’t message each other directly.

Can the same device run both?

Many popular boards appear in both projects’ supported lists (for example, the MeshCore FAQ lists RAK4631, Heltec V3, T-Deck, Station G2, and T1000-E, all of which also have Meshtastic support pages). But a radio runs one firmware at a time. Switching means reflashing, which replaces the other firmware. On nRF52 boards, Meshtastic’s docs note that leftover data in flash can cause problems and describe a factory erase; see our flashing guide. Check /devices/ for which firmware each board supports.

Which should you pick?

Based on how each project describes itself, here is a use-case view rather than a verdict:

• Join whatever your neighbors run. A mesh is only useful if people near you are on it. Check local groups first (finding nodes near you).
• Small moving groups without fixed infrastructure (hikers, events): Meshtastic’s default behavior lets every client help relay, which doesn’t depend on anyone installing a repeater. MeshCore’s FAQ suggests flashing two devices as companions when there are no other users nearby; because companions don’t relay, reaching beyond direct radio range depends on a repeater.
• Networks built around planned, well-sited repeaters: MeshCore’s design concentrates relaying on repeaters by default and learns paths for direct messages, which its docs present as a way to reduce collisions.
• Store-and-catch-up messaging: MeshCore’s room servers hold message history for users who were out of range.
• Internet bridging, sensors, ATAK, or a broad official app ecosystem: Meshtastic documents built-in MQTT, telemetry, and TAK roles.

A note on MeshCore project governance

On April 23, 2026, the MeshCore core team published a post on the official MeshCore blog announcing a split with a former team member, citing a trademark application and disagreements over AI-generated code. The post states that “the only ‘official’ MeshCore is the github repo” (meshcore-dev/MeshCore) and lists meshcore.io as the team’s site. This guide uses that repository and its documentation as the MeshCore source. We have only read the core team’s account; we have not verified the other party’s position or the status of any trademark filing.