Bitcoin Over Meshtastic: Signing and Broadcasting Transactions Off-Grid with BTC Mesh

Two Sovereign Layers, One Story

Bitcoin is sovereign money. Meshtastic is sovereign comms. On paper, the two belong together — but until recently, signing a transaction and actually getting it onto the Bitcoin network still required an internet connection somewhere in the pipeline. That last mile quietly reintroduced the ISP, the cell tower, and eventually a platform, right into the most important moment of a pleb’s day: broadcasting a transaction.

BTC Mesh — the open-source project by eddieoz, hosted at github.com/eddieoz/btc-mesh — closes that last mile. It lets you sign a Partially Signed Bitcoin Transaction (PSBT) on an air-gapped device, relay it hop-by-hop across a Meshtastic LoRa mesh, and have a gateway node in range of the internet rebroadcast it to the Bitcoin peer-to-peer network. No ISP at the signing end. No platform in the middle. Just LoRa and Bitcoin, wired together by the pleb community.

This is the layer where the sovereign stack starts compounding. Money plus comms equals payments that route around capture. Credit goes to eddieoz and the contributors who packaged this up in a way plebs can actually run. D-Central didn’t build any of this — we’re publishing to help more plebs use it.

What BTC Mesh Actually Does

The mental model is a relay race. There are three legs.

1. Leg 1 — Signing. A pleb, somewhere off-grid or on-grid, has a wallet. They build a transaction (or have it built for them by a coordinator), sign it, and produce a PSBT or a serialized signed transaction in hex.
2. Leg 2 — Relay over the mesh. BTC Mesh takes the signed transaction, chunks it into LoRa-sized packets, and hands it to a local Meshtastic node. The mesh forwards those packets hop-by-hop toward the nearest gateway node — a Meshtastic node that also has an internet connection or access to a Bitcoin node.
3. Leg 3 — Broadcast. The gateway reassembles the chunks, validates, and submits the transaction to the Bitcoin peer-to-peer network using its internet-connected Bitcoin node (bitcoind, a public mempool API, or both).

The clever parts are in the packetization and the acknowledgments. LoRa frames are small — tens to a few hundred bytes of payload depending on spreading factor. A raw Bitcoin transaction can easily be 200–500+ bytes, and complex multisig spends get larger. BTC Mesh splits the payload into numbered fragments, sends them over the mesh, has the gateway acknowledge receipt, and retransmits anything that drops. When the gateway has every fragment, it reconstitutes the transaction and submits it. The protocol sits cleanly on top of Meshtastic’s existing packet format — it reuses the mesh, not replaces it.

Why It Matters: Use Cases for the Plebs

This is not a toy. There are real scenarios where the only path from signed to in the mempool runs through a LoRa mesh.

Disaster Response and Grid Failure

Hurricanes, wildfires, ice storms, regional blackouts. The internet goes first. Cell towers last until their batteries die. In a disaster window that can span days or weeks, plebs who need to move money — to buy fuel, to pay family, to accept aid from peers — have no rails. BTC Mesh gives them rails. A neighborhood with a handful of solar-powered Meshtastic nodes and one internet-connected gateway (at a friend’s place with a surviving Starlink dish, say) becomes a local Bitcoin payment network until the grid comes back.

Censorship-Resistant Regions

Not every pleb lives in a jurisdiction where the ISP-to-bank-to-exchange chain is neutral. In regions where the on-ramps are blocked or monitored, LoRa mesh + Bitcoin becomes a peer-to-peer rail. The gateway can be anywhere — a friend across a border, a distant volunteer, a Tor-routed service. What matters is that the signing happens in a jurisdiction that’s hostile, and the broadcast happens in one that isn’t. The mesh spans the seam.

Rural and Remote Hashcenters

If you run a Hashcenter in a stranded-gas field, on a remote solar site, or at the end of a long dirt road, your internet is probably a single expensive link — satellite, microwave, or cellular. When that link drops, your miners keep hashing but you can’t receive payouts, can’t settle with hosted customers, and can’t move funds on-site. A LoRa relay to a town-based gateway means you can still push signed transactions out even when the main link is down. This bleeds naturally into the off-grid Hashcenter comms pattern.

Everyday Resilience

And then there’s the boring but important case: your ISP has a bad day. Your router dies. You’re traveling and your phone is in roaming-off mode. The mesh is always there, always listening. It’s the kind of infrastructure you want running in the background whether or not you think you’ll need it this month.

Limitations You Need to Know

Every pleb reading this should internalize what BTC Mesh is not. It’s not a replacement for an internet connection. It’s a narrow, specific, precious capability that buys you the ability to move transactions, not browse the web.

