Quick answer
There is no single best off-grid messaging protocol for Bitcoiners — it depends on medium, range, and whether you need a true peer mesh. Meshtastic and Reticulum are encrypted peer meshes; LoRaWAN is a gateway-and-server model; Briar and Bridgefy are short-range messengers; packet radio reaches far.
There is no single “best” off-grid messaging protocol for Bitcoiners. The right tool depends on the medium you can use, the range you need, whether you require strong end-to-end encryption, and whether you are building a true peer mesh or relying on operator infrastructure. Meshtastic and Reticulum are encrypted peer meshes well suited to moving signed transactions and coordination data without the internet; LoRaWAN is a gateway-and-server telemetry model; Briar and Bridgefy are short-range delay-tolerant messengers; and amateur packet radio offers long range but legally restricts content encryption in most jurisdictions.
Sovereign Bitcoiners care about communication that survives an internet outage, an ISP block, or a deliberate shutdown. A signed Bitcoin transaction is just a few hundred bytes of public data, so it can travel over surprisingly slow, narrow-band links. Coordination messages, node telemetry, and mining-site status can travel the same way. This guide lays out the major mesh and off-grid protocols a Bitcoiner might reach for, sourced from each project’s own documentation, so you can match a tool to a need rather than chase a winner. For the broader philosophy behind this, see our companion piece on Bitcoin and mesh networks as the same fight for sovereignty and the wider sovereignty hub.
Peer mesh versus infrastructure: the first distinction that matters
Before comparing features, separate the protocols into two families. A true peer mesh has no privileged nodes: every device can originate, relay, and receive traffic, and the network keeps working if any node disappears. Meshtastic, Reticulum, Bridgefy, and Briar’s local-radio modes are peer meshes. An infrastructure model routes traffic through dedicated gateways and a central server. LoRaWAN is the clearest example: end-devices only ever talk to gateways, and gateways forward everything to a network server that holds the keys and routing logic.
Neither family is superior in the abstract. Infrastructure models scale telemetry cleanly and are easy to operate; peer meshes degrade gracefully and resist single points of failure. For censorship-resistant Bitcoin coordination, the peer-mesh family is usually the closer fit, but a self-hosted LoRaWAN network can still be a legitimate, internet-independent telemetry layer for a mining site.
The protocols, one by one
Meshtastic (LoRa peer mesh)
Meshtastic is an open-source firmware that turns inexpensive LoRa radios into a long-range text-and-telemetry mesh. It runs on sub-GHz ISM bands (typically 433, 868, or 915 MHz depending on region) and uses a managed-flooding mesh so messages hop node-to-node. Per the project documentation, payloads are encrypted with AES256-CTR using a per-channel pre-shared key (the PSK can be 0, 128, or 256 bits), and as of firmware 2.5 direct messages can additionally use public-key cryptography. The packet header is always sent unencrypted so that nodes can relay packets they cannot themselves decrypt. The firmware is licensed GPL-3.0. Realistic range is a few kilometres per hop with line of sight, extended by multi-hop relaying. It is a natural fit for moving small signed payloads, position, and telemetry off-grid. Start with our Meshtastic getting-started primer for Bitcoiners, the LoRa protocol explainer, and the deep dive on broadcasting Bitcoin transactions over Meshtastic. To bridge a local mesh to the wider internet (carefully, since the default public broker exposes metadata), see our sibling Meshtastic MQTT guide.
Reticulum / RNS (medium-agnostic crypto networking)
Reticulum is not a radio; it is a complete cryptographic networking stack that runs over almost any medium: LoRa (via RNode firmware), packet radio, serial lines, Wi-Fi, Ethernet, and TCP/IP tunnels, in any combination. Its documentation states that it uses X25519 for ECDH key exchange, Ed25519 for signatures, AES-256 in CBC mode, and HKDF/HMAC-SHA256, with forward secrecy from ephemeral per-link keys, and that strong encryption is mandatory by default. Destinations are addressed by 16-byte (128-bit) hashes derived from truncated SHA-256, and the network supports up to 128 hops. Remarkably, it can remain functional on links as slow as 5 bits per second. The reference implementation is released under the Reticulum License (the protocol itself is public domain). For Bitcoiners it is a powerful transport layer: it can carry messaging (LXMF/Nomad Network), file transfer, or a relayed signed transaction across whatever physical links you have. We cover it fully in the Reticulum network guide.
LoRaWAN (star-of-stars, operator model)
LoRaWAN shares the LoRa radio layer with Meshtastic but is architecturally the opposite: a star-of-stars topology where end-devices reach gateways in a single hop and gateways forward IP packets to a central network server. It is not a peer mesh. Security uses AES-128 with two session keys: the NwkSKey protects message integrity (the MIC), and the AppSKey encrypts the application payload. Devices carry a 64-bit DevEUI and are assigned a 32-bit DevAddr by the network server; over-the-air activation (OTAA) derives the session keys from an AppKey. Range to a gateway can reach roughly 15 km in rural areas. Because it depends on a network server, LoRaWAN is internet-independent only if you self-host that server (open-source servers such as ChirpStack exist). Its best fit is large-scale sensor telemetry, including monitoring a mining or hashcenter site, rather than peer-to-peer Bitcoin messaging.
Briar (Bluetooth / Wi-Fi / Tor delay-tolerant messaging)
Briar is an open-source (GPLv3) secure messenger built for resilience. It syncs end-to-end-encrypted messages over Bluetooth and local Wi-Fi when there is no internet, over the Tor network when there is, and even via USB sticks or SD cards as a sneakernet. It uses the Bramble protocol suite, which is explicitly designed for delay-tolerant networks, and it has no central server. Range is limited to Bluetooth/Wi-Fi local distances when offline, but global when relaying over Tor. Briar is not a long-range radio mesh, so it will not move data across a valley by itself, but it is excellent for private, surveillance-resistant coordination and could carry out-of-band material such as a partially signed transaction between nearby devices. Pair it with hardware from our Bitcoin signing devices overview for an air-gapped workflow.
Bridgefy (Bluetooth mesh SDK)
Bridgefy is a Bluetooth Low Energy mesh SDK that app developers embed so their apps keep working without the internet by relaying messages phone-to-phone over nearby devices. Its current documentation describes end-to-end encryption based on the Signal Protocol, with the option for developers to add their own. It is worth stating neutrally that security researchers published vulnerabilities against Bridgefy in 2020, after which the developers said they were moving to the Signal Protocol; treat any messenger’s threat model on its own terms. The SDK source is published on GitHub but it is a commercial SDK rather than a copyleft project. Per-hop BLE range is on the order of 100 metres, extended by multi-hop. Bridgefy is most relevant when you are building an offline-capable app, not as an end-user Bitcoin tool.
Packet radio / AMPRNet (licensed amateur)
Amateur packet radio carries TCP/IP and AX.25 frames over licensed ham bands, with the 44.0.0.0/8 address space (44net / AMPRNet) historically reserved for it. It offers genuine long range, especially on HF, and runs entirely on RF without the internet. The critical constraint is regulatory: under the United States FCC Part 97, messages “encoded for the purpose of obscuring their meaning” are prohibited (47 C.F.R. § 97.113(a)(4)), and most national amateur services impose similar rules, so you generally cannot encrypt content. Authentication may be permissible, but private confidential traffic is not the intended use. Identity is tied to your callsign, so there is no anonymity, and commercial traffic is typically restricted. A signed Bitcoin transaction is public data, but Bitcoiners should weigh content-encryption and commercial-use rules in their own jurisdiction (rules differ in Canada and elsewhere) before relying on it.
Comparison table
| Protocol | Medium | Topology | Typical range | Encryption model | Internet-independent | Open-source status | Best-fit use |
|---|---|---|---|---|---|---|---|
| Meshtastic | LoRa (sub-GHz ISM) | True peer mesh (managed flood) | ~Few km/hop, multi-hop | AES256-CTR per-channel PSK; PKC for DMs (2.5+) | Yes (optional MQTT bridge) | GPL-3.0 firmware | Off-grid text, telemetry, signed-tx relay |
| Reticulum / RNS | Medium-agnostic (LoRa, packet radio, IP, serial) | True peer mesh, up to 128 hops | Depends on medium | X25519 + Ed25519 + AES-256, forward secrecy, default on | Yes | Reticulum License (protocol public domain) | Encrypted transport across any link |
| LoRaWAN | LoRa (sub-GHz ISM) | Star-of-stars (gateways + server) | ~Up to 15 km to gateway | AES-128; NwkSKey + AppSKey | Only if server self-hosted | Open spec; open servers exist (e.g. ChirpStack) | Large-scale sensor / site telemetry |
| Briar | Bluetooth, Wi-Fi, Tor, USB/SD | Peer-to-peer, delay-tolerant | Local (offline) to global (Tor) | End-to-end (Bramble protocol suite) | Partial (local links yes; Tor needs net) | GPLv3 | Resilient private coordination |
| Bridgefy | Bluetooth Low Energy | True peer mesh (phone-to-phone) | ~100 m/hop, multi-hop | End-to-end (Signal Protocol, per current docs) | Yes (BLE local) | Commercial SDK, source on GitHub | Embedding offline messaging in apps |
| Packet radio / AMPRNet | Amateur RF (HF/VHF/UHF), AX.25 | Routed / varies | Local to long-distance (HF) | Content encryption restricted by law | Yes (RF) | Open protocols; licence required | Licensed long-range, EmComm |
One project status note for completeness: the consumer goTenna Mesh device was discontinued as the company refocused on professional, public-safety, and defense products. It is omitted from the table above because it is no longer a consumer option.
Matching a protocol to a Bitcoin need
To broadcast a signed transaction from a location with no internet, a LoRa peer mesh (Meshtastic) or Reticulum carrying a transport app is the most direct path: a raw transaction is small enough for narrow-band radio, and a single internet-connected node anywhere in the mesh can relay it to the network. To coordinate people privately and resiliently, Briar’s delay-tolerant model is strong, and Meshtastic works well over distance. To monitor a mining site or hashcenter at scale, a self-hosted LoRaWAN network is a clean telemetry layer. For building your own application-layer network over mixed links, Reticulum’s medium-agnostic stack is the most flexible foundation. Many sovereign setups combine layers: radio mesh for the physical hop, Reticulum or Meshtastic for transport, and a signing device kept fully air-gapped. Explore the practical scenarios in off-grid hashcenter comms and keeping your node online when the ISP drops, and browse machine-readable reference data in the open-data hub.
Frequently asked questions
Which of these is a true peer mesh, and which is not?
Meshtastic, Reticulum, and Bridgefy are true peer meshes where any node can relay traffic, and Briar is peer-to-peer over its local links. LoRaWAN is the exception: it is a star-of-stars infrastructure model where end-devices only reach gateways, which forward to a central network server. Packet-radio networks vary and can be routed or meshed depending on how operators build them.
Can I really send a Bitcoin transaction over one of these?
Yes in principle, because a signed transaction is only a few hundred bytes of public data. Meshtastic and Reticulum are the most practical carriers, and a single internet-connected node in the mesh can forward the transaction to the wider network. We walk through this in our guide to Bitcoin over Meshtastic and in sending Bitcoin without internet.
Why can’t I just encrypt everything on amateur packet radio?
In most jurisdictions, amateur-radio rules prohibit transmitting messages encoded to obscure their meaning. The United States FCC Part 97 § 97.113(a)(4) is the well-known example, and Canada and other countries have comparable restrictions. Authentication is generally viewed as permissible, but confidential content encryption is not the intended use, so packet radio suits open, long-range, experimental traffic rather than private messaging.
Is LoRaWAN useless for sovereignty because it needs a server?
No. LoRaWAN is simply a different model. If you self-host the network server using open-source software, you control the keys and routing and remain internet-independent for telemetry. It is just not a leaderless peer mesh, so it is better suited to site monitoring than to censorship-resistant messaging between peers.
How do the encryption guarantees compare?
Reticulum mandates strong encryption by default (X25519, Ed25519, AES-256) with forward secrecy. Meshtastic encrypts payloads with AES256-CTR per channel and adds public-key direct messages, though its header is intentionally unencrypted for relaying. LoRaWAN uses AES-128 with separate network and application keys. Briar and Bridgefy provide end-to-end encryption at the messaging layer. Amateur packet radio generally cannot encrypt content by law. Always confirm the current threat model in each project’s own documentation before trusting it with sensitive coordination.
Where should a beginner start?
If you want hands-on results quickly, begin with Meshtastic using inexpensive LoRa boards and our getting-started primer. As your needs grow toward mixed media or stronger default cryptography, graduate to Reticulum. Keep the larger goal in view through the sovereignty hub: communication you control is the same project as money you control.




