HACKATHON 2026

Problem Statements

4 Tracks · 20 Problem Statements · 36 Hours

Track 1: Machine Learning & AI

Track 2: Web3 & Blockchain
Track 3: DevOps & Cloud Infrastructure
Track 4: Web Development
🤖 Track 1: Machine Learning & AI
 Problem Statement 1.1

GreenSync
Real-Time Energy Demand Forecaster for Microgrids

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Machine Learning & AI

Background & Context

Urban areas worldwide are rapidly shifting toward renewable energy microgrids that blend solar panels,
wind turbines, and battery storage. Unlike traditional power grids, microgrids must constantly balance a
volatile supply (which depends on weather) with fluctuating consumer demand. A sudden cloud cover can
drop solar output by 60% within minutes. If grid operators cannot anticipate demand spikes or generation
dips in advance, the result is either a blackout or costly emergency power purchases from the national
grid.
Current microgrid systems rely on static thresholds and rule-based controls. There is no predictive
intelligence that can tell operators "expect a 40% demand surge in the next two hours" and automatically
recommend switching from battery to grid power.

Problem Statement
Build GreenSync — a machine learning-powered energy demand forecaster that ingests historical
electricity usage data alongside live weather API feeds to predict energy needs for the next 6 hours. The
system should help microgrid operators make real-time switching decisions between solar, battery, and
grid power sources, reducing waste and preventing blackouts.

Core Requirements
1. Data Ingestion & Processing
• Ingest historical electricity usage time-series data (CSV upload or simulated)
• Integrate a live weather API (OpenWeatherMap, [Link], or similar) for temperature, cloud
cover, wind speed, and humidity
• Preprocess and normalize data with a reproducible pipeline
• Handle missing values and outliers gracefully
2. Predictive Model
• Train a forecasting model (LSTM, XGBoost, ARIMA, or Prophet) to predict energy demand for
the next 6-hour window
• Achieve a Mean Absolute Percentage Error (MAPE) of under 15% on test data
• Retrain or fine-tune the model when new data arrives
3. Optimization Engine
• Build an algorithm that recommends whether to draw from solar, battery, or grid power for each
hour in the forecast window
• Factor in battery charge level, current solar output, and predicted demand
• Flag periods of peak demand and estimated shortfall
4. Dashboard & Visualization
• Display a live chart of predicted vs. actual energy load
 • Add cost-optimization mode that factors in time-of-use electricity tariffs

• Deploy as a containerized microservice with a REST API for external integrations

• Add multi-microgrid support — aggregate and compare forecasts across several zones
• Show a colour-coded 6-hour outlook (safe / warning / critical)
• Provide downloadable forecast report in CSV or PDF format
Suggested Tech Stack
Bonus Challenges (Optional)
Category Recommended Options
•Implement anomaly detection to flag unusual demand spikes not explained by weather
ML Framework scikit-learn, TensorFlow/Keras, PyTorch, Facebook Prophet,
statsmodels
• Add cost-optimization mode that factors in time-of-use electricity tariffs
Data Processing Pandas, NumPy, Apache Kafka (optional streaming)
• Deploy as a containerized microservice with a REST API for external integrations
Weather API OpenWeatherMap API, [Link], Open-Meteo
• Add multi-microgrid support — aggregate and compare forecasts across several zones
Backend FastAPI, Flask, Django REST Framework
Frontend / Viz React + Recharts, Streamlit, Grafana, Plotly Dash
Suggested
Database Tech Stack TimescaleDB, InfluxDB, SQLite, PostgreSQL
Deployment
Category Docker, Heroku, Render, AWS EC2 freeOptions
Recommended tier

ML Framework scikit-learn, TensorFlow/Keras, PyTorch, Facebook Prophet,

statsmodels
Evaluation Criteria
Data Processing Pandas, NumPy, Apache Kafka (optional streaming)
Criterion
Weather API Weight
OpenWeatherMap API, [Link], Open-Meteo Max Points
Model Accuracy (MAPE, RMSEFastAPI,
Backend on test set) 30%
Flask, Django REST Framework 30
Dashboard Quality & Usability React + Recharts, Streamlit, Grafana,25%
Frontend / Viz Plotly Dash 25
Optimization
Database Logic & Recommendation QualityInfluxDB, SQLite, PostgreSQL
TimescaleDB, 20% 20
Data Pipeline Robustness
Deployment 15%tier
Docker, Heroku, Render, AWS EC2 free 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Model Accuracy (MAPE, RMSE on test set) 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
Dashboard Quality & Usability 25% 25
• Full pipeline
Optimization demo: ShowingQuality
Logic & Recommendation all required components functioning
20% end-to-end20

Data Pipeline Robustness 15% 15

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 1.2

Legal-Ease
AI Contract Analyzer for Regional Indian Languages

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Machine Learning & AI

Background & Context

Millions of small business owners and self-employed individuals in India sign complex legal contracts
every day — rental agreements, vendor contracts, service agreements, employment bonds — often
without truly understanding the terms. Most contracts are drafted in dense legal English full of Latin
phrases and convoluted clauses. For non-English-speaking entrepreneurs in tier-2 and tier-3 cities, this is
not a comprehension challenge; it is a legal and financial risk.
A hidden "auto-renewal" clause, an uncapped liability clause, or a one-sided termination right buried in
page 12 can cost a small business owner thousands of rupees — or their business entirely. Legal advice
is expensive, and free legal aid is inaccessible to most.

Problem Statement
Build Legal-Ease — an LLM-powered contract analysis tool that allows users to upload any contract (PDF
or plain text) and receive a simplified plain-language summary in Hindi, Tamil, or Telugu, along with a
highlighted list of risky or unfair clauses, each annotated with a severity score and a human-readable
explanation of the real-world risk.

Core Requirements
1. Document Ingestion
• Accept PDF and plain-text contract uploads
• Parse and extract text accurately, preserving clause structure
• Handle scanned PDFs via OCR (Tesseract or Google Cloud Vision)
2. LLM-Powered Analysis
• Integrate an LLM (GPT-4, Gemini, Claude, or open-source Llama 3) to simplify legal language
• Summarize each clause in plain, conversational language
• Detect red-flag clauses: hidden fees, unlimited liability, unfair termination, auto-renewal, data
sharing, non-compete, and penalty clauses
• Assign each flagged clause a severity level: Low, Medium, or High
3. Multi-Language Output
• Translate the simplified summary and clause explanations into at least one of: Hindi,
Tamil, or Telugu
• Ensure translations are natural and contextually accurate, not word-for-word
• Allow the user to select their preferred language from a dropdown
4. Report Generation
• Generate a downloadable summary report (PDF or DOCX) containing the simplified contract,
flagged clauses, and their risk scores
• Provide a visual risk dashboard: a pie chart of Low / Medium / High clauses
 • Add a chatbot interface where users can ask follow-up questions about specific clauses

• Support additional Indian languages: Marathi, Bengali, Kannada, or Gujarati

Bonus Challenges (Optional)

Suggested Tech Stack
• Context-aware warnings: instead of "liability clause found," say "If something goes wrong,
Category
you Recommended
may owe the other party an unlimited amount Options
of money with no cap"
LLM• OpenAI GPT-4o,
Implement clause comparison: highlightGoogle
how a Gemini, Anthropicfrom
clause deviates Claude API, Llama
standard 3 via
industry
templates Ollama
OCR Tesseract, Google Cloud Vision API, AWS Textract
• Add a chatbot interface where users can ask follow-up questions about specific clauses
PDF Parsing PyMuPDF, pdfplumber, PDFMiner
• Support additional Indian languages: Marathi, Bengali, Kannada, or Gujarati
Translation Google Translate API, IndicTrans2, AI4Bharat models
Backend FastAPI, Flask
Suggested
Frontend Tech Stack React, [Link], Streamlit
Report Generation
Category ReportLab, python-docx, WeasyPrint Options
Recommended
LLM OpenAI GPT-4o, Google Gemini, Anthropic Claude API, Llama 3 via
Ollama
Evaluation
OCR Criteria Tesseract, Google Cloud Vision API, AWS Textract
Criterion
PDF Parsing PyMuPDF, pdfplumber, PDFMiner Weight Max Points
Clause Detection Accuracy & Relevance
Translation 30%
Google Translate API, IndicTrans2, AI4Bharat models 30
Translation
Backend Quality & LanguageFastAPI,
Naturalness
Flask 25% 25
UI/UX & Report Usability
Frontend React, [Link], Streamlit 20% 20
Red Flag
Report Coverage & Severity Scoring
Generation Logic
ReportLab, python-docx, WeasyPrint15% 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Clause Detection Accuracy & Relevance 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demoQuality & Language Naturalness
Translation 25% 25
• &
UI/UX Full pipeline
Report demo: Showing all required components functioning
Usability 20% end-to-end20

Red Flag Coverage & Severity Scoring Logic 15% 15

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 1.3

DisasterScout
Satellite Imagery Change Detection for Disaster Response

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Machine Learning & AI

Background & Context

When a natural disaster strikes — a flood, earthquake, or landslide — the first 72 hours are critical.
Rescue teams need to know: Which roads are blocked? Which buildings have collapsed? Which areas
are still submerged? Traditionally, field surveyors and aerial reconnaissance gather this information
manually, a process that takes days and puts human lives at risk.
Satellite imagery offers a near-instant, birds-eye view of affected areas — but the volume of data is
enormous. A single satellite pass over a flood zone can generate gigabytes of high-resolution tiles.
Without automated analysis, human analysts are overwhelmed, and critical information is delayed.

Problem Statement
Build DisasterScout — a computer vision system that ingests pairs of pre-disaster and post-disaster
satellite image tiles and automatically segments and highlights: flooded areas, collapsed or damaged
buildings, blocked roads, and changed terrain. The output should be a visual damage assessment map
that rescue coordinators can act on immediately.

Core Requirements
1. Image Ingestion & Pre-processing
• Accept pairs of before/after satellite image tiles (JPEG/PNG/GeoTIFF)
• Align images to account for slight shifts in satellite position (image registration)
• Normalize color channels and handle different lighting/weather conditions
2. Change Detection Model
• Implement a semantic segmentation or change-detection model (U-Net, DeepLabV3+, Siamese
CNN, or similar)
• Classify changed pixels into at least three categories: flooded areas, structural damage,
blocked roads
• Use a pre-trained backbone (ResNet, EfficientNet) and fine-tune on disaster imagery datasets
(Copernicus EMS, xBD, or SpaceNet)
3. Visualization & Assessment Map
• Generate an overlay map highlighting affected regions in distinct colors per damage type
• Calculate and display affected area statistics: estimated sq. km flooded, number of buildings
flagged
• Provide a confidence score per segment
4. Rescue-Ready Output
• Export the annotated map as a PNG or GeoJSON file suitable for GIS tools
• Present a sortable table of affected locations with coordinates, damage type, and severity
 • Build an API endpoint that accepts a location bounding box and returns a damage
assessment automatically

• Add a severity scoring system: calculate a composite disaster impact score per grid tile

Bonus Challenges (Optional)

