Student Innovation-Provide ideas in a decentralized and distributed ledger technology used to store digital information that powers cryptocurrencies and NFTs and can radically change multiple sectors.

1. Executive Snapshot

This dossier presents a comprehensive technical blueprint and implementation strategy for SIH26194, a high-impact student innovation problem statement sponsored by AICTE and the Ministry of Education's Innovation Cell (MIC) [PS]. The project addresses the systemic vulnerability of centralized databases to document forgery, data corruption, and unauthorized alteration across critical public sectors in India [KNOWN]. To tackle these challenges, we propose VeriTrust DLT: an enterprise-grade, multi-sector Distributed Ledger Technology (DLT) platform that leverages smart contracts, Soulbound Tokens (EIP-5192) [RESEARCHED], W3C Verifiable Credentials [RESEARCHED], Zero-Knowledge Proofs (ZK-SNARKs) [RESEARCHED], and InterPlanetary File System (IPFS) [KNOWN] decentralized storage.

VeriTrust DLT establishes an immutable, publicly verifiable, privacy-preserving trust layer across three national domains: Academic Credential Badging (Education), Public Procurement Escrows (Governance), and Pharmaceutical/Agri-Supply Chain Provenance (Healthcare & Agriculture) [INFERENCE]. Designed for a 4–6 student team competing in Smart India Hackathon 2026, the architecture provides seamless interoperability with national initiatives such as DigiLocker [RESEARCHED], the National Blockchain Framework (NBF / Vishvasya) [RESEARCHED], and APAAR IDs [RESEARCHED].

Project Metadata

Fundamental System Objective: To architect and build a multi-sector, decentralized trust engine leveraging EVM-compatible smart contracts, non-transferable Soulbound NFTs (EIP-5192), and Zero-Knowledge proofs to store, verify, and enforce immutable digital information across education, public procurement, and supply chains without relying on single points of failure [INFERENCE].

2. Problem Deconstruction

The official problem statement reads:

"Student Innovation-Provide ideas in a decentralized and distributed ledger technology used to store digital information that powers cryptocurrencies and NFTs and can radically change multiple sectors." [PS]

To translate this high-level directive into an implementable software design, we extract the following atomic requirements:

• [Req-A] Core Technology Paradigm: The solution must be built on a decentralized and distributed ledger technology (DLT/Blockchain) framework [PS].
  • Interpretation: Systems built solely on centralized relational databases (e.g., PostgreSQL, MySQL) or conventional cloud storage are non-compliant [INFERENCE].
  • Implementation Implication: Deploy EVM-compatible smart contracts on a public-permissioned Layer-2 testnet (e.g., Polygon Amoy) or a local Hyperledger Besu consortium node [ASSUMPTION].
• [Req-B] Immutable Digital Information Storage: The ledger must securely store digital information in a tamper-resistant, audit-verifiable format [PS].
  • Interpretation: High-volume binary files (PDFs, images) should not be stored directly on-chain due to gas costs; instead, cryptographic content hashes (e.g., IPFS CIDs, SHA-256 state roots) must be anchored on-chain [INFERENCE].
  • Implementation Implication: Utilize IPFS / Pinata for off-chain payload storage and map IPFS Content Identifiers (CIDs) to smart contract state mapping tables [ASSUMPTION].
• [Req-C] Crypto & NFT Primitive Adaptation: The system must repurpose cryptographic primitives underlying cryptocurrencies (e.g., asymmetric cryptography, hashing, smart contract state execution) and Non-Fungible Tokens (NFTs) [PS].
  • Interpretation: Implement standard token interfaces (ERC-721 / ERC-1155) for supply chain assets and non-transferable Soulbound Tokens (EIP-5192) for academic credentials and identity records [INFERENCE].
  • Implementation Implication: Smart contracts must implement supportsInterface(0xb45a3c0e) for EIP-5192 compliance, ensuring credentials cannot be traded or transferred [RESEARCHED].
• [Req-D] Multi-Sector Application: The proposed idea must extend beyond pure speculative finance or cryptocurrencies to radically improve operations in multiple public or enterprise sectors [PS].
  • Interpretation: Demonstrating a single token or simple NFT marketplace is insufficient; the platform must showcase cross-sector application modules [INFERENCE].
  • Implementation Implication: Build three operational verticals within the unified web interface:
    1. Academic & Skill Credentialing (Education)
    2. Milestone-Based Public Procurement Escrow (Governance & Infrastructure)
    3. Pharmaceutical/Agri Track-and-Trace (Healthcare & Agriculture) [ASSUMPTION].
• [Req-E] Student Innovation Alignment: The architecture must be achievable within the constraints of an undergraduate team and aligned with AICTE / MIC evaluation criteria [PS].
  • Interpretation: The solution must be fully demonstratable, open-source compliant, scalable, and resilient under field testing conditions [INFERENCE].

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

Developing a decentralized public infrastructure platform for the Indian ecosystem presents real-world operational constraints:

