📡 Reaching bsv.cx without internet

Every bsv.cx service above talks HTTPS. This page is about the other path: reaching a bsv.cx service over Reticulum instead of TCP/IP — including from a device with no internet connection at all, over LoRa radio alone.

Two different claims, don't mix them up: the connection details below work over plain internet, from anywhere on Earth — no radio needed. The "zero internet" radio proofs further down were run on our own LoRa hardware, physically located in the Dayton, Ohio area — reaching our radios over the air only works if you're within range of them. If you're not nearby, the section below shows how to get the same zero-internet property anywhere, with your own radio.

Connect

Any Reticulum node can reach these directly over the open internet — no radio required for that part; the radio is what lets a device with zero internet reach a Reticulum node that, in turn, reaches this.

# minimal client: add a TCPClientInterface to 5.161.238.214:4242 in your own
# Reticulum config, request_path() a destination hash above, open a Link once
# resolved, then link.request(<name>, <payload>) with the shapes above.
# Full worked example: github.com/markqvist/Reticulum (RNS.Link, RNS.Destination)

How it works

Reticulum is an open cryptographic mesh networking stack — it does not care whether the link underneath is LoRa, packet radio, or an ordinary internet socket; the same identity, routing and encryption behave the same way over any of them. Each bridge above sits on the same box as the real bsv.cx HTTP API: it takes a request off Reticulum, calls the matching HTTP endpoint exactly like any other client would, and sends the real response back the same way it came in.

your device (no internet, LoRa only)
        ↓ radio hop
a Reticulum relay with internet (transport node)
        ↓ plain TCP, over the open internet
bsv.cx's own box — notarizes or verifies, same as any other request
        ↓ response, same path back

Proven

Notary, over radio: a notarize request left a device with its internet path deliberately disabled, crossed one LoRa hop to a relay, continued over the internet into this destination, got a genuine on-chain anchor, and the proof came back over the same radio link — no other path available. Round trip: ~5.5 seconds.

Notary, over plain internet, as any third party would: a throwaway identity with no relation to our own radio hardware, holding only this page's connection details, reached the destination above and got a genuine on-chain anchor back.

SPV verify, same way: a throwaway identity fetched a header for block 964658 and independently folded a real BUMP for an already-confirmed bsv.cx anchor against our own headers — both over the Reticulum destination above, zero bsv.cx-specific HTTP involved.

Attest, same way: a throwaway key signed a statement locally (Bitcoin Signed Message — no new tooling, the same "sign message" feature any wallet already has), and the attest request relayed the signature — unverified, untouched, exactly as signed — into a real anchor.

Broadcast, deliberately not with real funds: a signed transaction spending a fake, nonexistent input went over the same destination, through broadcast, into the real /broadcast endpoint, which genuinely tried to relay it to the network and came back with a real rejection — Missing inputs, exactly as a fake input should. That proves the relay path end to end without anyone's money moving; a real wallet's genuinely-signed, genuinely-funded transaction goes through the identical path and actually lands on-chain.

All of these are our own tests, not customer-usage theatre — same honesty rule as every other "proven on mainnet" claim on this site.

Point of sale, entirely offline

Put notarize and broadcast together and you get something more than either alone: a vendor generates an invoice with no network call at all, its hash gets notarized over this same destination — an on-chain record of exactly what was asked for, before any money moves — a buyer signs a real payment against it (the key never touches a radio), and the signed transaction goes out the same way. Neither side needs internet. Neither side needs bsv.cx in the middle, either — this isn't a hosted payment service, it's two independent wallets transacting directly, with bsv.cx as neutral notarization and broadcast infrastructure, nothing more. "Confirmed" means the broadcast ack, the same 0-conf standard as above — the right bar for small point-of-sale amounts.

Reference implementation (invoice → notarize → sign → broadcast, end to end): reticulum/pos-demo-sign.mjs + pos-demo-broadcast.py in the source tree.

Not near Dayton? Build your own gateway

The zero-internet property doesn't belong to our specific radios — it comes from the pattern underneath, and that pattern works anywhere. You don't need to be near us; you need a node of your own that has both a radio and an internet connection, sitting between your offline device and the public TCP interface above.

# gateway's config — the line that actually matters:
[[bsvcx Uplink]]
  type = TCPClientInterface
  enabled = Yes
  target_host = 5.161.238.214
  target_port = 4242

One real constraint, not a bsv.cx one: two LoRa radios only hear each other if their frequency, bandwidth, spreading factor and coding rate all match — and the frequency band you're legally allowed to transmit on depends on your country (915 MHz in the US, 868 MHz in the EU, etc.). Match your offline device's radio settings to your gateway's, and use a frequency that's legal where you are.

Once that's up, the offline device talks to your gateway over LoRa exactly like our LoRa device talked to Juno — and your gateway relays it over the internet to the exact same destinations above. Same mechanism, your own radios, anywhere on Earth.

What this is not

Not a full-catalog gateway — only single-file notary (not1), attestations (att1), raw broadcast, and SPV verify are wired up so far; batch, archive, and the paid services are still HTTPS-only. Not a wallet — we never generate, hold, or see a private key; "broadcast" only ever relays bytes you already signed elsewhere. Not rate-unlimited — the same per-caller fairness window the free HTTP endpoints use applies here too. Not monitored infrastructure with an uptime commitment — it is one box we run, kept alive by systemd, not a fleet with paging and failover.

← filestamp notary · SPV verify