Suggested Tech
• Integrate withStack
OpenStreetMap to overlay road network data and flag blocked road
segments by name
Category Recommended Options
• Implement a time-series slider showing progression of flooding or damage across multiple
Deep Learning
satellite passes PyTorch, TensorFlow/Keras, segmentation-models-pytorch
Computer Vision OpenCV, Albumentations (augmentation), GDAL (GeoTIFF)
• Build an API endpoint that accepts a location bounding box and returns a damage
assessment automatically
Datasets xBD Disaster Dataset, Copernicus EMS, SpaceNet, Sentinel-2 (free)
• Add a severity scoring Folium,
Visualization system:[Link],
calculateMatplotlib,
a composite disaster impact score per grid tile
Plotly
Backend FastAPI, Flask
Frontend React + Leaflet, Streamlit
Suggested Tech Stack
Deployment Docker, Google Colab (training), Hugging Face Spaces
Category Recommended Options
Deep Learning PyTorch, TensorFlow/Keras, segmentation-models-pytorch
Evaluation Criteria
Computer Vision OpenCV, Albumentations (augmentation), GDAL (GeoTIFF)
Criterion
Datasets Weight
xBD Disaster Dataset, Copernicus EMS, Max Points
SpaceNet, Sentinel-2 (free)
Segmentation
Visualization Accuracy (IoU, F1Folium,
on damage categories)
[Link], Matplotlib, Plotly 30% 30
Visualization
Backend Quality & Rescue Utility
FastAPI, Flask 25% 25
Data Pipeline & Pre-processing React
Frontend Robustness
+ Leaflet, Streamlit 20% 20
Output Export & Usability for GIS
Deployment Tools Google Colab (training), Hugging
Docker, 15% Face Spaces 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Segmentation Accuracy (IoU, F1 on damage categories) 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo Quality & Rescue Utility
Visualization 25% 25
• Full pipeline demo: Showing all
Data Pipeline & Pre-processing Robustness required components functioning
20% end-to-end20
Output Export & Usability for GIS Tools 15% 15
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 1.4

Log-Whisperer
AI-Driven Real-Time Log Anomaly & Root Cause Detector

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Machine Learning & AI

Background & Context

When a production system crashes, the clock is ticking. Every minute of downtime costs revenue, erodes
user trust, and piles pressure on on-call engineers. The first task in any incident — finding the root cause
— is also the hardest. A typical microservices application generates millions of log lines per hour.
Engineers spend hours scrolling through log files, running regex searches, and correlating events across
services, often while the system is still degraded.
The pattern that caused the crash is almost always in the logs — buried under thousands of routine INFO
messages. The question is: can a machine find it faster than a human?

Problem Statement
Build Log-Whisperer — a tool that ingests system logs in real time (or from uploaded log files), uses ML-
based anomaly detection and pattern matching to identify unusual sequences of events, and immediately
after a system failure, surfaces a concise "Crash Report" that pinpoints the root cause, the first anomalous
signal, and a recommended fix.

Core Requirements
1. Log Ingestion
• Accept log input via file upload (plain text, JSON), a simulated real-time stream, or Kafka topic
(optional)
• Parse common log formats: Apache, Nginx, syslog, structured JSON logs, Spring Boot logs
• Support at least 10,000 log lines per second in the processing pipeline
2. Anomaly Detection
• Implement anomaly detection using a statistical or ML approach: log clustering, Isolation
Forest, LSTM-based sequence anomaly, or regex + frequency analysis
• Flag error bursts, unexpected log sequences, missing heartbeat messages, and sudden spikes
in log volume
• Assign an anomaly score (0–100) per log event cluster
3. Root Cause Analysis
• After a crash or error spike is detected, generate a structured Crash Report containing:
the first anomalous event, the probable root cause, affected services/components, and a
timeline of events leading to the failure
• Use an LLM (optional but encouraged) to generate a human-readable explanation of the root
cause
4. Dashboard & Alerting
• Provide a real-time log monitoring dashboard with a live anomaly feed
• Send alerts (email, Slack webhook, or on-screen notification) when an anomaly score exceeds
the threshold
 incidents and surface past resolutions

• Add a natural-language query interface: "Show me all database timeout errors in the last
hour"
• • Display a searchable,
Implement filterablewarn
predictive alerting: log viewer with anomalous
5–10 minutes entries
before a likely highlighted
crash based on trend
analysis
Bonus Challenges (Optional)
• Integrate with ELK Stack (Elasticsearch, Logstash, Kibana) for enterprise-grade log
Suggested Tech
storage Stack
and search

• Build a "similar incidents" feature: compare the

Category current crashOptions
Recommended pattern with historical
incidents and surface past resolutions
ML / Anomaly Detection scikit-learn (Isolation Forest, DBSCAN), Drain3 (log parsing), PyOD
• Add a natural-language query interface: "Show me all database timeout errors in the last
LLM (Optional) OpenAI GPT-4o, Ollama + Llama 3, Anthropic Claude API
hour"
Log Parsing Logparser, Drain3, Python re module, Loki
• Implement predictive alerting: warn 5–10 minutes before a likely crash based on trend
analysis
Streaming Apache Kafka, Redis Streams, Python asyncio
Backend FastAPI, Flask
Frontend React, Grafana (dashboarding), Streamlit
Suggested Tech Stack
Database Elasticsearch, SQLite, InfluxDB
Category Recommended Options
ML / Anomaly Detection scikit-learn (Isolation Forest, DBSCAN), Drain3 (log parsing), PyOD
Evaluation Criteria
LLM (Optional) OpenAI GPT-4o, Ollama + Llama 3, Anthropic Claude API
Criterion
Log Parsing Weight
Logparser, Drain3, Python re module, Loki Max Points
Detection
StreamingAccuracy & Anomaly Apache
Scoring Quality 30%
Kafka, Redis Streams, Python asyncio 30
Crash Report Clarity & Actionability
Backend FastAPI, Flask 25% 25
Real-Time
Frontend Processing & Pipeline Performance
React, 20%
Grafana (dashboarding), Streamlit 20
Dashboard
Database Usability & Alert Design
Elasticsearch, SQLite, InfluxDB 15% 15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Detection Accuracy & Anomaly Scoring Quality 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo Clarity & Actionability
Crash Report 25% 25
• Full pipeline demo: Showing all required
Real-Time Processing & Pipeline Performance components functioning
20% end-to-end20
Dashboard Usability & Alert Design 15% 15
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 1.1
1.5

GreenSync
AgentHub
Real-Time Energy Demand
AI Agents Forecaster
Discovery for Microgrids
Platform
⏱ Duration 👥 Level 📦 Deliverable 🏆 Track
36 Hours Intermediate Any Format Machine Learning & AI

Background & Context

Background
The AI ecosystem & is
Context
growing at an unprecedented pace — thousands of AI agents are being
built by developers every
Urban areas worldwide are day, ranging
rapidly fromtoward
shifting codingrenewable
assistants energy
and research summarisers
microgrids that blend solar panels,
to customer
wind service
turbines, bots and
and battery creative
storage. generators.
Unlike Yetpower
traditional there grids,
is no centralised
microgrids platform
must constantly balance a
where
volatilethese
supplyagents
(whichcan be discovered,
depends on weather)compared, and accessed.
with fluctuating consumer Developers
demand. A publish
suddentheir
cloud cover can
agents across GitHub repositories, personal websites, and social media — making
drop solar output by 60% within minutes. If grid operators cannot anticipate demand spikes or generation
discovery fragmented,
dips in advance, time-consuming,
the result and largely
is either a blackout a matter
or costly of chance.
emergency power purchases from the national
grid.
A structured discovery platform — purpose-built for AI agents — can transform how
Current
developers microgrid systems
share their work rely on static
and how usersthresholds and
find the right rule-based
tool. controls.
By providing a There is no predictive
intelligence that can tell operators "expect a 40% demand surge in the next two hours" and automatically
searchable, reviewable, and categorised marketplace, AgentHub creates a two-sided
recommend switching from battery to grid power.
ecosystem that benefits builders and end-users alike.
Problem Statement
Problem Statement
Build GreenSync — a machine learning-powered energy demand forecaster that ingests historical
electricity
Build usage —
AgentHub data alongside live weather
a marketplace-like APIplatform
discovery feeds to where
predictdevelopers
energy needscanfor
listthe next 6 hours. The
their
system
AI agentsshould help microgrid
with detailed operators
capability make real-time
descriptions, and usersswitching decisions
can search, between solar, battery, and
filter, compare,
grid
and power
directlysources, reducing
interact with waste
available and preventing
agents. blackouts.
The platform should support agent ratings,
usage statistics, live demo invocations, and a structured tagging system that makes
Core
finding Requirements
the right AI agent for any task effortless.
1. Data Ingestion & Processing
Core Requirements
• Ingest historical electricity usage time-series data (CSV upload or simulated)
• Integrate a live weather API (OpenWeatherMap, [Link], or similar) for temperature, cloud
1. Agent Listing & Submission
cover, wind speed, and humidity
•• Allow developers
Preprocess to submitdata
and normalize agent listings
with with: agentpipeline
a reproducible name, one-line tagline, full
description, capability tags (e.g. coding,
• Handle missing values and outliers gracefully research, writing, data analysis),
input/output format, an integration endpoint or API URL, and a sample usage example
2. Predictive
• SupportModel
multiple agent categories: Productivity, Development, Research, Creative, Data
• Train a forecasting
Analysis, and Custom model (LSTM,
— each XGBoost,
browsable on ARIMA, or Prophet)
a dedicated topage
category predict energy demand for
• the next 6-hour
Validate window
submissions to ensure all required fields are present; flag and reject
• Achieve
duplicate listings Absolute
a Mean Percentage
with the same name or Error (MAPE)
endpoint URLof under 15% on test data
•• Retrain or fine-tune
Allow developers to the model
update when
their newmark
listing, dataanarrives
agent as deprecated, and respond to
user reviews
3. Optimization Engine from a developer dashboard
• Build
2. Search & an algorithm that recommends whether to draw from solar, battery, or grid power for each
Discovery
hour in the forecast window
• Implement full-text search across agent names, descriptions, and capability tags with
• Factor in battery
near-instant charge
results (< 300level,
ms current solar
response output, and predicted demand
time)
•• Flag periods
Provide of peak
faceted demand
filtering and estimated
by: category, shortfall
capability tags, minimum star rating, usage
count range, and
4. Dashboard & Visualization date added (last 7 days / 30 days / all time)
•• Display
Display search results
a live chart ranked byvs.
of predicted a composite score
actual energy of relevance, average rating, and
load
usage count; allow users to switch ranking to Newest or Most Used
• Show a Featured Agents carousel and a Trending This Week section on the homepage,
updated daily based on invocation counts and rating momentum
Bonus Challenges (Optional)

• Build an Agent Comparison Tool: users can select up to 3 agents side by side to
compare capabilities, star ratings, response latency, and pricing/access model

• Implement API Key Management for developers: generate, rotate, and revoke API keys
from the developer dashboard; display per-key usage analytics

• Add a Collections feature: authenticated users can curate and share themed agent
collections (e.g. 'Best agents for academic research') with a public shareable URL

• Integrate an Agent Health Monitoring dashboard showing uptime percentage, average

latency trend over 30 days, and incident history for each listed agent

Suggested Tech Stack

Category Recommended Options

Frontend React / [Link], TailwindCSS, Algolia InstantSearch or
Typesense

Backend [Link] + Express, FastAPI (Python)

Search Algolia, Typesense, or PostgreSQL full-text search

Database PostgreSQL, Redis (session / rate limiting)

Auth Clerk, Firebase Auth, or Auth0

Agent Invocation REST API calls, LangChain (optional agent orchestration)

Deployment Vercel, Render, or AWS EC2 free tier

What to Deliver

Teams may submit any of the following (or a combination):

• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview,
and key design decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
⛓ Track 2: Web3 & Blockchain
 Problem Statement 2.1

InsuChain
Parametric Weather Insurance for Farmers on the Blockchain

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web3 & Blockchain

Background & Context

Agricultural insurance is a lifeline for farmers facing droughts, unseasonal floods, and climate volatility —
but traditional insurance is notoriously slow. After a drought or flood, farmers file claims, surveyors assess
crop damage, and insurance companies deliberate. Payouts can take months — long after seeds need to
be replanted, loans become due, and families go hungry.
Parametric insurance replaces subjective damage assessment with objective, measurable triggers. If
rainfall falls below a threshold for a defined period, a payout is automatically triggered — no paperwork,
no surveyor, no waiting. Blockchain and decentralized oracles make this model transparent, tamper-
proof, and instant.

Problem Statement
Build InsuChain — a decentralized application (dApp) where farmers can purchase parametric weather
insurance policies. Smart contracts automatically monitor on-chain weather data fed by Chainlink oracles,
and instantly release insurance payouts to farmer wallets if weather conditions (such as rainfall below
5mm in a 30-day period) breach predefined thresholds.

