What If the Money Could Say No

Now and then I read about public money that was sanctioned and spent, while the school, hospital or road it paid for was never properly built.

Like most people, I'd read it and move on.

But I build backend systems for a living, and I started asking a different question: not who took the money, but why the system allowed it.

This post is a proposal. I haven't built any of it yet.

The idea applies to any public development spending: roads, schools, hospitals, water supply, welfare schemes. I'll use a road project as the case study throughout, because it's easy to picture and easy to verify on the ground.

Corruption is a systems problem

The usual response is to catch the people involved, through audits, inquiries and raids.

That matters, but it treats the symptom. The same openings stay in place for the next person.

Corruption depends on three things: discretion, opacity, and steps where nobody is checking. Reduce those, and the system makes dishonesty harder to do and easier to see.

A lot of that is an engineering problem, which is something I can work on.

The vision: blockchain, ledger and e₹ in one flow

The core of this proposal is two pieces working together. A blockchain ledger records every rupee and every decision, so nothing can be rewritten. Programmable e₹ carries the rules inside the money, so it can only go where it was approved to go.

Every rupee moves as e₹, and every step lands on the blockchain

Here is the full flow, using a road project as the case study:

Sanction on chain. The sanctioned amount, its purpose and the government order are written to the blockchain ledger.
Issued as programmable e₹. The funds reach the department's wallet as purpose-bound e₹, with the purpose, budget cap and expiry built into the tokens.
Allocated down the tree. The department allocates to the project. The contractor's wallet receives e₹ locked per milestone.
Spent only against bills. Payments to vendors and labour go out in e₹, and each must match a bill already on the ledger.
Evidence submitted. The contractor uploads geotagged photos for the milestone, and their hashes are written on chain.
Reviewed in public. Randomly assigned officials, engineers and citizens review the evidence. Their signed remarks go on chain.
Released by smart contract. When reviewers reach quorum, the next tranche unlocks automatically. If not, it stays frozen.
Visible to everyone. Every step appears on a public dashboard anyone in India can open.

The sections below go through each piece in detail.

Follow the rupee

Start with a ledger. Every rupee the government sanctions gets an entry, and every hop it takes after that gets one too.

Sanction → department → project → contractor → vendors and labour.

It's a tree. Each node can only spend from what its parent gave it, only on what it was given for, and never more than it got. The system enforces this on every write.

Every payment has to point at a bill. Every bill points at a GST invoice. If a contractor pays for cement, there is a matching invoice from a vendor, and anyone can check it.

This ledger is a permissioned blockchain. Copies run at independent bodies, such as the auditor and the finance department, so no single party controls the record.

It rests on three properties:

Append-only. Nothing gets edited. Corrections are new entries.
Hash-chained. Each entry carries the hash of the one before it. Change something old and everything after it breaks.
Anchored somewhere you don't control. A fingerprint of the ledger is published regularly to independent places, so even the operator can't rewrite history without it showing.

Each node checks the others. A change made in one place without a matching signed entry is caught by the rest.

Money that can say no

A ledger tells you where money went. It doesn't stop it from going somewhere it shouldn't. You only find out afterwards.

This is where the digital rupee helps. RBI's e₹ supports programmability: the sponsor of the funds can restrict what a wallet's money is allowed to be used for.

So give every node in the tree its own e₹ wallet, and let the tokens carry the rules:

In the road case study, the project's money can pay cement, steel and labour vendors. A hospital project's money would have its own list, such as builders and equipment suppliers. It can't pay anyone outside those categories.
It can't pay anyone without a matching bill already on the ledger.
It unlocks in tranches, one per milestone.
Unspent money returns to the parent budget after the deadline.

The ledger records the money, and the e₹ restricts it. Together, money can only move along its approved path.

One limitation: e₹ has no open API. It needs RBI and a bank partner, so it's outside what I can build alone.

What e₹ programmability supports today

