Communication and payments without the internet

An autonomous radio network for messaging, mutual credit and exchange

Imagine a pocket device with a screen and keypad: you could message a neighbour or prepare a purchase payment where there is no cellular service, Wi-Fi or global internet connection. Devices communicate over LoRa, a radio technology suited to small messages, and help carry one another’s data.

We are considering this network as an extension of CommonGround. A device could combine a personal messenger, a payment terminal and a radio relay. Messaging requires a data delivery path. Payments also require suitable credit relationships and coordinated financial state. The two paths need not be the same.

A pocket terminal with three roles

The proposed terminal would have a small screen, buttons or a numeric keypad, a battery and a radio module. It would store messages and the necessary local state, receive packets and automatically relay them. Both a standalone version without a smartphone and a version paired with a phone are possible.

To send a message, a user would select a recipient, enter text and confirm. For a purchase, they would select a seller, enter an amount, check their balance and available credit, then sign the operation with their own key. The interface must distinguish “waiting for delivery”, “being verified” and “completed”, so sending a message is not mistaken for making a successful payment.

Preliminary hardware candidates are the nRF52840 as a low-power portable controller, the SX1262 as a LoRa transceiver, and the ESP32-S3 as an alternative for a richer interface or gateway. These are components under consideration, not an approved device specification. Manufacturer information: Nordic Semiconductor, Semtech, Espressif.

Ready-made devices and DIY assembly

Ready-made LoRa devices and modular Meshtastic kits already exist. These examples illustrate possible hardware foundations, from enclosed portable radios to boards for DIY builds. They are not ready-made CommonGround payment terminals: compatible firmware, interfaces and a financial protocol still need development and testing.

Anyone wishing to build their own device will be able to assemble it from separate components: a compatible controller and LoRa module, antenna, battery with suitable power circuitry, display, buttons or keypad, and enclosure. A modular kit can provide a starting point, or a builder can design a board. Assembly and configuration skills are needed; CommonGround does not yet provide a finished build guide or tested firmware. The antenna and radio module must use compatible frequency bands and comply with local radio requirements.

Fixed relays: commercial and DIY

A fixed node is placed where it can communicate well with neighbouring devices, for example on a roof or suitable elevated site. It need not have a screen or keypad: the antenna, reliable power, weatherproof enclosure and maintenance access matter more. Solar panels and batteries must be sized for consumption, season and a reserve for sunless periods; continuous off-grid operation is not automatic.

These devices illustrate possible radio infrastructure. Relaying a packet does not make a node a creditor or financial intermediary. Transport compatibility, relay settings and CommonGround integration still require separate testing.

Mesh: messages travel through neighbours

A mesh network connects devices through available neighbours. Rather than depending on an operator’s base station, a message can cross several radio links. Anna cannot reach Gleb directly, but Boris can hear Anna, Vera can hear Boris, and Gleb can hear Vera: Anna → Boris → Vera → Gleb.

Relaying requires no human action: enabled devices do it automatically. Nodes can join, leave or move, and routes can change. The network can operate locally without internet access, but self-organisation does not guarantee connectivity. Without a chain of radio contacts, immediate delivery is impossible.

Meshtastic is an existing open-source example of off-grid LoRa communication. CommonGround still needs to choose an existing mesh protocol or its own transport; Meshtastic compatibility has not been implemented.

Radio range and capacity

For pocket devices, a broad planning estimate is hundreds of metres to several kilometres, depending on terrain, antennas, interference and radio settings. Dense urban buildings can sharply reduce range. Suburban and open terrain are often more favourable; clear line of sight between elevated sites can allow tens of kilometres. These are design estimates, not measurements of our terminal or promises of a particular range.

Fixed relays at suitable heights could connect successive areas and extend overall coverage. Each hop still consumes airtime: more nodes do not create unlimited capacity.

LoRa is primarily suitable for text and compact control or financial messages. Voice calls, photos and video are not the intended use. Frequencies, power and permitted transmission time vary by country; hardware configuration and operating settings must meet local requirements.