Core Requirements
1. Smart Contract Core
• Write a Solidity smart contract for policy creation, premium collection, and automatic payout
• Define parametric triggers: rainfall threshold, temperature extremes, or wind speed thresholds
• Implement a policy escrow: premiums are pooled and released on trigger or refunded on
expiry
• Emit events for all state changes (policy created, triggered, paid out)
2. Oracle Integration
• Integrate Chainlink Data Feeds or a mock oracle for weather data (rainfall, temperature)
• Demonstrate that the smart contract reads oracle data and evaluates trigger conditions
automatically
• Handle oracle downtime gracefully without locking funds permanently
3. Farmer-Facing dApp
• Build a web frontend where farmers can: browse available policy types, view trigger
conditions and premium amounts, purchase a policy by connecting a MetaMask wallet, and
track their active policies and payout status
4. Transparency Dashboard
• Display a public ledger of all active policies, trigger events, and payouts
• Show historical oracle data alongside trigger events for auditability

Bonus Challenges (Optional)

 • Deploy on a Layer-2 network (Polygon, Arbitrum) to reduce gas fees for farmers

Suggested Tech Stack

• Implement multi-parameter triggers: e.g., pay out only if both rainfall is low AND
Category exceeds 40°C
temperature Recommended Options
Smart
• Contracts Solidity,
Add reinsurance pooling: allowHardhat
externalorliquidity
Foundry, OpenZeppelin
providers to fund the insurance pool in
Oracle exchange for a premium share Data Feeds, Chainlink Any API, or mock oracle (Hardhat)
Chainlink
• Integration
Wallet Build a claim dispute mechanism using a DAO
MetaMask, [Link], vote
wagmi for edge cases
+ viem
• Deploy on a Layer-2 network
Frontend React +(Polygon, Arbitrum) to reduce gas fees for farmers
[Link], TailwindCSS
Testnet Ethereum Sepolia, Polygon Mumbai, Hardhat local node
Storage IPFS / Filecoin for policy documents, The Graph for indexing
Suggested Tech Stack
Category Recommended Options
Evaluation Criteria
Smart Contracts Solidity, Hardhat or Foundry, OpenZeppelin
Criterion
Oracle Weight
Chainlink Data Feeds, Chainlink Any Max
API, or mock oracle Points
(Hardhat)
Smart
WalletContract Logic & SecurityMetaMask, [Link], wagmi + viem 30%
Integration 30
Oracle Integration & Trigger Accuracy
Frontend React + [Link], TailwindCSS 25% 25
dApp UX & Wallet Flow
Testnet Ethereum Sepolia, Polygon Mumbai,20%
Hardhat local node 20
Transparency
Storage & Auditability IPFS / Filecoin for policy documents,15%
The Graph for indexing15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Smart Contract Logic & Security 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
Oracle demo
Integration & Trigger Accuracy 25% 25
• Full pipeline
dApp UX & Wallet Flow demo: Showing all required components functioning
20% end-to-end20
Transparency & Auditability 15% 15
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

Rules & Deliver

What to Constraints
• Team
Teams size: 2–4
may submit members
any of the following (or a combination):
•• All code must be version-controlled
Working prototype: A live or recorded in a demo
Git repository (publicinoraction
of the system shared with judges)
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 2.2

Pharma-Track
Anti-Counterfeit Medicine Ledger on the Blockchain

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web3 & Blockchain

Background & Context

The World Health Organization estimates that 10% of medicines in low- and middle-income countries are
substandard or falsified. Counterfeit medicines not only fail to treat illness — they can contain harmful
substances that injure or kill patients. Drug counterfeiting is a $75 billion global industry, and without a
reliable way to verify a medicine's authenticity at the point of dispensing, pharmacists and consumers
remain vulnerable.
Every genuine medicine batch travels from manufacturer to distributor to pharmacy through a complex
supply chain, each step offering an opportunity for counterfeits to enter. A blockchain-anchored tracking
system — where every step is recorded immutably — can make the entire supply chain transparent and
verifiable by any consumer with a smartphone.

Problem Statement
Build Pharma-Track — a blockchain-based supply chain tracking system where every medicine batch is
assigned a unique on-chain ID at the point of manufacture. A QR code linked to this ID allows anyone —
distributor, pharmacist, or patient — to scan and instantly verify the complete journey of that medicine
from factory to shelf, detecting any tampering or unauthorized entries.

Core Requirements
1. Smart Contract & Batch ID
• Write a Solidity smart contract to mint a unique on-chain batch ID for each medicine batch at
manufacture
• Record each supply chain step (manufacture, distributor received, pharmacy received, sold) as
an on-chain transaction
• Store batch metadata: medicine name, manufacture date, expiry date, manufacturer address,
quantity
• Make all batch records publicly readable but write-restricted to authorized parties
2. QR Code System
• Generate a QR code for each batch ID that links to the verification portal
• The QR code must encode the batch contract address and a unique identifier
• Support QR code printing/export for physical labels
3. Verification Portal
• Build a public web portal where anyone can scan or enter a batch ID and see the full supply
chain journey
• Highlight any gaps, unexpected actors, or unauthorized entries in the chain
• Display a green / amber / red authenticity verdict with reasoning
4. Role-Based Access
 genuine final sale, preventing fake end-point entries

• Integrate expiry date enforcement: automatically flag batches as expired and prevent them
from being scanned as valid

• • Implement
Build a cold-chain monitoring integration: link IoT temperature data to each batch record
three roles: Manufacturer, Distributor, Pharmacy — each can only add their own
supply chain step reputation score that aggregates counterfeit incident reports
• Add a manufacturer
• Demonstrate role assignment via wallet address whitelisting

Bonus Challenges (Optional)

Suggested Tech Stack
• Dual-key confirmation: both pharmacist and buyer must sign a transaction to confirm a
Category
genuine final sale, preventing fake end-pointRecommended
entries Options
Smart
• Contracts Solidity, Hardhat
Integrate expiry date enforcement: or Truffle, OpenZeppelin
automatically ERC721
flag batches as expiredorand
custom
prevent them
from being scanned asMetaMask,
Wallet Integration valid [Link], wagmi
• Build a cold-chain monitoring
QR Code integration:
[Link], link IoT
node-qrcode, temperature
ZXing data to each batch record
(mobile scanning)
• Add a manufacturer reputation
Frontend score TailwindCSS
React, [Link], that aggregates counterfeit incident reports
Testnet Ethereum Sepolia, Polygon Mumbai
Storage IPFS (for batch documents), The Graph (for queries)
Suggested Tech Stack
Category Recommended Options
Evaluation Criteria
Smart Contracts Solidity, Hardhat or Truffle, OpenZeppelin ERC721 or custom
Criterion
Wallet Integration MetaMask, [Link], wagmi Weight Max Points
Smart Contract Security & Role [Link],
QR Code Enforcement 30%
node-qrcode, ZXing (mobile scanning) 30
Supply Chain Traceability & Completeness
Frontend React, [Link], TailwindCSS 25% 25
Verification
Testnet Portal UX & QR Flow
Ethereum Sepolia, Polygon Mumbai 20% 20
Counterfeit
Storage Detection Logic 15%(for queries)
IPFS (for batch documents), The Graph 15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Smart Contract Security & Role Enforcement 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
Supplydemo
Chain Traceability & Completeness 25% 25
• Full Portal
Verification pipeline
UX demo: Showing all required components functioning
& QR Flow 20% end-to-end20

Counterfeit Detection Logic 15% 15

Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 2.3

FairPay
Milestone-Based Decentralized Freelance Escrow

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web3 & Blockchain

Background & Context

The global freelance economy is worth over $1.5 trillion — but it is built on trust that is frequently broken.
Freelancers deliver work and wait weeks for payment, facing chargebacks, disputes, or clients who
simply disappear. Clients, in turn, pay upfront and receive incomplete or substandard work with no
recourse. Centralized platforms like Upwork or Fiverr take significant cuts and act as arbiters — with all
the bias and opacity that entails.
Smart contracts offer an elegant alternative: a programmable escrow that holds funds and releases them
only when verifiable milestones are met — automatically, transparently, and without a middleman taking a
cut.

Problem Statement
Build FairPay — a decentralized escrow platform for freelancers and clients. Both parties define project
milestones upfront and lock payment into a smart contract. When a milestone is verifiably completed (via
GitHub commit hash, file upload IPFS hash, or multi-signature approval), the corresponding milestone
payment is automatically released to the freelancer's wallet.

Core Requirements
1. Contract Creation
• Allow a client to create a project contract specifying: total payment amount, milestone
breakdown (name, deliverable hash, payment percentage), and deadline per milestone
• Lock the total payment into the smart contract escrow at contract creation
• Support both ETH and ERC-20 token payments
2. Milestone Verification & Release
• Implement at least one automated verification method: GitHub API commit hash check,
IPFS file upload hash, or multi-signature approval by both parties
• Automatically release the milestone payment to the freelancer wallet upon verification
• Implement a dispute window: client can raise a dispute within 48 hours of milestone
submission
3. Dispute Resolution
• Implement a simple dispute resolution mechanism: multi-sig arbitration (client + freelancer +
a third neutral wallet) or a DAO vote
• If a dispute is unresolved by the deadline, release funds to the freelancer by default
4. Dashboard
• Build a web interface where both client and freelancer can see the contract status, milestone
progress, and payment history
• Show escrow balance and estimated release schedule
 • Implement recurring payment contracts for long-term retainer engagements

• Build a public job board where freelancers can discover and bid on FairPay contracts

Bonus Challenges (Optional)

Suggested Tech Stack
• Integrate GitHub webhooks to trigger milestone completion automatically when a specific
Category
commit tag is pushed Recommended Options
Smart
• Contracts Solidity,
Add reputation NFTs: on Hardhat,
successful OpenZeppelin
contract (ERC20,
completion, mint amulti-sig patterns)
non-transferable
reputation token to both
Verification parties
GitHub API, IPFS ([Link]), Chainlink Any API (optional)
• Integration
Wallet Implement recurring payment contracts
MetaMask, for wagmi
[Link], long-term retainer engagements
+ viem
• Build a public job boardReact,
Frontend [Link],
freelancers can discover and bid on FairPay contracts
TailwindCSS
Testnet Ethereum Sepolia, Polygon Mumbai
Backend (Optional) [Link] / Express for webhook handling
Suggested Tech Stack
Category Recommended Options
Evaluation Criteria
Smart Contracts Solidity, Hardhat, OpenZeppelin (ERC20, multi-sig patterns)
Criterion
Verification Weight Any API (optional)
GitHub API, IPFS ([Link]), Chainlink Max Points
Smart
WalletContract Logic & Fund Safety
Integration MetaMask, [Link], wagmi + viem 30% 30
Milestone
Frontend Verification Mechanism
React, [Link], TailwindCSS 25% 25
Dispute
Testnet Resolution Design Ethereum Sepolia, Polygon Mumbai 20% 20
Dashboard UX & Contract Clarity
Backend (Optional) 15%
[Link] / Express for webhook handling 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Smart Contract Logic & Fund Safety 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
Milestone Verification Mechanism 25% 25
• Full
Dispute pipeline
Resolution demo: Showing all required components functioning
Design 20% end-to-end20

Dashboard UX & Contract Clarity 15% 15

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

Rules & Deliver

What to Constraints
• Team
Teams size: 2–4
may submit members
any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 2.4

ChainWill
Smart Contract Dead Man's Switch for Digital Asset Inheritance

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web3 & Blockchain

Background & Context

