Why OffQen exists
The payment problem, the offline-first answer, and honest limits — the resilience case for the world's first offline transaction software.
What this page covers
Executive Summary
The hybrid architecture in two diagrams.
The Fundamental Problem
Internet dependency · rural coverage · outages · emergencies.
Security Problems & Solutions
Double spending · tampering · replay · device loss · 50% reserve.
The Advantages
Continuity · resilience · inclusion · auditability · merchant resilience.
Applicability
Geographic, industry and UX applicability.
Integrator Notes & Limits
Implementation guidance and honest constraints.
Executive summary
The problem
Digital payments assume constant internet. That assumption breaks the moment connectivity fails: poor rural coverage, outages, data exhaustion, congested events, and offline merchant terminals. When the pipe is down, the user is locked out of their own money.
The answer
OffQen moves ownership through cryptographic proof, never money through a live internet pipe. A device-to-device payment over BLE, NFC, QR, or Wi-Fi Direct with automatic cloud reconciliation the moment connectivity returns.
The user sees OPEN APP → SEE BALANCE → SEND / RECEIVE → SELECT PERSON → ENTER AMOUNT → AUTHENTICATE → CONFIRM → ✓ DONE. The cryptography stays invisible, exactly as a conventional payment app behaves.
The fundamental problem
The payment system assumes connectivity it does not control.
Poor network coverage
Rural towns, villages, and basements — payments silently fail because the cell tower is out of range.
Outages & disasters
Storms, floods, and blackouts take down towers. Cash becomes the only option, and even cash movement stalls.
Mobile data exhaustion
Running out of prepaid data means losing access to your own money — and paying to send it.
Congested events
Stadiums, festivals, and markets overload towers — thousands of phones, zero bandwidth, queues everywhere.
Offline merchant terminals
Shops without connectivity revert to cash registers. The customer cannot pay digitally.
Nepal at the edge
Mountain passes, remote hill districts, tourism hotspots, and disaster zones need payments that work when the network does not.
Security problems & solutions
How trust is preserved with no internet and no central party.
Double spending
Each STP carries a chain of custody reference and a unique nonce. A replay is rejected against both.
Tampering
ECDSA + SHA-256 signatures bind every field. Any alteration of amount, receiver, or chain breaks verification.
Replay attacks
Device nonces and timestamps make each transaction unique; the same STP cannot be re-sent.
Device loss
Remote device key revocation and a recovery flow keep a lost phone from moving value.
50% offline reserve cap
Over-reserve guard: a local wallet can never commit more than half its balance offline. Hard cap, never exceeded.
TEE-backed keys
Private keys are generated and used inside trusted execution hardware where possible, so the key never touches app memory.
The advantages
Why the world needs offline-first payment infrastructure.
Continuity of value
Money keeps moving when the network does not. No outage is a reason to lose access to your own funds.
Resilience
The payment rail is the devices, not the internet. A third failure point is removed from the loop.
Financial inclusion
People without reliable data plans, smartphone data, or affordable connectivity can still pay and be paid.
Auditability
The hash chain and digital signatures create a verifiable trail of every transaction, even when it was cached locally.
Merchant resilience
Shops keep taking digital payments through the next outage, buffering it until the network recovers.
Instant local commit
Payment commits in under 100ms on the device — no network round trip needed to get value moving.
Applicability
Where an offline-first layer earns its place.
Geographic diversity
Mountain districts, hill zones, and terai border towns each have distinct connectivity. One protocol, four channels — each suited to the local terrain.
Rural merchants
Corner shops, e-commerce last-mile delivery, and tourism stops in places with no data. They accept digital payments because the payment does not need the network.
Emergencies & disasters
Floods, earthquakes, and blackouts make the network a single point of failure. OffQen keeps financial continuity for aid and recovery.
Tourism & transit
Airports, bus stands, and mountain passes see huge transient traffic. Tourists pay in NPR or abroad without needing roaming data.
Integrator notes & limits
What to build on top, and what this demo keeps honest.
Stack basis
ECDSA + SHA-256 signatures, AES-256-GCM at rest, hash chains for tamper detection, two-phase commit for settled receipts.
Honest limits
This is a demonstration concept, not a licensed payment institution and not a live service. Offline sync logic, risk scoring, and settlement automation are the remaining engineering work.
Roadmap
P1 core protocol, P2 merchant ecosystem, P3 borderless resilience. Each phase defers only the work that depends on the previous one.
Contact
Project inbox: [email protected]