XMRMesh: Offline Monero Payments over Bluetooth Low Energy Mesh Networks

Summary

XMRMesh investigates whether a signed Monero transaction can travel from phone to phone over a BitChat-style Bluetooth Low Energy mesh until someone with connectivity submits it. The design separates five states that must not be confused: offline preparation, best-effort mesh delivery, gateway submission, mempool observation and chain confirmation.

It is not offline bearer cash: a signed transaction can conflict with another spend until Monero consensus accepts one of them. Releasing anything of value requires on-chain confirmation or an explicitly accepted zero-confirmation risk.

Abstract

This paper presents XMRMesh, a proposed design and unvalidated engineering draft for relaying signed Monero transactions over a BitChat-style Bluetooth Low Energy mesh until a connected peer can submit them. The design separates offline preparation, best-effort mesh delivery, gateway submission, mempool observation, and chain confirmation. Native Android/iOS wallet engines demonstrate cache-based offline construction in private regtest. Separately, the native constructor produced a complete public-stagenet payment: a 1,524-byte transaction constructed from 10,133,567 cached public outputs, submitted through Tor, observed in mempool and independently verified at block 2236657. This establishes construction, signing and gateway delivery, not physical BLE transport, radio performance, or a privacy guarantee. We define an initial transaction-fragment profile using canonical RingCT identifiers, 470 data bytes per fragment and real packet lengths. Other messages remain experimental. Bloom-filter key-image gossip is analyzed only as a non-authoritative hint with bandwidth, censorship, merge, denial-of-service, and privacy risks. The detection equation 1 − e^−λΔt, its rates, the 50–500 kbps budgets, latency model, and throughput arithmetic remain conditional illustrations rather than calibrated results. We make no claim of bounded loss, aggregate scalability, negligible energy, fixed fiat fees, absolute privacy, or safe zero-confirmation acceptance. The remaining roadmap requires physical Android/iOS BLE experiments.

Keywords: Monero; mobile mesh networks; Bluetooth Low Energy; offline payments; privacy; censorship resistance; store-and-forward; key images; double-spend detection.

Contributions

• A system design and an initial fragment profile for carrying Monero transactions in a BitChat-style envelope. It is not yet a complete packet-level specification.
• Key-image gossip compressed with Bloom filters that only provides hints: it never resolves a conflict authoritatively.
• A feasibility model with explicit payload, throughput, discovery and duty-cycle parameters; its figures are assumptions, not measurements.
• A threat analysis: radio metadata, malicious relays, Sybil neighborhoods, withholding gateways, filter poisoning and stale decoy caches.
• An implementation and validation roadmap that separates synthetic simulation from real Monero, Bluetooth, Tor and chain-confirmation evidence.

Evidence so far

• Native Android and iOS wallet engines build transactions offline from a cache, on a private regtest.
• One complete public-stagenet payment: a 1,524-byte RingCT transaction, built offline from a snapshot of 10,133,567 public outputs, submitted through Tor, seen in the mempool and independently verified at block 2,236,657. It takes four fragments of 470 data bytes.
• Synthetic fragmentation and reassembly vectors using the canonical RingCT identifier: 470 data bytes in a full 486-byte TX_FRAGMENT.

This demonstrates construction, signing and gateway delivery; not physical Bluetooth transport, radio performance or a privacy guarantee.

Limits

• Bluetooth relay between physical phones has not been tested yet.
• There is no privacy guarantee: radio, timing and size metadata remain, and Tor only hides the gateway's IP from the receiving node.
• Key-image hints carry bandwidth, censorship, denial-of-service and privacy costs that may outweigh their benefit, which has not been measured.
• The detection equation, its rates, the 50–500 kbps budgets, the latency model and the throughput arithmetic are conditional illustrations, not calibrated results.
• Decoy-cache provenance and safe age (30 days is only a hypothesis), notice and acknowledgment schemas, and anti-denial-of-service policy are still open.
• There is no independent review.

Roadmap

• M0: freeze the initial profile: envelope and TX_FRAGMENT schemas, limits and cross-platform vectors.
• M1: official wallet vectors (blob, txid and full validation) and offline-cache requirements.
• M2: a real stagenet payment between at least two physical devices: offline construction and signing, Bluetooth relay, Tor submission and independent confirmation.
• M3–M4: a physical Android/iOS matrix, a gossip experiment on more than five devices and cross-platform hardening.

Read and cite

The official link is the Zenodo DOI, where the PDF can be viewed and downloaded. Version 1.7 has DOI 10.5281/zenodo.23762733; the all-versions DOI is 10.5281/zenodo.23739901.

The design is explained without jargon in BV-XMRM · XMRMesh.

How to cite it:

BiVelio Inc (2026). XMRMesh: Offline Monero Payments over Bluetooth Low Energy Mesh Networks. Version 1.7. BiVelio Research, Privacy & Cryptographic Systems Series, Paper BV-XMRM, No. 1. CC0 1.0. https://doi.org/10.5281/zenodo.23762733

Public-domain document (CC0 1.0). Android software derivatives follow the GPLv3 and iOS ones the Unlicense of their upstream components.