Capability	What it allows	Source
Purpose-bound payments	Government agencies can make sure payments are used only for defined benefits	RBI, Feb 2024
Corporate expense rules	Companies can restrict spending to set expenses, such as business travel	RBI, Feb 2024
Validity period	Money can be used only within a set time window	RBI, Feb 2024
Geographic limits	Money can be used only in set areas	RBI, Feb 2024
Offline payments	Transactions in areas with poor or no connectivity	RBI, Feb 2024
Spending categories	Pilot widened in Aug 2024 to categories such as fuel, groceries, education, healthcare and travel	Fintech builder guide
Welfare (DBT) pilots	Food subsidies paid in e₹ in Gujarat, Puducherry and Chandigarh in 2025-26	RBI Annual Report, via EPI
Planned expansion	More DBT use cases and retail pilots in 2026-27	Outlook Money

How it needs to be extended

Today's rules are built for one payer and one wallet, like a subsidy to a citizen. Public works money passes through many hands, so programmability would need a few additions:

Rules that pass down a chain. A cap and purpose set at the department should carry down to the contractor and then the vendor, with each level's limit inside its parent's.
Payee lists by registry ID. Allow payment only to vendors with a verified GSTIN in an approved category, not just broad merchant categories.
Conditional release. Tokens stay locked until an external signed approval, such as the reviewer quorum, unlocks them.
Bill-linked transfers. Every transfer carries an invoice reference that must already exist on the ledger.
Automatic return. Unspent or expired money goes back to the parent wallet instead of just becoming unusable.
Public visibility for government wallets. Spending from government-program wallets is published openly, while personal e₹ use stays private.
Developer access. A sandbox API so govtech builders can build and test on programmable e₹.

Proof, not paperwork

The milestone check is the most important part. If the person being paid can also mark the work as done, the system adds little.

So a milestone unlocks only when there's evidence, and someone independent has looked at it.

Evidence comes from an app, not a gallery upload. Photos are geotagged and timestamped, checked against the project's actual boundary, and the device attests it isn't spoofing its location. The file's hash hits the ledger the moment it's taken. This makes reused or fake photos much harder to submit.

Reviewers come in three kinds: government engineers, verified volunteer engineers, and citizens who live nearby. They're assigned at random from outside the district, so the contractor can't choose them. Release needs a quorum, not one signature.

And every remark is public. They're signed, permanent and visible to anyone. A reviewer can add a follow-up. They can't edit what they said.

Public, permanent remarks matter. Approving poor work is harder when your name and approval history are visible to everyone.

The parts a ledger can't fix

There is a clear limit. A tamper-proof record proves nobody changed it later. It doesn't prove it was true in the first place.

An inflated bill stays inflated, even on a tamper-proof ledger.

So the edges need their own defences. Compare unit rates against the state's schedule of rates. Flag newly registered vendors linked to the contractor. Watch for money that returns to the contractor through a vendor. Pay labour directly into workers' own accounts, because that's where cash leaks most.

None of this is complete. Some kickbacks will happen off the system. The goal is to make corruption harder and more visible, not impossible.

Then there's scale. If this is public for all of India, it has to handle sudden spikes in traffic. The workload helps: writes are tiny, reads are enormous, and data changes slowly. Pre-building every project page as static JSON behind a CDN keeps the load off the database.

What I plan to build first

This won't solve corruption on its own.

Realistically, the part I can build on my own is the ledger: the allocation tree, bills, hash chaining, signed entries, external anchoring, and a public page that shows every rupee, using a mock road project. Everything else needs government integration. Programmable e₹ needs RBI and a bank partner. Official reviewers, sanction data and contractor records need departments to take part. If the ledger works for a mock project, it gives those conversations something concrete to start from.

The hard parts aren't really technical. Getting the data, getting a department to say yes, protecting the people who report. The ledger is where I can start.

I'm going to try building it. I'll write about the challenges as I run into them, and if possible, I'll open source it. If you've worked in government tech, public works, or audit, I'd like to hear where this falls short. Comments are open.