1. Connectivity & Internet Variability:

   • Reality: Sub-urban and rural centers (Tier-2/3 institutions, rural pharmacies, field tender inspectors) experience high latency, intermittent 3G/4G, or temporary connectivity loss [KNOWN].
   • Design Impact: The client frontend must be built as a Progressive Web Application (PWA) with LocalStorage / IndexedDB transaction queueing. Verification of credentials must work offline using self-contained cryptographically signed payloads encoded in High-Density QR Codes [INFERENCE].

2. Blockchain Gas Volatility & Transaction Costs:

   • Reality: Public Ethereum L1 gas fees ($10–$50 per transaction) make real-world credential issuance economically non-viable for public institutions [KNOWN].
   • Design Impact: Deployed contracts must target L2 networks (Polygon Amoy Testnet, Arbitrum Sepolia) or private/consortium networks (Hyperledger Besu). Batch minting primitives (ERC-1155 or array-based batch minting smart contracts) must be implemented to minimize per-credential gas overhead [INFERENCE].

3. Digital Literacy & User Experience (UX):

   • Reality: Non-technical users (university clerks, drug retailers, procurement auditors) cannot manage raw 24-word seed phrases, browser extensions (MetaMask), or manual gas price configurations [KNOWN].
   • Design Impact: Implement Web3Auth / Account Abstraction (ERC-4337) with social login (Google/Email OAuth) and relayers (OpenZeppelin Defender / Biconomy) to enable gasless meta-transactions for end-users [RESEARCHED].

4. Legal & Regulatory Environment in India:

   • Regulatory Reality: The Reserve Bank of India (RBI) prohibits financial institutions from handling unbacked private cryptocurrencies [RESEARCHED]. However, MeitY actively supports non-speculative enterprise blockchain adoption via the National Blockchain Framework (NBF) and the Vishvasya Stack [RESEARCHED]. Furthermore, the Digital Personal Data Protection (DPDP) Act 2023 mandates the "Right to Erasure" [RESEARCHED].
   • Design Impact: The system must not utilize public speculative crypto tokens for payment or user settlement [INFERENCE]. All on-chain records must store only non-personal cryptographic hashes and CIDs to comply with DPDP Act data minimization requirements [INFERENCE].

6. Research Questions

To ensure technical validity, the student development team must address the following empirical questions during the build phase:

1. Gas Optimization: What is the per-credential gas consumption differential between individually minting ERC-721 Soulbound Tokens versus batch-minting Merkle Tree Roots with on-chain zero-knowledge verification?
   • Validation Method: Execute benchmark tests using Hardhat Gas Reporter across 1, 100, and 1,000 credential issuance batches [ASSUMPTION].
2. IPFS Persistence & Latency: What is the average retrieval time and pin retention reliability of IPFS metadata payloads when using public gateways versus dedicated pinning services (Pinata / Web3.Storage)?
   • Validation Method: Measure gateway response latency across 50 simulated requests under constrained 3G bandwidth conditions [ASSUMPTION].
3. ZK-SNARK Circuit Performance: Can a Groth16 ZK-SNARK proof generated in the browser using SnarkJS execute within $<3$ seconds on a mid-range mobile processor?
   • Validation Method: Benchmark proof generation times on Android mobile browsers across WebAssembly (WASM) runtimes [ASSUMPTION].
4. Offline QR Density Limits: What is the maximum size of a W3C Verifiable Credential payload that can be reliably scanned from a smartphone screen by a standard camera using Version 40 QR codes with Level L error correction?
   • Validation Method: Test payload compression (CBOR/gzip) to maintain raw string length under $2,000$ characters [ASSUMPTION].

7. Data Requirements & Sources

8. Existing Solutions & Gap Analysis

To justify the technical architecture of VeriTrust DLT, we analyze existing systems deployed in India and globally:

+-----------------------------------------------------------------------------------+
|                            EXISTING SOLUTIONS MATRIX                              |
+--------------------------+----------------------------+---------------------------+
|      System / Portal     |      Strengths             |      Weaknesses / Gaps    |
+--------------------------+----------------------------+---------------------------+
| DigiLocker (MeitY)       | - High national adoption   | - Centralized issuer model|
|                          | - Government backed        | - No ZK-privacy proofs    |
|                          |                            | - Single point of failure |
+--------------------------+----------------------------+---------------------------+
| Vishvasya / NBF (NIC)    | - Indigenous BaaS          | - Permissioned-only access|
|                          | - Multi-state deployment   | - Locked to govt nodes    |
|                          |                            | - No open Web3 wallet ecosystem|
+--------------------------+----------------------------+---------------------------+
| Blockcerts (MIT Media Lab)| - Open W3C standard       | - High Bitcoin gas costs  |
|                          | - Public verification      | - Lacks multi-sector UI   |
|                          |                            | - No native ZK support    |
+--------------------------+----------------------------+---------------------------+
| VeriTrust DLT (Proposed) | - Multi-sector architecture| - Requires L2 / RPC nodes |
|                          | - EIP-5192 + ZK-SNARKs     | - Student-level prototype |
|                          | - Gasless UX + DigiLocker  |   (Needs scale testing)   |
+--------------------------+----------------------------+---------------------------+

