Real-Time Identification of Fraud-Linked Cryptocurrency Exchanges from Victim-Reported Suspect Wallet Addresses through Automated Blockchain Analytics

1. Executive Snapshot

Summary

The Real-Time Crypto Fraud Attribution System (RTCFAS) is an automated, multi-chain blockchain intelligence and investigative platform designed for Indian Law Enforcement Agencies (LEAs), the Indian Cyber Crime Coordination Centre (I4C), and the Ministry of Home Affairs (MHA) [PS]. When financial cyber fraud victims report suspect cryptocurrency wallet addresses via the National Cyber Crime Reporting Portal (NCRP / 1930 Helpline), bad actors rapidly layer funds through burner wallets, mixers, cross-chain bridges, and decentralized protocols to reach off-ramps [PS, KNOWN]. RTCFAS automates the complex task of multi-hop blockchain graph traversal, heuristic-based wallet clustering, and entity attribution to identify the nearest Virtual Asset Service Provider (VASP) or cryptocurrency exchange holding or processing the stolen funds in real-time [PS, INFERENCE]. By generating standardized legal notices, risk scores, and visual fund-flow graphs, the system enables LEAs to immediately issue freeze requests under Indian law (such as Section 91/102 CrPC / BNSS) and interface with registered VASPs via I4C’s SAHYOG portal to prevent asset siphoning [PS, KNOWN, INFERENCE].

Metadata Table

Fundamental System Objective

To automatically trace victim-reported suspect crypto wallet addresses across multi-chain ecosystems in real-time, cluster intermediary laundering wallets, identify the ultimate receiving exchange/VASP, and generate actionable evidence packages for Law Enforcement Agencies to freeze illicit proceeds [PS, INFERENCE].

2. Problem Deconstruction

Explicit Requirements (Extracted directly from Problem Statement [PS])

1. [REQ-01] Real-Time Wallet Ingestion: Ingest suspect cryptocurrency wallet addresses reported through cybercrime complaint systems (NCRP / 1930) across fraud types (investment scams, task-based frauds, sextortion, ransomware, phishing, darknet transactions, and organized cyber financial crimes) [PS].
2. [REQ-02] Automated Blockchain Tracing: Automatically perform multi-hop blockchain tracing starting from victim-reported addresses without requiring manual expert graph analysis [PS].
3. [REQ-03] VASP & Exchange Identification: Identify the nearest or final destination Cryptocurrency Exchange or Virtual Asset Service Provider (VASP) receiving direct deposits or layered funds [PS].
4. [REQ-04] Pattern & Typology Detection: Detect fund movement patterns, intermediary layering wallets, burner wallets, mixers/tumblers, bridges, and privacy-enhancing mechanisms [PS].
5. [REQ-05] Multi-Chain & Cross-Chain Support: Support multiple major blockchain ecosystems (e.g., Bitcoin, Ethereum, TRON, BNB Chain) and trace cross-chain fund movements [PS].
6. [REQ-06] System Integration: Integrate via APIs with I4C platforms, specifically NCRP (National Cyber Crime Reporting Portal) and the SAHYOG portal [PS].
7. [REQ-07] Automated Alerting & Risk Categorization: Perform AI/ML-assisted risk detection and wallet risk categorization, generating real-time automated alerts for high-risk transfers [PS].
8. [REQ-08] Investigation Dashboard & Visualization: Provide interactive analytics dashboards with fund-flow visualization, automated investigative recommendations, and standardized legal report generation for LEAs [PS].
9. [REQ-09] Scalable Architecture: Implement scalable blockchain indexing and API integration capabilities to reduce investigation response times and improve freezing of crime proceeds [PS].

Implicit & Derived Requirements [INFERENCE]

