Verifiable Committee (ROSCA) Ledger with Provably Fair Payout Draws

The problem: trust is the only thing holding the committee together

Committees, also known as BCs or ROSCAs, are one of the most common ways people in Pakistan and across South Asia save. Ten people each pay a fixed sum every month, and each month one of them receives the whole pot. The organiser keeps the record, often in a notebook or a WhatsApp chat. Disputes are common: who paid late, whether the draw was fair, why the organiser's cousin received the pot in the second month. When trust breaks, people lose money and friendships.

The record keeping problem is a computer science problem: a shared append-only log that one party controls, and a random draw that the party running it could rig.

What already exists and the gap

• Oraan digitises committees in Pakistan and runs its own committees, where members choose a payout month and the company manages the pool.
• Committee Book and similar tracker apps help an organiser record members, payments and draws without handling money.
• Notebooks and WhatsApp groups are what most committees still use.

The gap is verifiability. In tracker apps the organiser can still edit entries, and members have to trust that the draw was random. Nobody gives each member cryptographic proof that the history is intact and the draw was fair, while keeping the familiar informal committee run by people who know each other.

Inspiration

The Economics of Rotating Savings and Credit Associations (Besley, Coate and Loury, American Economic Review, 1993) models how random-draw and bidding ROSCAs let people without credit access buy lumpy goods sooner, and why the allocation rule matters to members' welfare. The cryptographic side draws on well-known building blocks: hash-chained logs as used in Certificate Transparency, and commit-reveal schemes for shared randomness.

What you build

• Organisers create a committee, invite members by link and record payments.
• Members confirm each of their payments with a tap, which signs the entry with a key held on their phone, and see the full ledger.
• Everyone takes part in the draw: each phone commits to a secret random value, then all reveal, and the combined value picks the next recipient. Anyone can rerun the verification.
• A member who suspects a problem taps "verify", and the app checks every signature and hash link, showing exactly where history was changed if it was.

The technically interesting part

• Hash-chained, signed entries. Each entry includes the hash of the previous one and the signatures of the payer and the organiser. Deleting or editing any entry breaks the chain for every member who holds a copy.
• Commit-reveal randomness. Members publish hashes of secret values first, then reveal them. Handle the classic weakness: the last person to reveal can refuse if they dislike the result. Design and justify a rule, such as a deadline after which a non-revealer's value is replaced by a fixed one and they are recorded as having withheld.
• Offline-first sync. Members in areas with poor connectivity record and sign entries offline; the server only relays and stores. Merging must never reorder confirmed history.
• Key management for ordinary users. People lose phones. Design recovery that does not let the organiser impersonate a member.

How to evaluate it

• Tamper tests: a script that edits, deletes, reorders and replays entries on the server and on one device; every attempt must be detected by other members.
• Draw fairness: simulate thousands of draws and test the distribution; demonstrate that a single dishonest participant cannot bias the result beyond what your rule allows.
• Field study: run with two real committees, record disputes, time spent and what members understood about verification.
• Usability: can a member with no technical background explain in their own words what the verify screen means?

Suggested plan

• Weeks 1 to 4: interview organisers and members; design the data model and the threat model.
• Weeks 5 to 10: signed hash chain, verifier and tamper tests.
• Weeks 11 to 15: commit-reveal draw and simulations.
• Semester 2, weeks 1 to 6: offline sync, reminders and key recovery.
• Semester 2, weeks 7 to 13: field study with real committees.
• Semester 2, weeks 14 to 15: report and demo.

Path to a product

Committees are huge and informal, and a tool that makes them more trustworthy without taking custody of money avoids most of the regulation that applies to holding funds. A free app with optional paid features for large organisers, or a partnership with a bank or wallet that wants to offer savings history to members, are realistic routes. Check with a lawyer before adding anything that touches money directly.

Scope warning

Never move or hold money in this project; record only. Do not invent your own cryptography: use a well-reviewed library for signatures and hashing. Do not use a blockchain; a signed hash chain gives the guarantees you need with far less complexity.

Learn what you need on Sefism

• Mobile development roadmap: offline-first apps and local storage.
• Cybersecurity roadmap: threat modelling and the basics of signatures and hashing.
• OWASP Cheat Sheet Series: key storage and cryptographic storage guidance.
• Flutter Documentation: if you build the app in Flutter.
• Backend development cheat sheet: the relay and sync server.

Get help with this idea

The hard part is a threat model that matches how committees really fail, and a verify screen ordinary members trust. Tauseef can help you scope the cryptography, plan the field study and keep the app clear of holding money. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session