Detailed Systems Evaluation

1. DigiLocker (Government of India / MeitY)

   • Description: A federated digital document wallet enabling Indian citizens to access authentic digital documents directly from issuing authorities [RESEARCHED].
   • Strengths: Over 300 million registered users, integration with major educational boards (CBSE, AICTE), legally valid under IT Act 2000 [RESEARCHED].
   • Weaknesses: Relies on a centralized/federated server architecture. If an issuing institute's API server is offline or compromised, document issuance/verification fails. Does not support Zero-Knowledge verification (users must share their full unredacted document) [INFERENCE].
   • Gap Remaining: Lacks decentralized immutability and privacy-preserving mathematical proofs [INFERENCE].

2. National Blockchain Framework (NBF / Vishvasya Stack - MeitY / NIC)

   • Description: India's indigenous Blockchain-as-a-Service (BaaS) infrastructure hosted across NIC data centers in Bhubaneswar, Pune, and Hyderabad [RESEARCHED].
   • Strengths: Over 34 crore documents verified across state land records, judiciary, and CBSE chains [RESEARCHED]. High security and government compliance.
   • Weaknesses: Operates as a strictly permissioned consortium accessible primarily to government entities [RESEARCHED]. Independent third parties, global employers, and open-source developers cannot interact directly with smart contract state or deploy custom decentralized applications [INFERENCE].
   • Gap Remaining: Public verification across cross-border hiring and private multi-sector supply chains requires public permissioned EVM interoperability [INFERENCE].

3. Blockcerts (MIT Media Lab / Learning Machine)

   • Description: An open-source anchor protocol for issuing verifiable educational credentials on public blockchains (Bitcoin / Ethereum) [KNOWN].
   • Strengths: Highly resilient standard based on W3C Verifiable Credentials; public verifiability [KNOWN].
   • Weaknesses: Bitcoin/Ethereum mainnet gas fees are prohibitive. Lacks native multi-sector application capabilities (e.g., procurement escrows, track-and-trace) and zero-knowledge privacy circuits [INFERENCE].
   • Gap Remaining: High transaction cost and single-domain focus [INFERENCE].

9. Candidate Solution Approaches

We objectively evaluate three potential architecture designs for the SIH solution:

10. Recommended Approach & Why

Selection

Approach 3: Public-Permissioned Hybrid EVM (Polygon Amoy L2 / Hardhat EVM) with Soulbound Tokens (EIP-5192), W3C Verifiable Credentials, Groth16 ZK-SNARKs, and IPFS Decentralized Storage is selected as the optimal implementation strategy [INFERENCE].

Justification & Rejection of Alternatives

1. Why Approach 1 (Centralized DB) was rejected:

   • Centralized databases completely violate Requirement [Req-A] and [Req-B] of the official problem statement, which explicitly demands decentralized and distributed ledger technology [PS]. Centralized databases retain a single point of failure and administrator corruption risk [KNOWN].

2. Why Approach 2 (Hyperledger Fabric) was rejected:

   • While Hyperledger Fabric is robust for enterprise consortia, setting up orderers, certificate authorities (CAs), multi-channel gossip protocols, and chaincode deployment during a 36-hour live hackathon demo introduces high operational failure risk [INFERENCE]. Furthermore, public verification by external employers or citizens requires complex API middleware rather than native blockchain explorer verification [INFERENCE].

3. Why Approach 3 Wins:

   • Approach 3 balances full technical compliance with hackathon feasibility. Deploying EVM smart contracts (Solidity) provides instant compatibility with Web3 developer tools (Hardhat, Ethers.js, Wagmi).
   • Utilizing EIP-5192 Soulbound Tokens prevents credential trading [RESEARCHED].
   • IPFS ensures off-chain storage without incurring excessive gas [KNOWN].
   • ZK-SNARKs (Circom/SnarkJS) give the team a distinct technical edge by enabling privacy-preserving verification [RESEARCHED].

11. Technical Architecture

Layered System Architecture Diagram

+-----------------------------------------------------------------------------------+
|                               VERITRUST DLT ARCHITECTURE                          |
+-----------------------------------------------------------------------------------+

[ PRESENTATION LAYER / FRONTEND ]
  |-- Web Application (Next.js 14, Tailwind CSS, Shadcn UI)
  |-- Progressive Web App (PWA) Engine (Service Workers, IndexedDB Offline Cache)
  |-- Mobile Camera Module (ZXing / Html5-QRCode for scanning Credential QR Codes)
  +-- User Authentication: Web3Auth (Google/Email OAuth -> Embedded Wallet)

