Startup notes
The book that can't be cooked.
A startup around savings groups in East Africa. I built the MVP, did the research, and stopped — the problem was real, my solution wasn't native enough.
Members pay in
Each contribution is a real Kaspa transaction to the group's address.
The chama wallet
The group is one wallet. Nobody holds it on the group's behalf.
The chain keeps the book
Every payment is the record. The server can read it; it can't rewrite it.
Where it started
At a Nura Global hackathon, a conversation about payments in Africa turned to the chama: a rotating savings group where members pay in on a schedule and one takes the pot each round. I read about it, spoke to friends who know the market, and decided it was worth researching.
The problem
A chama runs on trust and a book. That book is usually paper, a spreadsheet, or a WhatsApp thread — and it's the thing people argue about.
The design
A chama in Daftari is a real Kaspa wallet, not a database row. Members pay in on-chain, signed in the browser with Kastle. A wallet can join only after it has transacted with the group. Names and memberships live in a database; the money never does.
If the record can be edited, it isn't a record.
What I couldn't solve
- Privacy. A record no one can edit is also a record everyone can read. A chama's book belongs to its members, not the world.
- The edges. Onboarding people who have never held a key, disputes that don't require me, and groups that outgrow the people who already trust each other.
Why I stopped
Adoption. A chama is a group of people who already trust each other, and most would rather keep the system they know than move their money to an app built by an outsider. I wasn't part of that trust, and trust doesn't move because the code is better.
What I took from it
The lesson wasn't technical. A record can be made trustworthy; a relationship can't be coded. Next time I'd start with the group and its trust, not with the chain.