From MVP to pilot

This page records where the build stands, what has to happen before a pilot, and how the pilot is planned. The status is current to 4 November 2026.

Built and tested

Part	State
Smart contracts	Four Go chaincodes to the specification, released after four audit passes; batch 3 in final review
Network	Fabric 2.5.16 development network; Kubernetes pilot manifests; HSM signing through PKCS#11 tested with SoftHSM; monitoring; runbooks drilled, including onboarding a third state; the administrators' offline signing tool
Backend	api, projector and worker; OpenAPI contract of 230 operations; Dart and TypeScript SDKs; 2,280 tests passing; end-to-end and load tests on the real network
Officials' console	Ledger explorer, admin desk and sign-in by linking the phone; container image and Helm chart
Police app	Moved from Firebase to the backend (Firebase kept only for push delivery); registrar section; security review fixed
Court app	Moved; registrar section; security review fixed; 977 tests passing
Lab app	Moved; registrar section; security review fixed; final update pass in progress
Citizen app and portal	Moved; security review fixed; final update pass in progress

In progress

1. Chaincode batch 3, in final review: session-only keys, private reads whose answers the phone can check, stricter canonical text, per-institution SIM-check numbers, witness and accused numbers, the laboratory's label check and supplementary reports, court orders that must name a registered document.
2. Backend and SDK support for batch 3, the remaining network items (pilot guards, chart values, readiness checks), the console's last admin pages, and a security review of these changes.
3. Replacing the retired ingress-nginx with a maintained Gateway API controller for the public and internal entry points. This blocks go-live until it is done.
4. A full network run from nothing, channel updates signed with a smart card, and a rehearsal of the batch 3 chaincode upgrade.
5. The apps adopting batch 3, CI workflows for the app repositories, and audio and video statement capture in the police app.

Before go-live

Technical

• Fabric CA keys in each institution's HSM, outside the Kubernetes operator.
• Mutual TLS at peers and orderers, and TLS with client authentication on operations endpoints.
• HSM-backed keys for the operations-window administrator, and a hardware HSM in place of SoftHSM.
• Pod traffic encryption in every cluster.
• The backend's secrets out of the ingress controllers' reach.
• A staging rehearsal of deployment phases 0 to 3 on clusters that enforce network policies.
• Android and iOS release builds, which have not yet been compiled in the build environment.
• A point-in-time-recovery runbook for the backend's database, and a disaster-recovery drill.
• A load test on production-like hardware, to measure the expected throughput.
• A security audit (VAPT) by a CERT-In-empanelled auditor, and GIGW 3.0 and accessibility clearance.
• Decisions on retention periods for some operational tables, and on whether institution-scoped service keys move to each institution's HSM token.

Government

The pilot needs a State Government Order or MoU recognising DigiFIR as an electronic channel under BNSS s.173(1)(ii), India hosting, eSign onboarding, a TRAI DLT sender and the NIC SMS gateway, DigiLocker requester registration, and CCTNS FIR number references. External systems lists each approval with its approver, lead time and the fallback while it is pending. With the decisions taken with the pilot states: which districts, which state rules are notified there (e-Sakshya, BNSS FIR rules, electronic process), which CCTNS stack runs, the sponsoring officer, and retention schedules for complaints and FIRs in each state's police manual.

The pilot

Phase	Duration in the plan	Content
Integrations and approvals	Runs throughout	Each adapter ships against its simulator; switching to live is a configuration change once its approval lands
Pilot infrastructure	About 10 weeks	Kubernetes with the hlf-operator and Helm; HSM-backed organisation keys; ordering across sites; backups and a disaster-recovery drill; load tests; VAPT; CERT-In logging and NTP; GIGW and accessibility review; the decision to onboard to NBF or self-host
Pilot	About 4 months	Two or three districts across two states; trainer-of-trainers training; a help desk

The pilot measures: FIRs on the ledger, duplicate hints raised and decided, time from filing to IO assignment, verification queries, uptime and latency.

The plan's calendar dates were set before the build reached its current state and are to be confirmed with the pilot states.

Risks

Risk	Likelihood	Impact	Mitigation
Aadhaar approval is slow or refused	High	Citizens cannot use Aadhaar e-KYC in the pilot	DigiLocker and station verification exist from day one; Aadhaar is never mandatory
NBF cannot host the network or runs another Fabric version	Medium	The hosting plan changes	Configuration prepared for SmartBFT; the Kubernetes manifests run on any India-region cloud
Police workload at the counter rises	Medium	Adoption	One added element at the counter (the duplicate check); the same app screens; training
A device key is lost or stolen	Medium	An officer cannot act, or someone impersonates them	The registrar revokes at once, effective next block; app PIN; hardware-backed keys
A small team for a large scope	High	Dates slip	Phase gates, and reuse of the existing apps' code
Legal admissibility of device signatures	Medium	A court challenge	BSA s.63 certificates generated from the ledger; eSign for documents that need a legal signature
Cross-state privacy of text similarity	Medium	Objections under the DPDP Act or between states	Only file-hash hints cross state lines in the pilot
A chaincode defect after deployment	Medium	Wrong records are permanent	Specification, reviews and tests; upgrades by sequence; corrections are new versions

Sources: digifir-backend docs/PROJECT-STATUS.md, docs/PLAN.md sections 4, 6 and 8; digifir-network docs/KUBERNETES.md ("Open items before go-live"), docs/SECURITY_REVIEW.md ("Open before go-live").