The crypto industry has a silent inheritance crisis. An estimated 20% of all Bitcoin — worth hundreds of
billions of dollars — is considered permanently lost, largely because owners died or became
incapacitated without leaving their private keys or wallet access to anyone. Unlike a bank account, there
is no "forgot my password" option for a crypto wallet. Without proactive planning, digital assets are simply
gone.
Traditional inheritance for digital assets is also fraught: seed phrases written on paper can be destroyed,
stolen, or misread. A smart contract-based system can act as a reliable, programmable "dead man's
switch" — one that requires no trust in a third party and executes exactly as coded.

Problem Statement
Build ChainWill — a smart contract system that allows a wallet owner to designate beneficiaries and
define transfer conditions. The contract monitors the owner's wallet activity. If no activity is detected for a
user-defined period (e.g., 12 months), the contract automatically initiates asset transfers to designated
beneficiaries — without requiring any action from a centralized party.

Core Requirements
1. Inheritance Smart Contract
• Allow the owner to register their wallet, designate up to 5 beneficiary wallets, and define the
percentage allocation per beneficiary
• Allow the owner to set an inactivity threshold (e.g., 6 months, 1 year)
• Implement a "check-in" mechanism: the owner pings the contract to reset the inactivity timer
• On threshold breach, automatically transfer ETH/ERC-20 tokens per the allocation
2. Activity Monitoring
• Use a Chainlink Keeper or similar automation trigger to regularly check the last check-in
timestamp
• Allow the owner to extend or modify their threshold at any time (only while active)
• Emit events for each check-in, threshold change, and transfer execution
3. Multi-Asset Support
• Support ETH and at least one ERC-20 token transfer
• Implement a function to allow the owner to add or remove assets from the will at any time
4. Owner Dashboard
• Build a web interface for the owner to view beneficiary list, last check-in date, days remaining
until trigger, and asset allocations
• Show a one-click "Check In Now" button to reset the timer
 • Testnet will simulation: allow owners to do a test-run of the inheritance execution without
sending real funds

Bonus Challenges (Optional)

Suggested Tech Stack
• Conditional inheritance rules: an asset transfers to a beneficiary only when they reach a
Category
certain Recommended
age (verified by oracle), or after a co-signer approvesOptions
Smart
• Contracts Solidity,
Multi-signature confirmation Hardhat,
before finalOpenZeppelin (ERC20,
transfer: require 2-of-3ERC721)
trusted witnesses to
confirm before executing
Automation Chainlink Automation (Keepers), Gelato Network, or time-based
triggers
• NFT inheritance: support ERC-721 NFT transfers to named beneficiaries
Oracle Chainlink for external condition verification (optional)
• Testnet will simulation: allow owners to do a test-run of the inheritance execution without
sending real funds
Wallet Integration MetaMask, [Link], wagmi
Frontend React, [Link], TailwindCSS
Testnet Ethereum Sepolia, Hardhat local node
Suggested Tech Stack
Category Recommended Options
Evaluation Criteria
Smart Contracts Solidity, Hardhat, OpenZeppelin (ERC20, ERC721)
Criterion
Automation Weight
Chainlink Automation (Keepers), Gelato Max Points
Network, or time-based
triggers
Smart Contract Logic & Security (reentrancy, access 30% 30
control)
Oracle Chainlink for external condition verification (optional)
Inactivity Detection & Automation
Wallet Integration [Link], wagmi
MetaMask, 25% 25
Asset Transfer Accuracy & Multi-Beneficiary
Frontend Logic
React, [Link], TailwindCSS 20% 20
Owner
TestnetDashboard & UX 15%
Ethereum Sepolia, Hardhat local node 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Smart Contract Logic & Security (reentrancy, access 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
control)
demo
Inactivity
• Full Detection
pipeline& Automation Reliability
demo: Showing 25%
all required components functioning end-to-end25
Asset Transfer Accuracy & Multi-Beneficiary Logic 20% 20
All submissions
Owner must
Dashboard include a README with setup instructions,
& UX 15%architecture overview,
15 and key design
decisions.
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 2.1
2.5

InsuChain
SkillChain
ParametricPolygon-Based
Weather Insurance for Farmers
On-Chain on the Blockchain
Skills Platform
⏱ Duration 👥 Level 📦 Deliverable 🏆 Track
36 Hours Intermediate Any Format Web3 & Blockchain

Background & Context

