QuietAid

QuietAid helps students prove scholarship eligibility with Midnight without revealing the sensitive personal circumstances behind it.

Comment

Inspiration

Scholarship applications often require students to disclose deeply personal information before they even know whether they are a strong candidate. Household income, GPA, enrollment status, disability or accessibility eligibility, housing insecurity, location, and family circumstances can all become part of a traditional application profile.

That made us question a basic assumption:

Does a scholarship provider really need to see the sensitive information itself, or do they only need proof that the applicant satisfies the eligibility requirements?

That question inspired QuietAid.

QuietAid Depository: https://github.com/LucaCalbeaza/QuietAid---Midnight

For the Integrate Midnight to Upgrade an Existing App track, we started with an existing open-source scholarship finder and redesigned its data flow around privacy.

Original Open Source Depository: https://github.com/sujalbuilds/scholarship-finder-app

Our goal became:

Prove eligibility, not vulnerability.

Instead of asking students to reveal every circumstance that qualifies them for financial support, QuietAid explores how Midnight and zero-knowledge technology can let students prove selected eligibility requirements while keeping the underlying values private.

What it does

QuietAid is a privacy-first scholarship discovery and application platform.

A student first logs in and creates a Private Eligibility Profile containing information that may include:

  • household income
  • GPA
  • enrollment status
  • U.S. state
  • first-generation status
  • disability/accessibility eligibility
  • housing insecurity

For our new privacy workflow, this profile is kept in the browser rather than being sent to MongoDB for recommendation matching.

QuietAid then retrieves public scholarship information and public eligibility rules and performs scholarship matching locally.

The flow is:

Private student profile + public scholarship rules → local scholarship recommendations

When a student finds a relevant scholarship, they can choose Apply Privately with Midnight.

For our Midnight-enabled prototype, a Compact eligibility circuit verifies selected private requirements such as enrollment status and household income against the scholarship's predefined rules.

Instead of revealing:

"My household income is $X and my enrollment status is Y."

the student can prove:

"I satisfy the required eligibility conditions."

After successful verification, QuietAid creates a pseudonymous application.

A scholarship provider can initially see information such as:

  • application ID
  • pseudonymous applicant
  • scholarship
  • eligibility verification status
  • Midnight proof status

The provider does not initially receive the student's:

  • household income
  • GPA
  • disability/accessibility information
  • housing circumstances
  • name
  • email
  • other private eligibility information

If the provider wants to advance the applicant, they can request identity/contact information.

The student then decides what to reveal.

For example:

  • ☑ Name
  • ☑ Email
  • ☐ Address

Only the approved information becomes visible to the provider.

How we built it

QuietAid began as an existing open-source scholarship finder built with React, Express, and MongoDB.

The original application followed a traditional Web2 architecture:

Student profile → MongoDB → server-side recommendation engine → scholarship results

Sensitive profile information such as income, GPA, and location could be stored and processed by the backend.

For QuietAid, we created a new privacy-focused flow rather than simply adding more sensitive fields to the existing database.

Private profile

We introduced a separate private eligibility profile on the React frontend.

The new QuietAid-specific eligibility values remain in browser memory for the hackathon prototype instead of automatically being persisted to MongoDB.

Local scholarship matching

The backend exposes scholarship information and eligibility rules.

The frontend then compares those public rules with the student's private profile locally.

This changes recommendation matching from:

private data → backend

to:

public rules + private browser state → local matching

We also kept a clear distinction between recommendation and verification.

A local match means:

"This scholarship appears relevant to you."

A Midnight proof means:

"The required eligibility conditions have been verified."

Midnight Compact

We added a dedicated Midnight eligibility component using Compact.

Our initial circuit focuses on a deliberately small set of conditions so that we could build and test the privacy flow correctly.

The circuit uses private student values such as:

  • enrollment status
  • household income

and evaluates them against scholarship requirements such as:

  • enrollment required
  • maximum allowed income

Conceptually, the eligibility requirement is similar to:

$$ Eligible = (\neg RequiresEnrollment \lor Enrolled) \land (Income \leq MaximumIncome) $$

The student's actual private values are not intended to be disclosed as public outputs.

We also tested both positive and negative cases so that an applicant who does not satisfy the requirements cannot simply receive a verified application.

Trusted credentials

We also considered an important limitation of zero-knowledge proofs:

A ZK proof can prove that private inputs satisfy a circuit, but it cannot by itself prove that self-entered real-world information is truthful.

To address that, QuietAid includes the foundation for a mock trusted credential model.

For example:

  • a mock university could verify enrollment
  • a mock financial-aid office could verify an income band

The long-term architecture is:

Trusted issuer → private credential → Midnight eligibility proof → provider

The provider would learn that a trusted claim satisfies the scholarship requirement without receiving the underlying sensitive value.

Pseudonymous applications