Network configurations and payment-distance calculations

Consider a village and open rural terrain, distinguishing three link types: portable ↔ portable: 2 km, portable ↔ elevated fixed node: 5 km, fixed ↔ fixed: 10 km. These are selected comparison assumptions, not measured specifications or guaranteed ranges. Fixed nodes are assumed to have suitable placement, appropriate antennas and favourable line of sight.

Why can a fixed node reach further? Raising an antenna reduces obstruction effects and improves the radio path; a suitable external antenna can improve reception too. Being “fixed” is not itself a range advantage, and higher transmit power does not guarantee that a portable device can reply. RAKwireless explains these factors. The 2/5/10 km inputs are not automatically derived from height or measured CommonGround performance.

Terrain, tree belts, low antennas and interference can reduce range even outside towns. For a specific village, model heights, antennas, settings and terrain, for example with Meshtastic Site Planner, then field-test both directions of each link. The diagrams show radio delivery; credit relationships follow separately.

How many nodes can a chain contain: 5, 9 or 10?

LoRa itself has no universal “5–10 device” limit. The mesh protocol sets that limit. Meshtastic defaults to hop_limit = 3, with a maximum setting of 7. The official counting diagram shows a budget for intermediate retransmissions: three forwards give 5 radio devices including sender and receiver; seven give 9. M devices are joined by M − 1 physical radio links but need only M − 2 intermediate forwards. Direct reception requires no forwarding.

10 consecutively required devices need 8 forwards, beyond the normal Meshtastic budget. Those rows below are geometric calculations for another or specially designed transport, not a promise about standard firmware. The wider branched mesh may contain many more devices: the limit applies to a packet’s path, not the community’s size. Raising hop_limit increases airtime load and does not guarantee delivery.

For comparison, MeshCore describes up to 64 hops with a one-byte path format, but its ordinary clients do not relay messages. This is a different protocol and role model, not a drop-in replacement for a participants-only mesh. CommonGround’s transport has not been selected.

A mesh without dedicated relays. Powered-on participants’ devices forward messages automatically if their firmware and settings permit it. For M devices with equal link length d, L = (M − 1) × d. Moving or switching off an intermediate device can break the path; an alternative exists only if enough reachable nodes remain. Coverage depends on participants’ presence and battery charge.

A chain with N fixed relays has N + 1 radio links. With access links of length d and inter-relay links of length D, L = 2 × d + (N − 1) × D, N ≥ 1. Here d = 5 km and D = 10 km: one relay gives 5 + 5 = 10 km; five give 50 km. This sums link lengths, not a coverage radius: straight-line separation cannot exceed L and reaches it only for aligned nodes. All distances need field validation.

A payment has no separately guaranteed “LoRa range”. Return messages and access to components authorised to coordinate financial state are also required. A chain could carry a payment between its endpoints only if all required two-way links work, an eligible trust route exists and financial verification succeeds. When a route breaks, the message may be stored while settlement remains unconfirmed.

Relays cannot be added without limit: the protocol may restrict hop count, every packet consumes airtime, and verification and confirmation require further transmissions. Before deployment, measure both link directions, delays and losses; check antenna heights, traffic, power and permitted settings. An alternative radio path can improve resilience but creates no additional credit capacity.

Gateways: intranet, internet, Holochain and CommonGround

A gateway combines a LoRa interface with IP connectivity, for example a small computer with an attached radio. Gateways can communicate through a private radio intranet or the global internet. In both configurations, handheld terminals remain on local LoRa meshes.

Option 1. Radio bridges and a private intranet

An intranet is a private internal IP network that need not connect to the global internet. Directional radio bridges could connect gateway G1 to an elevated node T, then T to gateway G2. This is a separate backbone using IP-capable radio equipment, not an attempt to turn ordinary LoRa modules into a broadband link.

