Pulse

Problem

In Nigeria and across Sub-Saharan Africa, unreliable internet connectivity is a constant reality. Millions of people are locked out of digital financial services every day — not because they don't have a phone, or a bank account — but because a 3G tower went down, or USSD is congested, or the POS machine has no signal.

Existing fintech infrastructure assumes a persistent connection. That assumption fails constantly in emerging markets, and it costs real money for real people.

Research

Before writing any code, I spent weeks talking to local merchants and analyzing existing payment methods. The research highlighted that while mobile money (USSD) exists, it is highly prone to network timeouts. We needed a solution that was entirely decoupled from real-time network availability, relying instead on cryptographic trust established between two nearby devices.

Challenges

The Double-Spend Problem

The hardest engineering challenge was designing the escrow mechanism to prevent double-spending without access to a shared ledger. The solution was a deterministic nonce system tied to the device clock plus a monotonic counter — making replay attacks computationally infeasible even in offline conditions.

My Role

As the founder and lead engineer, I was responsible for the entire product lifecycle. I designed the architecture, built the frontend interfaces, and implemented the core Node.js payment layer and cryptographic validation engine.

Architecture

Pulse is a seven-layer offline payment protocol. It allows two parties to execute a financially guaranteed transaction using cryptographic proofs that are reconciled with the network when connectivity is restored.

flowchart LR
  A[User] -->|Signs Intent| B(Authorization)
  B -->|Locks Funds| C(Escrow)
  C -->|Encodes Txn| D(Transport)
  D -->|Scans QR/NFC| E(Peer Device)
  E -->|Stores Txn| F(Queue)
  F -->|Connectivity Restored| G(Settlement)

The protocol is structured in distinct layers, including:

Identity & Authorization: Cryptographic key-pair generation using secp256k1. The payer signs an intent; the payee verifies the signature locally without a server.
Transport & Queuing: Transactions are encoded as QR codes or NFC payloads, then queued in a local SQLite store with a priority ordering algorithm.
Reconciliation: When connectivity is restored, queued transactions are batched and submitted to the settlement network.

Design Process

The UX had to be foolproof. Since users might be offline, the interface needed to communicate transaction finality without a network confirmation. I designed clear, color-coded states and deterministic loading indicators to build trust in the offline process.

Development

The stack focused on performance and reliability on low-end devices:

Node.js React Native PostgreSQL SQLite (offline) ECDSA / secp256k1 Supabase

Results

Transactions: 10,000+ processed offline successfully.
Uptime: Operates reliably even with 0% internet coverage.
Growth: Piloted at 5 local markets, proving the viability of the protocol.

Lessons Learned

Building Pulse taught me that the most challenging engineering problems are not about writing clever code — they are about designing systems that remain correct when all your assumptions break down. Network reliability is an assumption. Clock synchronization is an assumption.

The discipline of adversarial thinking — asking "what if this component is unavailable?" at every layer — is something I now apply to every system I design, regardless of whether it touches payments.