[ APPLICATION LOGIC & CRYPTO MIDDLEWARE ]
  |-- Ethers.js v6 / Viem (Smart Contract Communication Interface)
  |-- SnarkJS Engine (In-Browser Groth16 ZK-Proof Generation & Verification)
  |-- W3C Credential Manager (JSON-LD Canonicalization & Ed25519 Signature Verification)
  +-- Pinata SDK (Client-Side IPFS CID Upload & Gateway Resolution)

[ SMART CONTRACT LAYER (EVM / SOLIDITY) ]
  |-- CredentialRegistry.sol (EIP-5192 Soulbound Token Standard - Academic Sector)
  |-- ProcurementEscrow.sol (Multi-Sig Milestone Release Contract - Governance Sector)
  |-- SupplyChainTracker.sol (ERC-1155 Batch Provenance Contract - Pharma/Agri Sector)
  +-- ZKVerifier.sol (Auto-generated Solidity Groth16 Proof Verifier)

[ DECENTRALIZED DATA & LEDGER INFRASTRUCTURE ]
  |-- Primary Ledger: Polygon Amoy L2 Testnet / Hyperledger Besu EVM Node
  |-- Off-Chain Storage: IPFS (InterPlanetary File System via Pinata Cluster)
  +-- External Systems (Simulated): DigiLocker OAuth API & National Academic Depository

Detailed Data-Flow Narrative

1. Credential Issuance Workflow (Education Sector):

   • Step 1: The University Registrar authenticates onto the VeriTrust Admin Portal using multi-factor Web3Auth.
   • Step 2: The Registrar uploads student degree data via CSV/JSON or manual form submission.
   • Step 3: The frontend generates a standardized W3C Verifiable Credential JSON payload, signs it using the institution's private key, and uploads the file to IPFS via Pinata API, obtaining IPFS Content ID CID_Degree.
   • Step 4: The frontend executes a transaction against CredentialRegistry.sol on Polygon Amoy testnet, calling mintSoulbound(studentWalletAddress, CID_Degree, SHA256_Hash).
   • Step 5: The smart contract validates caller authorization, mints an EIP-5192 non-transferable NFT to the student's address, emits a Locked(tokenId) event, and stores the state mapping on-chain.

2. Verification & Zero-Knowledge Workflow (Employer / Citizen):

   • Step 1: A job applicant presents their degree QR code or wallet address to an employer.
   • Step 2: Option A (Public Audit): The employer scans the QR code; the verifier app fetches the token URI from CredentialRegistry.sol, resolves the IPFS CID, and verifies that the cryptographic hash matches the on-chain record.
   • Step 3: Option B (Zero-Knowledge Audit): The employer requests proof that the applicant's $CGPA \ge 7.5$. The applicant's browser executes SnarkJS, loading the compiled Circom circuit .wasm and zkey file locally.
   • Step 4: SnarkJS generates a Groth16 proof using the private CGPA value and public threshold ($7.5$).
   • Step 5: The applicant submits the generated proof parameters (pi_a, pi_b, pi_c) to ZKVerifier.sol or directly into the verifier frontend, returning an instant TRUE/FALSE output without exposing the raw CGPA value.

12. Technology Stack

13. AI/ML Justification

While the core value proposition of VeriTrust DLT is rooted in deterministic cryptography and smart contracts, targeted AI/ML components add substantial value in specific pipeline modules:

+-----------------------------------------------------------------------------------+
|                              AI / ML INTEGRATION SCOPE                            |
+-----------------------------------------------------------------------------------+
|  [ IN-SCOPE AI MODULES ]                                                         |
|  1. OCR Document Digitization (Tesseract.js / OpenCV)                             |
|     - Extracts text from legacy paper certificates into structured JSON format.  |
|  2. Anomaly & Fraud Pattern Detection (Scikit-Learn / Isolation Forest)            |
|     - Flags suspicious surge in credential issuance from unverified IP addresses. |
|                                                                                   |
|  [ EXCLUDED / NOT RECOMMENDED AI USAGE ]                                          |
|  - Cryptographic Signature Verification (MUST remain deterministic math)         |
|  - Smart Contract Execution Logic (MUST remain immutable Solidity code)           |
+-----------------------------------------------------------------------------------+

Detailed Evaluation of AI Components

1. AI Component 1: Legacy Certificate OCR & Schema Parser

   • Purpose: Convert scanned physical degree PDFs/images from legacy university archives into structured W3C Verifiable Credential JSON payloads prior to on-chain hashing.
   • Model Type: Tesseract.js / OpenCV image preprocessing pipeline.
   • Input: Scanned JPG/PNG certificate document.
   • Output: JSON object containing studentName, degreeName, rollNumber, graduationYear, cgpa.
   • Why AI is Preferable: University historical archives consist of thousands of non-standardized paper scans. Manual keying is error-prone and labor-intensive.
   • Evaluation Metric: Character Error Rate (CER) $< 1.5%$ on sample certificates.
   • Failure Mode & Oversight: If OCR confidence score $< 95%$, the UI highlights low-confidence fields in red and forces manual review by the Registrar before signing.