In this example a portable terminal connects directly to G1’s elevated LoRa antenna over an assumed 5 km, with a matching access link at G2. The straight-route total is 5 + 10 + 10 + 5 = 30 km. Radio-bridge distances are assumptions too: antennas, line of sight, terrain, interference and permitted settings must be checked. LoRa accounts for 10 km and IP radio for 20 km; their sum is not a single LoRa device’s range.

To settle without the global internet, the required CommonGround/Holochain nodes and an authorised financial mechanism must be reachable inside the intranet. Local node discovery must be configured and operation without external network services tested. If authority or up-to-date financial state is unavailable within the reachable segment, settlement waits. A partition does not gain permission to spend shared credit independently a second time. This is a proposed architecture, not a ready-made autonomous mode.

Option 2. Gateways over the global internet

G1 receives a locally signed message and passes it to the application over the internet; G2 delivers data to another LoRa mesh. Participants need not have their own internet connection, but the gateways do need it between them. This option connects meshes beyond the private intranet, for example in different regions.

Here, the internet is transport, Holochain is the distributed application platform, CommonGround is the application and its exchange rules, and Credit Engine is the proposed financial execution mechanism. They are different layers, not four successive radio relays. A full application node could run on the gateway or a separate computer with explicitly limited authority. Holochain’s architecture separates clients from application nodes; the platform does not replace a coordinated settlement protocol.

Each local radio segment has its own forwarding budget. Internet connectivity can join remote settlements without an unbroken LoRa chain between them, so geographical reach no longer follows from one node’s radio range. The diagram’s 500 km is an assumed geographical gateway separation, not cable length or a Holochain limit.

CommonGround still needs a bidirectional bridge, signature checks, a single operation identifier, replay protection, confirmation delivery and recovery after interruptions. A gateway must not gain arbitrary power to change other people’s obligations. Simply forwarding or republishing a packet with a new hop_limit does not make a safe payment. If internet access fails, local messaging may continue while cross-network settlement waits for connectivity and financial confirmation. Ready-made Holochain/CommonGround gateway compatibility is not claimed.

Payments rely on a network of trust

The P2P finance article (Russian) explains mutual credit and IOUs, personal debt acknowledgements. Participants voluntarily open credit lines, setting the direction of trust, maximum debt and permitted use. Settlement changes balances of specific obligations; a radio transmission does not create money.

Anna buys goods from Gleb for 20 accounting units. Boris accepts Anna’s obligations, Vera accepts Boris’s, and Gleb accepts Vera’s. If the current balances, available limits and permissions allow it, settlement could follow Anna → Boris → Vera → Gleb. The sender need not know everyone in the wider network, but an arbitrary chain of acquaintances is not automatically a payment route.

Rippling means coordinated changes to obligations along such a route. In this example without fees, each intermediary’s claim on the previous participant and debt to the next increase by the same amount. Their net balance is preserved, but credit risk remains. Prior authorisation for rippling means the intermediary need not personally sign every purchase; it does not replace capacity checks or financial coordination.

Two routes: radio delivery and financial relationships

Option A: the routes coincide

The packet travels A → B → C → D, and those participants form the financial chain too. This is easy to understand, supports local exchange and could require fewer transport hops. However, suitable radio contacts and credit lines must coincide. Each relay on this chain must also be a financial intermediary, and payment routing is constrained by physical topology.

Option B: independent routes

Credit relationships connect A → B → C → D, while devices A → R1 → R2 → D deliver the packet. R1 and R2 need not extend credit. B and C may be temporarily disconnected from the radio mesh and need not relay this purchase’s packets.

This is the prospective target architecture: it can use a wider trust network, develop radio coverage more flexibly and separate data transport from economic responsibility. Authorised financial components must nevertheless coordinate changes to B’s and C’s credit lines. Delivery between A and D does not authorise them to change someone else’s balances arbitrarily.

What does an offline intermediary mean?

Five different actions must be distinguished:

