Tamper-Evident Farm-Subsidy Disbursement Trail with Merkle-Batch Anchoring (Java, MySQL)

UzhavanPay is an advanced BCA mini-project (University of Madras CBCS, slot 320S61, semester 6) that models the payment trail of a direct-benefit-transfer (DBT) farm-subsidy scheme — the pattern used by programmes such as PM-KISAN, where an instalment travels through field verification, sanction, a payment file and finally bank credit — and makes every step of that trail tamper-evident and independently verifiable.

The taluk office in the model has four roles: the field officer verifies a beneficiary and records the disbursement event; the taluk officer sanctions a batch; the disbursing officer generates the payment file and later imports the bank's credit acknowledgements; and the beneficiary checks status and can verify a receipt. Each disbursement event is hashed; each sanctioned batch is sealed into a Merkle tree whose root is written to an append-only anchor ledger — and, as an explicitly optional industry-standard extension, published to the Sepolia testnet through Web3j so the root exists outside the office's own database.

Given any receipt, the system can produce a Merkle inclusion proof: a handful of sibling hashes that lets a verifier confirm the payment belongs to the anchored batch without seeing anyone else's data.

The build uses the profile's own stack — Java (220C4A), MySQL (320C5B) and JSP/Servlets (320C5C) — with the Merkle tree and hash functions written in plain Java, plus JUnit tests for every proof. The design never stores Aadhaar or other government ID numbers: beneficiaries are internal codes with a masked bank reference.

Farm-subsidy instalments disbursed through a taluk office travel through several hands — field verification, sanction, payment-file generation, bank credit — and every hand touches the same database. Because the database is the only record, a person with write access can alter an amount, substitute a bank reference, mark a paid instalment as failed, or insert a fake beneficiary after the fact, and no conventional application will ever notice. When beneficiaries or auditors question a payment, the office can only point at the same mutable table, so disputes end as arguments. A full blockchain network is the textbook answer but is impractical for a single office that needs no cryptocurrency.

What is needed is a disbursement trail that is append-only and self-proving: recording must be as easy as today, but any alteration must become detectable, each payment must be provable to belong to a sanctioned batch, and the proof must not depend on trusting the office's own database alone.

Abstract

UzhavanPay is a semester-6 mini project that implements a tamper-evident disbursement trail for a taluk-level farm-subsidy scheme on the DBT pattern. Disbursement events (verify, sanction, payment file, bank credit) are hash-linked; sanctioned batches are sealed into Merkle trees whose roots are anchored in an append-only anchor store and optionally on a public testnet. A Merkle-proof service lets a beneficiary verify a receipt against the anchored root. The build uses Java Servlets/JSP, MySQL and JUnit.

Introduction

India moves farm subsidies through DBT: the sanctioning office releases instalments, a bank credits them, and portals such as the PM-KISAN beneficiary-status page let farmers see where an instalment stands. The integrity of that trail depends on the office's own database. If a row is altered — an amount changed, a credit marked 'failed' after money actually moved, a beneficiary swapped — ordinary software notices nothing, and an audit must trust whatever the database currently says.

Existing System

• Taluk-scale payment workflows are tracked in spreadsheets or plain CRUD systems with no cryptographic integrity.
• Any officer with database access can silently modify amounts, swap accounts or retro-mark statuses.
• Reconciliation between the office's records and bank acknowledgements is manual and produces disputes that neither side can prove.
• Beneficiaries see a status screen but have no way to check that what it shows was ever truly sanctioned.
• Blockchains solve this, but a full distributed ledger is neither deployable nor needed at taluk scale.

Proposed System

