DEV Community

Cover image for My Experience at Innohacks 4.0
Vedant Gupta
Vedant Gupta

Posted on

My Experience at Innohacks 4.0

#mlhacks #devchallenge #hackathon

This is a submission for the MLH x DEV Writing Challenge

What I Built

CryptoTracker (Sentinel) is a real-time Web3 forensics platform that follows stolen or scammed crypto from a suspect wallet to the exchange where it gets cashed out. It was built by Team Heisenbugs: me, Anshu Tyagi, Saksham Mittal and Priyanshu Arora.

Crypto fraud moves fast. Funds get split across dozens of wallets, passed through mixers, and cashed out before anyone has mapped the trail. We wanted a tool that makes that trail visible in minutes instead of hours of manual block-explorer digging.

Sentinel can:

  • Trace funds automatically. A BFS crawl over live Etherscan data builds a wallet graph in Neo4j and follows multi-hop splits.
  • Score contamination. A forward "haircut" taint model gives decayed risk scores, so risk officers get an objective threshold instead of a gut call.
  • Avoid false alarms. Dust filtering and volume-weighted decay stop attackers from "poisoning" innocent merchants with micro-transactions.
  • Spot laundering patterns. Stricter peel-chain detection plus a LightGBM fraud model flag suspicious behaviour.
  • Find the off-ramp. Entity resolution identifies exchanges, mixers and bridges, so investigators can see exactly where funds were cashed out.
  • Answer questions in plain English. A GraphRAG layer lets investigators ask questions without writing Cypher, and links off-chain threat intel (exploit reports, group attributions) to on-chain wallets.

It's useful for exchange deposit screening (KYT/AML), DeFi post-hack incident response, helping scam victims document where their funds went, and counterparty risk checks for institutional desks.

What I learned: most of our pain wasn't in the ML, it was in graph traversal.

  • Neo4j connection. Our API kept crashing with a routing error because we used the neo4j:// URI against a single local instance. The driver kept asking for a cluster routing table that didn't exist. Switching to bolt:// fixed it.
  • Supernodes. Our first crawler happily followed laundered funds into a major exchange hot wallet, then tried to pull in thousands of unrelated withdrawals. That burned our Etherscan rate limits and turned the graph into a hairball. The fix was circuit breakers: anything labeled as an exchange, mixer or bridge stops the crawl but is still recorded as an off-ramp.
  • False positives. Ordinary wallets that split a payment into three or four normal transfers were scoring above 70/100 for risk. Dust filtering and tighter peel-chain rules (low fan-out, 70-99.5% of volume to the main branch) fixed that.
  • Address casing. 0xAbC... and 0xabc... look like two different wallets to a database. Normalizing every address before the Cypher MERGE is what let threat intel attach to the right nodes.

Demo

Partner Technologies

We entered three MLH partner tracks:

Google Gemini API. Gemini powers the intelligent parts of Sentinel across several modules, including the GraphRAG layer that turns plain-English questions into graph queries and summarizes threat intel for investigators. [Add one or two specifics: which model, what prompts or tasks, and what surprised you.]

DigitalOcean. We used DigitalOcean's cloud infrastructure to run the backend for blockchain monitoring. [Add specifics: Droplets or App Platform, how you deployed, anything you'd do differently.]

Solana. [Add how you used it, or remove this paragraph if it was only a track submission.]

Beyond the partners, the core stack was FastAPI, Neo4j, NetworkX, LightGBM, React and TypeScript.

Hackathon Experience

We built CryptoTracker at InnoHacks 4.0, Innogeeks' flagship 24-hour national hackathon at KIET Deemed to be University, Ghaziabad (Oct 10-11, 2026).

It was a really great experience. The Innogeeks team were genuinely supportive from start to finish, and the whole event ran smoothly. The mentors were approachable and gave useful feedback when we were stuck. The judges were kind and engaged, asking real questions about our design choices instead of just ticking boxes.

The night was one of my favourite parts. Somewhere in the middle of the 24 hours, when everyone's eyes were a bit glazed from staring at screens, the organizers put together a fun session with music and dance performances. It was exactly the break we needed. For a little while nobody was thinking about bugs or deadlines, and the whole hall was cheering, laughing and recharging together. We went back to our laptops with a lot more energy than we left with.

The arrangements were also better than I expected from a hackathon. The food was properly organized, so we never had to choose between eating and debugging, and there was a dedicated sleeping area for anyone who needed to rest. It's a small thing, but it showed how much thought the Innogeeks team put into looking after the participants.

Twenty-four hours with three teammates teaches you a lot about splitting work and fixing things under pressure. I'll remember the late-night Neo4j debugging, and the moment the wallet graph finally traced a full path to an exchange off-ramp.

Huge thanks to Innogeeks, the mentors, the judges and my teammates. 🙌

Top comments (0)