EclipseProof

Prove you qualify without revealing your finances. EclipseProof uses issuer-backed zero-knowledge proofs for private rental and loan eligibility.

Comment

EclipseProof

When applying to rent a home, obtain financing, or act as a guarantor, people are often asked to share payslips, bank statements, and other sensitive financial documents.

A landlord may only need to confirm that an applicant earns more than a required threshold. Yet the applicant can end up revealing their exact salary, employer, tax deductions, account details, and unrelated transactions.

Citizens Advice confirms that rental applicants may be asked for employer references and recent bank statements to demonstrate income. It even recommends obscuring account numbers before sharing statements.

This exposed a fundamental problem:

We disclose an entire financial record to prove one small fact.

That led us to ask:

Why reveal exactly what you earn when you only need to prove that you qualify?

EclipseProof was inspired by the principle of data minimisation: organisations should receive enough information to make a decision, but no more than necessary.

What it does

EclipseProof is a privacy-preserving financial eligibility platform.

It allows a person to prove that verified financial information satisfies a landlord's or lender's policy without revealing the underlying values or documents.

The process involves three parties:

  1. A trusted employer, payroll provider, bank, or other approved institution issues a digitally signed financial credential.
  2. The individual keeps that credential encrypted under their control.
  3. A landlord or lender requests proof of a specific condition, such as verified monthly income being at least GBP 2,500.

After the user reviews and approves the request, a Midnight zero-knowledge circuit verifies that:

$$ \operatorname{ValidSignature}(credential) = 1 $$

$$ income \geq requiredThreshold $$

$$ currentTime < expirationTime $$

$$ requestNonce \notin consumedRequests $$

The verifier receives only a result such as:

Affordability requirement: GBP 2,500 per month
Requirement satisfied: Yes
Issuer status: Trusted
Proof status: Valid
Expiration: 24 hours

The verifier does not receive the applicant's:

  • Exact salary
  • Payslip
  • Employer details
  • Tax deductions
  • Account balance
  • Transaction history

Each proof is bound to a specific verifier, request, nonce, and expiration time. This prevents forwarding, replay, and indefinite reuse.

Our initial use case is rental affordability. The same infrastructure can later support:

  • Privacy-preserving loan pre-qualification
  • Guarantor verification
  • Mortgage screening
  • Student accommodation
  • Device financing

How we built it

HACKSPHERE Phase 1 is a conceptual round, so we focused on research, system design, threat modelling, and defining a realistic 24-hour MVP rather than writing the product before the competition.

We designed EclipseProof around an issuer-holder-verifier architecture inspired by the W3C Verifiable Credentials model.

Proposed stack

  • React, TypeScript, Vite, and Tailwind CSS for the issuer, applicant, and verifier interfaces
  • Lace Wallet for user authorisation and Midnight interaction
  • Midnight Compact for private eligibility logic
  • Midnight.js for contract deployment and transaction workflows
  • Node.js and Express for non-sensitive request coordination
  • PostgreSQL or Supabase for request metadata only
  • W3C Verifiable Credentials-inspired format for signed financial claims

Phase 2 workflow

  1. A simulated payroll issuer creates and signs an income credential.
  2. The renter stores the credential locally.
  3. A landlord creates an affordability request with a threshold, verifier identity, nonce, and expiration.
  4. The renter reviews the exact condition and provides consent.
  5. A local witness supplies the private credential fields to the Compact circuit.
  6. The circuit validates the issuer signature, credential status, threshold, nonce, verifier binding, and expiration.
  7. Midnight verifies the private state transition.
  8. The landlord receives only the minimum eligibility result.

Public blockchain state will contain only:

  • Approved issuer keys
  • Revocation commitments
  • Consumed request commitments

Raw financial information will never be uploaded to the blockchain or EclipseProof's application database.

Challenges we ran into

1. Authenticity

The first challenge was authenticity.

A zero-knowledge proof can show that a calculation was performed correctly, but it cannot make false input truthful.

If users entered their own salary or uploaded an editable document, they could prove a statement about manipulated data.

We addressed this by requiring credentials signed by trusted issuers.

2. Avoiding decorative blockchain usage

The second challenge was avoiding blockchain for the sake of using blockchain.

Storing payslips or completed proofs on-chain would create privacy and correlation risks.

We instead use Midnight as a trust and verification layer, while keeping sensitive values in private local state.

3. Privacy vs. regulated requirements

The third challenge was balancing privacy with the needs of regulated institutions.

Banks still require identity, anti-money-laundering, sanctions, affordability, and responsible-lending checks.

EclipseProof does not claim to replace those processes.

Instead, it provides a privacy-preserving way to answer individual eligibility questions within them.

4. Building a realistic 24-hour MVP

The final challenge was limiting the scope to something three team members can complete during a 24-hour hackathon.

We selected:

  • One credential type
  • One simulated issuer
  • One income-threshold policy
  • One rental-verification journey

This gives us a focused MVP that can demonstrate the core privacy model without trying to build an entire financial infrastructure platform in one day.

Accomplishments that we're proud of

We are proud that EclipseProof treats Web3 as essential infrastructure rather than an additional label.

Our architecture combines:

  • Issuer-backed authenticity
  • User-controlled financial credentials
  • Zero-knowledge threshold verification
  • Explicit holder consent
  • Verifier-specific proofs
  • Expiration and replay protection
  • Credential revocation without exposing its contents

We also developed a focused MVP that can demonstrate both successful and unsuccessful verification without using hardcoded approval results.

The planned demo will include:

  1. A valid credential
  2. Insufficient income
  3. A modified credential
  4. A replayed or expired request

Most importantly, EclipseProof changes the verification model from:

"Send me your financial documents."

to:

"Prove that you satisfy my policy."

What we learned

We learned that privacy and authenticity must be designed together.

Hiding financial information is not useful if the information cannot be trusted. At the same time, trustworthy verification should not require unrestricted disclosure.

We also learned that blockchain is most valuable here as a shared trust layer.

Public state can establish approved issuers, credential status, and request consumption, while zero-knowledge proofs keep personal financial values private.

Designing the system also taught us the difference between proving eligibility and making a complete financial decision.

EclipseProof can prove that a policy condition is satisfied, but lenders must still perform legally required identity, compliance, and risk checks.

Finally, we learned that good privacy design is also good data architecture.

The safest financial document for EclipseProof to store is one it never receives.

What's next for EclipseProof

If selected for Phase 2, we will build the complete rental-affordability MVP during the official 24-hour development period.

Our priorities will be:

  1. Implement the simulated payroll credential issuer.
  2. Build the verifier's affordability-request flow.
  3. Implement the Compact threshold-verification circuit.
  4. Integrate holder consent and Lace Wallet.
  5. Add expiration, credential-status, and replay checks.
  6. Deploy the interface and supported contract components to a public test environment.
  7. Demonstrate positive, negative, tampered, and replayed verification cases.

Beyond the hackathon

After the hackathon, we plan to validate the experience with:

  • Renters
  • Letting agents
  • Payroll providers

We will then explore integrations with:

  • Banks
  • Open-banking providers
  • Gig platforms
  • Financial institutions

The long-term vision is for EclipseProof to become a reusable financial eligibility layer through which people can prove they qualify for a home, loan, or service without exposing their complete financial lives.

Prove what matters. Reveal only what is necessary. exposing their complete financial lives.

Built With

Share this project:

Updates

Submission history