Open Grant Proposal: Filecoin-Backed Persistent Storage for BhuChain's Legacy Land-Record Pipeline

# Open Grant Proposal: `Filecoin-Backed Persistent Storage for BhuChain's Legacy Land-Record Pipeline`

**Project Name: BhuChain — Legacy Land-Record Storage Layer**

**Proposal Category: Storage** Choose one of `Developer and data tooling`, `Integrations`, `Research & protocols`, `Storage`, `Retrieval`, `FVM`, or `Other`. Learn what these categories are [here](https://github.com/filecoin-project/devgrants/blob/master/Program%20Resources/Open%20Grants%20README.md).

**Individual or Entity Name: Individual on behalf of Opscorelabs Pvt. Ltd. (Organization)** Is the proposal on behalf of an individual, or an entity/organization? Please note that the agreement and any payments must be completed by the same entity, either individual or organization.

**Proposer:** `0xVISHWAJEET`

**Project Repo(s)** Please list Github repos used for this project work.
https://github.com/0xVISHWAJEET/bhuchain

**(Optional) Filecoin ecosystem affiliations:** `Please disclose any existing work relationships with organizations in the Protocol Labs Network, including Protocol Labs, Filecoin Foundation, Filecoin Foundation for the Decentralized Web, and any others.`

**(Optional) Technical Sponsor:** `If you have previously discussed this project with a member of the IPFS or Filecoin project teams and they have agreed to be a technical sponsor, include their name and/or github handle here`

**Do you agree to open source all work you do on behalf of this RFP under the MIT/Apache-2 dual-license?: YES** Please respond with "Yes" or "No".

# Project Summary
BhuChain is an open-source, role-gated multi-signature land-governance layer for Indian land records: land parcels are ERC-721 tokens gated by an on-chain approval registry that mirrors the real institutional hierarchy of Indian revenue administration (Registrar, Circle Officer, Revenue Inspector, Judiciary, Bank). Alongside the governance layer, BhuChain runs an OCR/NER pipeline that reads scanned legacy Hindi/Urdu land records (khasra entries, mauja records) and fuzzy-matches them to digitized parcels. Beyond governance, the same platform also extends into property transactions, rental, and investment — out of scope for this specific proposal, noted here only for context.

Today, those scanned source documents and their OCR/NER extraction output are referenced only by a sha256 hash — there is no live decentralized storage layer pinning the actual files.

## Impact

Indian land administration has a well-documented digitization gap that isn't about scanning — DILRMP has already driven Records-of-Rights computerization to 99.9% national saturation — it's about what happens to the legacy paper *before* it enters that digitized system, and whether the scanned intermediate artifact itself is durable. A sha256 hash proves a document hasn't been tampered with *if you still have a copy of it*; it does nothing to guarantee the document remains retrievable in five or ten years, especially for records held by small district offices without robust IT infrastructure or backup discipline.

The risk of not solving this is concrete: a scanned legacy khasra record used as evidence in a mutation or dispute proceeding is only as good as whoever's local disk it happens to still be sitting on. Filecoin's storage-deal model — verifiable, durable, not dependent on a single centralized host staying online — solves exactly the retrievability half of a problem BhuChain's own architecture only currently solves the integrity half of.

Success looks like: every legacy document BhuChain's OCR pipeline processes has a real, verifiable Filecoin storage deal backing it, retrievable by CID independent of BhuChain's own infrastructure, with the CID recorded alongside the existing on-chain/database hash reference.

## Outcomes

1. A storage-deal-making integration in the `ml-engine/` document-ingestion pipeline: every scanned legacy document, once OCR/NER-processed, gets a real Filecoin storage deal made for it (not merely pinned to a gateway), and the resulting CID is captured.
2. The CID stored alongside the existing sha256 hash in BhuChain's Postgres schema, and surfaced in the parcel detail view so a user can verify/retrieve the original scanned document independent of BhuChain's own servers.
3. A small open-source library/module (dual MIT + Apache-2.0 licensed, per the agreement above) documenting this pattern — "durable content-addressed storage for OCR'd legacy government records" — reusable by any similar civic-records digitization project, not just BhuChain.
4. Success metric: 100% of newly-ingested legacy documents in the demo pipeline have a live, independently-retrievable Filecoin CID by the end of the final milestone (see Development Roadmap), verified by fetching the CID from a third-party gateway with BhuChain's own infrastructure offline.

## Data Onboarding

The direct audience is any Indian state/district revenue department with a legacy-document digitization backlog — the same audience BhuChain's broader project targets. This specific storage component's audience is narrower and more immediate: developers building similar civic-document-integrity tooling who can reuse the open-sourced module directly, independent of whether BhuChain itself ever reaches a government pilot. Onboarding the first users is realistic and low-friction: publish the module with clear documentation and a working example against BhuChain's own public demo dataset; the "first 10 users" are other open-source civic-tech / GovTech developers who could adopt the pattern for document types entirely unrelated to land records (any government archive with a similar integrity-without-retrievability gap).

## Development Roadmap

**Milestone 1 — Integration (3-4 weeks)**
- Functionality: Filecoin storage-deal client integrated into `ml-engine/`'s ingestion pipeline; every newly-processed document triggers a real storage deal (not gateway-only pinning).
- Deliverables: Architecture specification, storage adapter, initial ingestion integration, CID/hash schema changes, automated tests, deployment configuration, and an end-to-end test demonstration.
Team: 1 person — proposer, responsible for architecture, backend/storage integration, DevOps, testing, and documentation.
Funding: $10,000
Time: 1 month.

**Milestone 2 — CID persistence and retrieval surface (3-4 weeks)**
- Functionality: CID stored in Postgres alongside the existing sha256 hash; parcel detail view surfaces a retrieval link; a documented fallback path if a deal's storage provider becomes unavailable (retrieval via any provider holding a copy of the deal, not a single provider dependency).
- Deliverables: Reliable storage workflow, deal-status service, retry/reconciliation mechanism, retrieval service, hash-verification pipeline, monitoring/operational dashboards, and documented failure/recovery procedures.
Team: depends on requirements.
Funding: $20,000
Time: 2 months.

**Milestone 3 — Backfill, open-source module extraction, and documentation (2-3 weeks)**
- Functionality: existing demo-dataset documents backfilled with real deals; the storage-deal-making logic extracted into a standalone, documented, dual-licensed module usable outside BhuChain; a short write-up of the pattern for other civic-tech projects.
- Deliverables: Large-scale backfill, performance benchmarks, reliability test suite, failure-injection tests, storage/retrieval metrics, operational runbooks, and optimized ingestion workflows.
Team: 1 person — proposer, full-time.
Funding: $30,000
Time: 3 months.

## Total Budget Requested

| Milestone # | Description | Deliverables | Completion Date | Funding |
|===|===|===|===|===|
The requested $50,000 covers six months of dedicated engineering and delivery work by the proposer, including architecture and implementation, Filecoin/storage integration, backend and database development, DevOps and infrastructure work, automated testing, reliability engineering, historical data onboarding, performance validation, open-source extraction, documentation, and final ecosystem demonstration. Filecoin/network/storage-related operational costs will be tracked separately within the project's implementation and documented as part of the final technical report.
## Maintenance and Upgrade Plans

The storage integration becomes a standing part of `ml-engine/`'s ingestion pipeline — every document processed going forward uses it by default, so maintenance is folded into BhuChain's own ongoing development rather than being a separate commitment. The extracted open-source module will be maintained on a best-effort basis with the same repo/issue-tracker workflow as the rest of BhuChain; if it sees adoption outside BhuChain, a versioned release process will be added at that point rather than pre-built speculatively.

# Team

## Team Members

https://opscorelabs.com

## Relevant Experience

5+ years leading blockchain protocol and infrastructure engineering, including building and scaling an EVM-compatible L2 (Shibarium) from genesis through mainnet — custom node software (Bor/Heimdall) and bridge contracts in Go and Solidity, multi-region validator/RPC infrastructure, and CI/CD automation. Prior applied-cryptography work designing and compiling zk-SNARK circuits (Circom) for privacy-preserving credential validation and cross-chain bridge state proofs, plus earlier blockchain/smart-contract delivery on a government document-verification system and IBM Hyperledger Fabric deployments. This background — EVM/Solidity fluency, hands-on Go tooling, and applied ZK/cryptography — maps directly onto the storage-deal integration and CID-persistence work scoped in this proposal.

## Team code repositories

https://github.com/shibaone

# Additional Information

Start by inspecting the `ml-engine/` document-ingestion pipeline and the existing Postgres schema and parcel detail view. Review how scanned documents and sha256 hashes are currently handled, then use the milestone deliverables as the completion checklist: persistent CIDs, retrieval and verification behavior, automated tests, and documented integration outcomes.

Written by the indexing model from the issue text.