Akiba

Inspiration

Most savings and DCA apps built for African markets quietly route through a custodian — an exchange, a licensed VASP, a payment processor sitting between the user and their bitcoin. That's the same trust model the continent's mobile money systems have always had, just with sats instead of shillings. We wanted to know if a savings habit could exist without that intermediary at all: no custodian holding funds, no API key gatekeeping the swap, just two people — a saver and a peer — coordinating directly over an open protocol.

Pontmore gave us the missing piece. It's a Nostr-native protocol for coordinating bitcoin-fiat swaps and (human) agent discovery — which meant the "find someone with M-Pesa liquidity who wants sats" problem didn't need a centralized matcher at all. We already had SatStreak, a self-custodial Bitcoin DCA habit tracker built around a weekly streak mechanic. Akiba is what happens when you rip out the custodial swap path and replace it with a peer found on Pontmore.

What it does

Akiba lets a saver set a weekly bitcoin savings target — say KES 500 — denominated in local currency. When the schedule fires:

Akiba queries the Pontmore network to find a local peer (a human swap counterparty) able to fill the order. The peer's M-Pesa details arrive encrypted to the saver's Nostr key — no shared database, no custodian relaying payment info. The saver sends the M-Pesa payment directly to the peer and taps confirm in-app. Sats land in the saver's self-custodial Lightning wallet, and the streak continues.

There's no account to open with a third party and no API key brokering the trade — just the saver's Nostr identity, a peer's Nostr identity, and a protocol coordinating the handshake between them.

How we built it

Akiba is a pivot of SatStreak's existing architecture rather than a from-scratch build, which is what made a working version possible in the hackathon window. SatStreak already had:

Nostr-based identity for every user A PaymentProvider abstraction (originally pointed at MINMO for the M-Pesa↔Lightning leg) The weekly KES-denominated DCA scheduling and streak logic

For Akiba, we built a new Pontmore-specific client to replace the custodial swap path: instead of PaymentProvider talking to a single licensed counterparty, it now discovers a peer through Pontmore, receives their payment details encrypted over Nostr, and waits on the saver's confirmation before the Lightning leg settles. The notification layer was left as-is — NostrDM already solved "how do we reliably tell a saver their swap is ready" and that problem doesn't change when the counterparty becomes a peer instead of a custodian.

Challenges we ran into

Swapping a single trusted counterparty for an open peer network changes the trust assumptions in ways the original PaymentProvider interface wasn't designed for. With MINMO, a confirmed payment was effectively final; with a Pontmore peer, we had to think through what happens if a peer's M-Pesa details go stale, if a peer disappears mid-swap, or if the saver pays but confirmation lags — none of which existed as failure modes in the custodial version. Building the Pontmore client meant deciding how much of that escrow/dispute surface to handle in the hackathon build versus defer to the protocol itself.

Compressing this into the hackathon window also meant being disciplined about reuse: we didn't try to rebuild identity, notifications, or the streak/scheduling engine from zero — only the swap-matching core changed. The challenge was less "build something new" and more "swap one box in an existing architecture for a fundamentally different trust model without breaking the rest."

Accomplishments that we're proud of

We proved that a self-custodial DCA habit doesn't need a licensed swap partner to work end-to-end — peer discovery, encrypted payment handoff, and confirmation can all happen over Nostr and Pontmore alone. Reusing SatStreak's identity and notification layers unmodified also validated that those abstractions were designed well in the first place: the PaymentProvider/NotificationProvider split meant swapping out the custodial assumption didn't require touching the rest of the system.

What we learned

The biggest lesson was architectural: separating "how do we reach the user" from "how does the swap settle" early on is what made this pivot possible in hackathon time. We also came away with a much sharper sense of what peer-to-peer swap coordination actually requires beyond the happy path — discovery and encrypted handoff are the easy parts; the dispute and reliability questions are where an open protocol like Pontmore earns its complexity.

What's next for Akiba

Harden the Pontmore client around the failure modes surfaced during the build: stale peer details, swap timeouts, and a basic dispute path Expand peer discovery so savers can prefer previously-used peers or filter by reputation/liquidity signals on Pontmore Bring SMS-based confirmation fully into the swap-confirm step, so savers without a Nostr client installed can still complete the loop Pressure-test the model with real BitDevs Nairobi / Pontmore community members acting as peers, not just simulated counterparties

Built With

• nextjs