• A Java web application that records each disbursement as an append-only event carrying its own SHA-256 hash and the previous event's hash.
• A batch-sealing service that builds a binary Merkle tree over a sanctioned batch's events and stores the root in an append-only anchor table.
• An optional anchoring extension (industry-standard extra) that posts each Merkle root to the Sepolia testnet via Web3j and stores the transaction hash, giving the trail an anchor that survives even a full local database rewrite.
• A verification service that answers two questions on demand: is the whole trail internally consistent (full recompute), and does this receipt belong to the anchored batch (Merkle inclusion proof — logarithmic, no batch reveal).
• Role-based workflow enforcement with a state machine (Verified → Sanctioned → PaymentFiled → Credited/Failed → Retry), duplicate-instalment checks per cycle, and a beneficiary status portal with printable, proof-bearing receipts.

Feasibility Study

• Technical: Java's MessageDigest provides SHA-256; the Merkle builder is ~80 lines of plain Java; Web3j is one extra dependency used behind a feature flag. Tomcat, MySQL and JUnit run on any student laptop; the testnet option needs only an internet connection at anchoring time.
• Economic: All components are open source; Sepolia test ether is free from public faucets.
• Operational: Officers keep their existing flow — the app looks like a normal workflow tool — while the auditor gains a verify screen and the beneficiary gains a receipt QR that anyone can check.

In scope

• A single taluk office (simulated) with the four roles above and about 500 beneficiaries across 3 cycles of sample data.
• Disbursement events, batches, Merkle sealing, anchor store, inclusion proofs, status portal, audit reports.
• Optional Sepolia anchoring behind a configuration flag; simulation mode when offline.
• No Aadhaar or government ID numbers anywhere — internal beneficiary codes and masked bank references only.

Out of scope (v1)

• Real bank/NPCI integration: acknowledgements are imported from a CSV that stands in for the bank's file.
• A private Hyperledger/Fabric network or any cryptocurrency payments.
• Multi-taluk or state-level deployment, and GIS/land-record integration.
• Grievance-workflow management beyond status display.

The project uses an incremental model with weekly increments — the right fit for a 6-week mini project where each week must end in something demonstrable for the internal review.

Testing approach: JUnit unit tests for hash vectors, tree building (including 3-leaf and 5-leaf odd cases) and proof generation/verification; tamper tests that mutate stored rows and assert detection; black-box test cases per screen; and a scripted end-to-end demo from field verification to a verified receipt.

UzhavanPay follows a classic three-tier Java web architecture with the cryptographic services isolated in a plain-Java core library so they can be tested without a servlet container.

1. Presentation tier — JSP with JSTL, minimal JavaScript for the receipt-verification page; separate layouts per role.
2. Application tier — Servlets and DAO classes implement the workflow; the crypto package holds HashUtil (SHA-256, canonical bytes), MerkleTree (build, root, proof) and AnchorPublisher (Web3j or simulation) — all pure Java, no container dependencies.
3. Data tier — MySQL through JDBC with PreparedStatement everywhere; event, batch and anchor tables are append-only from the application.

flowchart LR
  B[Browser: officers / beneficiary] -->|HTTP| T[ Tomcat: Servlets + JSP ]
  T --> W[Workflow state machine]
  W --> DAO[JDBC DAOs - PreparedStatement]
  DAO --> DB[(MySQL)]
  W --> H[HashUtil - SHA-256 linking]
  W --> M[MerkleTree builder]
  M --> A[AnchorPublisher]
  A -->|flag on| S[Sepolia via Web3j]
  A -->|flag off| SIM[(Simulation anchor store)]
  T --> P[Proof service: inclusion proofs]
  P --> M

How a batch is sealed (Merkle tree)

flowchart TD
  R["Root: hash(h01 + h23)"] --> H01["h01 = hash(h0 + h1)"]
  R --> H23["h23 = hash(h2 + h3)"]
  H01 --> L0["h0: event 1 (verified payment)"]
  H01 --> L1["h1: event 2 (verified payment)"]
  H23 --> L2["h2: event 3 (verified payment)"]
  H23 --> L3["h3: event 4 (verified payment)"]

ER diagram

