Research project developed with IIT Patna to make agricultural movement transparent from field to payment. The system combines permissioned blockchain workflows with verifiable records and practical interfaces for every participant.
The Sugarcane Supply Chain Management System (SSCMS) is a proposed blockchain-enabled digital platform designed to improve transparency, traceability, accountability, and operational efficiency across the sugarcane supply chain. The platform connects farmers, Kisan Suvidha Kendras (KSKs), block-level officers, nurseries, seed verifiers, sugar mills, transporters, government authorities, financial stakeholders, distributors, retailers, and consumers through a unified digital ecosystem. Using Hyperledger Fabric, domain-driven microservices, event-driven communication, secure APIs, and role-based access control, the system aims to maintain trustworthy records of farmer registration, seed distribution, cultivation, procurement, transportation, weighment, quality assessment, pricing, payment status, processing, and product traceability.
Research project developed with IIT Patna to make agricultural movement transparent from field to payment. The system combines permissioned blockchain workflows with verifiable records and practical interfaces for every participant.
Sugarcane supply chains involve many independent participants, each responsible for different records and operations. Farmer registrations, land details, seed-lot information, delivery receipts, weighment readings, quality results, pricing calculations, payment instructions, and processing records may be maintained in disconnected applications or manual registers.
When information is fragmented, organizations may struggle to reconcile conflicting records, investigate disputes, track the origin of agricultural inputs, detect unauthorized changes, or provide farmers with a clear view of procurement and payment progress.
The problem is not simply the absence of software. It is the absence of a consistent, accountable way to share and verify information across organizational boundaries.
The proposed solution:
SSCMS introduces a unified application platform with 18 domain-oriented backend services and a permissioned Hyperledger Fabric network for selected shared-trust records.
Each service remains responsible for its own business domain, while APIs and events coordinate activities across the platform. The blockchain layer provides verifiable transaction history for approved records; conventional databases remain responsible for detailed operational data.
The system also incorporates governed organization onboarding, role and jurisdiction-based authorization, evidence management, payment reconciliation, operational monitoring, and QR-based product traceability.
Intended stakeholders:
Farmers: registration, cultivation information, procurement progress, weighment and quality visibility, payment status and grievance submission.
KSK and block personnel: farmer assistance, field verification, cultivation support and authorized local operations.
Nurseries and seed verifiers: nursery records, SeedLot creation, verification, distribution and traceability.
Distributed systems / Research · 2025
Sugar mills: procurement, gate intake, weighment, quality assessment, pricing, settlement workflows and processing.
Government authorities: organization governance, authorized approvals, master data, rules, oversight and compliance.
Transporters and logistics operators: dispatch, transport and delivery records.
Auditors: controlled access to evidence, audit trails, compliance cases and verification records.
Distributors, retailers and consumers: downstream custody and product-provenance information, with public access limited to approved data.
The Sugarcane Supply Chain Management System (SSCMS) is a proposed digital platform designed to improve transparency, traceability, accountability, and operational coordination across the sugarcane supply chain.
The platform connects agricultural operations with procurement, transportation, weighment, quality assessment, payment reconciliation, sugar processing, and finished-product traceability through a unified backend architecture.
What makes the project different?
SSCMS combines a permissioned blockchain with conventional databases and independently managed backend services. Hyperledger Fabric supports verifiable records shared between authorized organizations, while operational databases handle detailed business data and application workflows.
The system is designed to help stakeholders make informed decisions, improve record reconciliation, simplify audits, and provide farmers with better visibility into the journey from cultivation to procurement and payment.
The architecture is intended to support phased implementation, controlled access, integration with external systems, and future expansion across participating sugarcane-producing regions.
Project status: Proposed system design. Production deployment, integrations, and measurable operational outcomes should only be claimed after they have been implemented and verified.
SSCMS uses a modular technology architecture in which each technology has a defined responsibility. The objective is to select tools that support security, maintainability, interoperability, traceability, and long-term scalability.
Blockchain — Hyperledger Fabric
Hyperledger Fabric is the proposed permissioned blockchain platform. Unlike a public blockchain, it allows participating organizations to operate within a governed network with controlled identities and permissions.
It is intended to maintain verifiable transaction histories for selected records, including approved governance actions, procurement events, settlement-related records, and product-traceability events.
The proposed network uses four logical channels: Governance Registry, Cane Procurement, Settlement Audit, and Processing Traceability. Four chaincode domains separate registry, procurement, settlement, and traceability logic. The final network configuration must be validated against organizational privacy, endorsement, performance, and operational requirements.
Backend — Domain-Oriented Microservices
The backend is designed around 18 domain services rather than one large application or multiple disconnected systems. Each service owns a specific business responsibility, such as farmer management, seed verification, procurement, payments, or traceability.
This approach supports independent development, clearer service ownership, and controlled integration. It also requires disciplined API contracts, monitoring, deployment management, and reliable communication between services.
Smart Contracts — Chaincode
Chaincode implements approved business rules and transaction logic on Hyperledger Fabric. It can validate whether a proposed transaction meets the network's defined requirements before the transaction is committed.
Chaincode does not independently establish that a physical event actually occurred. Reliable verification still depends on authorized participants, trusted evidence, inspections, and appropriate approval workflows.
Programming Language — Go
Go is a candidate for Fabric chaincode and selected backend components where it fits the implementation requirements. The final programming language for each service should be recorded in the implementation specification rather than assumed to be identical across all services.
Data Storage — Relational Databases and Object Storage
Conventional databases store detailed operational records, user-facing application data, workflow states, and query-oriented information. Object storage holds documents, photographs, reports, and supporting evidence.
Only suitable, approved records or transaction proofs should be written to the blockchain. Sensitive identity information, bank details, and large documents should not be placed directly on the ordinary ledger.
Frontend — Web Applications and Progressive Web Apps
The platform is designed to provide role-specific interfaces for farmers, field personnel, nurseries, sugar mills, government administrators, auditors, logistics operators, and downstream supply-chain participants.
A Progressive Web App approach may support mobile access and selected offline workflows. The final frontend framework and offline synchronization design should be confirmed during implementation.
APIs and Event-Driven Integration
Secure APIs connect frontend applications with backend services. Events communicate business changes between services without requiring every operation to run as one synchronous request.
API specifications, event schemas, authentication, authorization, versioning, idempotency, and error handling are essential to reliable integration.
Infrastructure and DevSecOps
Containerization, automated testing, CI/CD pipelines, infrastructure as code, centralized monitoring, and controlled deployment processes are proposed to support repeatable releases and operational reliability.
Kubernetes, Helm, and Terraform or compatible alternatives may be selected according to deployment requirements, available infrastructure, and team expertise.
Interoperability and Traceability Standards
GS1 EPCIS may be adopted where appropriate to represent supply-chain visibility events, including the what, when, where, why, and how of product movement and custody.
The use of standards should be determined by the participating organizations' integration requirements.
Important implementation note:
Exact framework versions, cloud or on-premises hosting, database products, message brokers, and production infrastructure are implementation decisions and should not be represented as finalized until formally selected.
SSCMS is designed for the sugarcane agricultural and sugar-manufacturing ecosystem, with an initial deployment concept that may be evaluated in Bihar, India, subject to participating organizations, operational requirements, and applicable policies.
Primary objectives:
Establish a consistent digital workflow from farmer registration to procurement and payment reconciliation.
Improve the verification and traceability of nurseries, seed lots, cultivation records, and supply-chain events.
Provide authorized stakeholders with reliable access to relevant operational information.
Improve the investigation of discrepancies through evidence-linked records and audit trails.
Support transparent procurement, weighment, quality assessment, pricing, and settlement workflows.
Enable downstream product-provenance checks through QR-based access to approved information.
Provide a modular foundation for future integrations, reporting, and agricultural decision support.
Expected beneficiaries:
Farmers may benefit from improved visibility into their records and payment progress. Sugar mills may benefit from more consistent procurement and reconciliation workflows. Government authorities and auditors may benefit from controlled access to evidence and oversight information.
These are intended benefits, not measured results. Actual impact will depend on implementation quality, data accuracy, stakeholder adoption, connectivity, governance, and integration with participating organizations.
Farmer Registration and Verification
The farmer module is designed to maintain structured farmer profiles, associated land and cultivation records, verification status, and relevant organizational relationships. Authorized personnel can review submitted information, request corrections, and record verification decisions.
The objective is to reduce duplicate records, improve data consistency, and give farmers better visibility into their participation in the supply chain. Access to personal information must be restricted according to role, purpose, and applicable privacy requirements.
Nursery and SeedLot Traceability:
The nursery and seed management module is designed to record nursery information, SeedLot creation, verification, distribution, and links to authorized recipients. Each SeedLot can have a traceable history of relevant creation, inspection, approval, and distribution events.
This supports investigation of seed-origin discrepancies and improves accountability across agricultural input distribution. The reliability of these records depends on proper verification and trustworthy supporting evidence.
Cultivation and Field Operations:
Field personnel and authorized agricultural officers can record cultivation-related observations, field visits, verification results, and approved agricultural support activities.
Structured field records can improve coordination between farmers, local support centers, and higher-level administrators. Future versions may integrate GIS or satellite-derived information where legally and operationally appropriate.
Harvest, Transport and Delivery:
The logistics workflow is designed to connect authorized harvest or dispatch records with transportation, delivery, and custody events. Relevant participants can record the movement of sugarcane from its point of origin to the receiving facility.
Time-stamped events and supporting evidence can help authorized stakeholders investigate delays, missing records, and delivery discrepancies. Digital records supplement, rather than replace, physical inspection and operational controls.
Weighment and Quality Assessment:
The system is designed to capture weighment records, quality-assessment results, relevant reference identifiers, and authorized corrections. Where integrations are available, weighbridge systems may submit readings through controlled interfaces.
Consistent records help support procurement calculations, discrepancy investigation, and auditability. Equipment calibration, operator accountability, and the authenticity of source readings remain essential.
Procurement, Pricing and Payment Reconciliation:
The procurement module connects eligible farmer or supply records with delivery, weighment, applicable pricing rules, and settlement workflows. It is designed to track payment instructions, processing status, reconciliation results, and exceptions.
The system can improve payment visibility and reduce manual reconciliation work. Actual transfer of funds must be performed and confirmed through authorized banking or payment systems; a blockchain transaction alone does not prove that money has reached a recipient.
Sugar Processing and Product Lineage:
The processing module is designed to associate eligible incoming cane records with mill-processing batches and subsequent product-lot records, subject to the mill's operational data and traceability model.
This creates a structured digital relationship between selected incoming supply records and downstream product records. The accuracy of product lineage depends on reliable production data, correct batch relationships, and appropriate operational verification.
QR-Based Product Traceability:
A QR code can provide access to a public or authorized view of selected product-provenance information, such as approved batch references and relevant supply-chain events.
Public pages should display only information approved for disclosure. Private farmer details, personal identifiers, bank information, internal documents, and restricted business data must remain protected.
Grievance, Audit and Compliance:
The platform is designed to support grievance submission, case assignment, evidence collection, review, resolution, appeals, and audit trails. Access and actions are controlled according to the user's responsibilities and jurisdiction.
This can improve case visibility and accountability while helping authorized personnel investigate discrepancies. Final decisions must still be made by the legally or organizationally authorized authority.
Reporting and Operational Monitoring:
Authorized users can access role-appropriate reports on registration, verification, procurement, delivery, quality, settlement, grievances, and traceability.
Centralized monitoring and reporting can help organizations identify incomplete workflows, reconciliation exceptions, and operational bottlenecks. Reports must clearly distinguish verified facts, pending records, estimates, and derived analytics.
Sugarcane Supply Chain Management System follows a unified platform architecture with multiple role-specific frontend experiences, a shared API entry point, 18 domain-oriented backend services, operational data stores, and a permissioned blockchain trust layer.
Frontend applications:
Different stakeholders access the functions relevant to their responsibilities through dedicated interfaces. These experiences may include a Farmer PWA, KSK and Field App, Nursery and Seed App, Sugar Mill App, Government Administration Portal, Auditor Interface, Logistics Interface, Distribution and Retail Interface, and Consumer QR Experience.
API Gateway and security layer:
Frontend requests pass through a controlled API entry point responsible for routing and integration with authentication, authorization, request validation, rate limiting, and other applicable security controls.
Domain service layer:
The backend contains 18 services, each responsible for a defined business domain. Services communicate through documented APIs and asynchronous events where appropriate. Each service owns its operational data and business rules.
Operational data and evidence layer:
Conventional databases store detailed operational information, while object storage holds supporting documents and evidence. This separation supports efficient application queries and avoids placing unnecessary sensitive information on the blockchain.
Blockchain trust layer:
Hyperledger Fabric provides a shared, permissioned record of selected transactions that participating organizations need to verify. Access, endorsement policies, channel membership, and private-data mechanisms must be configured according to governance and confidentiality requirements.
Integration layer:
The Integration and Trust Gateway is designed to coordinate approved interactions with external systems and the Fabric network. External integrations may include banking or payment systems, weighbridges, government systems, or supply-chain standards where the relevant organizations provide access and authorization.
Reliability and operational controls:
The architecture requires monitoring, audit logging, backups, disaster recovery, secure secrets management, automated testing, idempotent event processing, and controlled deployment procedures.
The intended result is one coherent platform rather than nine independent backends. The final deployment topology, service boundaries, and infrastructure sizing must be validated during implementation.