The complete OffQen Q&A

OffQen is an offline-first digital payment application that allows verified users to send and receive digital value even when internet connectivity is unavailable.

The user experience should remain simple:

Select recipient → Enter amount → Authenticate → Confirm → Payment completed locally.

The complexity of cryptographic verification, Secure Transaction Packages, Chain of Custody, synchronization, risk analysis, and server settlement must remain mostly invisible to ordinary users.

No. Users should NOT need to understand:

• STPs
• hashes
• digital signatures
• transaction graphs
• public/private keys
• Chain of Custody
• Two-Phase Commit
• synchronization internals

These belong in advanced transaction details and developer/security documentation. The normal user should experience OffQen like a conventional payment app.

Download the app over the internet once, and the entire offline functionality lives on the device. No provisioning or data download is needed when connectivity is cut.

Verification is local, so authentication remains fast even when the network is down.

The 50% offline reserve cap. A user should never be able to commit more than half of their wallet balance in offline transactions.

The cap is enforced locally and cannot be bypassed without an online reconcile.

An offline wallet is a partial, locally reserved subset of the full balance. It can still send, but its commit range is bounded by the reserve cap and it reconciles against the cloud when connectivity returns.

The sender prepares the STP and commits locally (PENDING_SYNC). When connectivity returns, the host-to-host layer receives the STP, verifies the signature and hash chain, and only then promotes it to SETTLED. The receiver gets a two-phase commit so funds are not settled twice.

For a normal user:

OPEN APP → SEE BALANCE → SEND / RECEIVE → SELECT PERSON → ENTER AMOUNT → AUTHENTICATE → CONFIRM → ✓ DONE

For the backend: Authentication → Device Trust → Offline Reserve Validation → Transaction Construction → STP Generation → Hash → Digital Signature → Peer Verification → Two-Phase Commit → Local Storage → Pending Synchronization → Server Upload → Graph Reconstruction → Cryptographic Verification → Risk Analysis → Conflict Detection → Settlement. The first flow is what the user sees.

The user selects a recipient, enters the amount, authenticates, and confirms. The transaction commits locally in under 100ms, signed and hashed, and reconciles when the network comes back.

The app shows the user's full balance and highlights the reserved, locally-committed portion that is available for offline spend. A small "sync pending" indicator tells them what has already reconciled and what is still queued.

Yes. Received STPs are stored until the sender's transaction settles. A pending-receipt notification is queued and delivered the moment reconciliation completes.

No account is created for the demo concept. OffQen is a concept, not a live service.

Biometric unlock is optional but recommended, to keep the secure enclave as the only key store the app needs to touch.

Four offline transport channels: BLE, NFC, QR, and Wi-Fi Direct. Each is a different trade-off of range, friction, and device availability.

Best for close-proximity, hands-free transfers — peer-to-peer and near-field vending. Range is about 10 metres.

Tap-to-pay: range is under 4cm, so it is the most secure and friction-free option for small, face-to-face payments.

Any camera at any distance. QR works with a screen, a printed receipt, or a billboard — perfect for rural merchants and point-of-sale.

Infrastructure-free local area: group payments, pay walls, and merchant clusters up to 75–100 metres.

The home-page simulator walks through prepare → verify → commit → sync, with a live log and a generated STP payload, so users can see the state machine run before they ever use the app.

Ask the sender to scan your QR or connect over BLE/NFC/Wi-Fi Direct. The received STP is stored until the transaction settles.

Yes. Sender and receiver do not need to be online at the same time. The STP is delivered over the radio link and cached until it reconciles.

It shows as pending with a sync indicator. Once the chain verifies and the server settles it, the notification is delivered and the balance updates.

Each transaction is time-stamped and stored locally with its STP, signature, and chain reference. Offline sends are marked PENDING_SYNC until reconciled.

The app can export a CSV of all transactions with their STP hashes, signatures, and settlement state.

Each STP is stored in a sealed, encrypted local store with its hash chain, so a transaction can be re-verified at any time — even years later.

They sync as soon as the device reconnects. The server is notified, the transaction graph is rebuilt, and the transaction is auto-settled if the risk score is low.

The server rebuilds the transaction graph from the hash chain, verifying each link is contiguous and that no double spend exists in the reconciled set.

The server scores each pending transaction based on frequency, chain continuity, device trust, and amount. A low score auto-settles; a high score is held for manual review.

It stays PENDING_SYNC and retries on the next reconnect. The user is never notified as settled unless the server has confirmed it.

Yes — if the hash chain breaks, the signature is invalid, or the risk score exceeds the threshold. Rejected transactions are surfaced to the user with a clear reason.

50% of the wallet balance. A user can never commit more than half their funds to offline transactions until they reconcile.

There is no single fixed transaction limit in the concept; each transaction is validated against the reserve cap and the sender's balance locally.

It stays queued until the sender reconnects or the receiver comes online. There is no expiry that would risk a payment being lost.

Each transaction is signed with the sender's ECDSA key (TEE-backed when available), hashed with SHA-256, and chained to the previous transaction.