1. [IMP-01] Entity Attribution Database: Requires an extensive attribution dataset mapping known Exchange Hot/Cold Wallets, Deposit Addresses, and VASP Infrastructure (specifically FIU-IND registered VASPs) [INFERENCE].
2. [IMP-02] Offline & Local Deployability: Must function inside secure LEA intranet networks (e.g., State Cyber Cells) with fallback mechanisms when live external RPCs or APIs encounter rate limits [INFERENCE, ASSUMPTION].
3. [IMP-03] Evidentiary Integrity: Exported investigation reports must maintain strict cryptographic chain-of-custody hash signatures suitable for submission in Indian courts under Section 63 of the Bharatiya Sakshya Adhiniyam (BSA) 2023 [INFERENCE, KNOWN].
4. [IMP-04] Rate-Limit & RPC Resilience: Multi-chain crawling must handle high transaction volumes without exceeding free/public API tiers during hackathon demonstration [INFERENCE, ASSUMPTION].

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

1. Law Enforcement Operational Realities: Most district cyber cells in India operate with generalist police personnel who lack specialized blockchain forensic training [KNOWN, RESEARCHED]. Software must provide plain-English summaries (e.g., "Stolen funds reached Binance Deposit Wallet 0x123... on 2026-09-04 14:20 UTC") alongside technical evidence graphs [INFERENCE].
2. Bandwidth & Connectivity Constraints: Field officers operate over 4G/5G mobile connections or restricted intranet police networks [KNOWN]. Dashboard frontends must be lightweight (< 2MB payload) and support offline caching of completed trace reports [INFERENCE, ASSUMPTION].
3. API Rate Limits & RPC Availability: Commercial blockchain analytics APIs (Chainalysis, TRM) are closed-source and costly [RESEARCHED]. Public RPC endpoints (Infura, Alchemy, Ankr, TronGrid) enforce strict rate limits (e.g., 10-25 requests/sec) [KNOWN]. The system must use local node caching, indexed database mirrors, or batch request batching during hackathons [INFERENCE, ASSUMPTION].
4. Regulatory & Legal Environment: Under FIU-IND (Financial Intelligence Unit - India) mandates and PMLA rules, Virtual Digital Asset Service Providers (VDASPs) catering to Indian users must register as Reporting Entities [KNOWN, RESEARCHED]. Unregistered offshore exchanges are blocked via MHA/Sahyog notices under Section 79(3)(b) IT Act [RESEARCHED]. The system must distinguish between FIU-IND registered VASPs and non-compliant offshore platforms [INFERENCE].

6. Research Questions

1. Clustering Efficiency: How effectively can open-source heuristics (Common-Input Ownership, Change Address, Deposit Address reuse) cluster wallets on Account-based chains (Ethereum/TRON) compared to UTXO-based chains (Bitcoin)? [RESEARCHED]
2. Cross-Chain Tracing: How can cross-chain transfers via decentralized bridges (e.g., Uniswap, FixedFloat, ChangeNOW) be tracked when on-chain events lack explicit destination tag metadata? [RESEARCHED, NEEDS VALIDATION]
3. Exchange Hot Wallet vs Deposit Address: How can the system differentiate between a user-specific Exchange Deposit Address and an Exchange Central Hot Wallet using transaction patterns? [RESEARCHED]
4. NCRP / SAHYOG Integration Specs: What are the exact schema formats and security protocols required for API ingestion from NCRP and notice dispatch via SAHYOG? [NEEDS VALIDATION]
5. Real-time Traversal Depth vs Latency: What is the optimal graph depth cutoff ($k$-hops) to balance real-time query speed (< 3 seconds) with investigative completeness? [INFERENCE, ASSUMPTION]

7. Data Requirements & Sources

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: Basic Rule-Based Traversal & Static Lookup (Rule-Based Graph Search)

• Mechanism: Performs Depth-First Search (DFS) on public block explorer APIs starting from the suspect address up to $N$ hops. Compares each touched address against a static CSV database of known exchange hot wallets.
• Accuracy Potential: Low to Moderate. Fails on unlabelled deposit addresses, multi-chain swaps, or simple layering techniques like peel chains [INFERENCE].
• Complexity & Effort: Very Low. Fast to build using standard Python scripts and Etherscan API.
• Hackathon vs Production Feasibility: Hackathon: High | Production: Unviable (High false-negative rate, API rate limits) [INFERENCE].

Approach 2: Deep Learning & GNN-Only Transaction Pattern Classifier

