Lock
The user moves part of their balance into an Offline Vault with their partner. That value is reserved at the partner and cannot be spent elsewhere.
Two scans.Zero bars.
The payer's phone signs. The merchant's phone checks. The network catches up later.
The life ofan allowance
Certify
The partner signs an allowance certificate bound to the user's phone key (ECDSA P-256). It states the cap, currency and expiry.
Spend
The phone signs each payment. Funded value is used first, then any overdraft the partner extended.
Reconcile
Payments sync, duplicates and forks are checked, and settlement is produced. Unused value is released back after the grace period.
One payment, two scans, no network
The merchant and the payer never need a connection to each other or to a server.
Merchant
Show the request
The merchant device shows a QR with the amount, currency and a one-time request number.
Payer
Scan and confirm
The payer scans, sees the amount, and confirms with their PIN.
Payer
Sign and show
The phone signs the payment with its hardware-backed key and shows a payment QR.
Merchant
Verify in under a second
The merchant scans and checks everything offline: issuer signature, payer signature, limits, replay and chain.
Either device
Sync when there is signal
The first device to get a connection uploads. Settlement follows to the partner ledger.
What the merchant checks, offline, in undera second
Everything below runs on the merchant's device with cached issuer keys and the last synced revocation list.
- The issuer signature on the allowance certificate
- The allowance is not expired or revoked, as of the last sync
- The payer's signature on the payment
- The merchant ID and request number match this sale
- The currency matches and the running total is within the cap
- Sequence and running total are consistent with earlier payments from this allowance
- The previous-payment hash continues the chain
Seven layers, each withone job
A small, auditable protocol. Every layer can be reviewed, tested and replaced on its own.
- 1
Identity & Keys
A device key pair in the hardware keystore, attested at enrolment.
- 2
Allowance
A partner-signed certificate: device key, cap, currency, expiry, allowance ID.
- 3
Payment
A payer-signed payment with a sequence number, a running total and the previous payment's hash.
- 4
Transport
QR first. NFC and Bluetooth next. SMS and USSD fallbacks planned.
- 5
Queue & Sync
A durable encrypted queue that uploads whenever any device gets signal.
- 6
Reconciliation & Risk
Deduplicate, detect forks, apply limits and velocity rules, revoke keys.
- 7
Settlement
Batches to the partner ledger, domestic rails, or PAPSS for cross-border.
What happens ifsomeone cheats
Offline double-spend cannot be prevented with certainty. It can be made hard, bounded, detected and recovered. Here is each defence and what it buys you.
| Defence | Effect |
|---|---|
| Non-extractable device keys (hardware-backed and attested in native SDKs, planned) | Copying a device key out is hard; cloning a whole device is contained by caps and fork detection. |
| Allowance cap, per-transaction limit, expiry | Caps the maximum loss. |
| Hash-chained, sequenced payments | Any double-spend becomes a detectable fork. |
| Merchant-side consistency checks | Blocks naive replays at the same merchant. |
| Revocation list synced to merchants | Stops a known offender once merchants sync. |
| KYC'd allowance holder | The loss is recovered from the offender. |
| Risk pool guarantee | The merchant is paid regardless. |
Sync happens whenever anyonehas signal
The merchant does not need to be the one who connects. Either device can upload the signed payment, and each payment is already signed, so relaying it cannot change it.
Either side can settle
If the merchant's device fails before it syncs, the payer's copy can still be uploaded.
Settlement, your way
Batches go to your hosted ledger or your external ledger over the API and webhooks, over domestic rails, or through PAPSS for cross-border.