Roadmap & vision
Pilot timeline, planned phases, and future campus modules.
02 · Build Journey
From monorepo to MST Testnet pilot.
Six weeks of shipping — May 27 foundation through June 24 OS on-chain fixes. Dates reflect actual git and MSTScan milestones.
Foundation
Monorepo scaffold: 90+ Solidity contracts, NestJS API (37 controllers), Prisma schema (77 models), and Next.js role-based OS shells.
Frontend & deploy wiring
Five OS portals (Student, Faculty, Admin, Recruiter, Founder), Vercel build fixes, wagmi/MetaMask on MST, and initial Render + PostgreSQL deploy.
Zero-knowledge circuit
Circom credential policy compiled; Groth16 wasm/zkey artifacts generated; verifier contract prepared for MST deployment.
MST Testnet deployment
70+ UUPS proxy contracts deployed to chain 91562037 — CredentialRegistry, StudentRegistry, DYPCOEGovernor, CampusVotingProtocol, Groth16Verifier, and campus economy modules.
Production hardening (Phase A)
Fail-closed IPFS (no QmMock*), SIWE nonce replay block, persisted indexer cursor, CORS allowlist, unified relayer credential path, Slither fixes, feature reality matrix.
On-chain E2E evidence (Phase A/B)
Student1 IPFS backfill, CampusVoting poll id 0, first DYPCOEGovernor.propose on MSTScan, OZ Governor v5 signaling fix, API health green on Render.
OS on-chain bug fixes + MDVS alignment
Scholarship pre-flight ops, credentials MSTScan testnet links, allowance parent lookup + indexer, resume add/delete + anchor, faculty camera scanner stability, E2E rows 25–29 documented (954e3ee7).
Institution pilot readiness
Close remaining E2E matrix rows, Render production browser tests, relayer funding ops, and faculty/student onboarding runbooks.
Core Product · Document Verification Workflow
From upload to permanent, verifiable anchor.
The file is never on the chain. The proof is. That single sentence answers almost every hard technical question this product will get asked.
Student connects wallet via SIWE (cryptographic proof of ownership, no password). Document exists only in browser memory.
Stored: Nothing persisted yet
The document is hashed with SHA-256 entirely inside the browser — a unique fingerprint that changes if even one byte is altered.
Stored: A fingerprint of the file
The file is encrypted with AES-GCM-256 before it ever reaches a server. The plaintext never leaves the browser.
Stored: Encrypted blob
The encrypted blob is pinned to IPFS via Pinata, returning a content-addressed identifier (CID). The CID is the file's permanent address.
Stored: Encrypted blob, addressed by CID
The authorized institution role anchors the CID and the hash on-chain through DocumentRegistry.sol. The chain emits an event; nothing can be unwritten.
Stored: CID + hash, permanently
A backend indexer picks up the chain event and writes it into Postgres, carrying the transaction hash so the two records can always be reconciled.
Stored: Postgres row, linked to tx hash
Anyone re-computes the hash and compares it against what's on-chain. A match proves, mathematically, that the document is exactly what was issued. No login, no decryption, no gatekeeper.
Stored: A comparison, nothing new written
Verification requires no login, no decryption, and no institutional gatekeeper.
Anyone with the document reference — a recruiter, a foreign university's admissions office, another node on MST itself — can hit a public verification route. The system re-computes the hash and compares it against what's permanently recorded on-chain. A match proves, mathematically, that the document is exactly what the institution issued. No plaintext is ever exposed.
03 · Implementation
The trust layer for education — built and piloting on MST.
We built the specific infrastructure that makes a credential trustworthy without a phone call. The file never touches the chain; the proof does.
Live pilot at DYPCOE Akurdi — honest REAL / PARTIAL / MOCK labels from FEATURE_REALITY_MATRIX.
1 · Overview
Platform at a glance
51
Smart contracts
Identity, governance, campus finance
77+
Prisma models
Students, credentials, disputes, finance
4
Governance layers
Board → IT → Data → Protocol
1
Live pilot
DYPCOE Akurdi, Pune
2 · Live status
What works in the repo today
REAL = end-to-end on MST with DEMO_MODE=false. Detailed build steps are in Feature tracks below.
SIWE wallet login
Nonce-bound replay-safe signing
Credential relayer issuance
EIP-712 → Pinata → CredentialRegistry mint
Public verify (QR, ZK, doc hash)
Camera QR · Groth16 0xdCdB3a6b… · POST /documents/verify-hash
Document vault decrypt
Client-side AES via DocumentViewerModal
Attendance scanner
CampusQrScanner → wallet QR → POST /attendance/scan
Scholarship disbursement
AutomatedScholarship.distributeScholarships on MST
Hostel escrow
HostelEscrow.depositSecurity via ChainPay
Student allowance
ConditionalAllowance balance + payVendor
Resume anchor
Pinata JSON + DocumentRegistry.issue
Anti-plagiarism oracle
Gemini + AntiPlagiarismOracle tx on submit
API health + indexer
GET /api/v1/health — DB, Redis, RPC, IPFS, relayer
Student ID card + NFT
DocumentRegistry TX live; CredentialRegistry mint needs relayer ISSUER_ROLE
Learning passport publish
IPFS publish REAL; SBT balance 0 until credential mint succeeds
DAO governor UI
On-chain propose/vote/execute; off-chain stubs being removed
Campus jury / disputes
CampusJury resolveDispute on MST; grievance merge in progress
ChainPay settlement
TuitionVault deposit after webhook; per-college fee catalog planned
ERP records / enrollment
ENROLLED lifecycle + registries; multi-college import planned
Document vault upload E2E
Encrypt + Pinata + DocumentRegistry; production browser proof ongoing
Faculty vault
HOD share grants; ops validation needed
Founder finance / DeFi demo
Demo treasury flows only
Cross-chain bridge
Gated by NEXT_PUBLIC_SHOW_EXPERIMENTAL_CROSS_CHAIN
The Graph subgraph
Direct RPC + DB indexer used instead
Marketplace / ISA / syndicate
501 or demo paths outside credential core
3 · Stack
Four-layer architecture
ERP pillars and registrar workflows are in Institution Architecture ↓
Frontend
Next.js · wagmi · SIWE
Wallet sign-in, uploads, dashboards, public verify
Backend
NestJS · BullMQ · WebSocket
API logic, event indexing, real-time sync
Storage
PostgreSQL · IPFS/Pinata
Off-chain state; encrypted decentralized files
Chain
MST 91562037 · Solidity/UUPS
Hash + CID anchors; governance & credentials
Institution Architecture →
ERP, Administration, and Governance pillars for multi-college scale.
4 · Verify paths
How verification works
Full upload → hash → encrypt → pin → anchor flow is in Core Workflow ↑
/verify/{wallet}
Learning passport
ID card, enrollment, attendance QR, soulbound credentials
Checks: IdentityRegistry, StudentRegistry, CredentialRegistry SBT, VerificationRegistry
/verify/doc/{cid}
Document proof
Vault uploads, marksheets, PDF credentials with doc QR
Checks: DocumentRegistry hash match, campus DB index, optional ZK proof
MDVS Core Workflow →
Step-by-step visual: SIWE upload, SHA-256, AES-GCM, Pinata, DocumentRegistry anchor, indexer, public verify.
5 · Feature tracks
Implementation by pillar
Contract → API → UI → E2E evidence. Expand any track for build steps.
6 · Ops & gates
Blockers and production requirements
Relayer ISSUER_ROLE
Render relayer must hold ISSUER_ROLE on GovernanceRegistry. Run grant-relayer-issuer.ts; confirm via GET /health → hasIssuerRole.
Re-issue ID cards after role grant
Students with DocumentRegistry TX but NFT balance 0 need admin re-issue so mintCredential succeeds.
Production E2E evidence
OS rows 25–29 need browser proof on Render/Vercel URLs.
External audit before mainnet
Credential core requires third-party smart contract audit before MST mainnet pilot.
Production gates
04 · Institution Architecture
Three pillars to sell this platform to every college.
dypcoe on chain proves the credential protocol on one campus. Scaling to other institutions requires documented ERP, Administration, and Governance architectures — each anchoring critical events on MST consensus.
Full architecture docERP System Architecture
Student information, finance, attendance, placements
Every college runs academic and financial records in siloed ERPs. dypcoe on chain mirrors critical lifecycle events on MST while Prisma holds operational truth.
Today on dypcoe on chain
- ✓Prisma SIS — 77 models, student lifecycle ENROLLED → IdentityRegistry + StudentRegistry
- ✓Attendance anchor — Merkle batch + AttendanceRegistry.recordBatch
- ✓ChainPay + TuitionVault settlement webhooks
- ✓Scholarships — AutomatedScholarship.distributeScholarships with pre-flight ops
- ✓Grade lock + DocumentRegistry manifests
Required for multi-college scale
- ○Per-college tenant configuration and branding
- ○ERP CSV/API import for legacy SIS migration
- ○Academic calendar + fee rule templates per institution
- ○NAAC/NBA accreditation report packs from on-chain evidence
Administration Architecture
Registrar, HOD, relayer ops, compliance
Registrars must approve who can issue credentials, audit every action, and operate relayer/IPFS infrastructure without exposing private keys to faculty.
Today on dypcoe on chain
- ✓Admin OS — faculty issuer approval (grantFacultyChainRoles)
- ✓Unified audit timeline — audit_logs + blockchain_events + payment_orders
- ✓Production gates script (verify-production-gates.ts)
- ✓ISSUER_ROLE preflight on faculty issuance
- ✓Relayer health in GET /health
Required for multi-college scale
- ○Institution onboarding runbook (wallet, roles, Pinata, relayer funding)
- ○HOD/registrar RBAC templates per department
- ○SLA + observability stack (Render/Vercel monitoring)
- ○White-label branding per campus deployment
Governance Architecture
On-chain policy, disputes, treasury, upgrades
Multi-college rollout needs transparent upgrade paths, dispute resolution, and student/faculty voice in campus policy — not opaque admin overrides.
Today on dypcoe on chain
- ✓GovernanceRegistry — ISSUER_ROLE, REGISTRAR_ROLE, DEFAULT_ADMIN_ROLE
- ✓DYPCOEGovernor — propose, vote, execute on MST Testnet
- ✓CampusJury — resolveDispute for grievances
- ✓CampusVotingProtocol — poll create from approved MarketRequests
- ✓Indexer sync for ProposalCreated, VoteCast, DisputeOpened
Required for multi-college scale
- ○Multi-sig treasury for relayer and endowment funds
- ○UUPS upgrade playbook per proxy with timelock
- ○Dispute SLAs and escalation to accreditation bodies
- ○Syllabus/policy voting at scale across departments
Governance Architecture · Four-Layer Model
Who decides. Who owns. Who audits. What happens when things go wrong.
Built from four established governance disciplines: IT governance (COBIT 2019), data governance (DAMA-DMBOK), records governance (ISO 15489), and operational DAO practice. Authority escalates upward — only strategic or accreditation-relevant matters ever reach the Governing Board.
Data Domain Ownership (DAMA-DMBOK aligned)
Each data domain has a named Data Owner (accountable) and Data Stewards (operational). Sensitivity levels are tagged at the Prisma schema field level.
| Data Domain | Owner | Sensitivity |
|---|---|---|
| Academic records & credentials | Registrar / Controller of Examinations | Restricted |
| Student personal & contact details | Admissions / Registrar | Confidential |
| Financial records (fees, ISAs, hostel escrow) | Finance Officer | Restricted |
| Faculty records & payroll | HR / Establishment | Restricted |
| Placement & recruiter interaction data | Training & Placement Officer | Confidential |
| Bulletin, blogs, general announcements | Communications | Public |
RACI Responsibility Matrix
R = Responsible, A = Accountable, C = Consulted, I = Informed
| Decision | Board | Principal | IT Steering | Data Gov | DAO |
|---|---|---|---|---|---|
| Annual roadmap approval | A | R | R | C | I |
| Data classification policy | I | A | C | R | — |
| Records retention schedule | A | R | C | R | — |
| Production release / change | I | I | A | C | — |
| Admin role grants (Super Admin) | I | A | R | C | — |
| DPDP compliance & DPO appointment | A | R | C | R | — |
| Smart-contract upgrade | I | C | C | I | A/R |
| Treasury spend above threshold | I | C | I | — | A/R |
| NAAC/AICTE evidence export | I | A | C | R | — |
Risk Register & Security Governance
Named risks with governance controls — not a generic threat model.
Educational institutions in India face higher weekly attack rates than global average
Control: Mandatory security review before each release (CAB); incident-response runbook; periodic pen testing
Unrestricted Admin CRUD access (legacy design)
Control: Tiered admin roles, dual control on Super Admin, full write-audit log
Single deployer key controlling upgrades or treasury
Control: Multisig + timelock for all upgrade and treasury actions
DPDP Act non-compliance; unsettled legal status of token governance in India
Control: Named DPO; annual DPIA; legal counsel review before any token feature reaches production
Divergence between on-chain events and off-chain database after indexer lag
Control: Lineage pointers from every derived record back to source transaction
Dependence on Pinata, ChainPay, RPC providers with no fallback
Control: Documented vendor risk register reviewed annually by IT Steering Committee
Compliance & Regulatory Alignment
Built for Indian law, accreditation, and international records standards.
Digital Personal Data Protection Act, 2023
- Student data is personal data under Indian law with real financial penalties for mishandling.
- Named Data Protection Officer (DPO) required — appointed by the Principal.
- Annual Data Protection Impact Assessment (DPIA) before any AI feature processes student data.
- Client-side encryption and cryptographic hashing satisfy "reasonable security" expectations.
- Consent-driven architecture: students control vault access grants, not admin overrides.
NAAC / AICTE / NBA Accreditation
- NAAC's 2025 reforms moved SSR to fully digital, DVV-verified format with automated cross-referencing.
- Inconsistencies between institution claims and its systems are now algorithmically flagged (AISHE, NIRF, UGC).
- Platform guarantees student-progression records (Criterion II), research output (III), placement data (V), and governance evidence (VI) are exportable in matching format.
- A mismatch between the ERP and the AQAR is now a specific, automatically-detected accreditation risk.
- Binary Accreditation / Maturity-Based Graded Levels framework is directly served by this governance layer.
ISO 15489 — Records Management
- A trustworthy record must survive four tests: authentic, reliable, complete, and usable years later.
- Platform lifecycle — hash before encryption, encrypt before pinning, anchor before indexing — satisfies all four.
- Board-approved retention schedule states how long each record type must be kept.
- Logged chain-of-custody trail every time faculty or recruiter requests decryption access.
- On-chain-anchored documents have an internationally recognized basis for legal reliability.
Institutional Case
Why colleges structurally need this.
| Requirement | Why It's Non-Negotiable |
|---|---|
| Institutional control over issuance | A college cannot adopt a system where anyone can mint an official credential. |
| Statutory retention & legal defensibility | Marksheets and degrees carry legally mandated retention periods. |
| DPDP Act compliance | Student data is personal data under Indian law, with real financial penalties. |
| Works without every student owning crypto | Most students aren't wallet-native — friction kills adoption before it starts. |
| Exportable evidence for NAAC/AICTE | Accreditation cycles need clean digital evidence, not a new silo to reconcile. |
| No permanent public exposure of private data | A public ledger with plaintext student data is a compliance and reputational failure. |
Commercial Model
How MST Blockchain sells this to other institutions.
Nobody buys "blockchain." Institutions buy "my accreditation evidence is cleaner" and "my placement office stops fielding verification calls." Sell the outcome.
Licensing Models
Per-student annual license
Flat fee per enrolled student per year
Best fit: Predictable-budget institutions
Per-verification fee
Small fee paid by the verifying party
Best fit: High verification-volume institutions
Onboarding/integration fee
One-time fee to migrate records & configure a factory instance
Best fit: Every new institution, any pricing model
Freemium ERP + paid verification
Base ERP free/low-cost; blockchain layer as premium tier
Best fit: Budget-constrained land-and-expand
Competitive Position
Traditional campus ERP
No cryptographic verification — still requires manual third-party checks.
Credential-only tools (Blockcerts)
Issuance only, no integrated ERP, fees, hostel, or attendance layer.
Centralized Web2 e-verification
Trust depends on trusting the company, not the math.
Sales motion: Lead with the live DYPCOE pilot — a working verification link outperforms any slide deck. Route onboarding through SARAL Protocol. Sell through existing multi-campus trust relationships first.
Ideal Customer Profile
Autonomous colleges & multi-campus trusts
Already funding digital-infrastructure upgrades.
Institutions mid-cycle on NAAC/AICTE
Digital-evidence requirements reduce compliance burden.
Placement-heavy technical institutes
Faster recruiter-side verification is a visible differentiator.
Global Readiness
From one college to every university, in every country.
Priority #1: Credential Interoperability
If only one upgrade happens next, make it W3C Verifiable Credentials. A credential that only this platform can verify is a walled garden. A credential that speaks W3C VC can be checked by any verifier on earth using open tooling — that is the actual difference between "on-chain for one college" and "on-chain, everywhere."
Phased Governance Maturity
Each technical phase clears a governance gate first.
Governance maturity and technical maturity advance together — not governance being retrofitted after a security or compliance incident forces it.
Data classification policy drafted; RBAC model replaces unrestricted Admin CRUD; retention schedule drafted.
DPIA completed for any AI system processing student data; DPO sign-off on RAG data sources.
Agent action boundaries defined; no autonomous agent gets Super Admin-equivalent rights.
External audit of bridge/CCIP contracts before any credential leaves the institutional registry.
Governing Board sign-off specifically required — treasury includes hostel/tuition deposits.
Independent security audit complete; multisig + timelock live on all upgrade paths.
DPDP-equivalent review for every new jurisdiction; legal-wrapper review if DAO treasury scales.
09 · Roadmap
What we ship next — and when.
Phases A–E from the production hardening roadmap. We do not claim mainnet until an external audit clears the credential core.
Phase A — P0 hardening
- ·Remove mock IPFS/ZK/oracle paths outside demo mode
- ·Unified relayer credential issuance
- ·ProtectedRoute + on-chain preflight on critical flows
Phase B — Pilot polish
- ·Complete 9-flow + OS surface E2E verification on production URLs
- ·Document vault Render proof + maturity badges on demo modules
- ·Relayer balance monitoring, scholarship ops scripts, and ops runbook
Phase C — Governance depth
- ·DAO UI wired to live governor proposals
- ·Campus voting visible in app (poll id 0+ on-chain)
- ·GrantManager indexer sync
Phase D — Campus finance
- ·CampusBonds with real testnet tokens (remove mock stablecoin from prod UI)
- ·Treasury visibility grounded in on-chain balances
- ·Honest empty states for DeFi demos
Phase E — Scale & audit
- ·The Graph subgraph for credential/governor events
- ·PWA + mobile audit
- ·External smart contract audit
- ·Mainnet readiness playbook
MST mainnet pilot
- ·Post-audit contract redeploy
- ·Institution SLA + observability stack
- ·NAAC/NBA verification script partnerships
08 · Honest Readiness
Built for pilots. Transparent about maturity.
We pitch ambition with integrity. Production-ready MVP paths are live on MST Testnet; demo modules are clearly labeled.
Credential issuance (relayer + IPFS + SBT)
Unified RelayerService; real Pinata CIDs; ISSUER_ROLE gate; MSTScan links use testnet.mstscan.com.
Public verification portal (/verify)
Wallet-free on-chain + IPFS reads; demo paths gated by DEMO_MODE.
ZK threshold verification (Groth16)
Verifier 0xdCdB3a6b… on MST; wasm/zkey in repo; verify on Render after deploy.
Faculty issuer onboarding
Admin-approved grantFacultyChainRoles with audit trail — no auto-grant on registration.
Student profile IPFS + StudentRegistry
Live path + Student1 backfill (Jun 17); Student2 registration pending.
Document vault (encrypt + Pinata + on-chain)
Production API path exists; Render browser E2E not yet in evidence log.
Wallet login (SIWE)
Nonce-bound replay-safe flow; role onboarding policy tightening.
DAO & campus voting
Poll id 0 + governor propose on MSTScan (Jun 17); DAO UI partly off-chain; SyllabusDAO demo.
AI copilot & skill genome
Gemini chat + anti-plagiarism oracle; genome grounded in attendance + credentials.
Student resume + anchor
Add/delete experience rows; POST /students/resume/me/anchor on DocumentRegistry. E2E row 27 pending Render proof.
Conditional allowance wallet
GET /students/allowance/me + parent deposit API; indexer AllowanceDeposited events. ChainPay auto-deposit planned.
Campus finance (bonds, ISA, DeFi)
Contracts on testnet; UI uses mock/demo data — not production finance.
Marketplace / alumni / ISA APIs
Backend returns 501 Not Implemented; nav hidden or beta-badged.
MST mainnet deployment
External audit, subgraph, and gas optimization required first.