• Mechanism: Feeds raw transaction graphs into a Graph Neural Network (GNN - PyTorch Geometric) to classify whether a wallet belongs to a scammer, mixer, or exchange based on structural graph embeddings.
• Accuracy Potential: High for anomaly detection, but Low for precise entity attribution (cannot reliably identify which exact exchange owns an unlabelled address without hard labels) [INFERENCE].
• Complexity & Effort: High ML training complexity; requires massive labelled graph datasets.
• Hackathon vs Production Feasibility: Hackathon: Low (Data scarcity) | Production: Moderate (as a supplementary risk score module) [INFERENCE].

Approach 3: Automated Multi-Chain Graph Explorer with Hybrid Heuristics, Dynamic API Crawling, and ML Risk Scoring (RECOMMENDED HYBRID)

• Mechanism: Combines high-speed parallel graph traversal (Memgraph / NetworkX) with deterministic clustering heuristics (Common-Input Ownership, Change Address Detection, Deposit Address Reuse). Matches addresses against a dynamic VASP Attribution Index and uses a lightweight GNN/XGBoost model to score layering risk and typology patterns. Automatically triggers NCRP/SAHYOG alert templates [INFERENCE].
• Accuracy Potential: High. Combines exact deterministic labels with heuristic clustering and AI anomaly detection [INFERENCE].
• Complexity & Effort: Moderate to High, but well-scoped for a 4-6 student hackathon team using modular microservices.
• Hackathon vs Production Feasibility: Hackathon: High (using cached graph snippets + RPCs) | Production: High (scalable via Graph DB and full node RPCs) [INFERENCE].

10. Recommended Approach & Why

Selection

Approach 3: Hybrid Automated Multi-Chain Graph Explorer with Heuristic Clustering & FIU-VASP Attribution Engine is selected [INFERENCE].

Justification & Rejection of Alternatives

• Why Approach 1 was rejected: Simple static lookup cannot unmask modern cyber fraud techniques. Scammers rarely deposit funds directly into central exchange hot wallets; they use unique one-time user deposit addresses generated by exchange APIs [PS, RESEARCHED]. Without heuristic clustering (linking deposit addresses to parent exchange wallets), Approach 1 misses >80% of targets [INFERENCE].
• Why Approach 2 was rejected: Pure GNN models are black-box predictors. In criminal investigations and court proceedings, LEAs require deterministic evidence (exact transaction hashes, block numbers, address ownership proofs) admissible under Bharatiya Sakshya Adhiniyam (BSA) [KNOWN, INFERENCE]. A GNN alone cannot provide legally verifiable exchange identification [INFERENCE].
• Why Approach 3 Wins: It provides deterministic mathematical proof when a wallet links to a VASP deposit cluster, uses heuristics to trace through intermediary burner wallets, employs lightweight ML for risk categorization [PS], and generates compliant legal documentation ready for SAHYOG platform dispatch [PS, INFERENCE].

11. Technical Architecture

==================================================================================================
                              REAL-TIME CRYPTO FRAUD ATTRIBUTION SYSTEM (RTCFAS)
