Offline payments infrastructure that works when the network does not
Device-to-device payments transport and offline identity for fintechs, neobanks, and crypto wallets. Signed payloads move phone to phone without internet and settle when connectivity returns. Live on 350,000+ devices across 80+ countries.
Running the mesh across active deployments
Where the network is already deployed
Of the transport and identity layers
Between BLE, WiFi Direct, and internet
Every wallet assumes the internet, every outage proves otherwise
A wallet without connectivity is a brick
Outages, crowded venues, disasters, and dead zones all produce the same result: two funded accounts, two phones a meter apart, and no way to transact. The failure is not the money, it is the network between them.
The next markets live behind unreliable networks
The users fintechs and neobanks want next are in regions where coverage is patchy and data is expensive. Every failed transaction at the coverage line is an acquisition lost to cash.
Crypto is peer-to-peer everywhere except the last meter
Chains settle globally between anonymous parties, yet two wallets side by side still need the internet to move value. The most decentralized money in history has a centralized dependency at the point of sale.
Trust without connectivity is the hard problem
Verifying who you are transacting with, offline, is why most wallets refuse to try. Without an identity layer that works device-to-device, offline payments stay a demo.
What the mesh replaces
Device-to-device transaction transport
DORS carries signed transaction payloads phone to phone and phone to terminal over BLE and WiFi Direct, MLS-encrypted, with automatic failover and store-and-forward relay up to 8 hops. The path between two wallets no longer routes through a tower.
Counterparty identity verified offline
OfflineID gives every wallet an Ed25519 identity verifiable device-to-device with zero connectivity, with rotation and revocation anchored on-chain. Your app knows cryptographically who signed the other side before anything moves.
Settlement when connectivity returns
Signed payloads queue on-device, ordered and encrypted, and deliver the moment any node in the mesh reaches a settlement gateway. Opt-in telemetry gives you the transport audit trail for every hop in between.
What you can build for offline device-to-device payments
The transport and identity layers ship today for fintechs, neobanks, and crypto wallets. OfflinePay, the payment-specific layer, is in development on the same stack.
Device-to-device transaction transport
You can build offline payments today where your wallet signs a transaction and DORS carries the signed payload phone to phone over BLE and WiFi Direct inside an MLS-encrypted session, up to 8 hops, with the path between two wallets no longer routing through a tower.
Offline counterparty identity
You can build a trust root that works without a server: OfflineID gives every wallet an Ed25519 identity verifiable device-to-device, so your app knows cryptographically who signed the other side before anything moves, with rotation and revocation anchored on-chain.
Settlement on reconnect
You can build a settlement flow where signed payloads queue on-device, ordered and encrypted, and deliver the moment any node in the mesh reaches a gateway. OfflinePay, the payment-specific layer, is in development on this same stack.
The primitives behind offline payments infrastructure
Device-to-device payment transport
DORS carries signed transaction payloads phone to phone over BLE and WiFi Direct with automatic failover and store-and-forward relay up to 8 hops. The internet stops being the only path between two wallets a meter apart.
Counterparty identity verified offline
OfflineID gives every wallet an Ed25519 identity verifiable device-to-device with zero connectivity, so your fintech, neobank, or crypto app authenticates the other side before value moves. Rotation and revocation anchor on-chain.
Encrypted settlement queue and audit trail
Signed payloads travel and queue inside MLS-encrypted sessions and deliver to your settlement gateway on reconnect. Opt-in telemetry gives you a transport audit trail for every hop in between.
What your team can implement
Signed payload transport
Carry whatever your wallet signs, phone to phone, no server.
Offline counterparty identity
Authenticate the other wallet against an Ed25519 OfflineID.
Settlement on reconnect
Queue signed payloads and deliver when a node reaches a gateway.
MLS-encrypted sessions
End-to-end encryption between authenticated peers by default.
Sub-second transport failover
Switch between BLE, WiFi Direct, and internet without dropping.
Per-hop transport audit trail
Opt-in telemetry records delivery for every relay in the path.
On-chain rotation and revocation
Anchor identity lifecycle without a central authority.
Build on the SDK
React Native and TypeScript bindings over a Rust core.
What an offline payments SDK has to solve
Two problems stop payments without internet: moving a signed transaction between two phones with no network between them, and knowing who you are transacting with before anything moves. The mesh transport solves the first, carrying MLS-encrypted payloads phone to phone with store-and-forward relay up to 8 hops. OfflineID solves the second, giving every wallet an Ed25519 identity verifiable device-to-device with rotation and revocation anchored on-chain.
Settlement stays in your ledger. The mesh delivers the signed payload to a gateway the moment any node touches the internet, with a transport audit trail per hop. OfflinePay, the payment-specific layer on this stack, is in development.
The failure mode is everywhere the buyer is: saturated venues, rural corridors, outages. Start with the SDK and the rails are there when OfflinePay lands.
A signed payment, hopping to settlement
A customer wallet phone pays a merchant phone offline over the mesh, and the signed transaction relays to a settlement gateway dashboard the moment any node touches the internet.
Figure 1. The customer wallet authenticates the merchant with OfflineID and hands over a signed payload at the point of sale. The payload relays MLS-encrypted through the mesh and settles the moment any node touches the internet.
How a pilot runs
6 to 10 weeks, scoped up front, no open-ended commitments.
The SDK goes into your wallet build alongside your existing signing and settlement flow. Devices join the mesh and authenticate with OfflineIDs bound to your accounts.
A defined offline scenario in your corridor: connectivity denied at the point of sale, transactions signed, relayed, and settled when the mesh touches a gateway.
Success criteria agreed before week one, evaluated against the opt-in telemetry record: delivery rates, time to settlement, failover times, hop counts.
Payments FAQ
Is there an SDK for offline payments?
The transport and identity layers ship today: a React Native and TypeScript SDK over a Rust core, with 9,000+ downloads, carrying signed payloads device-to-device and verifying counterparties offline. OfflinePay, the payment-specific layer on top, is in development, so teams integrate the rails now and adopt the payment primitives on the same stack.
How do device-to-device payments work without internet?
Your wallet signs the transaction as it does today. The mesh moves that signed payload phone to phone over BLE or WiFi Direct inside an MLS-encrypted session, OfflineID proves who is on the other side, and the payload queues until any node in the mesh reaches a settlement gateway.
How do you prevent double-spending offline?
Spend authorization is a ledger concern and stays in your settlement layer. The mesh contributes the two primitives offline payments need underneath: authenticated counterparty identity via OfflineID, and reliable ordered transport for signed payloads until they reach settlement. OfflinePay, in development, builds payment-specific primitives on top.
Who owns KYC and compliance?
Your application does. OfflineID provides cryptographic device and user identity, verifiable offline; how you bind it to KYC-verified accounts, limits, and jurisdictions is your policy layer, exactly as it is today.
Which chains and payment rails does this work with?
The mesh is payload-agnostic. It transports whatever your wallet signs, a chain transaction, a stored-value voucher, or a payment instruction for your core banking system, and delivers it to a settlement gateway when connectivity exists anywhere in the mesh.
How are transactions secured between devices?
Sessions are encrypted end-to-end with MLS (RFC 9420) by default. Every device carries an Ed25519 OfflineID verified device-to-device, with rotation and revocation anchored on-chain. Payloads travel signed and encrypted between authenticated peers.
What is the latency for a device-to-device transaction?
Direct-link payloads move at transport speed with no server round-trip, and failover between BLE, WiFi Direct, and internet completes in under a second. Multi-hop delivery to a settlement gateway adds per-hop forwarding only.
How does a pilot work?
A 6 to 10 week scoped pilot against your wallet, your corridor, and success criteria we agree up front. Contact us to scope it.