Background & Context
Professional credentials today are either centrally controlled — LinkedIn endorsements,
Credly
Agricultural insurance is acertificates
badges, Coursera — or entirely
lifeline for farmers facingself-reported with no external
droughts, unseasonal floods, and climate volatility —
verification.
but traditionalBoth modelsisare
insurance vulnerable
notoriously to falsification,
slow. After a drought platform shutdown,
or flood, farmersand data surveyors assess
file claims,
lock-in. A developer with five years of verified blockchain
crop damage, and insurance companies deliberate. Payouts can take months — longexperience, attested to by after seeds need to
ten former colleagues, has no portable, tamper-proof
be replanted, loans become due, and families go hungry. proof of that expertise that cannot
be taken away
Parametric by a single
insurance company's
replaces policydamage
subjective decision. assessment with objective, measurable triggers. If
rainfall falls below a threshold for a defined
Blockchain-based credential systems can fundamentally period, a payout is automatically
change triggered
this. By anchoring skill— no paperwork,
no surveyor, no waiting. Blockchain and decentralized oracles
attestations on-chain — permanently, tamper-proof, and owned entirely by the holder — make this model transparent, tamper-
proof, and instant.
professionals gain a verifiable identity they carry across platforms, jobs, and borders.
Building on Polygon makes this practical for real users: low gas fees (sub-cent
Problem Statement
transactions), fast finality, and full EVM compatibility lower the barrier to entry.
Build InsuChain — a decentralized application (dApp) where farmers can purchase parametric weather
Problempolicies.
insurance StatementSmart contracts automatically monitor on-chain weather data fed by Chainlink oracles,
and instantly release insurance payouts to farmer wallets if weather conditions (such as rainfall below
5mm in
Build a 30-day—period)
SkillChain breach
a platform on predefined
Polygon where thresholds.
users create professional skill profiles
and request on-chain attestations from peers, employers, and institutions. Every
Core Requirements
attestation is recorded as an immutable on-chain transaction that anyone can verify
independently. Users receive a portable, cryptographically signed credential for each
1. Smart Contract Core
attested skill, shareable via a public profile link or an embeddable badge.
• Write a Solidity smart contract for policy creation, premium collection, and automatic payout
Core • Requirements
Define parametric triggers: rainfall threshold, temperature extremes, or wind speed thresholds
• Implement a policy escrow: premiums are pooled and released on trigger or refunded on
1. Skillexpiry
Profile Creation
• Emit events for all state changes (policy created, triggered, paid out)
• Allow users to connect their MetaMask wallet and create a profile with: display name
2. Oracle Integration
(optional), professional headline, a list of claimed skills each tagged with
• proficiency level (Beginner
Integrate Chainlink Data Feeds/ Intermediate
or a mock/ oracle
Expert), forand an optional
weather portfoliotemperature)
data (rainfall, or
LinkedIn URL
• Demonstrate that the smart contract reads oracle data and evaluates trigger conditions
• Store profile data off-chain (PostgreSQL or IPFS) referenced by the user's wallet
automatically
address;
• Handle oracle generate a shareable
downtime public
gracefully profilelocking
without URL ([Link] /profile/0x1234...)
permanently
• Allow users to add, update, or remove skills from their profile at any time, and
3. Farmer-Facing dApp
toggle individual skills between public and private visibility
• Build a web frontend where farmers can: browse available policy types, view trigger
• Display a verification badge on each skill showing the number of on-chain attestations
conditions and premium amounts, purchase a policy by connecting a MetaMask wallet, and
received — more attestations increase visual trust indicators
track their active policies and payout status
2.
4. On-Chain
Transparency Attestation
Dashboard Smart Contract
•• Write
Display a Solidity
a publicsmart
ledgercontract deployed
of all active on Polygon
policies, Mumbai
trigger events, that
and records skill
payouts
attestations: attestor wallet, recipient wallet, skill
• Show historical oracle data alongside trigger events for auditabilityidentifier, proficiency level,
and an optional short endorsement message (stored as a hash on-chain)
Bonus • Attestations
Challenges are immutable
(Optional) once recorded — they cannot be deleted or modified by
either party; only the recipient can choose to hide an attestation from their public
profile
• Emit events (AttestationCreated, AttestationHidden) for all state changes; ensure the
contract passes standard security checks for reentrancy and access control
Bonus Challenges (Optional)

• Implement Soulbound Skill NFTs: once a skill accumulates a configurable attestation

threshold, automatically mint a non-transferable ERC-5192 token as a permanent badge

• Add a Trust-Weighted Reputation Score per skill: weight attestations from wallets
with many outgoing attestations higher; display a visual trust graph per skill

• Build an Employer Verification Portal where companies can verify a candidate's

credentials by pasting their wallet address — no wallet connection required

• Implement DAO-based Certification: a decentralised committee of domain experts can

vote to grant official SkillChain Certifications for high-demand technical skills

Suggested Tech Stack

Category Recommended Options

Smart Contracts Solidity, Hardhat, OpenZeppelin (access control,
ERC-5192)

Blockchain Polygon Mumbai testnet, Polygon PoS mainnet

Wallet Integration MetaMask, [Link], wagmi + viem

Frontend React, [Link], TailwindCSS

Backend [Link] + Express, FastAPI

Storage / Indexing IPFS / Filecoin (credentials), The Graph (on-chain

indexing)

Database PostgreSQL (profiles & requests), Redis (sessions)

What to Deliver

Teams may submit any of the following (or a combination):

• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview,
and key design decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
🔧 Track 3: DevOps & Cloud Infrastructure
 Problem Statement 3.1

Chaos-Monkey for Web

Automated Resilience & Fault-Injection Testing Platform

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

DevOps & Cloud
36 Hours Intermediate Any Format
Infrastructure

Background & Context

Modern web applications run on complex, interdependent microservices. A single component failure can
cascade into a full system outage — unless the application has been designed and tested to tolerate such
failures. The problem is that most teams only discover these failure modes in production, when real users
are affected.
Chaos Engineering, pioneered by Netflix's Chaos Monkey, is the practice of deliberately injecting failures
into systems in a controlled environment to identify weaknesses before they surface in production. The
goal is not to break things — it is to prove that the system can handle breakage gracefully.

Problem Statement
Build a Chaos Engineering tool that allows developers to randomly inject faults into a running web
application (containerized) — including killing containers, inducing network latency, simulating CPU
spikes, and dropping database connections. The tool must monitor the application's health throughout the
chaos run and automatically generate a post-chaos resilience report.

Core Requirements
1. Fault Injection Engine
• Implement at least four fault types: container kill/restart, network latency injection (100ms–
2000ms delay), CPU stress (80–100% load on a container), and database connection drop or
timeout
• Allow configuration of fault intensity and duration per experiment
• Implement a safety brake: automatically halt the chaos run if the application becomes fully
unresponsive
2. Health Monitoring Stream
• Continuously monitor application health during a chaos run via HTTP health check endpoints
• Track and record: response times, error rates, uptime percentage, and recovery time after
each fault
• Stream live metrics to a monitoring dashboard
3. Control Panel
• Provide a web-based control panel to: select fault types and parameters, start and stop
chaos experiments, see the live health stream in real time
• Allow scheduling experiments for a future time
4. Post-Mortem Report
• Automatically generate a resilience report after each chaos run containing: faults injected,
system response per fault, weakest point identified, and recommended fixes
• Export report as PDF or Markdown
 • Build a "chaos schedule" feature: run experiments automatically every night on a staging
cluster

• Implement comparative resilience scoring across multiple application versions

Bonus Challenges (Optional)

Suggested Tech"intelligent
• Implement Stack chaos" using an LLM agent that decides which faults to inject based
on historical vulnerability patterns
Category Recommended Options
• Add Kubernetes-native fault injection using chaos-mesh or Litmus Chaos for pod-level
Containerization
attacks Docker, Docker Compose, Kubernetes (minikube for local)
Fault Injection tc (Linux traffic control), stress-ng, Toxiproxy, Pumba, chaos-mesh
• Build a "chaos schedule" feature: run experiments automatically every night on a staging
cluster
Monitoring Prometheus, Grafana, cAdvisor, custom health check scripts
• Implement
Backend comparativePython
/ Orchestration resilience scoring across
(subprocess, Docker multiple
SDK), Go,application
[Link] versions
Frontend React, [Link], TailwindCSS, [Link] / Recharts
Report Generation ReportLab, Markdown + Pandoc
Suggested Tech Stack
Category Recommended Options
Evaluation Criteria
Containerization Docker, Docker Compose, Kubernetes (minikube for local)
Criterion
Fault Injection Weight Pumba, chaos-mesh
tc (Linux traffic control), stress-ng, Toxiproxy, Max Points
Fault Injection Coverage & Reliability
Monitoring 30%health check scripts30
Prometheus, Grafana, cAdvisor, custom
Real-Time
Backend / Monitoring & Health Stream
Orchestration 25%
Python (subprocess, Docker SDK), Go, [Link] 25
Safety Brake & Experiment Control
Frontend React, [Link], TailwindCSS, Chart.js20%
/ Recharts 20
Post-Mortem Report Quality
Report Generation ReportLab, Markdown + Pandoc 15% 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Fault Injection Coverage & Reliability 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
Real-Time Monitoring & Health Stream 25% 25
• Full
Safety Brakepipeline demo:
& Experiment Showing all required components functioning
Control 20% end-to-end20

Post-Mortem Report Quality 15% 15

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

Rules & Deliver

What to Constraints
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 3.2

Pulse-Check
AI-Driven Latent Degradation Detector for Microservices

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

DevOps & Cloud
36 Hours Intermediate Any Format
Infrastructure

Background & Context

Traditional health checks are binary: a service is either up or down. But real-world degradation rarely
announces itself with a crash. Instead, a service gets progressively slower — 5 milliseconds slower per
hour, then 10, then 20 — until it tips over a cliff and becomes unresponsive, triggering a P1 incident at
3am. By the time alarms ring, the damage is done.
"Latent degradation" — the slow, invisible decline of a service — is one of the hardest reliability problems
to catch. The pattern is obvious in hindsight, but invisible to static threshold-based monitors that only alert
when things are already broken.

Problem Statement
Build Pulse-Check — an intelligent microservice health monitoring system that tracks latency trends over
time, detects gradual performance degradation (not just binary up/down), and proactively triggers a
canary rollback or alert before a service actually crashes. It should calculate a "Time to Crash" estimate
based on the current degradation trajectory.

Core Requirements
1. Real-Time Latency Monitoring
• Continuously probe multiple simulated microservice endpoints and record response times
• Store latency data as a time series with timestamps, service name, and response code
• Support at least 5 simulated services with configurable degradation scenarios
2. Degradation Detection Algorithm
• Implement trend analysis on the latency time series (linear regression, exponential smoothing,
or LSTM)
• Flag a service as "degrading" when it meets degradation criteria (e.g., p95 latency grows more
than 5% per monitoring cycle for 3 consecutive cycles)
• Calculate a "Time to Crash" estimate: based on current degradation rate, predict when the
service will breach its SLA threshold
3. Alerting & Automated Response
• Send an alert (Slack webhook, email, or on-screen notification) when degradation is detected,
including the estimated time to threshold breach
• Trigger an automated canary rollback simulation when the "Time to Crash" drops below 30
minutes
• Log all alerts and actions with timestamps for auditability
4. Degradation Dashboard
• Display per-service latency graphs showing the historical trend and the projected degradation
curve
 • Implement multi-metric degradation: detect degradation in CPU usage, memory, and error
rate simultaneously

• Build an anomaly correlation engine: if three services degrade simultaneously, infer a

shared root cause
• Show a health score (0–100) per service, updated in real time
• • Provide a timeline
Predictive view ofdashboard
failure scoring past degradation
showingevents and recovery
all services ranked byactions
Time to Crash

Bonus Challenges (Optional)

Suggested Tech
• Integrate withStack
a CI/CD pipeline: automatically block new deployments for a degrading
service
Category Recommended Options
• Implement multi-metric degradation: detect degradation in CPU usage, memory, and error
Monitoring
rate/simultaneously
Metrics Prometheus, Grafana, custom Python scraper, StatsD
Trend Analysis scikit-learn, NumPy (linear regression), statsmodels, Prophet
• Build an anomaly correlation engine: if three services degrade simultaneously, infer a
Alertingshared root cause Slack Incoming Webhooks, PagerDuty API, SMTP
• Predictive failure scoring
Backend dashboard
FastAPI, Flask,showing
Go all services ranked by Time to Crash
Simulated Services Docker Compose ([Link] / Python services with degradation scripts)
Frontend React + Recharts, Grafana dashboards, Streamlit
Suggested Tech Stack
Database InfluxDB, TimescaleDB, Prometheus TSDB
Category Recommended Options
Monitoring / Metrics Prometheus, Grafana, custom Python scraper, StatsD
Evaluation Criteria
Trend Analysis scikit-learn, NumPy (linear regression), statsmodels, Prophet
Criterion
Alerting Weight
Slack Incoming Webhooks, PagerDuty API, SMTP Max Points
Degradation
Backend Detection AccuracyFastAPI,
& Algorithm Quality
Flask, Go 30% 30
Time-to-Crash Estimation Precision
Simulated Services 25%
Docker Compose ([Link] / Python services 25scripts)
with degradation
Automated
Frontend Response & Rollback Logic+ Recharts, Grafana dashboards,
React 20%Streamlit 20
Dashboard
Database Quality & Real-TimeInfluxDB,
Updates TimescaleDB, Prometheus15%
TSDB 15
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Degradation Detection Accuracy & Algorithm Quality 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo Estimation Precision
Time-to-Crash 25% 25
• Full Response
Automated pipeline demo: Showing
& Rollback Logic all required components functioning
20% end-to-end20

Dashboard Quality & Real-Time Updates 15% 15

Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 3.3

Auto-Heal
Self-Repairing Container Infrastructure

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

DevOps & Cloud
36 Hours Intermediate Any Format
Infrastructure

Background & Context

In a typical production environment, on-call engineers receive a PagerDuty alert at 2am: "Service
payments-api is down." They SSH into the server, check the container logs, see a memory exhaustion
error, restart the container, verify the health check, and go back to sleep — an entire workflow that lasted
20 minutes and could have been automated end-to-end.
High-availability infrastructure should self-heal. A system that can detect its own failures, determine the
probable root cause, and automatically redeploy a healthy replacement — all without human intervention
— turns a 20-minute incident into a 20-second recovery.

Problem Statement
Build Auto-Heal — an autonomous container health monitoring and self-healing system. When a
container fails (crashes, becomes unresponsive, or exceeds resource limits), the system automatically
detects the failure, analyzes logs to tag a probable root cause, redeploys a healthy replacement, and logs
the full incident for review.

Core Requirements
1. Container Health Monitoring
• Continuously monitor a set of Docker containers for: process crashes, health check
failures, memory or CPU threshold breaches, and unresponsive HTTP endpoints
• Detect failure within 30 seconds of onset
• Support monitoring of at least 5 simultaneous containers
2. Failure Pattern Detection & Root-Cause Tagging
• Analyze container logs at the moment of failure to identify the probable root cause
• Tag each incident with a root-cause category: OOM (Out of Memory), application crash,
dependency failure, configuration error, or unknown
• Assign a confidence score to the root-cause tag
3. Auto-Redeployment
• On failure detection, automatically pull the last known-good image and spin up a replacement
container
• Verify the new container passes its health check before marking the incident as resolved
• Implement a maximum retry limit (3 attempts) with escalation to a human alert if retries are
exhausted
4. Incident Dashboard
• Maintain a real-time incident log: failure time, root cause, recovery action, and time-to-
recovery
• Display a visual timeline of failures and recoveries per service
 alert a human instead of retrying

• Integrate with Kubernetes: extend the system to manage pod-level healing in a minikube
cluster
• • Send
Buildaasummary alert (Slack/email)
"failure injection" mode to testfor each auto-healed
Auto-Heal incident
by deliberately crashing containers

Bonus Challenges (Optional)

Suggested TechanStack
• Implement ML model that learns failure patterns over time and predicts which container
is most likely to fail next
Category Recommended Options
• Add "circuit breaker" logic: after 3 failures of the same root cause, disable the service and
Containerization
alert a human instead of Docker, Docker Compose, Docker SDK for Python
retrying
Monitoring Prometheus + cAdvisor, custom health check scripts, Loki (log
• Integrate with Kubernetes: extend the system to manage pod-level healing in a minikube
aggregation)
cluster
Root Cause Analysis Python log parsing, scikit-learn (optional ML tagging), Drain3
• Build a "failure injection" mode to test Auto-Heal by deliberately crashing containers
Alerting Slack Webhooks, SMTP, PagerDuty
Backend Python (FastAPI / Flask), Go
Suggested
Frontend Tech Stack React, Grafana dashboards
Orchestration (Bonus)
Category Kubernetes, Helm, minikube
Recommended Options
Containerization Docker, Docker Compose, Docker SDK for Python
Monitoring Prometheus + cAdvisor, custom health check scripts, Loki (log
Evaluation Criteria aggregation)
Criterion
Root Cause Analysis Weight
Python log parsing, scikit-learn (optional Max Points
ML tagging), Drain3
Detection
Alerting Speed & Coverage (failure
Slack scenarios
Webhooks,handled)
SMTP, PagerDuty 30% 30
Root-Cause
Backend Tagging Accuracy Python (FastAPI / Flask), Go 25% 25
Redeployment
Frontend Reliability & Health Verification
React, Grafana dashboards 20% 20
Incident Dashboard
Orchestration & Alerting Kubernetes, Helm, minikube
(Bonus) 15% 15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Detection Speed & Coverage (failure scenarios handled) 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demoTagging Accuracy
Root-Cause 25% 25
• Full pipeline
Redeployment demo:
Reliability Showing
& Health all required components functioning
Verification 20% end-to-end20

Incident Dashboard & Alerting 15% 15

Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 3.4

ObservabilityMapper
Passive Auto-Discovery & Live Architecture Map for Microservices

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

DevOps & Cloud
36 Hours Intermediate Any Format
Infrastructure

Background & Context

In fast-moving engineering teams, the system architecture diagram is always wrong. Services are added,
renamed, deprecated, and re-routed — but nobody updates the Confluence diagram. When an incident
strikes, engineers spend precious minutes just answering the question: "Which services talk to which, and
through what?" This information should be derived automatically from actual traffic, not from stale
documentation.
Observability — the practice of making a system's internal state understandable from its external outputs
— has evolved beyond logs and metrics to include service topology. Knowing the real-time
communication graph of your services is not just an operational nicety; it is a prerequisite for effective
incident response and capacity planning.

Problem Statement
Build ObservabilityMapper — a tool that passively observes network traffic and API calls between a set of
containerized services (without requiring code changes or SDKs in those services) and automatically
generates a live, accurate, interactive architecture map showing service dependencies, call volumes,
error rates, and latency per connection.

Core Requirements
1. Passive Traffic Observation
• Use network-level traffic capture (eBPF, tcpdump, or sidecar proxy like Envoy) to observe inter-
service HTTP/gRPC calls without modifying target service code
• Parse captured traffic to extract: source service, destination service, endpoint called,
response code, and latency
• Handle at least 1,000 requests per second of captured traffic
2. Dependency Graph Construction
• Build a real-time directed graph of service-to-service dependencies from captured traffic
• Update the graph continuously as new traffic patterns emerge or existing ones change
• Detect when a previously observed dependency disappears (service deprecation or routing
change)
3. Interactive Architecture Map
• Render the dependency graph as an interactive visual map (force-directed or hierarchical
layout)
• Display per-edge metrics: calls per minute, error rate %, and average latency
• Color-code edges by health status: green (healthy), amber (elevated errors), red (high error
rate)
• Allow users to click on a service node to see its upstream and downstream dependencies
 generate IaC or service mesh configuration

• Integrate with Jaeger or Zipkin distributed tracing to correlate spans with the dependency
graph

• AddDetection
4. Change anomaly detection: flag a service connection whose latency or error rate significantly
& Alerting
deviates from its baseline
• Detect and alert on architectural drift: new unexpected dependencies, changed routes, or
• disappeared services
Build a "what-if" simulation: show which services would be affected if a selected service
• Maintain
went downa version history of the architecture map (snapshot per hour)

Bonus Challenges (Optional)

Suggested Tech
• Generate Stack
a machine-readable architecture export (JSON/YAML) that can be used to auto-
generate IaC or service mesh configuration
Category Recommended Options
• Integrate with Jaeger or Zipkin distributed tracing to correlate spans with the dependency
Traffic Capture
graph eBPF (Cilium, Pixie), tcpdump + libpcap, Envoy sidecar proxy, Istio
Graph Processing NetworkX (Python), Graphology (JS), [Link] force graph
• Add anomaly detection: flag a service connection whose latency or error rate significantly
deviates from its baseline
Visualization [Link], React Flow, [Link], Grafana (optional)
• Build a "what-if" simulation:
Backend Pythonshow which Go
(FastAPI), services would be affected if a selected service
went down
Containerization Docker Compose, Kubernetes + minikube
Storage Redis (real-time graph), PostgreSQL (history), InfluxDB (metrics)

Suggested Tech Stack

Category
Evaluation Criteria Recommended Options
Traffic Capture eBPF (Cilium, Pixie), tcpdump + libpcap, Envoy sidecar proxy, Istio
Criterion Weight Max Points
Graph Processing NetworkX (Python), Graphology (JS), [Link] force graph
Traffic Capture Accuracy & Passivity (no code changes 30% 30
needed)
Visualization [Link], React Flow, [Link], Grafana (optional)
Dependency
Backend Graph Completeness & Real-Time
Python (FastAPI),Updates
Go 25% 25
Map Visualization Quality & Interactivity
Containerization 20%
Docker Compose, Kubernetes + minikube 20
Change
Storage Detection & Alerting Redis (real-time graph), PostgreSQL15% 15
(history), InfluxDB (metrics)
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Traffic Capture Accuracy & Passivity (no code changes 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
needed)
demo
Dependency Graph Completeness & Real-Time Updates 25% 25
Map Visualization Quality & Interactivity 20% 20
Change Detection & Alerting 15% 15
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
 • Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
🌐 Track 4: Web Development
 Problem Statement 4.1

Zero-Waste Marketplace
Hyper-Local Food Sharing Portal

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web Development

Background & Context

Every day, restaurants, catering companies, wedding halls, and households throw away tonnes of
perfectly edible food simply because it was cooked in excess or is approaching its expiry date. Meanwhile,
millions of people go to bed hungry within the same neighbourhoods. This is not a supply problem; it is a
coordination and distribution problem.
NGOs and food banks exist to bridge this gap, but they struggle with two fundamental challenges:
discovering available food in real time before it spoils, and coordinating pickup logistics. A technology
platform that connects food donors with collectors — with real-time expiry alerts and geolocation
matching — can eliminate this coordination gap.

Problem Statement
Build Zero-Waste Marketplace — a Progressive Web App (PWA) that enables food donors (restaurants,
households, event organizers) to list available food items with quantity, pickup window, and location.
Local NGOs and volunteers can discover nearby listings in real time, claim items, and coordinate pickup
— reducing food waste while feeding those in need.

Core Requirements
1. Donor-Side Features
• Allow donors to register and create food listings: food type, quantity, dietary info (vegan,
contains nuts), pickup window (start time, expiry time), and pickup location (GPS or address)
• Send automated "expiry approaching" push notifications to nearby collectors 1 hour before the
listing expires
• Allow donors to view their listing history and impact statistics (total food donated, pickups
completed)
2. Collector-Side Features
• Display a real-time map (Leaflet or Google Maps) showing active food listings within a user-
configurable radius
• Allow collectors to filter listings by food type, dietary requirements, and pickup window
• Implement a one-tap "Claim" feature that reserves a listing for 30 minutes and notifies the donor
3. Trust & Safety
• Implement a Trust Score system for both donors and collectors, based on completed pickups,
ratings, and on-time rates
• Allow users to rate each transaction (1–5 stars with optional comment)
• Flag accounts with repeated cancellations or low ratings for admin review
4. PWA & Offline
• The app must function as a PWA: installable on mobile, with offline access to previously
loaded listings and a queued "claim" action that fires when connectivity is restored
 "tomorrow's wedding, expect 50 portions at 9pm")