==================================================================================================

 [ EXTERNAL INGESTION LAYER ]
 +-----------------------------------+     +-----------------------------------+
 |   NCRP Portal / 1930 Webhook API  |     |   Manual LEA CSV/Batch Ingestion   |
 +-----------------------------------+     +-----------------------------------+
                   |                                         |
                   +-------------------+---------------------+
                                       v
 [ API GATEWAY & QUEUE LAYER ]
 +-----------------------------------------------------------------------------------------------+
 | FastAPI Gateway / JWT Auth / Rate Limiter / Celery Task Queue (Redis Message Broker)           |
 +-----------------------------------------------------------------------------------------------+
                                       |
                   +-------------------+---------------------+
                   v                                         v
 [ FORENSIC GRAPH & TRACING ENGINE ]           [ HEURISTIC CLUSTERING ENGINE ]
 +-----------------------------------+         +-----------------------------------+
 | - Multi-Hop Traversal (BFS/DFS)   |         | - Co-Spend / Common Input (BTC)   |
 | - Multi-Chain Indexer (ETH, BTC,  | <-----> | - Change Address Detection        |
 |   TRX, SOL, BNB)                  |         | - Deposit Address Aggregation     |
 | - Cross-Chain Bridge Event Matcher|         | - Re-use & Multi-Sig Clustering   |
 +-----------------------------------+         +-----------------------------------+
                   |                                         |
                   +-------------------+---------------------+
                                       v
 [ ATTRIBUTION & AI ANALYTICS LAYER ]
 +-----------------------------------------------------------------------------------------------+
 | - VASP Master Registry (FIU-IND Registered vs Offshore Non-Compliant List)                    |
 | - OpenSanctions / OFAC Blacklist Matcher                                                     |
 | - XGBoost / PyTorch Geometric Risk Scoring Engine (Peel Chain & Mixer Pattern Detection)     |
 +-----------------------------------------------------------------------------------------------+
                                       |
                   +-------------------+---------------------+
                   v                                         v
 [ DATA & STORAGE LAYER ]                      [ OUTPUT & INTEGRATION LAYER ]
 +-----------------------------------+         +-----------------------------------+
 | - Memgraph / Neo4j Graph Database |         | - SAHYOG Platform API Dispatcher  |
 | - PostgreSQL (Incident & Audit)   |         | - Standardized PDF Dossier Gen    |
 | - Redis (RPC Response Cache)      |         | - Interactive Cytoscape UI Dashboard|
 +-----------------------------------+         +-----------------------------------+
==================================================================================================

Step-by-Step Data Flow Narrative [INFERENCE]

1. Ingestion: A fraud complaint logged on NCRP triggers a JSON payload containing the victim's transaction hash, suspect wallet address (e.g., 0x71C... or T9z...), token type (e.g., USDT, BTC), scammed amount, and incident timestamp [PS].
2. Queueing & Fetching: FastAPI pushes the job to Celery/Redis. The ingestion service queries public RPCs (Alchemy/TronGrid) or cached blockchain nodes to fetch the transaction tree [INFERENCE].
3. Graph Traversal & Clustering: The Graph Engine initiates a $k$-hop Breadth-First Search (BFS). If an intermediary wallet splits funds (Peel Chain), the Heuristic Module evaluates co-spending and deposit patterns to cluster sibling addresses into a single entity [RESEARCHED, INFERENCE].
4. VASP Matching: At each node, the address is checked against the VASP Master Registry. If an address matches a known exchange deposit pool (e.g., Binance USDT Deposit Contract or CoinDCX Deposit Wallet), the traversal halts and flags the VASP [PS, INFERENCE].
5. AI Risk Scoring: The transaction topology (velocity, fan-out ratio, time intervals) is passed to the ML Risk Engine to calculate a Risk Score (0-100) and tag typologies (e.g., "Automated Layering via Mixer" or "Direct VASP Off-ramp") [PS, INFERENCE].
6. Alerting & Report Dispatch: The platform renders the interactive graph on the LEA dashboard, formats a Section 91/102 BNSS Freeze Notice PDF with cryptographic hashes, and prepares an API payload for the SAHYOG portal to notify the relevant exchange compliance officer [PS, INFERENCE, KNOWN].

12. Technology Stack

13. AI/ML Justification

Component 1: Wallet Risk Scoring & Fraud Typology Classifier