1. Permission: the credit-line owner has authorised its use for rippling in advance.
2. Capacity check: the accounting mechanism determines how much is actually available now.
3. Reservation: the necessary available amount is protected against concurrent use.
4. Coordination: related obligations change under common rules, without conflicting versions.
5. Confirmation: participants receive a verifiable result for a completed payment.

An offline person need not repeat permission already given. Their switched-off terminal cannot independently check new operations, however. Limited delegated authority or advance reservations are possibilities; the specific design still needs development and testing.

Credit Engine is the proposed separate financial component. It would validate operations, maintain accounts and make financial state reproducible. Transport delivers data to it; transport does not replace it. If an authorised coordination mechanism cannot be reached, final settlement may have to wait for connectivity to return.

Why a signature does not prevent double spending

A signature authenticates the sender and protects message integrity. It does not prove that the same credit capacity has not been used in another signed payment. Two isolated network areas could both regard the same remaining capacity as available and accept incompatible operations.

Rules for exclusive write authority, reservations and recovery after partitions are therefore needed. Classical rippling alone does not make payments safe in completely isolated network partitions. For autonomous CommonGround, preventing double spending remains an open engineering problem.

Store-and-Forward: keep it and deliver later

Store-and-Forward means retaining a message until it can be forwarded. If Boris is out of range, an intermediate node could keep an encrypted message addressed to him and forward it when a suitable contact appears. This would help with moving users, switched-off devices and gaps between settlements.

Brief packet buffering in RAM is different from durable storage. Surviving a power loss requires non-volatile memory, retention and deletion rules, and message protection. These mechanisms still need investigation. The existing Meshtastic Store & Forward module illustrates a particular messaging implementation, not a ready-made CommonGround settlement solution.

Store-and-Forward transports information; it neither completes settlement nor prevents double spending by itself. Even a delivered signed payment message may still await financial confirmation.

Message security and privacy

The proposed protocol needs operation signatures, unique identifiers, replay checks, private-message encryption and secure key storage. Payments additionally require protection against conflicting spending and a verifiable history of state changes.

Ideally, radio relays see only the information needed to forward a packet, rather than private correspondence or credit relationships. Financial disclosure should be minimised. Radio activity and some technical characteristics can remain observable, however. Metadata protection and limiting participant tracking are separate challenges; absolute anonymity is not promised.

CommonGround and Holochain

Holochain is the foundation of the distributed CommonGround application; LoRa mesh is a possible additional transport for small amounts of data. Running full Holochain directly on an nRF52840 is not a demonstrated capability assumed by this proposal.

One possible approach is for terminals to hold their own keys and limited local data, transmitting messages and signed operations. Gateways would connect the radio mesh to full CommonGround nodes. Internet or other suitable connectivity would permit synchronisation with the wider network. Credit Engine remains separate from radio transport, and finalisation requires a tested consistency model.

This extension could support external exchange in the Participatory Economy, while keeping P2P debts distinct from organisations’ internal capital accounts.

Three possible uses

Beyond cellular coverage. Rural neighbours exchange short messages as nearby devices relay packets automatically. Without a continuous route, a message waits for a later contact.

At a local market. A buyer selects a seller, enters an amount and signs a message. The terminal shows “delivered”, followed by “awaiting financial confirmation”. The seller treats payment as complete only after the protocol’s confirmation, not merely after packet receipt.

Between settlements. Fixed relays at elevated sites connect several radio hops. No cellular operator is required on every segment, but actual coverage, load and power supply still need field testing.

Development status

No release date is set. Next steps are selecting transport and hardware, testing the financial execution model, building a prototype and measuring delivery, battery life and recovery after interruptions. Working radio messaging and safe payment settlement must be demonstrated separately.

Continue with P2P finance (Russian), development status (Russian), the CommonGround repository and the information-site source.

For a technical example of rippling, see the official XRP Ledger documentation. It describes a different protocol; it does not imply that CommonGround will use XRP Ledger or the XRP token.