From what to build to how to build it — our platform helps you understand, plan, and solve SIH 2026 problem statements with complete insights into requirements, solution approaches, technology stacks, architecture, AI/ML, and implementation roadmaps.
Search for your problem statement, and start building your solution.
| Description: | • Background Organizations today rely heavily on centralized identity and access management systems, which create significant security and operational risks. These systems are vulnerable to cyber attacks, identity theft, unauthorized access, and single points of failure. Additionally, digital and physical asset ownership is often managed through disconnected or semi-centralized systems, making verification of authenticity, access rights, and ownership history difficult and unreliable. There is a growing need for a decentralized, tamper-proof system that can securely manage user identities, control access permissions, and ensure transparent ownership of digital assets • Detailed Description The system aims to introduce a blockchain-based framework that integrates decentralized identity management, access control, and NFT-based digital asset ownership. Each user is assigned a decentralized identifier, which serves as a secure and verifiable digital identity independent of centralized authorities and authenticated using cryptographic proofs. Digital assets are represented as Non-Fungible Tokens (NFTs),ensuring each asset is unique, traceable, and permanently recorded on the blockchain.These NFTs are directly allocated to user identities, establishing verifiable ownership that cannot be altered or duplicated.Smart contracts govern all operations within the platform, allowing only authorized administrators to mint NFTs and assign them to user identities, ensuring controlled asset creation and secure distribution. The system also implements Role-Based Access Control (RBAC), where administrators define roles such as Admin, Manager, Auditor,and User and assign specific access rights to each identity. These permissions are enforced automatically by smart contracts during all operations. Every activity, including identity creation, NFT creation, asset allocation, access rights assignment, ownership transfers, and permission updates, is immutably recorded on the blockchain, providing a transparent and tamper-proof audit trail for verifying ownership, authenticity, and access history. • Expected Solution The expected solution is a decentralized blockchain-based platform that integrates secure digital identity management, NFT-based asset ownership, and access control into a unified and trustless system. It utilizes decentralized identifiers to provide users with self-sovereign, cryptographically verifiable identities that function independently of centralized authorities. Digital assets are issued as Non-Fungible Tokens (NFTs), ensuring uniqueness, traceability, and immutable ownership, with each NFT directly linked to a user’s decentralized identity to establish a permanent and verifiable connection between assets and their owners.The system should be governed by smart contracts that enforce strict rules for NFT creation, allocation, transfer, and validation. Only authorized administrators are allowed to create NFTs and assign them to identities, ensuring secure and controlled asset governance while preventing unauthorized duplication or reassignment. Additionally, the platform should implement Role-Based Access Control (RBAC), where administrators define roles and assign access permissions that determine user privileges within the system. All identity operations, NFT transactions, and access control updates are permanently recorded on the blockchain, ensuring complete transparency, auditability,and tamper-proof verification of ownership, permissions, and transaction history. |
| Organization: | Bharat Electronics Limited |
| Department: | Bharat Electronics Limited |
| Category: | Software |
| Theme: | Blockchain & Cybersecuritytd> |
| Youtube Link: | Not provided |
| Dataset Link: | Not provided |
| Contact info: | Not provided |
Bharat Electronics Limited (BEL), a premier defense Public Sector Undertaking (PSU) under the Ministry of Defence, Government of India, requires a unified, decentralized, and tamper-proof platform that addresses the vulnerabilities of centralized Identity and Access Management (IAM) systems [PS]. Centralized IAM frameworks represent single points of failure susceptible to cyberattacks, identity theft, unauthorized access, and credential compromise [PS]. Furthermore, managing physical and digital enterprise assets through siloed or semi-centralized databases prevents verifiable provenance, ownership integrity, and immutable authorization logging [PS].
The proposed platform introduces an enterprise-grade Web3 trust architecture that integrates W3C-compliant Decentralized Identifiers (DIDs) for self-sovereign user identity [PS], Non-Fungible Tokens (NFTs based on ERC-721 / ERC-1155 standards) for unique digital asset tokenization and ownership linkage [PS], smart contract-enforced Role-Based Access Control (RBAC) [PS], and an immutable on-chain transaction trail covering every identity, asset, and permission state change [PS]. This dossier presents a complete technical blueprint, data architecture, security evaluation, and hackathon execution plan tailored for a 4–6 student development team.
| Parameter | Value |
|---|---|
| Problem Statement ID | SIH26125 [PS] |
| Title | Blockchain-Based Secure Platform for Identity, Access Control, and Digital Asset Management [PS] |
| Organization | Bharat Electronics Limited (BEL) [PS] |
| Department | Bharat Electronics Limited [PS] |
| Category | Software [PS] |
| Theme | Blockchain & Cybersecurity [PS] |
| Submission Deadline | 30 September 2026 [PS] |
| Ideas Counter | 1/500 [PS] |
| Core System Objective | To build a trustless, cryptographically verifiable, decentralized governance platform that unifies self-sovereign user identity (DID), NFT digital asset provenance, and smart contract-enforced Role-Based Access Control (RBAC) with an immutable on-chain audit trail [PS]. |
The problem description provided by Bharat Electronics Limited (BEL) is deconstructed into atomic, explicit requirements [PS], along with logical derived implications [INFERENCE].
Requirement 2.1 (Self-Sovereign Identity via DIDs) [PS]
did:ethr or did:key) with public-key cryptographic signatures (ECDSA secp256k1 or Ed25519) for user authentication [INFERENCE].[PS]Requirement 2.2 (NFT-Based Digital Asset Representation & Allocation) [PS]
[PS]Requirement 2.3 (Smart Contract Governed Asset Minting & Distribution) [PS]
onlyAdmin access modifiers on mint() and assignAsset() functions within Solidity / Rust chaincode [INFERENCE].[PS]Requirement 2.4 (Role-Based Access Control - RBAC) [PS]
Admin, Manager, Auditor, User) managed and validated on-chain.AccessControl standard or custom bitmask role management directly into smart contract function execution pipelines [INFERENCE].[PS]Requirement 2.5 (Immutable On-Chain Audit Trail) [PS]
IdentityCreated, NFTMinted, AssetAllocated, RoleGranted, AssetTransferred, PermissionUpdated) for indexing via graph nodes or event listeners [INFERENCE].[PS]Inferred Requirement A (Decentralized Asset Storage) [INFERENCE]
Inferred Requirement B (Key Management & Web Wallet Interface) [INFERENCE]
+-----------------------------------------------------------------------------------+
| STAKEHOLDERS |
+--------------------------+--------------------------+-----------------------------+
| System Administrator | Asset Manager / Officer | Auditor & Compliance Officer|
| (BEL Security Lead) | (Logistics / Operations) | (Internal / Defense Audit) |
+--------------------------+--------------------------+-----------------------------+
| End User / Engineer | Defense Technical Lead | IT Infrastructure Team |
| (Field Asset Handler) | (SIH Evaluator / BEL) | (Network / Node Operators) |
+--------------------------+--------------------------+-----------------------------+
| Stakeholder | Goal | Current Pain | System Need |
|---|---|---|---|
| System Administrator (BEL Security Manager) [INFERENCE] | Maintain zero-trust access control, provision user DIDs, assign organizational roles, and revoke compromised accounts. | Centralized IAM DBs are targets for cyberattacks; single point of compromise grants global system privileges. | Decentralized DID registration portal, on-chain role management interface, instant cryptographic role revocation. |
| Asset Manager / Logistics Officer [INFERENCE] | Mint digital asset NFTs, assign assets to qualified personnel, track movement, and verify asset authenticity. | Asset records scattered across legacy ERPs; high risk of asset duplication, loss, or unauthorized handover. | Dashboard to mint NFTs with IPFS metadata, assign assets directly to user DIDs, and track transfer history in real time. |
| Auditor / Compliance Officer [INFERENCE] | Perform forensic audits of digital asset history, access logs, and administrative permission changes. | Centralized logs can be modified or deleted by insider threats; audit compilation is manual and slow. | Real-time, immutable audit trail viewer querying on-chain events with cryptographic proof of non-tampering. |
| End User / Engineer / Defense Personnel [INFERENCE] | Authenticate self-sovereignly, prove asset ownership, access authorized software/docs, and transfer assets safely. | Complex password resets, centralized credential lockouts, lack of personal proof of assigned asset responsibility. | Cryptographic key management interface (WebAuthn/MetaMask), single-click identity verification, digital wallet for asset NFTs. |
| Defense Technical Evaluator (SIH Judge) [INFERENCE] | Verify that the platform fulfills all BEL requirements with real blockchain execution, robust security, and practical UX. | Generic Web3 hackathon projects lack enterprise RBAC, rely on public testnet faucets, or fail to show complete asset governance. | Clear demonstration of W3C DID issuance, smart contract RBAC enforcement, real IPFS NFT minting, and live audit logging. |
| Proposed Module / Feature | Technical Component | Primary Requirement Justification | Implementation Mechanism |
|---|---|---|---|
| Self-Sovereign Identity Portal | W3C DID Module (did:ethr / did:key) |
Requirement 2.1 [PS] | Generates ECDSA key pair, builds standard W3C DID Document, anchors public key to DIDRegistry contract. |
| Digital Asset Minting Engine | ERC-721 / ERC-1155 Smart Contract | Requirement 2.2 [PS] | Mints unique asset tokens containing metadata CID, asset serial number, and initial DID assignment. |
| Admin Governance Console | Access-Gated Web Dashboard | Requirement 2.3 [PS] | Triggers smart contract mintAsset() restricted via onlyAdmin modifier backed by OpenZeppelin AccessControl. |
| On-Chain RBAC Engine | RoleManager Smart Contract |
Requirement 2.4 [PS] | Stores role assignments (ADMIN_ROLE, MANAGER_ROLE, AUDITOR_ROLE, USER_ROLE) on-chain; validates function callers. |
| Immutable Audit Ledger Viewer | Graph Indexer / EVM Event Listener Dashboard | Requirement 2.5 [PS] | Listens to all contract events (IdentityCreated, NFTMinted, RoleGranted, AssetTransferred) and presents indexed logs. |
| Encrypted File Vault | IPFS + AES-GCM-256 Encryption Client | Inferred Req A [INFERENCE] | Encrypts raw asset binaries locally before uploading to IPFS; stores resulting IPFS CID in NFT metadata. |
| Client Wallet Integration | EIP-1193 / Wagmi / WebAuthn | Inferred Req B [INFERENCE] | Enables users to sign transaction payloads and authenticate DID ownership directly from browser or mobile client. |
When deploying identity and digital asset governance within high-security enterprise or defense organizations such as Bharat Electronics Limited (BEL) [PS], real-world environmental constraints must dictate system architecture:
+-----------------------------------------------------------------------------------+
| ENVIRONMENTAL & OPERATIONAL CONSTRAINTS |
+-----------------------------------------------------------------------------------+
| 1. Air-Gapped / Private Network Operations (No public internet dependency) |
| 2. Cryptographic Key Custody & HSM Integration (Zero plain private key storage) |
| 3. High Throughput & Low Latency Transaction Finality (Deterministic execution) |
| 4. User Experience Abstraction (Hiding raw gas fees & hexadecimal hashes) |
| 5. Compliance with Indian Cybersecurity & Data Protection Laws (DPDP Act 2023) |
+-----------------------------------------------------------------------------------+
To ensure the platform design is technically sound and defensible before hackathon judges, the following core research questions must be resolved:
did:ethr, did:key, or did:pkh) provides the optimal balance between off-chain resolve speed, cryptographically verified signature validation, and on-chain lookup overhead? [RESEARCHED]| Data Type | Purpose | Ideal Real-World Source | Hackathon Substitute | Access Method | Availability | Privacy Sensitivity | Confidence |
|---|---|---|---|---|---|---|---|
| User Identity Metadata | Generating W3C DID Document & key binding | Enterprise HR / Active Directory LDAP [KNOWN] | Mock JSON User Directory with ECDSA Keypair Generator | Web3 Wallet API / Local Keygen | High (Internal) | High (Contains PII off-chain) | [INFERENCE] |
| Decentralized Identifier (DID) | Cryptographic user identification on-chain | W3C DID Resolver (did:ethr / did:key) [RESEARCHED] |
Self-generated W3C compliant DID document & registry contract | JSON-RPC / Smart Contract resolve() |
High (Open standard) | Low (Public key derivative) | [PS] |
| Digital Asset Specifications | Technical drawings, firmware, software binaries | Enterprise PLM / ERP (e.g. SAP, Siemens Teamcenter) [KNOWN] | Mock PDF/CAD/ZIP asset payloads with synthetic metadata | Local File Upload UI | High (Internal) | High (Encrypted off-chain) | [INFERENCE] |
| Asset NFT Metadata | Linking asset ID to IPFS payload & schema | Standard ERC-721 / ERC-1155 Metadata Schema [RESEARCHED] | Standard JSON file pinned to IPFS / Pinata | IPFS Gateway API / JSON HTTP | High (Public standard) | Medium (Contains file hash) | [PS] |
| Role & Permission Matrix | Mapping user DIDs to system roles | Enterprise Access Management Policy [KNOWN] | Configurable JSON matrix (ADMIN, MANAGER, AUDITOR, USER) |
Smart Contract State Query | High (Local config) | Low (Role identifiers) | [PS] |
| Audit Log Events | Immutable tracking of identity, asset, role changes | EVM Event Logs (IdentityCreated, NFTMinted, etc.) [PS] |
Indexed EVM Event Logs via Web3.js / Ethers.js | Web3 Filter / GraphQL Indexer | High (On-chain) | Low (Hashed identifiers) | [PS] |
+-----------------------------------------------------------------------------------+
| EXISTING SOLUTIONS VS BEL SYSTEM |
+---------------------------------------+-------------------------------------------+
| Legacy Centralized IAM (Active Dir) | Single point of failure, mutable logs, |
| | vulnerable to credential theft. |
+---------------------------------------+-------------------------------------------+
| Public NFT Platforms (OpenSea) | No enterprise RBAC, public data exposure, |
| | volatile gas fees, no DID integration. |
+---------------------------------------+-------------------------------------------+
| Standalone W3C DID Systems (ION) | Identity management only; lacks digital |
| | asset tokenization and fine-grained RBAC. |
+---------------------------------------+-------------------------------------------+
| PROPOSED SIH26125 PLATFORM | Unified DID + NFT Asset Tokenization + |
| | Smart Contract RBAC + Immutable Logs. |
+---------------------------------------+-------------------------------------------+
[KNOWN][RESEARCHED][RESEARCHED]The proposed platform directly fills these gaps by unifying W3C DIDs, standard EVM NFT standards (ERC-721/1155), OpenZeppelin smart contract RBAC, and IPFS encrypted payload storage into a single enterprise solution tailored for defense/PSU asset governance [INFERENCE].
To determine the most practical and effective architecture for a 4–6 student team under SIH constraints, three candidate solution approaches were evaluated:
+-----------------------------------------------------------------------------------+
| CANDIDATE ARCHITECTURES |
+-----------------------------------------------------------------------------------+
| Approach 1: Public EVM L2 (Polygon/Arbitrum) + Basic ERC-721 + Web3 Auth |
| Approach 2: Permissioned Hyperledger Fabric + FabAsset + Private MSP Network |
| Approach 3: Hybrid EVM Enterprise Architecture (Besu / Polygon L2 Testnet / |
| Hardhat Local Nodes + OpenZeppelin RBAC + W3C DID + ERC-1155 + IPFS) |
+-----------------------------------------------------------------------------------+
did:ethr.AccessControl + ERC-1155 / ERC-721 Multi-Token) on a local/private EVM node (Hardhat / Anvil / Local Hyperledger Besu instance or Polygon testnet). Implement W3C did:ethr / did:key identity layer, client-side WebAuthn / Ethers signature validation, and IPFS file storage.| Evaluation Dimension | Approach 1 (Public L2) | Approach 2 (Fabric Chaincode) | Approach 3 (Hybrid Enterprise EVM) |
|---|---|---|---|
| Problem Statement Fit | Medium (Fails enterprise privacy) | High | Extremely High |
| DID & Cryptographic Proofs | High (did:ethr) |
Medium (MSP X.509 certificates) | High (did:ethr / did:key) |
| NFT Asset Provenance | High (ERC-721) | Medium (FabAsset standard) | High (ERC-1155 / ERC-721) |
| Smart Contract RBAC | Medium (Custom modifiers) | High (Chaincode ACL) | High (OpenZeppelin AccessControl) |
| Deterministic Demo Reliability | Low (Public faucet dependent) | Medium (Complex multi-container) | Extremely High (Local RPC Node) |
| Hackathon Implementation Effort | Low (3-4 days) | Very High (12-15 days) | Optimal (4-6 days) |
| Production Scalability for BEL | Low | High | High (EVM Enterprise Besu) |
Selected Strategy: Approach 3 (Hybrid Enterprise EVM Architecture with W3C DID, OpenZeppelin RBAC, ERC-1155 Multi-Token Assets, and IPFS Payload Storage).
Admin, Manager, Auditor, User) [PS], and immutable audit logging [PS].+-----------------------------------------------------------------------------------+
| SYSTEM ARCHITECTURE |
+-----------------------------------------------------------------------------------+
| 1. CLIENT LAYER |
| +-----------------------+ +-----------------------+ +----------------------+ |
| | Admin Portal | | Manager / Logistics | | Auditor Console | |
| | (DID Gen / Role Mgr) | | (NFT Mint / Allocate) | | (On-Chain Log View) | |
| +-----------------------+ +-----------------------+ +----------------------+ |
| | PWA Client (Ethers.js / Wagmi / WebAuthn / Offline Event Queue) | |
+-----------------------------------------------------------------------------------+
| (HTTP / JSON-RPC / IPFS API)
v
+-----------------------------------------------------------------------------------+
| 2. API & GATEWAY LAYER |
| +----------------------------------------------------------------------------+ |
| | Node.js / Express Middleware + Web3 API Gateway | |
| | - W3C DID Resolver & Verifier (`did:ethr` / `did:key`) | |
| | - EIP-712 Typed Data Signature Authentication | |
| | - AES-256 File Encryptor / IPFS Pinning Manager | |
| +----------------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------+
| (JSON-RPC Calls / IPFS Swarm)
+--------------------+--------------------+
| |
v v
+---------------------------------------+ +-----------------------------------------+
| 3. BLOCKCHAIN LEDGER LAYER | | 4. DECENTRALIZED STORAGE LAYER |
| (Local Besu / Hardhat Node) | | (IPFS / Private Pinning Service) |
| +--------------------------------+ | | +-------------------------------------+ |
| | Identity Registry Contract | | | | Raw Asset Payload (.cad, .bin, .pdf) | |
| +--------------------------------+ | | +-------------------------------------+ |
| | RBAC Permission Contract | | | | Encrypted Asset Files (AES-GCM-256) | |
| +--------------------------------+ | | +-------------------------------------+ |
| | Asset NFT Contract (ERC-1155) | | | | Token Metadata JSON Documents | |
| +--------------------------------+ | | +-------------------------------------+ |
| | Immutable Audit Logger Contract| | | +-------------------------------------+ |
| +--------------------------------+ | +-----------------------------------------+
+---------------------------------------+
+-----------------------------------------------------------------------------------+
| STEP-BY-STEP DATA FLOW |
+-----------------------------------------------------------------------------------+
| STEP 1: USER DID PROVISIONING |
| User Keypair Generated -> Public Key anchored on DIDRegistry -> DID issued |
| |
| STEP 2: ADMIN ROLE ASSIGNMENT |
| Admin signs GrantRole transaction -> AccessControl updates state on-chain |
| |
| STEP 3: ASSET ENCRYPTION & IPFS PINNING |
| Asset File Encrypted (AES-GCM) -> Uploaded to IPFS -> CID returned |
| |
| STEP 4: SMART CONTRACT NFT MINTING & ALLOCATION |
| Admin calls mintAsset(DID, CID) -> Smart contract verifies Admin role -> Token minted|
| |
| STEP 5: ACCESS EXECUTION & AUDIT LOGGING |
| User requests asset access -> Smart contract validates role/ownership -> Log emitted|
+-----------------------------------------------------------------------------------+
secp256k1) locally in the client browser using WebAuthn or Ethers.js [INFERENCE].DIDRegistry smart contract, constructing a W3C-compliant identifier (e.g., did:ethr:0x71C...39A) [INFERENCE].grantRole(bytes32 role, address account) on the RoleManager smart contract [PS].RoleGranted(role, account, admin) event recorded on-chain [PS].mintAsset(address toDID, uint256 assetId, string memory uri) on the AssetNFT contract [PS].MANAGER_ROLE or ADMIN_ROLE. If verified, the NFT token is minted and transferred directly to toDID [PS].AssetAllocated(assetId, toDID, managerDID, timestamp) is emitted [PS].toDID is the registered owner of assetId and holds an active USER_ROLE [PS].AssetAccessed(assetId, userDID, timestamp) is published on-chain [PS].| Layer | Selected Technology | Why Chosen | Alternative Considered | Why Alternative Rejected |
|---|---|---|---|---|
| Frontend UI | React.js + Next.js 14 + TailwindCSS | High-performance server-side rendering, component modularity, rapid UI development for hackathons. | Angular / Vue.js | Slower prototyping speed; smaller Web3 library ecosystem. |
| Web3 Client Engine | Ethers.js v6 + Wagmi / Viem | Robust, lightweight library for smart contract interactions, event filtering, and typed EIP-712 signature generation. | Web3.js | Slower execution overhead; less strict TypeScript support. |
| Smart Contracts | Solidity v0.8.24 + OpenZeppelin Contracts v5 | Industry-standard language and audited contract libraries (AccessControl, ERC1155, Pausable). |
Rust / Chaincode | Higher compilation complexity; harder to debug within hackathon timeframe. |
| Development Blockchain | Hardhat / Anvil (Local EVM) | Fast execution, instantaneous block finality, full console log debugging, zero public network latency. | Ethereum Sepolia Testnet | Vulnerable to RPC downtime, slow block times, and faucet rate limits during live judging. |
| Decentralized Storage | Kubo IPFS Node / Pinata API | Content-addressable storage ensuring file immutability; hash (CID) directly matches on-chain NFT metadata. | AWS S3 | Centralized cloud storage introduces single point of failure and violates Web3 principles. |
| Backend API Gateway | Node.js + Express.js + TypeScript | Asynchronous I/O, rapid implementation of REST endpoints for DID resolution and IPFS encryption. | Python FastAPI | Extra friction integrating with JavaScript-native Web3 client SDKs. |
| Local Offline Database | IndexedDB (Dexie.js client side) | Native browser database capable of storing offline transaction queues and encrypted secret keys. | SQLite | Requires native C bindings that complicate browser PWA execution. |
| Smart Contract Auditor | Slither + Solhint | Static analysis tools to detect reentrancy, access control flaws, and gas inefficiencies before deployment. | Manual Audit | High risk of missing critical smart contract vulnerabilities under tight deadlines. |
The core functional requirements specified by BEL—Decentralized Identifiers, NFT Minting, Role-Based Access Control, and Immutable Event Logging [PS]—are strictly deterministic cryptographic operations. They require absolute, mathematical certainty (e.g., ECDSA signature verification, zero-tamper ledger immutability).
AI/ML MUST NOT be used for access control validation or identity resolution, as ML probabilistic outputs introduce non-deterministic false positives or false negatives that compromise system security [INFERENCE].
+-----------------------------------------------------------------------------------+
| AI/ML MODULE: ANOMALY DETECTION ENGINE |
| (OPTIONAL ADD-ON) |
+-----------------------------------------------------------------------------------+
| [INPUT] -> On-chain Event Stream (Timestamps, User DIDs, Asset IDs, Role Changes) |
| | |
| v |
| [PROCESSING] -> Isolation Forest / Autoencoder (Detects abnormal access patterns) |
| | |
| v |
| [OUTPUT] -> Anomaly Risk Score (0.0 - 1.0) -> Triggers Admin Audit Flag |
+-----------------------------------------------------------------------------------+
While the core ledger is deterministic, an optional auxiliary AI component can analyze audit logs for anomalous administrative behavior [INFERENCE].
RoleGranted, AssetTransferred, AssetAccessed) containing timestamps, actor DIDs, and asset IDs [INFERENCE].+-----------------------------------------------------------------------------------+
| DATA SCHEMAS & OFFLINE DESIGN |
+-----------------------------------------------------------------------------------+
| 1. DID DOCUMENT SCHEMA (W3C Compliant) |
| - id: "did:ethr:0x71C7656EC7ab88b098defB751B7401B5f6d8976F" |
| - verificationMethod: [ { id: "...#key-1", type: "EcdsaSecp256k1...", ... } ] |
| |
| 2. ASSET NFT METADATA SCHEMA (ERC-1155 / ERC-721) |
| - name: "BEL Tactical Radar Schematic v4" |
| - asset_id: "BEL-RADAR-2026-089" |
| - payload_ipfs_cid: "QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco" |
| - encryption_algo: "AES-GCM-256" |
| |
| 3. OFFLINE PWA SYNCHRONIZATION QUEUE |
| Client Offline Action -> Signed with Local DID Key -> Stored in IndexedDB -> |
| Connection Restored -> Auto-relayed to Blockchain RPC -> State Synced |
+-----------------------------------------------------------------------------------+
did:ethr){
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "did:ethr:0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
"verificationMethod": [
{
"id": "did:ethr:0x71C7656EC7ab88b098defB751B7401B5f6d8976F#controller",
"type": "EcdsaSecp256k1RecoveryMethod2020",
"controller": "did:ethr:0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
"blockchainAccountId": "eip155:1:0x71C7656EC7ab88b098defB751B7401B5f6d8976F"
}
],
"authentication": [
"did:ethr:0x71C7656EC7ab88b098defB751B7401B5f6d8976F#controller"
]
}
{
"name": "BEL Tactical Radar Module Schematic",
"description": "Encrypted technical blueprint for BEL radar unit R-104",
"image": "ipfs://QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/preview.png",
"external_url": "https://bel-india.in/assets/R-104",
"attributes": [
{ "trait_type": "Classification", "value": "Restricted Enterprise" },
{ "trait_type": "Asset ID", "value": "BEL-RADAR-2026-089" },
{ "trait_type": "FileType", "value": "CAD/DWG" },
{ "trait_type": "Encryption", "value": "AES-GCM-256" }
],
"properties": {
"encrypted_payload_cid": "QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco",
"payload_hash_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"created_by_did": "did:ethr:0x90F79bf6EB2c4f870365E785982E1f101E93b906"
}
}
+-----------------------------------------------------------------------------------+
| SECURITY & GOVERNANCE CONTROL MATRIX |
+-----------------------------------------------------------------------------------+
| 1. ZERO PII ON-CHAIN -> Only public keys, DIDs, role bitmasks, and CIDs. |
| 2. RBAC ACCESS CONTROL -> OpenZeppelin AccessControl with strict function modifiers.|
| 3. SMART CONTRACT AUDITING -> Slither static analysis + ReentrancyGuard execution.|
| 4. AES-GCM-256 ENCRYPTION -> File binaries encrypted client-side before upload. |
| 5. CRYPTOGRAPHIC PROOFS -> EIP-712 typed data signatures for user authentication.|
+-----------------------------------------------------------------------------------+
AccessControl with strict modifiers (onlyRole(ADMIN_ROLE), onlyRole(MANAGER_ROLE)). Require multi-signature authorization for granting new ADMIN_ROLE accounts [INFERENCE].ReentrancyGuard to all state-mutating asset transfer functions; execute automated static analysis using Slither [INFERENCE].RoleManager contract includes an administrative emergency function revokeRole(role, targetDID) and a key rotation function updateDIDOwner(oldDID, newDID) gated by multi-sig approval [INFERENCE].To deliver a working prototype within the hackathon build window, features are prioritized into explicit build tiers:
+-----------------------------------------------------------------------------------+
| HACKATHON MVP SCOPE MATRIX |
+-----------------------------------------------------------------------------------+
| MUST BUILD (Core Demo Engine) |
| - W3C DID Generation Portal (`did:ethr` / `did:key`) |
| - Smart Contract RBAC Engine (Admin, Manager, Auditor, User) |
| - NFT Asset Minting & DID Allocation (ERC-1155) |
| - Real-Time On-Chain Audit Log Viewer |
| - AES-256 Encrypted IPFS File Upload Client |
+-----------------------------------------------------------------------------------+
| SHOULD BUILD (Enhanced Value) |
| - Role Revocation & Key Rotation Interface |
| - Offline PWA Action Queue with Sync Indicator |
| - Exportable PDF Forensic Audit Reports |
+-----------------------------------------------------------------------------------+
| NICE TO HAVE (If Time Permits) |
| - AI Anomaly Detection Alert Badge on Audit Console |
| - ERC-4337 Account Abstraction Gas Relayer |
+-----------------------------------------------------------------------------------+
| DO NOT BUILD DURING HACKATHON (Out of Scope) |
| - Hardware Security Module (HSM) PKCS#11 Native Integration |
| - Enterprise SAP/ERP Legacy Connector Plugins |
| - Production Cross-Chain Bridges |
+-----------------------------------------------------------------------------------+
AccessControl for four roles (ADMIN, MANAGER, AUDITOR, USER) [PS].IdentityCreated, NFTMinted, RoleGranted, AssetTransferred) [PS].To ensure a seamless presentation during judging, all external dependencies (such as public blockchain RPCs or public IPFS gateways) will be replaced with local, high-reliability simulation setups:
+-----------------------------------------------------------------------------------+
| LIVE DEMO SIMULATION SETUPS |
+-----------------------------------------------------------------------------------+
| Dependency | Production Real-World | Hackathon Local Simulation |
+---------------------+-------------------------------+-----------------------------+
| Blockchain Ledger | Enterprise Besu Private Net | Local Anvil / Hardhat Node |
| IPFS Storage | Multi-Node Private Cluster | Local Kubo IPFS Desktop Node|
| User Key Management | Enterprise HSM / Smartcard | Client WebAuthn / Ethers |
| Enterprise Assets | Defense CAD Schematics (.dwg) | Pre-loaded Sample Schematics|
+---------------------+-------------------------------+-----------------------------+
[0:00 - 1:00] ROLE SETUP & DID ISSUANCE
1. Admin opens Portal -> Generates DID: `did:ethr:0xAdmin...`
2. Admin grants `MANAGER_ROLE` to Logistics Lead (`did:ethr:0xManager...`)
3. Admin grants `USER_ROLE` to Field Engineer (`did:ethr:0xEngineer...`)
-> Show instant on-chain transaction confirmation & log event in Audit Console.
[1:00 - 2:30] ASSET ENCRYPTION & NFT MINTING
1. Manager selects asset file: "Tactical Radar System Blueprint v2.pdf"
2. System encrypts file locally (AES-256) -> Uploads to IPFS -> Returns CID: `QmXoy...`
3. Manager executes `mintAsset()` -> Assigns NFT token directly to Field Engineer DID.
-> Show token balance updating on Engineer's wallet interface.
[2:30 - 3:30] PERMISSIONED ACCESS & CRYPTOGRAPHIC PROOF
1. Engineer attempts asset access -> System requests EIP-712 cryptographic signature.
2. Engineer signs request -> Smart contract verifies ownership & user role.
3. Asset payload decrypted in browser -> File preview opens.
4. Show Unauthorized User (`did:ethr:0xAttacker...`) attempted access -> Denied on-chain!
[3:30 - 5:00] IMMUTABLE AUDIT TRAIL & OFFLINE TEST
1. Open Auditor Console -> Show tamper-proof timeline of all events.
2. Simulate offline network disconnect -> Perform asset verify -> Action queued in IndexedDB.
3. Reconnect network -> Action automatically syncs and commits to ledger!
The implementation plan is structured across three development phases, aligned with the 30 September 2026 submission deadline [PS]:
+-----------------------------------------------------------------------------------+
| IMPLEMENTATION TIMELINE |
+-----------------------------------------------------------------------------------+
| PHASE 1: CORE PROTOCOL & SMART CONTRACTS (Months 1–2 / Target: Oct 2025) |
| - Finalize Solidity contracts (DIDRegistry, RoleManager, AssetNFT, AuditLogger) |
| - Complete unit test suite (Hardhat / Foundry) with 100% branch coverage |
| - Deploy local test network and verify IPFS upload workflow |
+-----------------------------------------------------------------------------------+
| PHASE 2: FRONTEND INTEGRATION & SECURITY (Months 3–6 / Target: Feb 2026) |
| - Build Next.js Dashboard UI (Admin, Manager, Auditor, User views) |
| - Integrate Ethers.js, WebAuthn client key management, and EIP-712 signing |
| - Implement IndexedDB offline action queue and PWA sync engine |
| - Execute static code analysis with Slither and optimize gas usage |
+-----------------------------------------------------------------------------------+
| PHASE 3: TESTING, DEMO HARDENING & PILOT (Months 7–12 / Target: Sep 2026) |
| - Perform simulated attack testing (unauthorized minting, replay attacks) |
| - Pre-load realistic asset datasets and configure local deterministic node |
| - Finalize pitch deck, video demo, and documentation for SIH presentation |
+-----------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------+
| TESTING & VALIDATION PIPELINE |
+-----------------------------------------------------------------------------------+
| 1. SMART CONTRACT UNIT TESTS -> Hardhat / Foundry (100% Function Coverage) |
| 2. STATIC SECURITY ANALYSIS -> Slither + Solhint (Zero High/Medium Findings) |
| 3. RBAC MODIFIER TESTS -> Verify Unauthorized Callers are Reverted |
| 4. OFFLINE SYNC VALIDATION -> Simulate Network Dropout & Re-connection Sync |
| 5. END-TO-END WORKFLOW INTEGRATION -> Full User Journey Verification |
+-----------------------------------------------------------------------------------+
| Test Category | Target Component | Method / Tool | Pass Criteria |
|---|---|---|---|
| Smart Contract Unit Tests | DIDRegistry, AssetNFT, RoleManager |
Hardhat / Foundry Test Suite | 100% of functions pass; full branch coverage achieved. |
| Static Security Audit | Solidity Source Code | Slither Static Analyzer | Zero high-severity or medium-severity security vulnerabilities. |
| RBAC Enforcement | Function Modifiers (onlyRole) |
Automated Penetration Scripts | Non-admin accounts attempting mintAsset() or grantRole() are reverted. |
| Cryptographic Signature Verification | EIP-712 DID Authentication | Client-Side Ethers.js Assertions | Invalid cryptographic signatures fail on-chain verification. |
| IPFS Encryption Integrity | AES-GCM Payload Upload/Download | SHA-256 Hash Assertion | Decrypted file binary matches original unencrypted file hash exactly. |
| Offline Sync Performance | IndexedDB Offline Queue | Network Throttling Simulation | Queued signed transactions sync successfully upon connection restore. |
| UI Usability | End-to-End User Journeys | Playwright Automated End-to-End | Complete user flow executes without unhandled JavaScript exceptions. |
| Risk Event | Likelihood | Impact | Severity | Risk Mitigation Strategy |
|---|---|---|---|---|
| Smart Contract Reentrancy or Access Control Vulnerability | Low | High | High | Use audited OpenZeppelin standard libraries (AccessControl, ReentrancyGuard); run Slither static analysis [INFERENCE]. |
| Browser Key Exposure via XSS Attack | Medium | High | High | Sanitize all UI inputs; store private key material using WebAuthn browser enclave or encrypted local vaults [INFERENCE]. |
| Public Blockchain Network Latency / Faucet Outage during Demo | High | High | High | Run a local, deterministic EVM node (Anvil / Hardhat) for the live demo, eliminating public internet dependency [INFERENCE]. |
| Accidental Upload of Unencrypted Sensitive Files to IPFS | Low | High | High | Enforce mandatory client-side AES-256 encryption in the UI upload component prior to sending data to IPFS [INFERENCE]. |
| User Key Loss / Lockout from System | Medium | Medium | Medium | Implement an administrative multi-sig key rotation function on-chain to re-bind DIDs upon identity verification [INFERENCE]. |
| Team Scope Creep Beyond Build Deadline | Medium | Medium | Medium | Strict adherence to MVP scope matrix; freeze smart contract code 30 days prior to submission [ASSUMPTION]. |
+-----------------------------------------------------------------------------------+
| COST & SCALABILITY ANALYSIS |
+-----------------------------------------------------------------------------------+
| HACKATHON ENVIRONMENT (Zero-Cost Prototyping) |
| - Local EVM RPC Node (Anvil / Hardhat): $0.00 |
| - Local IPFS Kubo Node: $0.00 |
| - Vercel / Netlify Frontend Hosting: $0.00 |
| - Total Hackathon Budget: $0.00 |
+-----------------------------------------------------------------------------------+
| PRODUCTION DEPLOYMENT (Enterprise Enterprise Besu Cluster) |
| - 4x Hyperledger Besu Validator Nodes (On-Premises Hardware): Existing BEL Infra |
| - Private IPFS Cluster Nodes (3x Pinning Nodes): Internal Data Center |
| - Transaction Gas Costs: $0.00 (Private network with zero gas pricing) |
| - System Scalability: ~400-1,000 TPS on private EVM consensus |
+-----------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------+
| KEY SYSTEM DIFFERENTIATORS |
+-----------------------------------------------------------------------------------+
| Feature | Generic Hackathon Entry | PROPOSED SIH26125 SOLUTION |
+-----------------------+----------------------------+------------------------------+
| Identity Standard | Raw Metamask Wallet Address| W3C Compliant DID Document |
| Access Control | Basic Owner Address Modifier| OpenZeppelin Multi-Role RBAC |
| Asset Tokenization | Simple ERC-20 / ERC-721 | ERC-1155 Multi-Token + IPFS |
| Audit Mechanism | Console logs / Server DB | Immutable On-Chain Events |
| Network Dependency | Public Testnet Faucets | Local Deterministic EVM Node |
| Security Strategy | Plaintext File Uploads | Client-Side AES-256 Encrypted|
+-----------------------------------------------------------------------------------+
MANAGER_ROLE) without revealing their specific DID or account address on-chain [INFERENCE].[ASSUMPTION][ASSUMPTION] The SIH judging panel will evaluate the system using standard modern Web browsers (Chrome / Firefox / Edge) supporting Web3 wallet extensions or WebAuthn APIs.[ASSUMPTION] Synthetic digital asset files (dummy CAD diagrams, technical spec PDFs) are sufficient for demonstrating system capabilities during judging.[ASSUMPTION] A local deterministic blockchain node (Anvil / Hardhat) running on the demonstration laptop is acceptable for proving enterprise EVM functionality.[ASSUMPTION] Four primary organizational roles (Admin, Manager, Auditor, User) fully cover the required operational hierarchy for the MVP.[NEEDS VALIDATION][NEEDS VALIDATION] Exact API interfaces or single sign-on (SSO) protocols used by Bharat Electronics Limited's existing internal Active Directory / LDAP infrastructure.[NEEDS VALIDATION] Specific physical HSM hardware model requirements (e.g., YubiKey, Nitrokey, PKCS#11 smartcards) for field deployment.[NEEDS VALIDATION] Network firewall configurations and air-gapped subnet rules within BEL development facilities.| Metric | Recommendation / Value |
|---|---|
| Recommended Strategy | Approach 3: Hybrid Enterprise EVM Architecture using OpenZeppelin Smart Contract RBAC, W3C DIDs (did:ethr), ERC-1155 Multi-Token Asset Provenance, and Encrypted IPFS Payload Storage [INFERENCE]. |
| Recommended Stack | Next.js 14, Ethers.js v6, Solidity v0.8.24, OpenZeppelin v5, Hardhat / Anvil, Kubo IPFS, Dexie.js (IndexedDB) [INFERENCE]. |
| Biggest Dependency | Client-side cryptographic key generation and browser Web3 / WebAuthn execution stability [INFERENCE]. |
| Biggest Risk | Public testnet failure or gas faucet outage during live evaluation (mitigated by using a local deterministic node) [INFERENCE]. |
| Biggest Technical Challenge | Ensuring client-side AES-256 asset encryption integrates cleanly with IPFS pinning and EIP-712 DID signature validation [INFERENCE]. |
DIDRegistry.sol contract supporting W3C did:ethr public key resolution.RoleManager.sol and AssetNFT.sol contracts incorporating OpenZeppelin AccessControl and ERC1155.| Buildability Score | Confidence Level |
|---|---|
| 95/100 | HIGH |
Title: Hyperledger Fabric Architecture & FabAsset Technical Standard [2.2, 2.3]
Title: W3C Decentralized Identifiers (DIDs) v1.0 Core Architecture [1.2, 1.6]
Title: Ethereum Multi-Token Standard (ERC-1155) Specification [4.1, 4.2]
Title: OpenZeppelin AccessControl Smart Contract Library Documentation [4.8]
Title: Bharat Electronics Limited (BEL) Software Products & Solutions Portfolio [3.1, 3.11]
What we think about this platform, and how it can help people solve SIH problems.
" 30M+ Google Gemini tokens went into researching, analyzing, and understanding all 233 SIH problem statements to make them easier to explore and solve. "
" The platform makes SIH problem statements much easier to understand. Having everything from the problem details to the procedure in one place. "
" Oh, you got ads? Well, we need to make money too! But, you can use our platform to help you win SIH and take home the prize money. "
Get in touch if you need help bringing your ideas to life, or simply have an interesting idea you'd like to talk through. I'm always open to a conversation and exploring new possibilities together.