1. What exact problem does AI solve? Automatically categorizes suspect wallet behavior (e.g., Peel Chain, Mixer usage, High-velocity Layering, Mule Wallet) and assigns a composite Risk Score (0-100) to prioritize LEA investigations [PS, INFERENCE].
2. What is the input? Graph features: Out-degree, in-degree, average time delta between transactions, transaction value variance, ratio of round-value transfers, and cluster entropy [INFERENCE].
3. What is the output? Risk Score (0-100), Fraud Typology Tag (e.g., INVESTMENT_SCAM_LAYERING), and Confidence Level [PS, INFERENCE].
4. Why can a simpler rule/system not solve it? Cybercriminals continuously tweak transfer amounts and time delays to evade fixed threshold rules. An ML model detects subtle multi-variable topological patterns [INFERENCE].
5. What data is required? Historical labelled transaction graphs of known scammed addresses vs legitimate user wallets (synthesized/derived from public datasets like Elliptic Data Set / Ethereum Phishing Dataset) [RESEARCHED, ASSUMPTION].
6. How will it be evaluated? Precision, Recall, F1-Score, and ROC-AUC curve on held-out test transactions [INFERENCE].
7. What happens when it is wrong? False positives or false negatives do NOT block LEA action; the AI score serves purely as an investigative aid. The underlying deterministic transaction graph is always presented to the investigator [INFERENCE].
8. Does it require training? Yes (XGBoost / Random Forest on engineered graph features) [INFERENCE].
9. Does it require fine-tuning? No deep fine-tuning required for standard tree models [INFERENCE].
10. Does it require RAG? No [INFERENCE].
11. Does it require computer vision? No [INFERENCE].
12. Does it require speech processing? No [INFERENCE].
13. Does it require forecasting? No [INFERENCE].
14. Is human oversight required? YES. Law Enforcement Officers must review and validate the findings before issuing legal freeze orders [PS, INFERENCE].

Areas Where AI Should NOT Be Used [INFERENCE]

• VASP Identification: Determining whether an address belongs to a specific exchange MUST rely on deterministic address matching, deposit contract heuristics, and verifiable on-chain logs—NOT AI prediction [INFERENCE].
• Legal Notice Generation: Legal freeze notices under Section 91/102 BNSS must be generated from exact database records and cryptographic proofs, not generative AI models [INFERENCE, KNOWN].

14. Data Architecture & Offline/Low-Network Design

Database Schema Highlights [INFERENCE]

+---------------------------------------------------------------------------------+
|                                 POSTGRESQL SCHEMA                               |
+---------------------------------------------------------------------------------+
| TABLE: incidents                                                                |
|   - incident_id (UUID, PK)                                                      |
|   - ncrp_ack_no (VARCHAR, UNIQUE)                                               |
|   - victim_wallet_address (VARCHAR)                                             |
|   - suspect_wallet_address (VARCHAR)                                             |
|   - chain_id (VARCHAR) -- 'BTC', 'ETH', 'TRX', 'SOL'                             |
|   - fraud_category (VARCHAR) -- 'INVESTMENT', 'TASK', 'SEXTORTION', etc.         |
|   - reported_amount_inr (NUMERIC)                                               |
|   - status (VARCHAR) -- 'PENDING', 'TRACED', 'NOTICE_SENT', 'FUNDS_FROZEN'      |
|   - created_at (TIMESTAMP)                                                      |
+---------------------------------------------------------------------------------+
| TABLE: vasp_registry                                                            |
|   - vasp_id (UUID, PK)                                                          |
|   - vasp_name (VARCHAR) -- e.g., 'CoinDCX', 'Binance', 'WazirX'                 |
|   - fiu_ind_status (VARCHAR) -- 'REGISTERED', 'NON_COMPLIANT_OFFSHORE'           |
|   - nodale_email (VARCHAR)                                                      |
|   - sahyog_entity_code (VARCHAR)                                                |
+---------------------------------------------------------------------------------+
| TABLE: address_attributions                                                     |
|   - address (VARCHAR, PK)                                                       |
|   - vasp_id (FK -> vasp_registry.vasp_id)                                       |
|   - label_type (VARCHAR) -- 'DEPOSIT_ADDRESS', 'HOT_WALLET', 'COLD_WALLET'       |
|   - confidence_score (FLOAT)                                                    |
+---------------------------------------------------------------------------------+

+---------------------------------------------------------------------------------+
|                               MEMGRAPH GRAPH SCHEMA                             |
+---------------------------------------------------------------------------------+
| NODES: (:Wallet {address: STRING, chain: STRING, is_vasp: BOOL, risk: FLOAT})   |
| NODES: (:VASP {name: STRING, fiu_status: STRING})                               |
| EDGES: (:Wallet)-[:TRANSFERRED {tx_hash: STRING, amount: FLOAT, timestamp: INT}]->(:Wallet) |
+---------------------------------------------------------------------------------+

