Blockchain-Anchored Contribution and Auction Ledger for a Registered 25-Member Chit Fund (Solidity, PHP/MySQL)

NammaChit is a BCA fifth-semester project (BCU SEP 2024, slot 24BCAPJ) that re-records the oldest neighbourhood finance institution in India — the chit fund — on a shared, tamper-evident ledger. In a registered chit under the Chit Funds Act, 1982, twenty-five members pay a fixed contribution every month for twenty-five months, an auction decides who takes the month's pot at a discount, and the foreman (the organiser) keeps the register that says who paid, who won and who is owed. Every chit dispute — "my payment is not written", "the auction was rigged", "the foreman vanished" — is really a dispute about trust in one person's register: exactly the problem a shared ledger solves.

The system is deliberately hybrid. The money logic lives in a Solidity smart contract deployed on a local Hardhat Ethereum network: contributions, the monthly auction (lowest bid wins the pot, discount shared by the unprized members), the statutory 5% cap on the foreman's commission, and every state change emitted as an unalterable event. A familiar PHP/MySQL member portal (the BCU syllabus stack: 24BCA51 Web Programming, MySQL, 24BCA54 Cryptography) handles registration, meeting calendars, notices and SHA-256 document hashing — minutes and the chit agreement are hashed and the hashes anchored on-chain, so later edits are detectable. A JavaScript front end calls the contract through ethers.js and MetaMask.

Solidity, Hardhat, ethers.js and MetaMask are industry-standard extras, clearly beyond the syllabus; the syllabus contributes JavaScript, PHP, MySQL, hashing and cryptography fundamentals — and a project story examiners rarely hear.

A registered 25-member chit fund moves about ₹2.5 lakh every month, but the institution's entire book-keeping is one register held by one person. Members cannot verify who has paid, the auction's winning bid is whatever the foreman minuted it as, the discount owed to unprized members is computed by hand and contested, and the statutory limit on the foreman's commission exists only on paper. When the foreman is honest, the system works; when the foreman errs or absconds, twenty-five families have no independent record of contributions, bids or payouts — only counterfoils and memory.

The group needs a shared ledger that no single member can alter: contributions and auctions recorded as they happen, the commission cap and discount distribution enforced by code rather than by goodwill, meeting minutes anchored by hash so later edits are provable, and a familiar web portal so that members who have never touched cryptocurrency can still participate. The project must also answer, honestly, where a blockchain is unnecessary — and where only it can help.

Abstract

Chit funds are India's home-grown rotating savings institution: members contribute monthly, an auction assigns the pot at a discount, and the foreman's register is the only record. The register model creates disputes (altered entries, rigged bids) and fraud (foremen absconding with collected funds). NammaChit replaces it with a Solidity smart contract on a local Hardhat Ethereum network that enforces contributions, auctions, the statutory 5% commission cap and payouts, while a PHP/MySQL portal manages off-chain records and anchors their hashes on-chain. The result is a chit whose history no single member — including the foreman — can alter.

Introduction

A registered chit fund is a rotating savings and credit scheme governed by the Chit Funds Act, 1982: subscribers agree on a chit amount (say ₹2,50,000), a duration (25 months) and a monthly contribution (₹10,000). Each month an auction is held; the member accepting the largest discount wins the pot (the prized subscriber), and the discount is shared among the remaining (unprized) members as credit against future contributions. The foreman runs this cycle and takes a commission capped at 5% of the chit amount. For lakhs of households without easy formal credit, chits are working capital — and because pots are large and cash-based, disputes and foreman fraud are standing complaints.

Existing system and its failures

• Paper register or Excel maintained by the foreman; members see it only at meetings.
• Auction by show of hands, minuted by the foreman — rigged-bid allegations are routine and unverifiable afterwards.
• Cash collections with counterfoils; a member's "I paid" fights the foreman's "you did not".
• Worst case: the foreman absconds with months of collections.
• Limitations: no shared truth, no audit trail, no enforced commission cap, no automatic discount sharing.

Proposed system

