# Protocol Comparison Reference

This page provides a technical comparison between MeshCore and Meshtastic - the two most widely deployed open-source LoRa mesh networking platforms. Both run on similar hardware and serve similar goals, but make very different design choices.

## Feature Comparison Table

<table id="bkmrk-featuremeshcoremesht"><tr><th>Feature</th><th>MeshCore</th><th>Meshtastic</th></tr><tr><td>Routing</td><td>Hybrid flood-first / direct-route-after: the first message to an unknown destination is flooded (carrying the payload), and the path it took is recorded as a byproduct; subsequent messages are sent directly along that learned path. There is no separate route-request/route-establishment phase.</td><td>Controlled (managed) flooding with hop limit and duplicate suppression. Most roles rebroadcast, but rebroadcast depends on role and rebroadcast mode (e.g. CLIENT\_MUTE does not rebroadcast). See *meshtastic.org/docs/overview/mesh-algo/*.</td></tr><tr><td>Encryption</td><td>Channel traffic: AES-128 in ECB mode with a 2-byte (16-bit) truncated HMAC-SHA256 MAC (encrypt-then-MAC, MAC prepended). Direct messages use a per-pair shared secret from ECDH (Ed25519 identity keys transposed to X25519). **Note:** ECB mode leaks repeated/structured plaintext blocks and the 16-bit MAC is forgeable by an active attacker (~32k attempts); key length (128 vs 256) is not the main security difference. Keys are static, so there is no forward secrecy.</td><td>AES-256-CTR with a shared PSK per channel.</td></tr><tr><td>Key Exchange</td><td>ECDH using each node's Ed25519 identity keypair transposed to X25519/Curve25519; each node pair derives a unique 32-byte shared secret (AES-128 uses 16 bytes of it). Keys are static (no forward secrecy or key revocation).</td><td>Static pre-shared key (PSK) distributed out-of-band; no per-pair key agreement for channels</td></tr><tr><td>Direct messages</td><td>End-to-end encrypted using a per-pair ECDH-derived key (AES-128-ECB with a 2-byte MAC and static keys, so no forward secrecy).</td><td>End-to-end encrypted via X25519 ECDH + AES-CCM (introduced with PKI direct messaging in recent firmware; verify the exact version against meshtastic.org).</td></tr><tr><td>Infrastructure role</td><td>Explicit firmware types: Companion (BLE or USB serial), Repeater, Room Server, and Sensor.</td><td>Router/Repeater/Client/Tracker among ~12 device roles in current firmware (some, e.g. REPEATER, are deprecated); the exact count varies by firmware version. As of 2026; see meshtastic.org device-config Roles.</td></tr><tr><td>Node discovery</td><td>Advertisement packets (flood or zero-hop)</td><td>NodeInfo broadcast flood</td></tr><tr><td>Position sharing</td><td>In advertisements (optional)</td><td>Continuous broadcast to channel (configurable interval)</td></tr><tr><td>Scalability</td><td>Better at high node counts due to path-based unicast reducing channel utilization</td><td>Best under ~100 nodes; flooding overhead grows with network size</td></tr><tr><td>Network mapping</td><td>App shows routing topology; community map at meshcore.co.uk/map.html</td><td>meshmap.net aggregates public data</td></tr><tr><td>Message storage</td><td>Room servers (store-and-forward)</td><td>[Store and Forward module](https://wiki.meshamerica.com/books/meshtastic/page/store-and-forward-module) (node-based)</td></tr><tr><td>App ecosystem</td><td>MeshCore app (iOS/Android)</td><td>[Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) (iOS/Android/web)</td></tr><tr><td>Web interface</td><td>config.meshcore.io (config). Community-run interfaces (e.g. app.meshcore.nz) also exist and may change. As of 2026.</td><td>client.meshtastic.org</td></tr><tr><td>Firmware update</td><td>Web flasher (flasher.meshcore.io) over USB. OTA updates are also supported on nRF52 devices via the `start ota` command.</td><td>Web flasher + OTA via app</td></tr><tr><td>Primary hardware</td><td>T114, RAK4631, T-Beam v1.2+ and similar. SX126x/LR11xx radios are strongly preferred, but SX127x (SX1276) is also supported in current firmware (limited build variants); the real constraint on older ESP32 boards is MCU/flash size, not the radio chip.</td><td>All of the above + many more (supports SX1276, SX1262, and others)</td></tr><tr><td>License</td><td>Open source, MIT (upstream: github.com/ripplebiz/MeshCore; community fork: github.com/meshcore-dev/MeshCore)</td><td>Open source (github.com/meshtastic)</td></tr></table>

## When to Choose MeshCore

- Building dedicated network infrastructure - repeaters on towers, rooftops, or hilltops where path-based routing reduces channel congestion.
- Your community already uses MeshCore and you need to integrate with an existing deployment.
- You want stronger per-pair direct message encryption - ECDH per-pair keys provide better isolation than a shared channel PSK.
- Deploying a large-scale network (100+ nodes) where flooding creates significant channel congestion.

## When to Choose Meshtastic

- You need the widest hardware compatibility - Meshtastic has the largest catalog of supported boards. (Note: MeshCore now also supports some SX127x/SX1276 boards in current firmware, so SX1276 is no longer MeshCore-incompatible.)
- You need WiFi/MQTT bridging for internet-connected nodes.
- Your community or region already has an established Meshtastic network.
- You need TAK/ATAK integration or other Meshtastic-specific integrations.
- You prefer a larger community and more third-party tooling.

*Sources: MeshCore packet format documentation (github.com/meshcore-dev/MeshCore), Meshtastic documentation (meshtastic.org), Meshtastic protobufs (github.com/meshtastic/protobufs)*