Keep the tills coordinated when the internet goes down
An offline POS mesh for retail: multi-hop coordination between registers, handhelds, and the back office with no router dependency. Price lookups, inventory holds, and queued transactions keep moving through outages and dead corners, then reconcile when a link returns. Live on 350,000+ devices across 80+ countries.
Coverage grows with device density, not router range
Move catalogs and queued transactions between authenticated peers
Internet to BLE to WiFi Direct with no coordination gap
The same mesh runs across 80+ countries
Where retail connectivity fails
A dropped connection closes the tills
When the router, ISP, or upstream provider goes down, connected registers stop authorizing, price lookups fail, and the line stops moving. The revenue you lose is not a system fault, it is the network between the till and the processor.
Store WiFi ends before the store does
Back rooms, stockrooms, curbside lanes, and the far corners of a large floor are exactly where handhelds lose signal. Inventory checks, mobile checkout, and clienteling all break at the edges of the coverage map.
Peak days are when the network buckles
Crowded floors, pop-ups, and event retail put the most devices on the weakest infrastructure at the highest-revenue hours. The moment you most need every register live is the moment the shared connection saturates.
Reconciliation after an outage is guesswork
When devices go dark independently, sales, voids, and stock moves scatter across terminals with no shared record. The day gets pieced back together by hand, and disputes get settled without a trustworthy trail.
What the mesh replaces
Register-to-register and floor-to-back-office mesh
DORS forms a multi-hop mesh between registers, handhelds, and back-office devices over BLE, WiFi Direct, and the internet, with automatic failover and sub-second transport switching. Coordination continues across the whole floor with or without a router.
Counterparty and device identity verified offline
OfflineID gives every register, handheld, and gateway an Ed25519 identity verifiable device-to-device with zero connectivity. A device joins the store mesh and authenticates its peers on the spot, with rotation and revocation anchored on-chain.
Signed transaction transport, settlement on reconnect
The signed payloads your registers already produce move phone to terminal to gateway over the mesh, ordered and MLS-encrypted, and queue on-device until any node reaches a settlement gateway. Authorization stays with your processor.
What you can build for stores and floors
Concrete retail capabilities you can integrate today on the SDK primitives, no named-customer required.
You can build an offline point of sale
Capture the sale on the register or handheld, sign it with OfflineID, and queue it on-device while the store is dark. The signed payload moves across the mesh and delivers to your settlement gateway when a link returns. Authorization and settlement stay with your processor and ledger.
You can build a floor that never loses coordination
A handheld in the stockroom invokes the price-lookup or inventory-hold service on the register gateway through the devices between them. Service Discovery gives every device a request/response interface to every capability within 8 hops, so the floor coordinates mesh-only.
You can build gap-free offline reconciliation
Opt-in telemetry buffers every transaction, void, and stock move on-device through the outage, then flushes to your system of record in order when a link returns. The day reconciles against one tamper-evident record, not a hand-assembled patchwork.
What an offline POS system actually is
A connected point of sale fails during an outage because every register holds its own link to a processor, and the outage takes that link away. A multi-hop mesh network removes that assumption: your registers, handhelds, and back-office devices connect to each other over BLE and WiFi Direct, and traffic hops device to device up to 8 hops until it reaches its destination or a connected gateway. Coordination continues even when the router does not.
Payment authorization and settlement stay where they belong, in your ledger and processor. The mesh contributes the two primitives an outage removes: counterparty identity verified device-to-device, and reliable ordered transport for the signed payloads your registers already produce, held until they reach a settlement gateway. OfflinePay, our offline-capable payment layer, is in development on this same stack.
The transport and identity layers are shared with our payments infrastructure, and Offline Protocol sits alongside offline-first data tools rather than replacing them, as our comparison with Ditto lays out.
The primitives behind offline retail coordination
Register-to-register and floor-to-back-office mesh
DORS meshes registers, handhelds, and back-office devices over BLE and WiFi Direct with automatic failover, so coordination continues across the whole floor with or without a router.
How mesh networking works →Device and counterparty identity verified offline
Every register, handheld, and gateway carries an Ed25519 self-sovereign identity verifiable device-to-device with zero connectivity. Devices authenticate each other on the spot as they join the store mesh.
How offline identity works →A sales record with no outage gaps
Opt-in telemetry buffers every transaction, void, and stock move on-device through the outage, then flushes to your system of record in order when any link returns.
How telemetry works →What your team can implement
Each capability is a shipped SDK primitive. Follow the link to the reference.
Floor-to-back-office mesh transport
Route price lookups and order state device to device with automatic failover.
→Price and inventory service invocation
Expose a lookup or inventory-hold service discoverable across the floor.
→Offline device authentication
Verify a register or handheld device-to-device with an Ed25519 OfflineID.
→Gap-free offline reconciliation
Buffer the sales record on-device, flush in order when a link returns.
→Signed transaction transport
Carry the signed payloads your registers produce across the mesh to settlement.
→Rust core on registers and handhelds
Run the SDK on the Android hardware and tablets stores already use.
→Encrypted retail sessions
Every payload moves inside an MLS-encrypted, authenticated session.
→Scope a retail pilot
A 6 to 10 week pilot against your store and your registers.
→How a pilot runs
6 to 10 weeks, scoped up front, no open-ended commitments.
The SDK goes onto registers, handhelds, and a back-office gateway. Devices join the store mesh and authenticate each other with store-provisioned OfflineIDs.
A defined offline scenario in your store: the internet denied, WiFi out of range in the back, price lookups and queued transactions running mesh-only.
Success criteria agreed before week one, evaluated against the opt-in telemetry record: delivery rates, failover times, hop counts, reconciliation completeness.
Retail and point of sale FAQ
Can a store take payments during an internet outage?
Offline Protocol provides the offline transport, identity, and coordination layer that keeps POS terminals, handhelds, and the back office talking to each other when the internet is down. Payment authorization and settlement stay with your ledger or processor, exactly as they do today. OfflinePay, our offline-capable payment layer, is in development on the same stack, so teams integrate the transport and identity primitives now and adopt the payment primitives when they land.
How does an offline POS system stay coordinated without a network?
DORS forms a multi-hop mesh between registers, handhelds, and back-office devices over BLE and WiFi Direct with relay up to 8 hops. Price lookups, inventory holds, order state, and queued transactions move device to device with no store WiFi and no router, then reconcile to your system of record the moment any device in the mesh regains a link.
Does this replace our payment processor?
No. Authorization and settlement remain your processor and ledger concern. The mesh contributes the two primitives an outage takes away: authenticated device-to-device identity through OfflineID, and reliable ordered transport for the signed payloads your registers already produce, held until they reach a settlement gateway.
What does the store hardware need to be?
The SDK ships as a React Native and TypeScript binding over a Rust core, so it runs on the Android handhelds, tablets, and register hardware retailers already use. Back-office gateways that can run the Rust core join the same mesh directly.
How is transaction and customer data secured between devices?
Sessions are encrypted end-to-end with MLS (RFC 9420) by default, and every device carries an Ed25519 OfflineID verified device-to-device. Signed payloads move between authenticated peers only, never in the clear, whether the store is online or dark.
What happens to sales recorded while the store was offline?
Every transaction, void, and inventory change is captured, signed, and queued on-device. Opt-in telemetry buffers the full record through the outage and flushes it in order the moment a link returns, so the day reconciles to your system of record with no gap.
Does the mesh work across a large store or multiple floors?
Routing is multi-hop up to 8 hops, so coverage grows with device density rather than radio range. Every register, handheld, and back-office device on the floor extends the mesh, and chunked transfer moves payloads up to 100MB across it.
How does a pilot work?
A 6 to 10 week scoped pilot against your store, your registers, and success criteria we agree up front. Contact us to scope it.