• A ChitGroup smart contract: 25 members, 25 monthly rounds, per-round auction window, sealed-bid commit then reveal (bids cannot be copied), automatic pot transfer to the round winner, pro-rata discount credit to unprized members, a commission function hard-capped at 5%, and penalties for late contributors.
• Event-sourced history: every contribution, bid, reveal, payout and distribution emits an Ethereum event — the ledger is the minutes.
• PHP/MySQL portal (off-chain): member profiles (name, phone, nominee — no government ID numbers), meeting calendar, notices, contribution receipts, and SHA-256 hashes of the chit agreement and meeting minutes stored in MySQL and anchored on-chain.
• Consensus: a Proof-of-Authority local network (Hardhat's dev node) with known validators — appropriate for a permissioned group of 25 known members.

Feasibility

• Technical: Solidity, Hardhat, ethers.js, PHP, MySQL and MetaMask are all free; the dev network needs no real cryptocurrency; the contract is under 300 lines with a full test suite — within a 12-week, three-member team's reach.
• Economic: zero cost; even a production deployment on a low-fee EVM chain would cost a few rupees of gas per month.
• Operational: a familiar portal plus a browser wallet is a small step, and the demo runs fully offline on one laptop.

In scope

• One registered chit group: 25 members, 25 monthly rounds, fixed contribution, auction by sealed bid with reveal, discount sharing, 5% foreman commission cap, late-payment penalty rules.
• Local permissioned network (Hardhat dev node / PoA-style) with MetaMask accounts representing members.
• PHP/MySQL portal for off-chain records and document-hash anchoring; ethers.js integration and dashboard.
• Hardhat unit tests and a demo dataset of three simulated rounds.

Out of scope (v1)

• Real-money deployment on a public mainnet; the prototype uses the Hardhat network's test ether.
• KYC/AML verification, Aadhaar/PAN collection or regulator filing workflows — the design deliberately stores no government ID numbers.
• Recovery litigation tooling, credit scoring and integration with actual bank/UPI payment rails.
• Mobile apps (the portal is responsive web); multi-chit management.

The team follows the Incremental SDLC model — a working skeleton (contract + portal talking to each other) exists by week 4, and each of the three increments adds an enforceable feature, so the 24BCAPJ review schedule (three internal reviews) always has something demonstrable.

Team split (3 members): Member A — smart contract and its tests; Member B — PHP/MySQL portal, hashing and anchoring service; Member C — JavaScript/ethers.js front end, MetaMask flows and the HTML report generator. Reviews, documentation and the demo script are shared.

Testing approach: Hardhat tests with chai assertions for every invariant (including the 5% cap and reentrancy guard behaviour); portal tested with black-box test cases; a two-laptop dress rehearsal of the demo before submission.

The system is a hybrid of an on-chain trust core and an off-chain convenience layer, deliberately split along the line "what must no one be able to alter" versus "what is only useful if it is convenient".

1. On-chain core (Solidity on Hardhat network): the ChitGroup contract holds the member registry, round state machine, contributions (in test ether), auction bids and payouts. Storage is minimised to what integrity requires; everything else lives off-chain.
2. Off-chain portal (PHP + MySQL): registration, meeting calendar, notices, downloadable receipts, and the SHA-256 hash registry. MySQL keeps full documents; only their 32-byte hashes go on-chain as anchors, so a document that is later edited no longer matches its hash.
3. Client layer (JavaScript): the browser page uses ethers.js to read contract state, submit transactions through MetaMask, and render round dashboards; the portal's PHP API serves portal data to the same page.

flowchart TD
  M([Member browser]) --> P["PHP portal
  (registration, calendar, notices)"]
  P --> DB[(MySQL: members, minutes,
  receipts, anchor index)]
  P --> H["SHA-256 hash service
  (agreement, minutes)"]
  H -->|anchor hash| SC["ChitGroup contract
  (Solidity)"]
  M -->|"MetaMask signs txn"| E["ethers.js client"]
  E --> SC
  SC --> EV["Events: Contribution, Bid,
  Reveal, Payout, Distribution"]
  EV -->|"listener syncs"| DB
  SC --> CH[("Hardhat local network
  (PoA-style, 25 known members)")]

Contract state machine

flowchart LR
  J["JOINED: members registered"] --> C["CONTRIBUTING: month opens,
  contributions accepted"]
  C --> BID["BIDDING: sealed commitments"]
  BID --> REV["REVEAL: bids opened,
  lowest wins the pot"]
  REV --> PAY["SETTLED: pot to winner,
  discount shared, commission ≤ 5%"]
  PAY --> C
  PAY --> D["COMPLETED: all 25 rounds done"]

The round cycle repeats twenty-five times; after the final round the contract moves to COMPLETED and refuses all state changes. Every arrow in this diagram is a guarded transition in code — an attempt to contribute during BIDDING, bid after the window, or reveal before REVEAL reverts with a specific error, and those reversions are exactly what the Hardhat test suite asserts.

• Guarantor and collateral rules for prized members, modelled as on-chain stake that is released on completing the remaining contributions.
• Multi-group and foreman-reputation contracts so a foreman's completed chits are publicly countable.
• UPI off-ramp integration (documented as future work) linking on-chain settlement to real bank transfers through a payment-service partner.
• A formal audit pass — run a static-analysis tool (Slither-class) and file the findings in the report.
• Mobile-first PWA for the portal with push reminders on contribution and auction days.
• Gas and cost study comparing the prototype against a public low-fee EVM chain for a real deployment decision.