What DigiFIR is
DigiFIR is a shared case record for First Information Reports (FIRs). The state police, the judiciary and forensic science laboratories keep it together on a permissioned Hyperledger Fabric blockchain. It follows a case from the citizen's complaint to the court's final order, and no single institution can rewrite what the others have recorded.
Each person who acts on a case signs that action with a key held on their own phone. A smart contract checks the signature against the person's registered role and jurisdiction before the action reaches the ledger. Another check confirms that the right institutions agreed before it is committed. The backend servers carry these signed actions to the ledger and build fast read views from it, but they hold no one's key, so they cannot create, change or backdate a record.
Problems it addresses
| Today | With DigiFIR |
|---|---|
| A complaint that a station never registers can disappear without a trace. | The complaint is on the ledger from the moment it is filed, with its time. A complaint that stays unregistered stays visibly unregistered on a ledger the judiciary also holds. |
| Handoffs between police, laboratory and court rely on paper and separate systems. | Final reports, lab reports, court orders and status requests travel on the same record and reach each side's app. |
| Forged FIR copies and "digital arrest" scams use fake police documents. | Anyone can check a document against the ledger by its SHA-256 fingerprint without uploading the document itself. |
| Gaps in the chain of custody of evidence are hard to prove or disprove. | Every custody hop needs signatures from both the giver and the receiver, and the last holder and time are always visible. |
| The same incident can be registered twice at different stations. | A national duplicate check runs at registration. A probable duplicate is never refused: it goes to a magistrate, who decides. |
Who uses it
| Person | Where they work | What they do |
|---|---|---|
| Citizen | Citizen app (Android, iPhone) or the web portal | File a complaint, sign it, track it, verify a police document |
| Police officers | Police app | Decide on complaints, register FIRs, keep the case diary, seize evidence, send parcels to the laboratory, file final reports |
| Forensic laboratory staff | Lab app | Receive or refuse parcels, record examination stages, seal reports, hand exhibits back |
| Magistrates | Court app | Decide probable duplicates and closure reports, take cognizance, record remand, bail, transfer and quash orders, ask for status reports |
| Registrars | The same apps, registrar section | Enrol officials' phones in person, keep the roster, revoke keys |
| Auditors and court staff | Officials' desktop console | Read the ledger explorer, check integrity reports, work the admin desk |
| Anyone | Public verification page | Check whether a police document is on the ledger |
Roles and privileges lists exactly what each role may do and see.
Design principles
The architecture follows five rules, taken from the project's architecture decisions.
- The chaincode decides what is allowed. Every change of state carries a signature made on the actor's own device. The chaincode checks it against the actor's role and jurisdiction, and the endorsement policy checks which institutions agreed.
- Data that every member can read is kept to a minimum. The shared ledger holds hashes, salted references, statuses, links and decentralised identifiers. Narratives and personal details stay in private data collections of the state concerned. Files are encrypted and kept off the chain. The Aadhaar number is stored nowhere.
- Nothing is deleted. A correction is a new version, and a case only moves forward through its states. Erasure under a court order destroys keys and purges private values, and the proof that they existed stays on the ledger.
- The officer's screens and legal flows stay the same. Only the layer underneath changes.
- No outage of an outside system blocks a filing. Each government system is reached through an adapter that also has a simulator.
How it fits with existing government systems
DigiFIR sits beneath the systems states already run. In the pilot it is the signed-intake and integrity ledger:
- CCTNS stays the legal FIR register. Registration on DigiFIR records the CCTNS FIR number and the hash of the FIR document.
- e-Sakshya stays the evidence-capture system where state rules notify it. Evidence records on DigiFIR anchor the e-Sakshya identifiers and hashes.
- e-Forensics stays the laboratory system.
- When a magistrate takes cognizance, the court app opens the case in eCourts through an adapter and records the CNR number it gets back.
Becoming the system of record itself would need a State Government Order and a CCTNS integration.
Scope of the MVP
The MVP is a working end-to-end system on a development Fabric network:
- Four member institutions: the police of two states (State A and State B), the judiciary and the forensic laboratories. A national ordering service with three Raft orderers is run for the network by NBF/NIC in the target design.
- Four chaincodes:
identity-registry,fir-registry,evidence-custodyandjudicial-actions. - One common backend with an OpenAPI contract of 230 operations, plus Dart and TypeScript SDKs.
- Four Flutter apps (citizen, police, court, lab), the citizen web portal and the officials' desktop console, all moved from their earlier Firebase backends onto the common backend.
- Kubernetes manifests, HSM signing, monitoring and runbooks for the pilot.
The planned pilot covers two or three districts in two states. Nationwide rollout, prosecution and prisons as ledger members, cross-state text-similarity hints and live write-back to CCTNS are outside the pilot. The development reference data uses stations in Jaipur (Rajasthan) and New Delhi.
NOTE
The build status is current to 4 November 2026. From MVP to pilot lists the items still in progress and the open decisions.
Where to go next
- Reviewers of the MVP report: start with MVP coverage, then System architecture.
- Citizens, officers, laboratory staff and magistrates: open the user manuals.
- Operators: read Deployment architecture and Operations runbooks.
- Developers: read Repositories and Run it locally.
Sources: digifir-backend docs/architecture/ARCHITECTURE.md, docs/PLAN.md section 1, docs/PROJECT-STATUS.md; digifir-magistrate-app README.md.