Offline & Low-Network Resiliency Strategy [INFERENCE, ASSUMPTION]

1. Local Edge Cache: All queried block header data, transaction graphs, and resolved attribution labels are stored locally in Memgraph/Redis. Re-querying an existing target loads instantly without internet access [INFERENCE].
2. Bandwidth Reduction: The frontend requests optimized JSON graph representations (transmitting only node IDs and edge weights) rather than raw verbose blockchain transaction payloads, reducing bandwidth usage by >90% [INFERENCE].
3. PWA Local Storage: The LEA web interface caches compiled PDF reports and case notes in Browser IndexedDB for offline review in remote field locations [INFERENCE, ASSUMPTION].

15. Security, Privacy & Governance

1. Personal Identifiable Information (PII) Protection: Cybercrime victim names, phone numbers, and bank account details present in NCRP reports must be encrypted at rest (AES-256) and in transit (TLS 1.3) [KNOWN, INFERENCE].
2. Role-Based Access Control (RBAC):
   • Level 1 (Field Officer): Initiate trace, view visualization, export PDF dossier [INFERENCE].
   • Level 2 (Station In-Charge / Inspector): Approve and digitally sign Section 91/102 BNSS freeze notices dispatched to VASPs [KNOWN, INFERENCE].
   • Level 3 (I4C Admin): Manage VASP Master Registry, update attribution seeds, view aggregate cyber fraud analytics [PS, INFERENCE].
3. Chain of Custody & BSA 2023 Compliance: Under Section 63 of the Bharatiya Sakshya Adhiniyam (BSA) 2023, digital evidence generated by the platform must include SHA-256 checksums of raw RPC responses, system timestamps, and digital officer signatures to be admissible in court [KNOWN, INFERENCE].
4. Regulatory Validation & VASP Coordination: The system clearly tags VASPs as FIU-IND Registered or Non-Compliant Offshore Platform [KNOWN, RESEARCHED]. For non-compliant platforms, the system routes notice requests via I4C’s SAHYOG portal for URL/app takedown or ISP-level blocking under Section 79(3)(b) of the IT Act 2000 [RESEARCHED, KNOWN].

16. MVP Scope (Hackathon Build)

In Scope (MUST & SHOULD BUILD) [ASSUMPTION]

• Multi-Chain Tracing Core: Real-time tracing engine supporting Ethereum (ETH/USDT), TRON (TRX/USDT), and Bitcoin (BTC) using public RPCs/Explorers [PS, ASSUMPTION].
• Automated VASP Identification: Detection of destination Exchange Deposit Addresses and Hot Wallets for top Indian/International exchanges (e.g., Binance, CoinDCX, WazirX, KuCoin) [PS, ASSUMPTION].
• Heuristic Clustering Module: Implementation of Co-spend heuristic (UTXO) and Deposit Address Clustering (Account model) [PS, RESEARCHED].
• Interactive Visual Graph: React + Cytoscape interface rendering multi-hop transaction trees with color-coded risk nodes [PS].
• NCRP Data Simulator: Mock NCRP Complaint Ingestion UI allowing judges to enter a suspect address or upload JSON complaint files [PS, ASSUMPTION].
• Standardized Legal Dossier Export: 1-click PDF generation of court-ready forensic reports and pre-filled Section 91/102 BNSS notice forms [PS, KNOWN].
• AI Risk Categorization: Lightweight XGBoost model tagging high-risk layering patterns and calculating wallet risk scores [PS, INFERENCE].

Described Only / Out of Scope (DO NOT BUILD IN HACKATHON) [ASSUMPTION]

• Direct live production database write access to official I4C NCRP or SAHYOG enterprise servers (simulated via local REST webhooks) [KNOWN, ASSUMPTION].
• Full-node mainnet sync for 10+ obscure blockchains (Solana, Cardano, Monero) [ASSUMPTION].
• Hardware-level HSM digital signature integration for notice signing [INFERENCE].

17. Live Demo Simulation Plan