• Build an impact analytics dashboard showing: total meals saved, kg CO2 avoided, and
weekly trends
• • Achieve a Lighthouse
Implement multilingualPWA score
support for of at least
Hindi 80least one other Indian regional language
and at

Bonus Challenges (Optional)

Suggested Tech
• Integrate Stack
a route optimization feature for NGO drivers picking up from multiple donors in
one trip
Category Recommended Options
• Add a "surplus forecast" feature: donors can pre-announce expected surplus (e.g.,
Frontend React / 50
"tomorrow's wedding, expect [Link], TailwindCSS,
portions at 9pm") Workbox (PWA), Service Workers
Maps [Link] + OpenStreetMap, Google Maps API
• Build an impact analytics dashboard showing: total meals saved, kg CO2 avoided, and
weekly trends
Backend [Link] + Express, FastAPI, or Supabase (BaaS)
• Implement multilingualPostgreSQL
Database support for Hindi and at
+ PostGIS least one other
(geospatial), IndianFirebase
Supabase, regionalFirestore
language
Push Notifications Firebase Cloud Messaging (FCM), Web Push API
Auth Firebase Auth, [Link], Supabase Auth
Suggested Tech Stack
Category Recommended Options
Evaluation
Frontend Criteria React / [Link], TailwindCSS, Workbox (PWA), Service Workers
Criterion
Maps [Link] + OpenStreetMap, GoogleWeight
Maps API Max Points
Real-Time
Backend Map & Listing Discovery 25% (BaaS)
[Link] + Express, FastAPI, or Supabase 25
PWA Quality & Offline Functionality
Database PostgreSQL + PostGIS (geospatial), 25% 25
Supabase, Firebase Firestore
Trust
Push Score System & Safety Features
Notifications 20%Push API
Firebase Cloud Messaging (FCM), Web 20
Push
Auth Notification & Expiry Alert Firebase
System Auth, [Link], Supabase
20%
Auth 20
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Real-Time Map & Listing Discovery 25% 25
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo & Offline Functionality
PWA Quality 25% 25
• Full pipeline demo: Showing
Trust Score System & Safety Features all required components functioning
20% end-to-end20
Push Notification & Expiry Alert System 20% 20
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 4.2

Eco-Cart
Chrome Extension for Carbon Footprint-Aware Shopping

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web Development

Background & Context

E-commerce has transformed shopping — but at an invisible environmental cost. The average online
shopper has no idea whether the product in their cart was manufactured 5 km away or shipped from a
factory 10,000 km across the planet, what materials it is made from, whether those materials are
recyclable, or what the carbon footprint of its delivery will be. This information exists — scattered across
product pages, manufacturer websites, and shipping APIs — but it is never surfaced at the point of
purchase, where it can actually change behaviour.

Problem Statement
Build Eco-Cart — a browser extension that activates on major e-commerce product pages (Amazon,
Flipkart, or similar) and automatically analyses the product's environmental impact. It assigns an "Eco-
Score" (A to F) based on materials, manufacturing origin, estimated shipping distance, and packaging
type, and suggests more sustainable alternatives when available.

Core Requirements
1. Product Data Extraction
• Automatically extract product information from the active e-commerce page: product
name, brand, category, materials (from description), origin country, and weight/dimensions
• Use DOM scraping or the retailer's public API where available
• Handle variations across different e-commerce site layouts (at least 2 supported sites)
2. Eco-Score Algorithm
• Calculate an Eco-Score (A to F) based on a weighted combination of: estimated shipping
distance (origin country to user location), material sustainability score (recycled, organic,
synthetic), product category carbon intensity (electronics vs. apparel vs. food), and packaging
type if detectable
• The scoring algorithm must be transparent and explainable — show the user the breakdown
3. Sustainable Alternative Suggestions
• For products scoring D or below, suggest at least 2 more sustainable alternatives from the same
platform or a curated dataset
• Show the Eco-Score comparison between the original product and each alternative
4. Extension UI
• Display the Eco-Score as a floating sidebar or popup panel on the product page
• Show a score breakdown chart (radar or bar) per sustainability dimension
• Include a "My Eco Impact" summary: cumulative eco-score across all products viewed this
session

Bonus Challenges (Optional)

 • Build a leaderboard: compare your average Eco-Score this month against anonymized
community benchmarks

• Integrate with a product carbon footprint database (Open Food Facts, GoodGuide, or
Suggested Tech Stack
custom-scraped dataset)

• Add a shopping cart scanner: analyse all items

Category in the cart simultaneously
Recommended Options and show total
cart Eco-Score
Extension Chrome Extension Manifest V3, Vanilla JS / React + Vite
• Implement a browser-side ML model ([Link]) to infer materials and origin from
DOM Scraping Content Scripts, MutationObserver API
product images
Eco-Score Backend FastAPI / [Link] (hosted), or fully client-side computation
• Build a leaderboard: compare your average Eco-Score this month against anonymized
community benchmarks
Data Sources Open Food Facts API, custom product carbon dataset, Google Maps
API (distance)
Visualization [Link], [Link], TailwindCSS (popup UI)
Suggested
ML (Optional)Tech Stack [Link], ONNX Runtime Web

Category Recommended Options

Extension Chrome Extension Manifest V3, Vanilla JS / React + Vite
Evaluation Criteria
DOM Scraping Content Scripts, MutationObserver API
Criterion Weight Max Points
Eco-Score Backend FastAPI / [Link] (hosted), or fully client-side computation
Eco-Score Algorithm Robustness & Explainability 30% 30
Data Sources Open Food Facts API, custom product carbon dataset, Google Maps
Product Data Extraction Accuracy
API (distance) 25% 25
Alternative Suggestion Quality &[Link],
Visualization [Link], TailwindCSS (popup 20%
UI) 20
Extension UI/UX & [Link], ONNX Runtime Web 15%
ML (Optional) 15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Eco-Score Algorithm Robustness & Explainability 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
Productdemo
Data Extraction Accuracy 25% 25
• Full Suggestion
Alternative pipeline demo:
QualityShowing all required components functioning
& Relevance 20% end-to-end20

Extension UI/UX & Performance 15% 15

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.
Innovation & Bonus Features 10% 10

Rules & Deliver

What to Constraints
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 4.3

VolunteerCompass
Real-Time Volunteer-to-Event Matching Platform

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web Development

Background & Context

Community service is one of the most powerful forces for social good — but it is chronically under-
organised. Volunteers who want to give their time struggle to find events that match their skills,
availability, and location. NGOs and community organisers, meanwhile, post events on WhatsApp groups
and paper notices, hoping the right people will see them. The mismatch is enormous: skilled volunteers go
unmatched while events go understaffed.
A technology platform that intelligently matches volunteers to events based on their profiles — skills,
availability, location, and past participation — can dramatically increase the efficiency and reach of
community service.

Problem Statement
Build VolunteerCompass — a map-based web platform where community organisers can post volunteer
events (cleanups, tutoring sessions, blood donation drives, food distribution) and volunteers can discover,
filter, and RSVP to nearby events in real time. The platform should use smart matching to surface the
most relevant events to each volunteer based on their profile.

Core Requirements
1. Event Management
• Allow organisers to create events with: title, description, required skills, number of volunteers
needed, date/time, location (GPS pin or address), and event category
• Allow organisers to view RSVPs, send announcements to confirmed volunteers, and mark event
completion
• Support recurring events (e.g., weekly tutoring sessions)
2. Volunteer Profile & Matching
• Allow volunteers to create profiles with: skills, interests, availability (days and hours),
preferred event categories, and location
• Implement a matching algorithm that scores and ranks events for each volunteer based on skill
overlap, location distance, and availability fit
• Send push notifications to matched volunteers when a new relevant event is posted nearby
3. Interactive Map
• Display all active events on an interactive map (Google Maps or Leaflet)
• Allow filtering by: distance radius, event category, date, and required skills
• Show event markers with a quick-preview card (event name, date, volunteers needed)
4. Impact Dashboard
• Show each volunteer their personal impact stats: total hours volunteered, events attended,
and skills contributed
 • Implement a team RSVP feature: volunteers can RSVP as a group (college club,
corporate team)

• Build an automated event reminder system: SMS or WhatsApp reminder 24 hours before
the event
• Display community-level impact: total volunteer hours, events completed, and beneficiaries
• served
Add a skill-gap analysis: show organisers which skills are in shortage in their area and
suggest recruitment strategies
Bonus Challenges (Optional)
• Gamification: award digital badges for milestones (first event, 10 hours, 5 events) and
Suggested
displayTech Stack
a leaderboard

• Implement
Category a team RSVP feature: volunteers Recommended
can RSVP as a Options
group (college club,
corporate team)
Frontend React / [Link], TailwindCSS
• Build an automated event reminder system: SMS or WhatsApp reminder 24 hours before
Maps Google Maps API, [Link] + OpenStreetMap
the event
Backend [Link] + Express, FastAPI, or Supabase
• Add a skill-gap analysis: show organisers which skills are in shortage in their area and
suggest recruitment strategies
Database PostgreSQL + PostGIS (for geospatial queries), Supabase
Auth Firebase Auth, [Link], Auth0
Notifications Firebase Cloud Messaging, Twilio (SMS), WhatsApp Business API
Suggested Tech Stack
Matching Algorithm Custom weighted scoring (Python / JS), optional ML reranking
Category Recommended Options
Frontend React / [Link], TailwindCSS
Evaluation
Maps Criteria Google Maps API, [Link] + OpenStreetMap
Criterion
Backend Weight
[Link] + Express, FastAPI, or Supabase Max Points
Matching
DatabaseAlgorithm Quality & Relevance 25%
PostgreSQL + PostGIS (for geospatial queries), Supabase 25
Map
AuthInterface & Event Discovery UX
Firebase Auth, [Link], Auth0 25% 25
Impact Dashboard & Analytics Firebase Cloud Messaging, Twilio (SMS),
Notifications 20% WhatsApp Business
20 API
Real-Time Notifications & RSVPCustom
Matching Algorithm Flow weighted scoring (Python / JS),
20%optional ML reranking
20
Innovation & Bonus Features 10% 10

What to Deliver
Evaluation Criteria
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Matching Algorithm Quality & Relevance 25% 25
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo & Event Discovery UX
Map Interface 25% 25
• Full
Impact pipeline
Dashboard demo: Showing all required components functioning
& Analytics 20% end-to-end20

Real-Time Notifications & RSVP Flow 20% 20

Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 4.4

ComputeShare
Distributed Browser-Based Compute Donation Network

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web Development

Background & Context

The world has an enormous amount of idle compute power. At any given moment, billions of browser tabs
sit open on laptops and phones, doing nothing while their CPUs sit at 2% utilisation. Meanwhile,
researchers, scientists, and developers face long queues for GPU and CPU time on expensive cloud
services to run simulations, render frames, train models, or compute complex mathematical problems.
Volunteer computing has existed since SETI@Home in the 1990s, but it required users to download
dedicated software. Modern web APIs — WebWorkers for background computation, WebAssembly for
near-native performance, and WebSockets for real-time coordination — make it possible to build a
distributed computing network that runs entirely in the browser, with zero installation.

Problem Statement
Build ComputeShare — a web platform where users can "donate" their idle browser CPU cycles to a
shared compute pool. A coordinator distributes computational tasks (e.g., mathematical computations,
image processing, data crunching) across connected browsers using WebWorkers. Donors can see their
contribution in real time, and task submitters can track progress and retrieve results.

Core Requirements
1. Coordinator Server
• Build a WebSocket server that maintains a registry of connected browser workers
• Split a computational task into independent sub-tasks and distribute them across available
workers
• Reassign sub-tasks if a worker disconnects mid-computation
• Aggregate results from all workers and return the final output to the task submitter
2. Browser Worker Client
• Build a browser-based worker that connects to the coordinator via WebSocket
• Use WebWorkers to run computation off the main thread (non-blocking)
• Implement a CPU throttle control: workers can cap the CPU they donate (25% / 50% / 75% /
100%)
• Show the volunteer a real-time CPU contribution meter and estimated tasks completed
3. Task Submission Interface
• Allow users to submit computational tasks: a mathematical function to evaluate over a
range, an image processing batch, or a simulated scientific computation
• Show real-time progress: percentage complete, active workers, and estimated time remaining
• Allow download of results when the task completes
4. Contribution Dashboard
 speed in the browser

• Add a task marketplace: users can post compute tasks with a reward (points or tokens) for
contributors

• • Display
Implement fault tolerance with task checksumming: verify each sub-task result before
a community dashboard: total compute donated (CPU-hours), tasks completed, and
aggregating to prevent malicious results
active workers right now
• • Show per-volunteer
Build a contribution
browser extension stats:
version for CPU-hours
always-on donated,
background tasksdonation
compute contributed to, and uptime

Bonus Challenges (Optional)

Suggested TechWebAssembly
• Implement Stack (WASM) for compute-intensive tasks to achieve near-native
speed in the browser
Category Recommended Options
• Add a task marketplace: users can post compute tasks with a reward (points or tokens) for
Frontend
contributors React / Vanilla JS, Web Workers API, WebAssembly (WASM)
Real-Time Communication WebSockets ([Link] / native WS), WebRTC (optional P2P)
• Implement fault tolerance with task checksumming: verify each sub-task result before
aggregating
Backend to [Link]
/ Coordinator malicious results Go (for high concurrency), Redis (task queue)
+ [Link],
Task• Queue
Build a browser extension version
Redis for always-on
+ BullMQ, RabbitMQ,background compute donation
or custom in-memory queue
Computation Examples [Link], custom WASM modules, [Link] (image/video)
Database PostgreSQL, MongoDB, SQLite (contribution tracking)
Suggested Tech Stack
Category Recommended Options
Evaluation
Frontend Criteria React / Vanilla JS, Web Workers API, WebAssembly (WASM)
Criterion
Real-Time Communication Weight
WebSockets ([Link] / native WS), WebRTC (optionalMax Points
P2P)
Coordinator Reliability & Task Distribution
Backend / Coordinator Logic
[Link] + [Link], 30%
Go (for high concurrency), 30
Redis (task queue)
Browser Worker Performance &Redis
Task Queue Non-Blocking UXRabbitMQ, or custom
+ BullMQ, 25%
in-memory queue 25
Fault Tolerance
Computation (worker disconnect
Examples handling)
[Link], 20%
custom WASM modules, [Link] 20
(image/video)
Contribution
Database Dashboard & Real-Time Feedback
PostgreSQL, 15%
MongoDB, SQLite (contribution tracking) 15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Coordinator Reliability & Task Distribution Logic 30% 30
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
Browserdemo
Worker Performance & Non-Blocking UX 25% 25
• Tolerance
Fault Full pipeline
(workerdemo: Showing
disconnect all required components functioning
handling) 20% end-to-end20

Contribution Dashboard & Real-Time Feedback 15% 15

Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end
All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 4.5

ReputeChain
Decentralized Cross-Platform Professional Reputation Aggregator

⏱ Duration 👥 Level 📦 Deliverable 🏆 Track

36 Hours Intermediate Any Format Web Development

Background & Context

Your professional reputation is scattered across a dozen platforms. Your GitHub shows your code
contributions, LinkedIn shows your endorsements, Upwork shows your client ratings, Stack Overflow
shows your expertise score. Each platform holds a piece of your professional identity — but none of them
talk to each other, and you own none of them. If LinkedIn shuts down tomorrow, your 500+ connections
and endorsements are gone.
Self-sovereign identity is the idea that you should own your digital identity and reputation —
cryptographically signed, portable, and verifiable by anyone without relying on a centralized platform.
Combining this with on-chain attestation makes professional reputation something you can carry with you
across platforms, jobs, and borders.

Problem Statement
Build ReputeChain — a web platform that aggregates a user's professional reputation data from multiple
platforms (GitHub, LinkedIn, Upwork, or simulated equivalents), computes a composite reputation score,
and anchors it on-chain as a cryptographically signed, verifiable attestation that the user fully owns and
can share with anyone.

Core Requirements
1. Multi-Platform Data Aggregation
• Integrate with at least 2 real APIs (GitHub, LinkedIn, [Link], Stack Overflow) or provide realistic
mock data flows for demonstration
• Extract relevant reputation signals: contribution count, stars, endorsements, ratings, review
scores, and tenure
• Normalize signals across platforms into a unified reputation schema
2. Reputation Score Computation
• Compute a composite reputation score (0–1000) from aggregated signals using a weighted
algorithm
• Break the score into dimensions: Code Quality, Community Trust, Professional Experience,
and Delivery Reliability
• Show a full explanation of how each dimension was scored (transparent algorithm)
3. On-Chain Attestation
• Allow the user to anchor their reputation score on-chain as a signed attestation (using EAS —
Ethereum Attestation Service — or a custom smart contract)
• The attestation must include: score, timestamp, source platforms, and a cryptographic hash
of the underlying data
• Anyone must be able to verify the attestation via the smart contract or EAS explorer without
trusting ReputeChain
 • Implement peer attestations: allow other users to cryptographically vouch for specific
skills, adding to the reputation score

• Build a recruiter verification portal: employers can paste an attestation hash and see a
4. Shareable
verifiedReputation Profile
score without connecting a wallet
• Generate a public profile URL that shows the user's reputation score, dimension breakdown,
• and
Add a reputation changelog: show how the score has evolved over time as new data is
on-chain attestation link
pulled
• Provide an embeddable badge (SVG/PNG) that third-party sites can use to display the verified
• score
Implement ZK-proof verification: allow users to prove their score exceeds a threshold
without revealing the exact number
Bonus Challenges (Optional)
• Implement peer attestations: allow other users to cryptographically vouch for specific
Suggested
skills, Tech
adding Stack
to the reputation score

• Build a recruiter verification portal: employersRecommended

Category can paste an attestation
Options hash and see a
verified score without connecting a wallet
Frontend React, [Link], TailwindCSS
• Add a reputation changelog: show how the score has evolved over time as new data is
APIs GitHub REST API, LinkedIn API, Stack Exchange API, [Link] API
pulled
Backend [Link] + Express, FastAPI
• Implement ZK-proof verification: allow users to prove their score exceeds a threshold
without
Blockchain revealing the exact
/ Attestation number
Ethereum Attestation Service (EAS), Solidity (custom contract)
Wallet Integration MetaMask, [Link], wagmi
Database PostgreSQL, MongoDB (cached reputation data)
Suggested Tech Stack
Testnet Ethereum Sepolia
Category Recommended Options
Frontend React, [Link], TailwindCSS
Evaluation
APIs Criteria GitHub REST API, LinkedIn API, Stack Exchange API, [Link] API
Criterion
Backend [Link] + Express, FastAPI Weight Max Points
Data Aggregation
Blockchain Quality & Platform
/ Attestation Coverage
Ethereum Attestation Service (EAS), 25% 25
Solidity (custom contract)
Reputation Score Algorithm Transparency
Wallet Integration MetaMask,&[Link],
Fairnesswagmi 25% 25
On-Chain
Database Attestation & Verifiability 25% data)
PostgreSQL, MongoDB (cached reputation 25
Shareable
Testnet Profile & Embeddable Badge UX
Ethereum Sepolia 15% 15
Innovation & Bonus Features 10% 10

Evaluation
What Criteria
to Deliver
Teams may submit any of the following (or a combination):
Criterion Weight Max Points
• Working prototype: A live or recorded demo of the system in action
Data Aggregation Quality & Platform Coverage 25% 25
Reputation Score Algorithm Transparency & Fairness 25% 25
On-Chain Attestation & Verifiability 25% 25
Shareable Profile & Embeddable Badge UX 15% 15
Innovation & Bonus Features 10% 10

What to Deliver
Teams may submit any of the following (or a combination):
• Working prototype: A live or recorded demo of the system in action
 • Architecture design + demo: A well-documented architecture diagram with a walkthrough
demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview, and key design
decisions.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
 Problem Statement 4.1
4.6

Zero-Waste Marketplace
QuestLearn
Hyper-Local Food Sharing
Gamified Learning Portal
Platform
⏱ Duration 👥 Level 📦 Deliverable 🏆 Track
36 Hours Intermediate Any Format Web Development

Background & Context

Background
Online learning has & Context
a well-documented completion problem. The average MOOC completion
rate is under 10%
Every day, restaurants, — not because
catering learners
companies,lack wedding
intention,halls,
but because traditional throw away tonnes of
and households
e-learningedible
perfectly formatsfoodare passive,
simply provide
because delayed
it was cooked feedback,
in excessand or isfail to sustain motivation
approaching its expiry date. Meanwhile,
beyond the first session. Video lectures and text lessons do not activate the
millions of people go to bed hungry within the same neighbourhoods. This is not a supply problem; it is a same
neural rewardand
coordination circuits as games,
distribution where progress is visible, feedback is instant, and
problem.
every
NGOssmall and achievement
food banks exist is explicitly celebrated.
to bridge this gap, but they struggle with two fundamental challenges:
discovering available food in
Gamification — applying game design elementsreal time before it spoils,
such asand XP coordinating pickup logistics.
points, level progression, skill A technology
platform that connects food donors with collectors — with
trees, streaks, and leaderboards to non-game contexts — has been shown in multiple peer-real-time expiry alerts and geolocation
matching — can eliminate this coordination gap.
reviewed studies to increase e-learning completion rates by 40–60%, improve knowledge
retention, and dramatically boost daily active engagement. When learners earn XP for a
Problem Statement
quiz, unlock a new skill tree branch, or compete on a leaderboard, learning becomes a
Build
gameZero-Waste
they want toMarketplace
play rather than — a aProgressive
task they mustWebcomplete.
App (PWA) that enables food donors (restaurants,
households, event organizers) to list available food items with quantity, pickup window, and location.
Local NGOsStatement
Problem and volunteers can discover nearby listings in real time, claim items, and coordinate pickup
— reducing food waste while feeding those in need.
Build QuestLearn — a fully gamified, interactive learning platform where content is
Core
structured Requirements
as Quests that users complete through lessons, mini-challenges, and quizzes.
The platform must implement a complete game mechanics layer — XP points, level
1. Donor-Side Features
progression, a visual skill tree, daily streaks, achievement badges, and real-time
• Allow —
leaderboards donors to register
to create and create
a self-reinforcing foodloop
game listings: food learners
that keeps type, quantity,
engageddietary
and info (vegan,
contains nuts), pickup window (start time, expiry time), and pickup location (GPS or address)
returning every day.
• Send automated "expiry approaching" push notifications to nearby collectors 1 hour before the
listing expires
Core Requirements
• Allow donors to view their listing history and impact statistics (total food donated, pickups
completed)
1. Course & Quest Structure
2. Collector-Side
• Allow courseFeatures creators to structure learning content as Quests — each Quest contains: a
• topicDisplay a real-time
title, one or more mapLessons
(Leaflet (text/markdown
or Google Maps) showing
with embedded activemedia),
food listings within a user-
a Mini-Challenge
configurable radius
or coding exercise, and a Quiz that must be passed to unlock the next
•• Implement
Allow collectorsa visualto filter
Skilllistings by foodare
Tree: Quests type, dietary
nodes in arequirements, and pickup
directed dependency window
graph;
• Implement a one-tap "Claim" feature that reserves a listing
completing a Quest unlocks its successor nodes; locked Quests are visually greyed for 30 minutes and notifies
outthe donor
and display prerequisite requirements on hover
3. Trust & Safety
• Support at least three content types: interactive multiple-choice / fill-in-the-blank
• Implement a Trust Score system for both donors and collectors, based on completed pickups,
Quiz, text/markdown Lesson with embedded images or video, and a Coding Challenge with
ratings, and on-time rates
a sample input/expected output pair
• Allow users to rate each transaction (1–5 stars with optional comment)
• Allow course creators to set XP reward values per Quest and per correct quiz answer,
• Flag accounts with repeated cancellations or low ratings for admin review
and configure a minimum passing score (e.g. 70%) required to unlock the next Quest
4. PWA & Offline
• The app must function as a PWA: installable on mobile, with offline access to previously
loaded listings and a queued "claim" action that fires when connectivity is restored
Bonus Challenges (Optional)

• Implement an AI-powered Adaptive Quiz Engine: adjust question difficulty based on

the learner's past performance using a spaced repetition algorithm (SM-2) or Item
Response Theory (IRT); show harder questions for consistently correct answers

• Add a Code Sandbox: embed an in-browser editor (Monaco or CodeMirror) for

programming Quests with automatic test case validation via a sandboxed execution API
(Judge0)

• Build a Multiplayer Quiz Battle mode: two learners answer the same question set
simultaneously; first to 10 correct answers wins bonus XP and a special battle badge

• Implement a Creator Economy: community members can submit Quests for review;
accepted Quests earn the creator XP and a Creator badge; top creators are featured
on the homepage

Suggested Tech Stack

Category Recommended Options

Frontend React / [Link], TailwindCSS, Framer Motion (animations)

Skill Tree Viz React Flow, [Link], or [Link]

Backend [Link] + Express, FastAPI, or Supabase (BaaS)

Database PostgreSQL / Supabase, Redis (XP cache, streak data)

Real-Time [Link] or Supabase Realtime (leaderboard live updates)

Auth Firebase Auth, [Link], or Supabase Auth

Code Sandbox Judge0 API, Monaco Editor (bonus coding challenge

feature)

What to Deliver

Teams may submit any of the following (or a combination):

• Working prototype: A live or recorded demo of the system in action
• Architecture design + demo: A well-documented architecture diagram with a walkthrough demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with setup instructions, architecture overview,
and key design decisions.
Rules & Constraints
• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline
Open Innovation
 Open Innovation Challenge

Bring Your Own Idea

Build Anything That Makes a Difference
Duration Team Size Deliverable Track
36 Hours 2–4 Members Any Format Open Innovation

Background & Context

The four defined tracks of Hackathon 2026 cover a broad landscape of technology — but
the most transformative ideas rarely fit neatly into predefined categories. History's
most impactful innovations often emerged from the intersection of disciplines, from
unexpected angles, or from problems nobody had thought to frame as a challenge yet. Open
Innovation exists to give those ideas a home.

If your team has a compelling problem you want to solve — one that does not fall within
the existing four tracks, or one that cuts across multiple tracks — the Open Innovation
challenge is your space. There are no prescribed problem statements here. The only
requirement is that your idea is original, technically ambitious, and creates genuine
value for real users.

What is Open Innovation?

Open Innovation is an unrestricted track where teams define their own problem statement,
design their own solution, and build a working prototype over 36 hours. You are not
competing against teams in the other tracks — you are judged entirely on your own
merits: the clarity of the problem you identified, the quality of your solution, and the
potential impact of what you built.

What Can You Build?

Your submission can be anything — a product, tool, platform, research prototype, or

experience — as long as it meets the core requirements. To spark ideas, some broad
directions that teams have found fruitful in past hackathons:
• Accessibility & Assistive Technology — tools that meaningfully improve the lives of
people with disabilities, language barriers, or limited digital literacy
• Climate & Sustainability — applications that help individuals, businesses, or
governments reduce environmental impact or adapt to climate change
• Education & Skilling — platforms that improve learning outcomes for underserved
communities, non-traditional learners, or emerging skill sets
• Healthcare & Mental Wellness — tools that improve access to health information,
early detection, mental health support, or medication adherence
• Financial Inclusion — solutions that bring affordable financial services to unbanked
or underbanked populations
• Government & Civic Tech — platforms that improve public service delivery,
transparency, or citizen engagement with government
This list is illustrative, not exhaustive. If your idea does not fit any category above
but solves a real problem in a novel way, it is welcome here.
Core Requirements

1. Define a Clear Problem Statement

• Submit a written Problem Statement (max 300 words) in your README covering: the user
group affected, the pain point being solved, and why existing solutions are
insufficient
• The problem must be real and verifiable — not hypothetical. Reference publicly
available data, research, or lived experience to validate it

2. Build a Working Prototype

• Deliver a functional prototype demonstrating the core value proposition end-to-end —
not a slide deck, Figma mockup, or video concept
• The prototype must be operable by a judge without the team present; provide clear
setup and usage instructions in the README
• At minimum, demonstrate: the primary user flow, one full end-to-end scenario, and the
key differentiating technical feature

3. Demonstrate Real-World Feasibility

• Include a section in your README on deployment path: who would use it, how it would
reach them, and what the next three development milestones would be
• Address data privacy, safety, and ethical considerations — especially if your solution
handles sensitive user data or affects vulnerable populations

4. Technical Depth & Execution Quality

• The solution must demonstrate genuine technical effort appropriate to the 36-hour
timeframe — judges will review source code and architecture
• All code must be original and version-controlled in a public or shared Git repository;
clearly document any third-party APIs or libraries used
• Bonus marks for: scalability considerations, security implementation, test coverage,
and clean system design

Bonus Challenges (Optional)

• Conduct at least 3 structured user interviews and share key insights in your README
— demonstrating evidence-based product design

• Build and deploy a publicly accessible live version of your prototype on free-tier
cloud hosting so judges can interact without any local setup

• Implement an in-product feedback loop: collect user feedback, display an analytics

dashboard, or log usage patterns for future iteration

• Pitch a sustainable model: describe how the solution sustains itself financially or
operationally beyond the hackathon
What to Deliver

Teams may submit any of the following (or a combination):

• Working prototype: A live or recorded demo of the full end-to-end user flow
• Architecture design + demo: A well-documented system diagram with a walkthrough demo
• Full pipeline demo: Showing all required components functioning end-to-end

All submissions must include a README with: problem statement, architecture overview,
setup instructions, key design decisions, and the team's problem validation approach.

Judging Criteria

Open Innovation submissions are evaluated on five dimensions by a panel of industry

practitioners, academics, and impact investors.

Problem Clarity & Validation

Is the problem real, well-defined, and backed by evidence? Does the team demonstrate deep
understanding of the user and context?

Solution Originality & Insight

Is the approach genuinely novel? Does it reframe the problem or apply technology in a way
that is not immediately obvious?

Technical Execution
Is the prototype functional and technically sound? Does the implementation show
engineering depth and thoughtful system design?

Potential Impact
If deployed at scale, how many people would benefit and how significantly would their
situation improve?

Presentation & Communication

Can the team articulate the problem, demo the solution, and answer questions clearly in a
5-minute pitch?

Important Notes

Open Innovation teams must declare their track at registration and may not switch to
another track after the hackathon begins. A panel of at least three judges will
independently score each submission; the final score is the average.

Rules & Constraints

• Team size: 2–4 members
• All code must be version-controlled in a Git repository (public or shared with judges)
• No real production credentials or sensitive data; use sandbox / test environments
• Cloud spend, if any, is the responsibility of the team — use free tiers where possible
• Open-source tools only; no proprietary enterprise licenses required
• Submissions must be made via the hackathon portal before the 36-hour deadline