Online & Offline — the complete transaction process
How OffQen sends value without internet, and reconciles the moment the network answers. Every state, every rule, and every failure mode covered.
Two paths, one transaction
The online flow and the offline flow share the same cryptographic core. They differ only in where the commit happens.
Online path
The STP is signed, transmitted over the network, and committed by the server in a single go. The local wallet is updated as part of the same two-phase commit.
Offline path
The STP is signed, transmitted radio-only, and committed locally first. The server reconciles it later, after connectivity returns.
Online vs offline side by side
The same transaction on the wire. The only real difference is who commits first.
Direction of commit
Online: server commits, clients acknowledge.
Offline: local device commits, server reconciles later.
Network dependency
Online: requires an internet path.
Offline: zero internet — radio-only link.
Latency
Online: round-trip to the server.
Offline: under 100ms on-device.
Safety net
Online: the server is authoritative.
Offline: 50% reserve cap + hash chain + ECDSA bound.
Failure recovery
Online: retry the HTTP call.
Offline: re-upload on reconnect; server rebuilds the graph and verifies chain continuity.
Receipt
Online: immediate ACK from the server.
Offline: local ACK, host-to-host; settle gets promoted later.
Transaction states
CREATED → PREPARED → PENDING_SYNC → SYNCING → SETTLED.
Double-spend protection: a transaction can never reach SETTLED more than once because the hash chain and the server-side graph reconstruction both enforce a single confirmed hash per nonce.
Step-by-step: the offline send
Every stage, from the device's perspective, then from the receiver's.
The sender's device verifies its own key, checks the local balance against the 50% reserve cap, and builds the Secure Transaction Package. No server call.
The STP is signed with the TEE-backed ECDSA key, hashed with SHA-256, and chained to the previous transaction's hash for tamper evidence.
The STP crosses the radio link — BLE (~10m), NFC (<4cm), QR (any camera, any distance), or Wi-Fi Direct (~75–100m). Zero internet is used.
The device persists the transaction to its local ledger and marks the state PENDING_SYNC. The user sees ✓ DONE.
When connectivity returns, queued STPs upload in batch, the server reconstructs the graph, verifies hash chains and risk, and auto-settles. The sender's ledger is aligned.
What happens when it all goes wrong
Failure mode, and the exact mechanism that keeps the money safe.
The receiver is offline
The STP caches on the receiver's device and settles the moment they come online. Nothing is lost, nothing is double-spent.
The sender goes offline after sending
The local commit stands (under the 50% cap). The server reconciles on reconnect and promotes it to SETTLED.
Network is slow, not gone
Retry logic with exponential backoff handles the queue. Failed STPs are flagged, not dropped.
Risk score is high
Auto-settle is withheld; the transaction waits for manual review. No money moves into an account the server does not trust.
The Secure Transaction Package
The exact payload that crosses a radio link. Currency is NPR throughout.
{
"transactionId": "example-tx-0f3a9c21",
"senderId": "sender-device-id",
"receiverId": "receiver-device-id",
"amount": 120.00,
"currency": "NPR",
"timestamp": 1729000000000,
"previousHash": "a1b2c3d4e5f60718293a4b5c6d7e8f9011223344",
"signature": "4f9e7d2c1b8a635f0e4d9c8b7a632f1e0d5c4b9a8f7e6d5c4b3a2f1e0d9c8b7a6",
"hash": "9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7"
}
Signed with the sender's ECDSA key, hashed with SHA-256, and chained to the previous transaction. The receiver verifies all four before accepting the STP.