2. AI Component 2: Credential Issuance Anomaly Detector

   • Purpose: Detect compromised institutional keys or insider fraud (e.g., a rogue university clerk issuing 500 fake degrees at 2:00 AM).
   • Model Type: Lightweight Isolation Forest / Unsupervised Anomaly Detection model.
   • Input: Real-time transaction metadata (issuance rate, timestamp, batch size, target wallet distribution).
   • Output: Risk Score ($0.0$ to $1.0$).
   • Why AI is Preferable: Static rules fail to detect subtle, distributed fraudulent issuance patterns across multiple batches.
   • Failure Mode & Oversight: High risk scores trigger a multi-sig lock on the contract, requiring two department heads to approve the batch.

3. EXPLICIT NEGATIVE SPECIFICATION (Where AI MUST NOT be used):

   • AI must never be used to determine the validity of a cryptographic signature or smart contract state. Verification must remain 100% deterministic mathematical execution (Ecdsa signature recovery and ZK-SNARK proof verification) [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Data Schemas

W3C Verifiable Credential JSON Schema (Academic Degree)

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://schema.org"
  ],
  "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "type": ["VerifiableCredential", "AcademicDegreeCredential"],
  "issuer": "did:ethr:polygon:0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
  "issuanceDate": "2026-06-15T00:00:00Z",
  "credentialSubject": {
    "id": "did:ethr:polygon:0x3C44CdD459693451D7898732299d638e4a90f11C",
    "studentName": "Aarav Sharma",
    "rollNumber": "AICTE-2022-84920",
    "institution": "Delhi Technological University",
    "degree": "Bachelor of Technology in Computer Science",
    "graduationYear": 2026,
    "cgpaHash": "0x8f3c7b21a8d052e..."
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-06-15T08:30:00Z",
    "verificationMethod": "did:ethr:polygon:0x71C...#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3jG...x9Lq"
  }
}

Solidity Smart Contract Core Storage Layout (CredentialRegistry.sol)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

struct Credential {
    string ipfsCID;        // IPFS Content Identifier mapping to off-chain payload
    bytes32 payloadHash;   // SHA-256 hash of raw JSON payload for integrity check
    uint656 issuedAt;      // Unix timestamp of issuance
    address issuer;        // Institutional wallet address
    bool isRevoked;        // Revocation flag
}

mapping(uint256 => Credential) private _credentials; // Token ID -> Credential Struct
mapping(bytes32 => uint256) private _hashToTokenId;  // Duplicate prevention map

Offline & Low-Network Synchronization Flow

[ OFFLINE USER DEVICE ] 
  |-- User scans Credential QR code in remote area (no internet connection).
  |-- Service Worker intercepting request; loads cached W3C Public Key Schema.
  |-- Client performs local elliptic-curve signature validation (Ed25519) on raw QR payload.
  +-- Result displayed instantly: "OFFLINE VERIFIED (Signature Valid, Chain Check Pending)".

[ RE-ESTABLISHING CONNECTIVITY ]
  |-- Network Listener detects online event (`navigator.onLine == true`).
  |-- Dexie.js offline queue flushes pending verification logs to server.
  +-- Frontend queries Polygon RPC node to verify on-chain `isRevoked == false` status.

15. Security, Privacy & Governance

1. DPDP Act 2023 Compliance & Right to be Forgotten:

   • Challenge: Public blockchains are immutable; storing Personally Identifiable Information (PII) on-chain violates section 12 of India's DPDP Act 2023 [RESEARCHED].
   • Mitigation: Zero PII is stored on-chain [INFERENCE]. On-chain smart contracts store only salted SHA-256 cryptographic hashes and IPFS CIDs [INFERENCE]. Off-chain IPFS payloads can be encrypted using the student's public key (Lit Protocol / ECIES), ensuring that if revocation is needed, the decryption key is destroyed, rendering the off-chain payload unreadable (Cryptographic Erasure) [RESEARCHED].

2. Access Control & Institutional Key Governance:

   • Role-Based Access Control (RBAC): Smart contracts inherit OpenZeppelin AccessControl.sol.
   • Roles Defined:
     • DEFAULT_ADMIN_ROLE: Multi-sig contract owner (Governed by AICTE / University Board).
     • ISSUER_ROLE: Verified institutional wallets authorized to mint credentials.
     • REVOKER_ROLE: Administrative role authorized to flag credentials as revoked in compliance with disciplinary or legal orders.

3. Smart Contract Vulnerability Safeguards:

   • Contracts implement OpenZeppelin ReentrancyGuard on all state-changing functions.
   • Integer overflow/underflow protection enforced via native Solidity 0.8+ checks.
   • Contracts are statically analyzed using Slither and Mythril prior to testnet deployment.

16. MVP Scope (Hackathon Build)

To deliver a high-quality demonstration within the Smart India Hackathon timeframe, the team must aggressively prioritize core features:

+-----------------------------------------------------------------------------------+
|                                  MVP SCOPE BREAKDOWN                              |
+-----------------------------------------------------------------------------------+

  [ MUST BUILD (Core Hackathon MVP) ]
  [x] Interactive Web Portal (Next.js 14) with Web3Auth Social Login.
  [x] Education Module: Mint & View EIP-5192 Soulbound Degree NFTs on Polygon Amoy.
  [x] IPFS Pinata integration for uploading & resolving credential metadata JSON.
  [x] Zero-Knowledge Verification Module: Browser-based SnarkJS CGPA threshold proof.
  [x] Governance Module: Milestone Procurement Escrow contract with 2-of-3 multi-sig release.
  [x] Track & Trace Module: ERC-1155 Pharma Batch provenance tracking dashboard.
  [x] One-Click Public Verifier Page (Verify by QR code scan or Token ID).

  [ SHOULD BUILD (If Time Permits) ]
  [!] Service Worker PWA for offline QR signature verification.
  [!] Export credential directly into simulated DigiLocker JSON payload format.
  [!] Basic Tesseract.js OCR engine for legacy paper certificate upload.

  [ DO NOT BUILD / OUT OF SCOPE DURING HACKATHON ]
  [-] Production mainnet deployment with real cryptocurrency payments.
  [-] Custom hardware IoT sensor nodes for live temperature tracking in pharma transit.
  [-] Deep enterprise integration with full Samarth ERP or NIC infrastructure.

17. Live Demo Simulation Plan

In a hackathon setting, external live government APIs, physical satellite feeds, or production ERPs are either unavailable or restricted. The team must construct a robust, transparent simulation environment:

+-----------------------------------------------------------------------------------+
|                              LIVE DEMO SIMULATION ARCHITECTURE                    |
+-----------------------------------------------------------------------------------+

[ ACTOR 1: University Registrar ]
  |-- Action: Opens Admin Portal -> Selects "Issue Batch Degrees".
  |-- Input: Uploads pre-configured `sample_degrees.json` (5 Student Records).
  |-- Execution: Web3Auth signs tx -> Hardhat/Polygon Amoy mints EIP-5192 SBTs -> Pinata pins CIDs.
  +-- Output: Live Polygonscan transaction link generated in < 5 seconds.

[ ACTOR 2: Graduating Student ]
  |-- Action: Logins with Google (`[email protected]`) -> Views "My Digital Vault".
  |-- Action: Selects "Share with Employer via ZK-Proof".
  |-- Input: Sets constraint: "Prove CGPA >= 7.5 without showing raw marks".
  +-- Execution: SnarkJS runs Groth16 circuit in browser -> Generates ZK-Proof JSON in ~2s.

[ ACTOR 3: Employer / HR Auditor ]
  |-- Action: Opens Public Verifier Portal (no login required).
  |-- Action: Paste ZK-Proof JSON or Scan QR Code from mobile screen.
  +-- Execution: Smart contract `ZKVerifier.sol` calls `verifyProof()` -> Displays Green Checkmark:
      "VERIFIED: Student satisfies CGPA >= 7.5 constraint (Raw CGPA mathematically hidden)".

[ ACTOR 4: Public Tender Inspector (Governance Module Demo) ]
  |-- Action: Simulates road construction inspection -> Approves "Milestone 2: Sub-grade Paving".
  |-- Execution: Submits multi-sig approval -> Escrow smart contract auto-releases 25% funds.

18. Implementation Roadmap

The roadmap is strictly sized against the project submission deadline of 30 September 2026 [PS]:

+-----------------------------------------------------------------------------------+
|                              IMPLEMENTATION ROADMAP                               |
+-----------------------------------------------------------------------------------+

PHASE 1: ARCHITECTURE & SMART CONTRACT DEVELOPMENT (Weeks 1 - 3) [Sep 5 - Sep 25, 2026]
  |-- W1: Setup Hardhat environment; write `CredentialRegistry.sol` (EIP-5192).
  |-- W2: Write `ProcurementEscrow.sol` and `SupplyChainTracker.sol`.
  |-- W3: Compile Circom ZK circuits for CGPA threshold proofs; generate verifier.sol.
  +-- Milestone 1: 100% smart contract unit test coverage on local Hardhat network.

PHASE 2: FRONTEND & MIDDLEWARE INTEGRATION (Weeks 4 - 6) [Sep 26 - Oct 16, 2026]
  |-- W4: Build Next.js 14 Web Portal, UI design, Web3Auth login integration.
  |-- W5: Integrate Pinata IPFS SDK, Ethers.js v6 contract bindings, SnarkJS.
  |-- W6: Implement QR code generator and reader components.
  +-- Milestone 2: Fully working end-to-end issuance and verification flow on local node.

PHASE 3: MULTI-SECTOR MODULES & TESTNET DEPLOYMENT (Weeks 7 - 9) [Oct 17 - Nov 7, 2026]
  |-- W7: Deploy smart contracts to Polygon Amoy L2 Testnet; verify on Polygonscan.
  |-- W8: Build Multi-Sector dashboards (Education, Procurement, Pharma).
  |-- W9: Implement PWA Service Worker for offline credential validation.
  +-- Milestone 3: Live deployed testnet prototype accessible via public URL.

