Decentralised Academic Assistant
Build a system that combines blockchain smart contracts, artificial intelligence, and Node.js to create an immutable, intelligent academic communication platform.
Context & Motivation
In modern universities, communication between professors and students is scattered across emails, WhatsApp groups, learning platforms, and in-class announcements. This fragmentation creates two fundamental problems:
Information Fragmentation
Students don't know where to find important information. They repeatedly ask the same questions: "Is there class today?", "When is the next exam?", "Did the professor share the exercises?" — consuming the professor's time.
Lack of Provable Trust
When a student claims "I was never informed about the exam", there is no irrefutable proof that the announcement was published — or that the student received it. A server admin could alter logs retroactively.
The Scrooge Problem — Again
Remember Module 3? A centralised server controlled by a single admin is exactly ScroogeCoin's problem: one entity can censor, modify, or delete records. The blockchain solves this by making records immutable and verifiable by all parties — professor, student, and administration — without trusting any single party.
Your mission: build a decentralised academic assistant that centralises communications through an intelligent agent, automates student responses, and guarantees the integrity of critical announcements using blockchain technology.
Project Vision
The system revolves around an intelligent central agent that acts as a living memory of the course. It combines two pillars:
Blockchain (60%)
Smart contracts guarantee immutability, traceability, and non-repudiation. Announcements, document hashes, and student acknowledgments are recorded on-chain. No single party can tamper with the records.
Artificial Intelligence (20%)
A conversational agent powered by RAG (Retrieval Augmented Generation) lets students query announcements, documents, and schedule in natural language. The AI is a facilitator — the blockchain is the source of truth.
Core Principle
The AI makes the blockchain accessible. The blockchain makes the data trustworthy. Node.js ties everything together.
System Actors
Technical Architecture
Technology Stack
Smart Contracts — The On-Chain Core
The blockchain layer is the foundation of the system. You will design, implement, and test four smart contracts that guarantee immutability, access control, and provable communication.
AnnouncementLog.sol
The central contract. Every critical announcement (exam date, homework deadline, schedule change) is recorded on-chain with a content hash, category, target group, timestamp, and publisher address.
- publish() — Only accounts with
PROFESSOR_ROLEcan publish. Emits anAnnouncementPublishedevent. - verify() — Anyone can verify an announcement's integrity by comparing its content hash with the on-chain record.
- Events — Every publication emits an event with indexed fields for efficient off-chain querying.
Uses: OpenZeppelin AccessControl (M9), events & modifiers (M7), structs (M8).
DocumentRegistry.sol
When the professor uploads a PDF or exercise sheet, the backend computes its SHA-256 hash and stores it on-chain. Anyone can later verify the document wasn't modified by recalculating the hash and comparing.
- register() — Stores file hash, file name, target group, and timestamp.
- verifyDocument() — Compares a given hash against the on-chain record.
This is exactly the hash pointer concept from Module 2, applied to real documents.
AcknowledgmentLog.sol
When a student views an announcement, they sign a transaction — creating cryptographic, timestamped proof that they were informed. This solves the "I didn't know" problem permanently.
- acknowledge() — The student's wallet signs the TX → non-repudiable proof of awareness.
- Events —
Acknowledged(announcementId, student, timestamp)for off-chain tracking.
Digital signature = proof of identity (M2). Signed transaction = non-repudiable action (M3).
RoleManager.sol
Manages on-chain roles (ADMIN, PROFESSOR, STUDENT) and group membership. Each wallet address is mapped to a role and a group (e.g., MF1, MF2). The agent uses this to filter announcements by group.
- assignRole() / assignGroup() — Admin-only role and group management.
- getRole() / getGroup() — Used by the backend to enforce permissions before responding.
Testing Requirement
All four contracts must have TypeScript tests using viem (Module 11 patterns). Test scenarios: publish as professor ✅, publish as student ❌, verify correct hash ✅, verify tampered hash ❌, acknowledge as correct group ✅, acknowledge as wrong group ❌.
Backend Node.js & AI Agent
The Node.js backend is the orchestrator. It connects the frontend interfaces to both the blockchain and the AI agent.
REST API
| Endpoint | Method | Who | Description |
|---|---|---|---|
POST /api/announcement |
POST | Professor | Publish announcement → hash on-chain + index in vector store |
POST /api/document |
POST | Professor | Upload document → SHA-256 hash on-chain + RAG indexing |
POST /api/chat |
POST | Student | Send question → RAG retrieval → LLM response |
GET /api/announcements |
GET | All | List announcements (filtered by user's group) |
POST /api/acknowledge/:id |
POST | Student | Sign acknowledgment on-chain via wallet |
GET /api/verify/:id |
GET | All | Verify announcement integrity against blockchain |
AI Agent — RAG Pipeline
The agent uses Retrieval Augmented Generation (RAG). Instead of retraining a model, the system retrieves relevant context from its memory and feeds it to the LLM at query time:
Index: Every announcement and document is split into chunks and converted to vector embeddings (stored in a vector database or in-memory store).
Query: When a student asks a question, the query is vectorised and the K most similar chunks are retrieved (cosine similarity).
Generate: The retrieved context + the student's question are sent to the LLM API. The model generates a contextualised response.
Permission-Aware Responses
The AI agent must respect access control. Before responding, the backend checks the student's group (from the RoleManager contract) and only retrieves announcements targeted at "all" or the student's specific group. The system prompt includes the student's identity and group to prevent information leakage.
Frontend DApp
Two web interfaces built with pure HTML, CSS, and JavaScript — no framework needed (consistent with Module 12). Both connect to MetaMask for wallet-based authentication.
Student Interface
CONSUMER- Conversational chat panel (sends to
/api/chat) - Announcement feed filtered by group
- "I've read this" button → signs TX on-chain via MetaMask
- Document verifier: drag & drop a file → compares SHA-256 hash with blockchain
Professor Dashboard
PUBLISHER- Announcement publisher (category, group, content)
- Document uploader with on-chain hash registration
- Acknowledgment tracker: who read what, when?
- On-chain history with block explorer links
Wallet = Identity
There's no traditional login. The user connects their MetaMask wallet, and the backend reads their role and group from the RoleManager smart contract. The wallet address is their identity — just like in Module 2, where public key = identity.
Deliverables & Grading
MVP — Required Deliverables (70%)
1 Smart Contracts
4 Solidity contracts deployed and tested on Hardhat local network. Uses OpenZeppelin AccessControl. All functions documented.
2 Contract Tests
TypeScript test suite with viem. Covers: role-based access, publish/verify flow, acknowledgment flow, edge cases (wrong role, tampered hash).
3 Node.js Backend
Express API with endpoints for announcements, documents, chat, and verification. Integrates with blockchain via viem and with AI via LLM API.
4 AI Conversational Agent
RAG pipeline: indexing, retrieval, and generation. Permission-aware responses filtered by student group. Works with any LLM API.
5 Web Frontend
Student chat interface + professor dashboard. MetaMask connection. On-chain acknowledgment signing. Document verification.
6 Documentation & Demo
README with setup instructions, architecture diagram, and a working live demo or recorded video walkthrough.
Grading Criteria
| Criterion | Weight | Description |
|---|---|---|
| Smart Contracts | 25% | Code quality, correct use of OpenZeppelin, well-designed events, proper access control |
| Contract Tests | 15% | Scenario coverage: publish, verify, acknowledge, role enforcement, edge cases |
| Node.js Backend | 20% | Clean architecture, working API, proper blockchain + AI integration |
| AI Agent / RAG | 15% | Response relevance, context awareness, permission filtering |
| Frontend DApp | 10% | Functional UI, MetaMask integration, on-chain verification working |
| Documentation & Demo | 10% | README, architecture diagram, setup reproducibility, demo quality |
| Code Quality | 5% | Clean code, consistent naming, no hardcoded secrets, modular structure |
Optional Extensions Bonus
Each extension can earn up to 5 bonus points. These are not required but demonstrate deeper mastery.
Hyperledger Besu Deployment
Deploy the contracts on a private 4-node QBFT Besu network using Docker Compose. Same Solidity code, different network — just like Module 17 promises.
Telegram Bot Interface
Add a Telegram bot as an alternative interface to the web app. Students can query the agent directly from Telegram. Uses the same backend API.
Voice Message Support
The professor sends a voice message → automatic transcription (Whisper API) → content analysis → on-chain registration if it contains an announcement.
Automatic PDF Analysis
Parse uploaded PDFs, extract text, split into chunks, and index in the RAG vector store. Students can then ask questions about document content.
Analytics Dashboard
Visualise on-chain data: acknowledgment rates per announcement, average read time, group engagement. Built with Chart.js using event logs.
Security Audit (Slither)
Run Slither static analysis on all contracts. Document findings, fix vulnerabilities, and include the audit report. Applies Module 13 concepts.
Module-by-Module Alignment
This project is designed to apply concepts from across the entire course:
| Module | Concept | Application in Project |
|---|---|---|
| M2 | SHA-256, ECDSA signatures | Hash announcements & documents, sign transactions |
| M3 | The Scrooge Problem | Core motivation: why a centralised server isn't enough |
| M4 | Decentralisation, consensus | Why a multi-node network is more trustworthy |
| M7–M8 | Solidity fundamentals & patterns | All 4 smart contracts |
| M9 | OpenZeppelin AccessControl | Role-based access in AnnouncementLog & RoleManager |
| M10 | Hardhat v3 tooling | Project compilation, deployment, Ignition scripts |
| M11 | Testing with viem | Complete test suite for all contracts |
| M12 | DApp frontend + MetaMask | Student & professor web interfaces |
| M13 | Smart contract security | Slither audit (extension) |
| M17 | Hyperledger Besu private network | Enterprise deployment (extension) |
Summary
This project synthesises the entire course into a single, cohesive application. The blockchain provides trust and immutability. The AI provides accessibility. Node.js provides the infrastructure. Together, they solve a real problem that you experience every day as students. Good luck!