After successful eligibility verification, the backend stores a privacy-safe application record containing information such as:

  • public application ID
  • scholarship
  • pseudonym
  • verification status
  • safe Midnight metadata
  • disclosure state

Private eligibility attributes are not stored inside the provider-facing application record.

Provider dashboard and selective disclosure

We built a provider workflow where applications are pseudonymous by default.

The provider can see that eligibility has been verified while sensitive information remains marked as Not disclosed.

The provider can then request contact information, and the student explicitly decides what to share.

Importantly, this is not only a frontend hide/show feature. Provider-facing API responses are designed to exclude private eligibility information.

Updated User Interface

On top of the new backend privacy workflow, we also upgraded the original Scholarship Finder App user interface to a more modernized dark blue graphic theme with a new grid based layout.

Challenges we ran into

One of our biggest challenges was understanding that privacy is not achieved simply by adding a zero-knowledge proof to an existing application.

We had to rethink where data was stored, where matching happened, which information the backend actually needed, and which information the scholarship provider should receive.

Another challenge was separating matching from verification.

Our scholarship matcher can locally determine that a scholarship appears suitable, but that calculation is not itself a cryptographic proof. We had to keep the two concepts separate so that we did not accidentally represent normal frontend logic as zero-knowledge verification.

We also had to think carefully about scholarship rule integrity.

If the student were allowed to choose the eligibility limits used during verification, the proof would be meaningless. The verification therefore needs to correspond to the scholarship's actual predefined rules.

Another major challenge was the difference between proving a statement and proving that the underlying real-world data is trustworthy.

A zero-knowledge circuit can prove:

"The private value I supplied is below this threshold."

It cannot automatically prove:

"A university or financial-aid institution confirmed that this is my real value."

That led us to design the mock trusted credential layer.

Finally, integrating Midnight into an existing React + Express + MongoDB application required us to preserve the useful parts of the original project while creating a separate privacy-focused architecture rather than rewriting everything from scratch.

Accomplishments that we're proud of

We are especially proud that QuietAid is not simply a new interface placed on top of the original scholarship finder.

We changed the information flow of the application.

Some of the accomplishments we are most proud of include:

  • upgrading an existing open-source application instead of starting from zero
  • creating a private eligibility profile that does not need to be stored in MongoDB for the new matching flow
  • moving scholarship recommendation matching into the browser
  • integrating Midnight Compact eligibility verification
  • supporting both successful and failed private eligibility scenarios
  • creating pseudonymous scholarship applications
  • separating identity from eligibility
  • designing provider-facing APIs around data minimization
  • allowing students to control when their name and contact information are disclosed
  • exploring mock trusted credentials rather than pretending that zero-knowledge proofs automatically verify self-entered real-world information

The result we care about most is that a scholarship provider can receive:

"This applicant satisfies the eligibility requirements."

without automatically receiving:

"Here are all of the personal circumstances that made this applicant eligible."

What we learned

The biggest lesson from building QuietAid was that privacy is not a single checkbox or feature.

It is a question of:

Who needs to know what, when do they need to know it, and can the system prove the necessary fact without revealing everything behind it?

We also learned that zero-knowledge systems work best when the statement being proved is carefully scoped.

Instead of exposing an entire student profile, the application can focus on a much smaller statement:

"This applicant satisfies the scholarship's requirements."

We learned to distinguish three different ideas that are easy to mix together:

  1. Private matching helps students discover opportunities without sending their new eligibility profile to the recommendation server.
  2. Zero-knowledge verification proves that private values satisfy defined scholarship rules.
  3. Trusted credentials provide confidence that those private claims originated from an approved real-world source.

Each solves a different problem.

We also learned that hiding fields in the user interface is not enough. Privacy has to exist at the API and data-model level as well. If sensitive information is already returned by the backend, it has already been exposed even if the frontend chooses not to render it.

Most importantly, working on QuietAid changed the way we think about application design: instead of asking how much information we can collect, we started asking how little information we actually need.

What's next for QuietAid

The hackathon version intentionally keeps the Midnight eligibility circuit focused so that the core privacy flow can remain understandable and testable.

The next step is to extend private verification to additional scholarship conditions such as:

  • GPA thresholds
  • state eligibility
  • first-generation status
  • disability/accessibility eligibility
  • housing insecurity

We would also like to move from mock credential issuers toward real institutional credentials from organizations such as universities and financial-aid offices.

A future QuietAid could give students a reusable private credential wallet where verified claims are stored under the student's control and reused across different scholarship applications without repeatedly exposing the underlying information.

We also want to extend the prototype with production-ready Midnight wallet and network integration, stronger credential issuance and revocation, and secure persistence for student-controlled private information.

Eventually, the same approach could extend beyond scholarships.

Many systems ask people to expose sensitive information simply to prove that they qualify for something.

QuietAid explores a different model:

Prove the requirement. Reveal only what is necessary. Let the user control the rest.

Built With

Share this project:

Updates

Submission history