PHASE 4: TESTING, OPTIMIZATION & DEMO PREPARATION (Weeks 10 - 12) [Nov 8 - Nov 30, 2026]
  |-- W10: Execute security analysis using Slither; gas optimization audits.
  |-- W11: Field testing on low-bandwidth mobile devices; load testing RPC nodes.
  |-- W12: Finalize SIH pitch deck, video walkthrough, and live demo script.
  +-- Final Milestone: Production-ready SIH submission dossier and repo by Deadline.

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon Prototype Layer Cost

• Polygon Amoy L2 Testnet Gas: ₹0 (Free testnet faucet tokens).
• IPFS Pinata Storage: ₹0 (Free tier provides up to 1GB storage / 500 pinned files).
• Hosting & Web Deployment: ₹0 (Vercel / Netlify free developer tier).
• Domain & RPC Infrastructure: ₹0 (Public RPC endpoints and free Alchemy developer account).
• Total Hackathon Cost: ₹0 (100% Free Tier Compliant) [INFERENCE].

Production System Layer Cost (Scale: 1 Million Credentials / Year)

• L2 Gas Costs (Polygon Mainnet / Arbitrum Nova): ~0.001 MATIC per issuance $\rightarrow \approx$ ₹150,000 / year for 1M credentials [INFERENCE].
• Dedicated IPFS Cluster Pinning (Pinata Enterprise / Filecoin): $\approx$ ₹25,000 / month $\rightarrow$ ₹300,000 / year [INFERENCE].
• Managed RPC Nodes (Alchemy / QuickNode Enterprise): $\approx$ ₹40,000 / month $\rightarrow$ ₹480,000 / year [INFERENCE].
• Total Production Operating Cost: $\approx$ ₹9.3 Lakhs per year (Cost per credential $\approx$ ₹0.93, representing a $95%$ cost reduction compared to physical certificate security paper printing) [INFERENCE].

22. Differentiation

To stand out among 500+ competing student teams, VeriTrust DLT incorporates specific differentiators mapped directly to problem requirements:

+-----------------------------------------------------------------------------------+
|                               KEY DIFFERENTIATORS                                 |
+-----------------------------------------------------------------------------------+

1. TRUE MULTI-SECTOR DEMONSTRATION (Not just a generic EdTech app)
   - Demonstrates working smart contracts across THREE distinct domains:
     Academic Credentials (EIP-5192), Public Tenders (Escrow), Pharma (ERC-1155).

2. ZERO-KNOWLEDGE PRIVACY INTEGRATION (Circom / Groth16)
   - Enables selective attribute disclosure (proves qualification without exposing PII).
   - Solves the open privacy dilemma present in traditional public blockchain systems.

3. WEB2-FRIENDLY UX VIA WEB3AUTH & GASLESS RELAYERS
   - Users log in with standard Google OAuth.
   - Eliminates seed phrases, gas management, and MetaMask installation barriers.

4. DUAL ON-CHAIN / OFFLINE VERIFICATION ENGINE
   - PWA architecture with Ed25519 QR signature validation operates seamlessly
     even in rural areas with zero internet connectivity.

5. ALIGNMENT WITH NATIONAL STANDARDS (DigiLocker / NBF / DPDP Act)
   - Native export support for W3C Verifiable Credentials compatible with DigiLocker.
   - Strictly off-chain PII architecture compliant with the DPDP Act 2023.

23. Future Scope

Post-hackathon production enhancements include:

1. National Blockchain Framework (Vishvasya) Native Adapter: Building custom Hyperledger Besu chaincode bindings to allow seamless dual-anchoring across public L2s and NIC government nodes [INFERENCE].
2. Automated Cross-Border Credential Verification: Integrating with global W3C DID networks (e.g., European Digital Identity Wallet - EUDI) to allow Indian university graduates to instantly verify degrees with overseas employers [RESEARCHED].
3. Hardware IoT Cold-Chain Integration: Linking BLE/GPS temperature sensors directly to the SupplyChainTracker.sol smart contract for real-time automated drug quarantine upon temperature breach [INFERENCE].

24. Assumptions & Open Items Log

Consolidated Assumptions Log [ASSUMPTION]

1. [ASM-01]: Polygon Amoy L2 Testnet will remain stable and accessible throughout the evaluation phase.
2. [ASM-02]: Employers and verifiers have mobile devices with camera functionality capable of scanning standard QR codes.
3. [ASM-03]: Synthetic datasets generated via Faker.js accurately mirror real-world AICTE university degree schemas and CDSCO drug batch logs.

Consolidated Items Needing Validation [NEEDS VALIDATION]

