veil

AI Insights Without Identity Exposure Privacy by Default. Intelligence by Design.

Comment 1

Inspiration

Many students never report harassment, bias, or academic abuse because they fear retaliation, embarrassment, or being labeled a troublemaker. Anonymous tip lines often cannot prove the reporter is a real enrolled student, while formal portals usually expose identity from day one. We wanted something in between: a channel where the institution can trust that the person filing is eligible to complain, but where that person’s name does not automatically travel with the report. Veil was inspired by that gap—giving students a safer path to speak up while still giving administrators enough structure to act.

What it does

Veil lets college students file serious complaints—harassment, safety issues, discrimination, academic pressure, bullying, and similar concerns—with their identity hidden from administrators by default. Students verify with their institutional email and a one-time code, then enter a protected workspace to describe what happened in their own words. Before any admin sees the case, the system redacts identifying details (names, roll numbers, emails, and similar information) and turns the report into a categorized, severity-rated, summarized case staff can review. After submitting, students can optionally request that their identity be shared with a committee, with a clear warning before they consent. The core promise is simple: verified student, hidden identity, actionable complaint.

How we built it

We built Veil as a full-stack web application with a student-facing flow from landing and email verification through a protected dashboard. Institutional login gates access; verified sessions unlock the complaint workspace. A privacy processor sanitizes raw complaint text, assigns category and severity, tracks what was redacted, and produces an admin-safe summary and case hash. The dashboard guides students through eligibility, complaint submission (with a processing modal showing results), and optional identity reveal with a confirmation step.

A core part of the build is Midnight Network, a privacy-focused blockchain designed for applications that need to prove facts without exposing sensitive data on a public ledger. We wrote a Veil smart contract in Midnight’s Compact language that stores only what is safe to be public: a student eligibility commitment, proof-verified status, a complaint hash (not the complaint itself), disclosure state (hidden, student-requested reveal, or committee-only), and a case counter. Student credentials and complaint integrity can be anchored on-chain while names, roll numbers, emails, and raw narrative never touch the chain. Our server connects to a local Midnight devnet (node, indexer, and proof server via Docker), deploys the contract, and exposes API routes so the dashboard can register commitments, log complaint hashes, and update reveal state when the network is live. When Midnight is unavailable, the same student flow still runs off-chain so demos and judging are not blocked—but the architecture is built so a pilot school can turn on real on-chain proofs and selective disclosure when ready. That combination—private processing in the app plus provable state on Midnight—is how we connect “verified student, hidden identity” to something institutions can audit without storing PII on-chain.

Challenges we ran into

Balancing demo usability with a real privacy story was hard—we had to auto-bootstrap credentials after login so judges could reach the complaint flow quickly, while still explaining that verification, eligibility, and disclosure are separate ideas. Midnight Network added its own layer of difficulty: the devnet stack (node, indexer, proof server) had to be running and healthy before on-chain steps worked, and ledger reads could hang when the network was slow or misconfigured, which initially blocked the whole dashboard behind a single status check. We solved that with timeouts, background chain writes, and off-chain fallbacks so students could still complete the flow while Midnight caught up or stayed disconnected. Learning Midnight’s Compact contracts and wallet integration—what belongs on-chain versus what must never be disclosed—took iteration; we had to resist putting even hashed or encrypted raw complaints on the ledger and stick to commitments, complaint hashes, and disclosure flags only. Designing selective disclosure on top of that was another challenge: the contract supports hidden, student-requested, and committee-only states, but the UI had to make “request reveal” feel deliberate, with explicit consent, not a casual click. Redaction still had to be strong enough for demos—regex rules catch many PII patterns, but they are not a substitute for production-grade NLP.

Accomplishments that we're proud of

We are proud of shipping an end-to-end narrative people can walk through in minutes: verify, file a complaint, see sanitized output, and optionally consent to reveal. On Midnight, we deployed a real Veil contract with circuits for student commitment registration, complaint hash logging, and reveal requests—proving eligibility and case integrity on a privacy-oriented chain without ever writing raw complaint text or personal details to the ledger. We never put complaint content on-chain; only commitments, hashes, proof-verified flags, and disclosure state. The UI surfaces that boundary—what admins see versus what stays private—and the processing modal makes sanitization tangible with category, severity, and redaction counts. We connected the dashboard to Midnight devnet through deploy scripts and API routes so live demos can show Midnight live when the stack is up, while the same app still runs off-chain when it is not. Tests around complaint processing and contract snapshots mean the MVP is more than slides: it is a working prototype where private processing in the app and provable state on Midnight tell one coherent story.

What we learned

We learned that privacy in grievance systems is as much about UX and policy as cryptography—and that blockchains like Midnight are useful when you treat them as a proof layer, not a database for sensitive text. Students need to understand what “hidden” means, what “reveal” means, and who will see their identity if they consent; on-chain disclosure state only matters if the product explains it in plain language. We learned that institutional email verification and cryptographic eligibility on Midnight solve different problems: email answers “are you a student at this school?” while a commitment and proof on Midnight answer “can this reporter prove eligibility without attaching their name to the case?” Working with Midnight taught us to design contracts around data minimization—only store what you are willing to be public forever in metadata form—and to plan for devnet fragility (timeouts, async writes, graceful degradation). We also learned how to scope an MVP: one magic moment (verified reporter, hidden identity, actionable case) first; full committee admin flows, mainnet pilots, and production-grade NLP later.

What's next for veil

Next, we would connect real email OTP delivery and tie verification to an actual student directory, expand redaction and triage with stronger NLP models reviewed for bias and safety, and build a committee admin view that calls Midnight’s approveCommitteeReveal path so committee approval is on-chain and auditable, not only in local UI state. We want hardened auth (server-side sessions, audit logs), clearer retention policies for raw versus sanitized data, and smoother Midnight deployment—reliable testnet or mainnet pilots with partner institutions, better monitoring when the node or indexer is down, and documented runbooks for schools. We would explore Midnight features more deeply for selective disclosure policies (who can read what, and when) as the product matures. Longer term, Veil could support attachments with private off-chain storage anchored by on-chain hashes, multilingual complaints, escalation workflows, and aggregated, anonymized analytics so institutions see patterns without exposing individual reporters—using Midnight where proof and consent matter, and keeping human-readable complaint content off the ledger by default.

Built With

Share this project:

Updates