To present a compelling, fraud-proof demonstration during the SIH judging round without relying on volatile real-world mainnet state or gated government APIs:

1. Simulated NCRP Ingestion Feed:
   • Create an "NCRP Live Incident Trigger" module in the admin UI [ASSUMPTION].
   • Click "Simulate Incoming 1930 Fraud Report" to inject a realistic cyber fraud case (e.g., ₹15 Lakhs Investment Scam involving TRON USDT transfer) [PS, ASSUMPTION].
2. Real Mainnet / Testnet Live Tracing:
   • Input a pre-verified real-world transaction hash from Ethereum or TRON mainnet (e.g., a known scam address moving USDT to a Binance deposit address) [ASSUMPTION].
   • The platform executes live multi-hop BFS traversal via public Etherscan/TronGrid APIs in front of the judges, rendering the graph step-by-step in under 3 seconds [INFERENCE, ASSUMPTION].
3. Simulated SAHYOG VASP Dispatcher:
   • Show the automated detection of the receiving VASP (e.g., Binance / FIU-IND REID: VA00045558) [RESEARCHED, ASSUMPTION].
   • Click "Generate & Dispatch Freeze Order", showing the instant output of a court-ready PDF evidence package and simulated SAHYOG API transmission log [PS, INFERENCE].

18. Implementation Roadmap

Given the deadline of 30 September 2026 (approx. 25 days build sprint):

==================================================================================================
                               25-DAY HACKATHON IMPLEMENTATION ROADMAP
==================================================================================================

 [ PHASE 1: DATA ENRICHMENT & ARCHITECTURE ] (Days 1 - 5 | Sep 5 - Sep 9, 2026)
 - Build VASP Master Attribution Seed Database (500+ known exchange hot/cold/deposit addresses).
 - Set up FastAPI backend, PostgreSQL schema, and Memgraph graph database container.
 - Implement multi-chain RPC wrappers (Web3.py, Etherscan API, TronGrid API).

 [ PHASE 2: GRAPH FORENSICS & CLUSTERING ENGINE ] (Days 6 - 12 | Sep 10 - Sep 16, 2026)
 - Implement BFS/DFS recursive multi-hop graph traversal engine with configurable depth limit.
 - Build Heuristic Clustering Algorithms (UTXO Co-Spend & ETH/TRON Deposit Address Reuse).
 - Integrate ML Risk Classifier (XGBoost model trained on graph topological features).

 [ PHASE 3: FRONTEND UI & LEGAL REPORT GENERATOR ] (Days 13 - 18 | Sep 17 - Sep 22, 2026)
 - Build interactive Cytoscape.js Graph Visualization UI with node filtering & search.
 - Develop ReportLab PDF Generation Service for Section 91/102 BNSS Notice Dossiers.
 - Create Mock NCRP Ingestion Portal & SAHYOG API Dispatch Simulator.

 [ PHASE 4: SYSTEM INTEGRATION, TESTING & DEMO POLISH ] (Days 19 - 25 | Sep 23 - Sep 30, 2026)
 - Perform end-to-end integration testing using known real-world scam case studies.
 - Optimize graph traversal query latency (achieve < 3s query time using Redis caching).
 - Draft slide deck, record backup demo video, and finalize SIH submission dossier.
==================================================================================================

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon Phase

• Cloud & Hosting: ₹0 (Localhost deployment on student laptops using Docker Compose) [ASSUMPTION].
• API Costs: ₹0 (Free tiers of Etherscan, TronGrid, Alchemy, and OpenSanctions APIs) [RESEARCHED, ASSUMPTION].
• Database: Open-source Memgraph Community Edition + PostgreSQL [INFERENCE].

Production System Phase (State/National LEA Scale)

• Infrastructure: On-premise air-gapped Cloud Server cluster (e.g., MeghRaj / NIC Cloud) with 64-core CPU, 256GB RAM, NVMe Storage [KNOWN, INFERENCE].
• Blockchain Indexing Nodes: Dedicated self-hosted archive nodes for BTC, ETH, TRON (~$300 - $500/month in bandwidth/storage) [INFERENCE].
• Licensing: Open-source stack minimizes commercial software licensing fees [INFERENCE].

