₦8,500Create request
Merchant requests an amount
The merchant enters the amount. igoPay creates a QR request on their phone.
Offline payment acceptance, verified in under a second.
igoPay is infrastructure for signing and verifying payment obligations with no network, on everyday iPhones and Android phones. A payer signs on their device, a payee verifies it offline, and any double-spend leaves signed, undeniable proof. Settlement rides your existing rails when a connection returns.
We build the acceptance layer. A licensed partner brings the rail and the licence. No customer funds are ever held.
✈️ Airplane mode
igoPay
Request a tab
₦8,500
Let them scan this
RequestSignVerify
Signed tab recorded
₦8,500
Pending
Money has not moved.
Settle later by an agreed method.
The primitive
One thing, done well: a signed obligation anyone can verify offline.
igoPay moves proof, not money. A payment obligation is signed by a hardware-backed key on the payer's phone, carried over QR, and checked by the payee with no server and no connection.
Software can't prevent a double-spend offline, so igoPay makes it self-incriminating instead. Every promise is hash-chained, and a fork is a signature the payer can't deny. No balance is held and no value is issued, so the acceptance layer needs no licence to run.
The full design, threat model and measured results are open. Read the design doc and the threat model.
How it works
Request. Sign. Verify.
Two phones, iOS or Android. Two QR scans. No server in the transaction path.
Confirm tab₦8,500Hold to sign
Buyer checks and signs
The buyer scans the request, checks the details and signs with a key held on their device.
✓Verified offlinePending receipt saved
Merchant verifies offline
The merchant scans the signed response. Both devices retain a pending receipt.
Settlement happens on a rail you choose, when a connection returns. The acceptance layer is identical whichever rail settles it.
What is built and tested
The offline acceptance layer, in code.
- ✓ Builds and verifies signed promises offline, with no server
- ✓ Hash-chains them, so a double-spend produces a fork proof
- ✓ Holds no private keys itself; signing stays on the device
- ✓ Ships as one no_std Rust core, run from Swift and Kotlin, with a passing test suite
What it does not do
The limits, stated plainly.
- × It holds no funds and issues no value
- × It detects double-spends, it can't prevent them
- × It settles nothing on its own; a licensed rail does
- × It is not a privacy product; the issuer sees the graph on sync
Offline verification proves that a device key signed the recorded details. It does not prove the payer has funds or will settle.
Use cases
One primitive, many deployments.
The same signed, offline-verifiable obligation supports more than one product. We build the layer. Partners build the products. Here are shapes the layer supports.
Signed offline tabs
A merchant records credit for a repeat buyer and verifies the signed amount offline. Settled later on a rail.
Same primitiveFake-alert-proof receipts
A payment claim the payee verifies on their own device, so a faked screenshot or transfer alert can't pass.
Same primitiveOffline payment instructions
A signed order captured offline that settles on a licensed rail the moment a connection returns.
Same primitiveTickets, passes and vouchers
Single-use claims for transport or events, verified offline in one scan. Reuse shows up the same way a double-spend does.
Same primitiveAgent and delivery receipts
Proof of handoff signed at the point of contact, checked later without trusting a photo.
Same primitiveAttestations and access grants
Signed claims a device can check at the door, with no server and no live lookup.
Same primitiveOne honest caveat. What's built and tested today is the core protocol, the acceptance layer. The use cases above are what a partner could build on it, not products we ship. We don't hold funds or run a consumer app; a licensed partner brings the rail, the licence and the distribution.
Demo
See the offline flow in 90 seconds.
A payee requests an amount, a payer signs it offline, and both devices keep a verified, matching record.
The prototype signs and verifies the obligation. It moves no money and settles nothing on its own.
90-second demo coming soon
Replace this card with your video when it is ready.Work with us
Who we're built for.
igoPay is for institutions and technical partners, not consumer sign-ups. If you can deploy, settle, assess or back offline acceptance, we want to talk.
Banks, PSPs and fintechs
Deploy the offline acceptance layer under your own licence and brand, with your merchants.
Discuss a deployment →Licensed settlement partners
Plug igoPay into your rail so offline obligations settle the moment connectivity returns.
Explore integration →Engineers and security researchers
Read the protocol, the threat model and the Rust core. Try to break it and tell us how.
Read the protocol →Accelerators and funders
Back deep infrastructure with a clear licensed-partner and acquisition path.
Meet the founder →Nigerian legal and regulatory advisors
Pressure-test the non-custodial thesis and the path to a responsible deployment.
Advise us →FAQ
Questions, answered plainly.
What exactly is igoPay?+
Infrastructure, not a consumer app. igoPay signs and verifies payment obligations offline. A licensed partner builds the product and settles the money on top of it.
Do you hold money or need a licence?+
No. The acceptance layer holds no funds and issues no value, so it needs no licence to run. Real-money settlement runs through a licensed partner. We're validating that non-custodial position with Nigerian counsel before any real-money deployment.
How do you handle double-spending offline?+
You can't prevent it in software, and we don't claim to. igoPay detects it. Promises are hash-chained and signed on the payer's device, so a fork is proof they can't deny, and the payee can check it on the spot.
Why does it work on ordinary phones?+
Signing uses a hardware-backed key on the phone: the Secure Enclave on iPhone, the Keystore on Android. Verification is just a signature check. Neither phone needs anything beyond that.
What does a partner bring, and what does igoPay bring?+
The partner brings the rail, the licence and the distribution. igoPay brings the offline acceptance layer: signing, verification and the anti-double-spend chain.
Is it production-ready?+
No. The Rust core and protocol are built and tested, and the same core already runs from Swift and Kotlin. The Android app is in progress, iOS follows from that core, and a field pilot comes after.
Can I read the design?+
Yes, it's open. The design doc, the threat model and the code and README are all on GitHub.
Work with igoPay
Talk to us about a deployment or a pilot.
Tell us who you are and what you'd build on offline acceptance.
We work with institutions and technical partners, not consumer sign-ups.