1. [NV-01]: Exact API specification for direct push integration into DigiLocker Requestor/Issuer endpoints (Requires official organizational onboarding) [NEEDS VALIDATION].
2. [NV-02]: Formal legal standing of ZK-SNARK mathematical proofs under Section 65B of the Indian Evidence Act for courtroom admissibility [NEEDS VALIDATION].

Final Recommendation

The student team should proceed to solve problem SIH26194 using the proposed VeriTrust DLT architecture [INFERENCE]. The multi-sector design directly matches AICTE's Innovation goals, and the EVM + IPFS + ZK stack provides high technical depth while remaining fully achievable within the build window [INFERENCE].

Recommended Stack

• Frontend: Next.js 14, Tailwind CSS, Shadcn UI, PWA Service Workers.
• Smart Contracts: Solidity v0.8.24, OpenZeppelin (EIP-5192, ERC-1155, AccessControl), Hardhat.
• Cryptography & Storage: Circom 2.1, SnarkJS (Groth16 ZK-SNARKs), IPFS (Pinata SDK), Web3Auth.
• Ledger Network: Polygon Amoy L2 Testnet (Local Anvil/Hardhat network fallback).

Biggest Dependency

Availability and response latency of public EVM L2 testnet RPC nodes during the live evaluation demo [INFERENCE].

Biggest Risk

UX friction or latency during client-side Zero-Knowledge proof generation on low-spec mobile hardware [INFERENCE].

Biggest Technical Challenge

Implementing browser-compatible Groth16 ZK-SNARK proof generation using SnarkJS while keeping WASM binary sizes low enough for instant mobile execution [INFERENCE].

First 5 Actions

1. Initialize Hardhat development environment and install OpenZeppelin contracts library.
2. Write and unit-test CredentialRegistry.sol implementing the EIP-5192 Soulbound Token standard.
3. Design and compile the Circom ZK circuit (cgpa_verifier.circom) and generate the Solidity verifier contract using SnarkJS.
4. Scaffold the Next.js 14 Web Application and configure Web3Auth social login integration.
5. Setup Pinata IPFS API keys and build utility helper functions for off-chain payload pinning and CID resolution.

Validation Before Coding

• Verify that Hardhat local node compiles Solidity 0.8.24 contracts cleanly without warnings.
• Test SnarkJS WASM execution in a standard Chrome browser tab to verify proof generation takes $< 3$ seconds.
• Confirm Pinata API upload returns valid CIDs resolving on public IPFS gateways (https://ipfs.io/ipfs/<CID>).

Buildability Score /100

92 / 100 (Exceptional buildability; standard EVM toolchains, well-documented EIP standards, free testnet gas, and browser-native ZK libraries make full execution realistic for a 4–6 student team) [INFERENCE].

Confidence

HIGH (Supported by verified public frameworks, published EIP standards, and established open-source tooling) [INFERENCE].

Research Sources

1. NITI Aayog - Blockchain: The India Strategy (Part 1)
   https://niti.gov.in/sites/default/files/2020-01/Blockchain_The_India_Strategy_Part_I.pdf
   Source Type: Official Government Policy Report
   Supported Claim: Evaluates blockchain strategy for governance, trust building, supply chain tracking, and document verification in India.
   Reliability: High (Government Think Tank).

2. Ministry of Electronics and IT (MeitY) / PIB - National Blockchain Framework (NBF) & Vishvasya Stack
   https://www.pib.gov.in/PressReleasePage.aspx?PRID=2182023&reg=3&lang=2
   Source Type: Official Government Press Release
   Supported Claim: Details the launch of NBF, Vishvasya BaaS stack, and over 34 crore verified documents across state chains.
   Reliability: High (Official Ministry Data).

3. National Informatics Centre (NIC) - Centre of Excellence in Blockchain Technology
   https://blockchain.gov.in/
   Source Type: Government Technology Portal
   Supported Claim: Documents government adoption of Hyperledger Fabric and EVM chains for land records, property, and certificates.
   Reliability: High (Official Government Infrastructure).

4. Ethereum Improvement Proposals (EIPs) - EIP-5192: Minimal Soulbound NFTs
   https://eips.ethereum.org/EIPS/eip-5192
   Source Type: Technical Standard Specification
   Supported Claim: Defines the standard interface for non-transferable Soulbound tokens on EVM networks.
   Reliability: High (Canonical Ethereum Standard).

5. W3C Standards Consortium - Verifiable Credentials Data Model v1.1
   https://www.w3.org/TR/vc-data-model/
   Source Type: International Web Standard
   Supported Claim: Defines JSON-LD data models and cryptographically verifiable claims for digital credentials.
   Reliability: High (Official Web Standards Body).

6. DigiLocker Platform Technology Specification - DigiLocker Technology & Requestor APIs
   https://www.digilocker.gov.in/web/technology
   Source Type: Official Government Portal Documentation
   Supported Claim: Details OAuth 2.0 integration, digital signature verification, and machine-readable JSON/XML formats in DigiLocker.
   Reliability: High (Official Portal Docs).