• Bandwidth is tiny. A single Meshtastic hop at LongFast moves ~1 kbps on paper, much less after airtime overhead, acknowledgments, and mesh routing. Broadcasting a 300-byte transaction can take several seconds of on-air time. Broadcasting a batch of ten transactions can take a minute.
• Duty cycle matters. In the EU (868 MHz) regulatory regime, ETSI caps you to ~1% duty cycle per hour on the main sub-bands. In practice that limits how much transaction traffic a dense mesh can push before nodes hit their legal ceiling and back off. North America’s 915 MHz band is friendlier.
• Confirmation latency is the Bitcoin protocol’s job, not the mesh’s. Once the gateway broadcasts, you’re back in normal Bitcoin territory — you wait for blocks like everyone else. The mesh helps you get in; it doesn’t speed up confirmations.
• Gateway trust model. The gateway node can see your transaction before it broadcasts (it has to, in order to validate and submit). In most deployments this is fine — the gateway can’t steal funds because the transaction is already signed — but it can, in theory, delay or suppress broadcast. If that’s in your threat model, you want multiple independent gateways.
• Amounts-under-duress caveat. Don’t do time-sensitive trading over a mesh. The latency and jitter are not HFT-friendly. This is for payments and for proofs that need to get through, not for market orders.

These aren’t deal-breakers. They’re constraints to respect. The plebs who get the most out of BTC Mesh are the ones who treat it like shortwave: a resilient, lower-bandwidth alternative that complements a normal internet connection.

A Practical Walkthrough

Here’s the shape of a real setup. Specifics will drift as BTC Mesh releases evolve, but the architecture is stable.

Step 1 — Stand Up the Mesh

Before you touch Bitcoin, make sure you have a working Meshtastic mesh with at least two nodes. Walk through the Meshtastic getting-started guide if you haven’t: flash a Heltec V3 (or similar), pick a region, create a private channel with a fresh PSK, pair a phone, send a test message. Don’t skip this. BTC Mesh is a layer on top of a working mesh; if your mesh doesn’t work, BTC Mesh won’t either.

Step 2 — Set Up a Gateway

One node in your mesh needs to be the gateway — the pleb with an internet connection running the BTC Mesh gateway service alongside a Bitcoin node (your own bitcoind is the sovereign answer). Clone the BTC Mesh repo, follow the gateway install instructions, point it at your Bitcoin node’s RPC, and configure which Meshtastic channel it listens on.

Step 3 — Set Up a Signing Node

The signing side can be as simple as a laptop running a Bitcoin wallet and a BTC Mesh CLI tool that dumps a PSBT into the mesh via a connected Meshtastic node. For stronger opsec, keep the wallet on an air-gapped machine, export the signed transaction to the mesh-connected machine via QR or USB, and push it into the mesh from there. The mesh doesn’t care how the PSBT got to it; it only cares about relaying the bytes.

Step 4 — Broadcast

Initiate the send. The CLI (or your wallet plug-in) chunks the transaction, hands it to the Meshtastic node, and you watch the hops. Each relay in between acknowledges. The gateway reassembles, validates, and pushes to the Bitcoin network. You should see a TXID come back — either displayed by the gateway or returned over the mesh as a final ACK. That TXID is your receipt. From there, it’s a normal Bitcoin transaction like any other.

Step 5 — Verify

If you have a spare internet link somewhere — even a different household member’s connection — pull up a block explorer and look for your TXID. Confirmations will start landing on the next block. Congratulations: you just moved Bitcoin without using the internet.

Security Notes

A few opsec points plebs should internalize.

• Default Meshtastic channels are public-readable (they ship with a known PSK). If you broadcast a signed transaction on LongFast, every Meshtastic node in range can decode and read it. Signed transactions are not secret — they’re public once they hit mempool — but you probably don’t want your intentions visible to the neighborhood five minutes before broadcast. Use a private channel with a strong PSK for BTC Mesh traffic.
• Mesh-layer privacy is thin. LoRa is RF. Someone with an SDR and patience can locate your node’s transmissions. This matters less for transaction broadcast (which is public anyway) and more for the fact that you’re running a LoRa node at all. Plan accordingly for your threat model.
• Air-gap the signer. The strongest deployment is: air-gapped hardware wallet does the signing; the mesh-connected machine only ever sees already-signed transactions. Never put seed material on a mesh-connected device.
• Gateway diversity. If there’s only one gateway, that gateway can delay your broadcast. Run more than one, or know which of your neighbors is running one.

What Comes Next

The BTC-over-mesh story is still early. A few directions the community is pushing in (some experimental, some still on whiteboards):

• Nostr-over-mesh bridges. Post Nostr events without internet. The identity layer meets the comms layer.
• Lightning over mesh. More demanding than on-chain because Lightning needs round-trip latency for HTLC negotiation — but experiments exist. Expect this to mature slowly.
• PSBT coordination protocols. Multiple signers coordinating a multisig spend entirely over mesh, no rendezvous server. Fits naturally with air-gapped signers.
• Regional relay networks. Volunteer-operated gateway nodes mapped and documented so plebs in a new region know where the nearest sovereign on-ramp is.

None of this is D-Central’s work. It’s eddieoz, the Meshtastic contributors, and a growing list of pleb volunteers. Our part is making sure more Bitcoiners know these tools exist and can use them.

Further Reading

• /sovereignty/ — the full sovereign stack hub.
• The pleb’s sovereign stack manifesto — why comms and money belong together.
• Meshtastic getting started — get a working mesh before you add Bitcoin.
• LoRa protocol explained — the physics underneath.
• Sending Bitcoin without the internet — the original primer on censorship-resistant broadcast.

Money without comms is stranded. Comms without money is chatter. Stack them together and the pleb gets one more layer decentralized — the real one, the one where the ISP can die and the transactions still go through.