22. Differentiation

23. Future Scope

1. Zero-Knowledge & Privacy Coin Analytics: Integrate advanced statistical deanonymization heuristics for privacy-preserving coins (e.g., Zcash, Monero output ring analysis) [RESEARCHED].
2. Automated Mempool Monitoring: Intercept pending unconfirmed scammed transactions in the mempool to issue pre-execution freeze alerts [INFERENCE].
3. Darknet & Telegram Bot Scraper Integration: Automatically scrape darknet marketplaces and illicit Telegram channels to continuously feed fresh wallet labels into the VASP Registry [PS, RESEARCHED].

24. Assumptions & Open Items Log

Consolidated Assumptions [ASSUMPTION]

• [ASS-01] Public RPC endpoints (Etherscan, TronGrid, Alchemy) will provide sufficient uptime and rate limits during the hackathon demo [ASSUMPTION].
• [ASS-02] A static seed database of 500+ top exchange hot/cold/deposit addresses is sufficient to demonstrate multi-VASP identification [ASSUMPTION].
• [ASS-03] Synthetic NCRP JSON complaint payloads can accurately simulate real-world victim reporting fields [ASSUMPTION].

Open Items Needing Validation [NEEDS VALIDATION]

• [VAL-01] Exact API payload specifications and authentication protocols for official I4C SAHYOG portal integration [NEEDS VALIDATION].
• [VAL-02] Court admissibility standards across different State High Courts regarding open-source graph clustering evidence under BSA 2023 Section 63 [NEEDS VALIDATION].

Final Decision & Ending Summary

Final Recommendation

Adopt Approach 3 (Hybrid Automated Graph Explorer with Heuristic Clustering & FIU-VASP Attribution Engine). Build a modular FastAPI + Memgraph + React stack focused on Ethereum (USDT), TRON (USDT), and Bitcoin [INFERENCE, ASSUMPTION].

Recommended Stack

• Frontend: React.js, Tailwind CSS, Cytoscape.js [INFERENCE].
• Backend: Python FastAPI, Celery, Redis [INFERENCE].
• Databases: Memgraph (In-Memory Graph DB), PostgreSQL (Relational Data) [INFERENCE].
• Analytics/ML: PyTorch Geometric, XGBoost, Web3.py, Etherscan/TronGrid APIs [RESEARCHED, INFERENCE].

Key Parameters

• Biggest Dependency: Reliability and rate limits of blockchain data RPC APIs during live testing/demo [INFERENCE, ASSUMPTION].
• Biggest Risk: Obfuscation via cross-chain DEX swaps or unlabelled mixing protocols breaking automated graph continuity [PS, INFERENCE].
• Biggest Technical Challenge: Performing sub-second multi-hop graph traversal while accurately clustering deposit addresses on account-based blockchains (TRON/Ethereum) [RESEARCHED, INFERENCE].

First 5 Actions

1. Spin up Docker container environment with Memgraph and PostgreSQL [INFERENCE].
2. Ingest public wallet attribution seed lists (WalletExplorer, Etherscan labels, GraphSense tags) into PostgreSQL [RESEARCHED, INFERENCE].
3. Implement Web3/RPC wrapper services for TRON (TronGrid) and Ethereum (Etherscan/Alchemy) [RESEARCHED, INFERENCE].
4. Write BFS multi-hop graph traversal engine in Python with Redis caching [INFERENCE].
5. Build React + Cytoscape graph visualizer UI and ReportLab Section 91/102 BNSS PDF notice generator [INFERENCE, KNOWN].

Validation Before Coding

• Verify public RPC API key rate limits for Etherscan and TronGrid [RESEARCHED, ASSUMPTION].
• Test Cytoscape.js rendering performance with a 500-node mock graph in browser [INFERENCE].

Final Scores

• Buildability Score: 88 / 100 (Highly feasible for a skilled 4-6 student team in 25 days using open-source tools) [INFERENCE].
• Confidence: HIGH [INFERENCE].

Research Sources