erDiagram
  USER ||--o{ DISBURSEMENT_EVENT : acts
  BENEFICIARY ||--o{ DISBURSEMENT_EVENT : "receives"
  CYCLE ||--o{ DISBURSEMENT_EVENT : "covers"
  BATCH ||--o{ DISBURSEMENT_EVENT : "seals as leaves"
  BATCH ||--o| ANCHOR_RECORD : "is anchored by"

  USER {
    string id PK
    string username UK
    string passwordHash
    string role
  }
  BENEFICIARY {
    string code PK
    string name
    string village
    string landAlias
    string bankRefMasked
    string status
  }
  CYCLE {
    string id PK
    string label
    decimal amount
  }
  DISBURSEMENT_EVENT {
    string id PK
    string beneficiaryCode FK
    string cycleId FK
    string stage
    decimal amount
    string officerId FK
    datetime at
    string eventHash
    string prevEventHash
    string batchId FK
  }
  BATCH {
    string id PK
    string cycleId FK
    string merkleRoot
    int leafCount
    datetime sanctionedAt
  }
  ANCHOR_RECORD {
    string id PK
    string batchId FK
    string merkleRoot
    string anchorType
    string txRef
    datetime anchoredAt
  }

DFD — Level 0 (context diagram)

flowchart LR
  FO([Field Officer]) --"verification events"--> SYS((UzhavanPay<br/>Disbursement Trail))
  TO([Taluk Officer]) --"sanction"--> SYS
  DO([Disbursing Officer]) --"payment file, bank acks"--> SYS
  BEN([Beneficiary]) --"status query, receipt proof"--> SYS
  SYS --"sanctioned batches, audit reports"--> TO
  SYS --"anchored roots"--> AN([Anchor: store / testnet])

DFD — Level 1

flowchart TD
  FO([Field Officer]) --> P2["2.0 Record verification event"]
  P2 <--> D3[(D3 Beneficiaries)]
  P2 <--> D4[(D4 Disbursement Events)]
  TO([Taluk Officer]) --> P3["3.0 Sanction batch + build Merkle tree"]
  D4 --> P3
  P3 --> D5[(D5 Batches)]
  P3 --> P4["4.0 Publish anchor"]
  P4 --> D6[(D6 Anchor Records)]
  DO([Disbursing Officer]) --> P5["5.0 Payment file + bank acknowledgements"]
  P5 <--> D4
  BEN([Beneficiary]) --> P6["6.0 Status + receipt proof"]
  D5 --> P6
  D6 --> P6
  D4 --> P6
  U([Any officer]) --> P1["1.0 Authenticate + role check"]
  P1 <--> D2[(D2 Users)]

Use-case diagram

flowchart LR
  FO([Field Officer])
  TO([Taluk Officer])
  DO([Disbursing Officer])
  BEN([Beneficiary])
  subgraph UP[UzhavanPay]
    UC1(Login)
    UC2(Verify beneficiary + record event)
    UC3(Sanction batch and seal Merkle root)
    UC4(Generate payment file)
    UC5(Import bank credit acknowledgements)
    UC6(View status and verify receipt proof)
    UC7(Run full-trail audit)
    UC8(Anchor root to testnet)
  end
  FO --- UC1 & UC2
  TO --- UC1 & UC3 & UC7 & UC8
  DO --- UC1 & UC4 & UC5
  BEN --- UC6

• Federation: several taluk offices anchoring roots to a shared permissioned ledger (Hyperledger Fabric), turning one trail into a district-wide one.
• Signed payment files: cryptographically sign the bank CSV so the bank can verify it came from the office unaltered.
• Grievance workflow: beneficiary-raised disputes that auto-attach the Merkle proof and audit extract.
• Land-record verification hooks: plugging the registry into state land-record portals for automated eligibility re-checks.
• Analytics: cycle-level dashboards (sanction-to-credit time, failure rates by bank branch) for the collector's review.