[Proposal setup] Proposal title

Please provide your proposal title

Modular Governance Privacy Toolkit

[Proposal Summary] Time

Please specify how many months you expect your project to last

3

[Proposal Summary] Translation Information

Please indicate if your proposal has been auto-translated

No

Original Language

en

[Proposal Summary] Problem Statement

What is the problem you want to solve?

Delegators can’t give honest feedback on DReps, comments expose wallets, while anonymous ones lack credibility. Governance lacks safe, verifiable, reputation-weighted reviews.

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

No

Describe any dependencies or write 'No dependencies'

No dependancies

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

Please provide here more information on the open source status of your project outputs

All code will be MIT-licensed and developed in a public GitHub repo from day one. Modules, contracts, and UI components will be reusable, with open issues/PRs and full docs for other teams to adopt

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal

Governance

[Campaign Category] Category Questions

What is useful about your DApp within one of the specified industry or enterprise verticals?

Our dApp solves a concrete governance problem: today, delegators and DReps have no safe, structured way to give and receive honest, verifiable feedback. On platforms like 1694-style DRep directories, comments are either fully public (linking straight to a wallet, which discourages criticism) or fully anonymous (impossible to trust, since anyone can spam).

This dApp introduces “verified but anonymous” governance feedback. When a user connects their wallet, we verify on-chain that they are an actual delegator of a given DRep (and how much ADA they delegated), but we do not expose which wallet they used. That enables two governance-specific features:

• Anonymous verified DRep reviews: Only real delegators can leave “verified” reviews on a DRep’s profile, but their identity stays private. This creates a credible public record of under‑ or over‑performance that future delegators can rely on.
• Anonymous whistleblower reports: Users can report misconduct (eg. broken campaign promises) while proving they are legitimate governance participants, not trolls or outside attackers.

In short, the dApp makes governance feedback actionable and trustworthy (because it’s tied to real on-chain participation) while keeping it safe to provide (because reviewers are not doxxed).

What exactly will you build? List the Compact contract(s) and key functions/proofs, the demo UI flow, Lace (Midnight) wallet integration, and your basic test plan.

Contracts and proofs

We will build two Compact contracts on Midnight:

1. DelegationProofVerifier (core)

• State: currentSnapshotId, snapshotRoots[snapshotId] = root.
• Function: verifyDelegationProof(snapshotId, drepId, minAmount, root, publicAmount, zkProof) : bool.
• It verifies a ZK proof that there exists a stake credential delegated to drepId in snapshot snapshotId with amount ≥ minAmount, and that publicAmount is consistent with the private amount (exact or range). This backs the “Verified Delegator” badge

2. AnonCredentialVerifier (for whistleblowers)

• State: issuerPubKey.
• Function: verifyCredentialProof(requiredRole, minScore, zkProof) : bool

Off‑chain we will implement:

• A snapshot + Merkle builder that reads Cardano delegation data, produces (snapshotId, root) and per‑delegator proofs.
• A simple credential issuer that signs governance roles (e.g. “this address is a registered DRep”) to be used in the second contract.

Demo UI flow and Lace/Midnight integration

We will ship a small React demo (1694‑style DRep page) wired to Lace and these contracts.

DRep review flow:

• User clicks “Connect Lace” - We obtain Cardano stakeKey and a Midnight account handle from Lace
• Frontend asks our snapshot service for current snapshotId, root, then for a delegation proof for (stakeKey, drepId) and turns it into zkProof.
• Frontend submits a Midnight transaction calling: DelegationProofVerifier.verifyDelegationProof(...), User signs this via Lace.
• If the call succeeds, UI shows: ✅ Verified delegator (X ADA) and unlocks the review form.
• The review is stored off‑chain with a reference to the successful verification (not to the wallet).

Whistleblower flow:

• User connects Lace, asks issuer for a governance credential (e.g. role = drep).
• Wallet generates zkProof for that credential.
• Frontend calls AnonCredentialVerifier.verifyCredentialProof(...) via Midnight; on success, it allows submitting an anonymous report tagged as “filed by verified DRep/delegator”

We will provide small helpers around Lace, e.g.:

• connectLace() → { stakeKey, midnightAccount }
• submitDelegationProofTx(...) and submitCredentialProofTx(...) that build/sign Midnight calls.

Basic test plan

Contract tests (Compact):

• DelegationProofVerifier: accepts known‑good proofs; rejects wrong snapshotId, drepId, minAmount, or tampered proof/root.
• AnonCredentialVerifier: accepts valid credential proof; rejects wrong role, wrong issuer key, or modified attributes.

Off‑chain tests:

• Snapshot builder: for fixed test data, Merkle root matches known value; generated proofs verify; any byte flip in proof fails.
• Credential issuer: unit tests for issuing and rejecting credentials based on simple fixture data.

End‑to‑end demo tests:

• Browser tests that:
  • a mocked delegator sees the “Verified delegator” badge and can post a review;
  • a non‑delegator does not see the badge and cannot post a verified review;
  • a mocked DRep can file a whistleblower report that appears with a “verified DRep” tag but no wallet info.

How will other developers learn from and reuse your repo? Describe repo structure, README contents, docs/tutorials, test instructions, and extension points. Which developer personas benefit, and how will you gauge impact (forks, stars, issues, remixes)?

The repo is designed as a reference implementation + toolkit that other governance teams can clone, copy from, or plug in directly, without having to design the cryptography or UX from scratch.

Repo structure (planned)

midnight-governance-toolkit/

├── contracts/

│ ├── delegation-proof/

│ │ ├── DelegationProofVerifier.compact

│ │ └── tests/

│ └── anon-credentials/

│ ├── AnonCredentialVerifier.compact

│ └── tests/

├── services/

│ ├── snapshot-builder/ # builds delegation Merkle roots + proofs

│ └── credential-issuer/ # issues governance credentials

├── frontend/

│ ├── components/ # reusable React widgets

│ │ ├── VerifiedDelegationBadge.tsx

│ │ ├── AnonReviewForm.tsx

│ │ └── WhistleblowerForm.tsx

│ └── demo-app/ # 1694-style example UI

├── examples/

│ ├── anonymous-reviews/

│ └── whistleblower-reports/

└── docs/

├── Quick-Start.md

├── Integration-Guide.md

├── Privacy-Explainer.md

└── Design-Notes.md

README + docs/tutorials

• README.md: problem/solution summary, architecture diagram, “run the demo” in 10–15 minutes.
• docs/Quick-Start.md: step‑by‑step to run snapshot service, deploy contracts, and post a verified review.
• docs/Integration-Guide.md: how to wire /api/delegation-status, configure contracts, and use the React components.
• docs/Privacy-Explainer.md + Design-Notes.md: what is proven vs hidden, and why we chose this design.

Developer personas

• Governance platform maintainers: add verified reviews/whistleblowers via REST + widgets.
• Compact/Midnight devs: fork/modify the contracts and tests as templates.
• Frontend engineers: drop in React components + minimal TS helpers for Lace/API.
• Governance researchers: tweak thresholds/configs in the demo to test mechanisms.

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

We’re building a modular, open‑source privacy toolkit using Midnight’s Compact language that enables “verified but anonymous” feedback in blockchain governance. It targets a specific trade‑off that currently blocks honest participation: feedback is either credible but risky (on‑chain, tied to a wallet) or safe but useless (anonymous, easy to spam). Our toolkit lets users prove they are real governance participants while keeping their wallet identity private.

Core innovation: selective disclosure

The toolkit allows users to cryptographically prove statements like “I delegated 50,000 ADA to this DRep for 3 months” without revealing which wallet or stake key they used. This is fundamentally different from existing privacy options:

• Mixing services hide everything or nothing – you can’t selectively prove specific facts.
• Anonymous comments have no weight – anyone can post without holding any stake.
• Public on‑chain comments are permanently linked to identity – creating fear and self‑censorship.

Our approach uses Midnight’s zero‑knowledge capabilities to verify delegation (and other governance roles) while keeping the underlying wallet opaque. It’s like an Amazon “verified purchase” badge for governance: a review is visibly backed by real participation, but neither the platform nor other users can trace it to a specific address.

Four modular components

Instead of one monolithic dApp, we expose four small, composable modules:

• Module 1: Proof of Delegation - A Compact smart contract plus off‑chain helper that produce cryptographic proofs of delegation. Users prove they delegated X ADA to a specific DRep (or meet a minimum threshold) without revealing their wallet. This prevents spam and fake reviews while preserving anonymity.
• Module 2: Anonymous Credentials - A Compact contract for governance credentials. Users can prove properties like “I’m a registered DRep” or “I’ve voted in 100+ proposals” without revealing which DRep or which address. This enables credible criticism and whistleblower flows where only experienced participants can file certain reports.
• Module 3: User Interface Components - Pre‑built React widgets that surface these privacy features behind simple controls. Users see clear options like: “Post anonymously,” “Prove I delegated to this DRep,” “Show my delegation range,” “Prove I’m a registered DRep.” No cryptography knowledge is required; projects can drop these widgets into existing governance UIs.
• Module 4: Developer Resources - A well‑structured repo with example Compact contracts, a snapshot/proof service, Next.js demo app, tests, and written guides. Other teams get copy‑pasteable code, REST contracts, and tutorials that let them integrate verified‑but‑anonymous feedback in days instead of re‑inventing everything.

Real‑world demonstration

We will integrate the toolkit into www.1694.io, Cardano’s DRep campaign platform, as a reference deployment. This produces two concrete applications:

• Anonymous DRep Reviews – Delegators can leave honest reviews on a DRep’s profile with a visible “Verified delegator (X ADA)” badge, but the platform never sees which wallet they used. Underperforming DReps finally face credible, on‑chain‑backed criticism instead of silent stake exits, while good DReps build trustworthy reputations from real delegators rather than pure marketing.
• Anonymous Whistleblower Reports – Delegators or DReps can report misconduct (vote buying, broken promises, misuse of funds) while proving they are legitimate governance participants, not external trolls. Platform administrators see that a report comes from a real actor with defined on‑chain status, but cannot link it back to a specific wallet.

Why this approach works

The design is intentionally modular: other governance platforms can pick what they need. A project that only wants anonymous, verified reviews uses Modules 1 + 3; a project that only needs whistleblower protection uses Modules 2 + 3; a full governance feedback system uses all four.

All code is MIT‑licensed and open from day one, so teams can fork, extend, or embed it without licensing friction. Beyond solving today’s review/whistleblower problem, the toolkit establishes a reusable pattern for governance dApps where users control exactly which facts they reveal—enabling credible criticism without career risk, reputation without identity, and verification without surveillance.

[Your Project and Solution] Impact

Please define the positive impact your project will have on Midnight ecosystem

Immediate Impact: Honest Governance Feedback

Today, governance discussions are dominated by supporters and marketing; delegators who are unhappy usually just move their stake silently. Our toolkit turns that into structured, accountable feedback:

• Delegators can warn others about underperforming DReps without exposing their wallet or full on-chain history.

• High-performing DReps can point to a visible record of verified reviews instead of relying only on campaign copy.

• New delegators make decisions based on real experiences (from stake‑weighted participants), not just social media narratives.

• Governance platforms get a continuous feedback signal that highlights problems early instead of after large governance failures.

On www.1694.io alone, this immediately affects 1,000+ active users and hundreds of DReps. Once implemented there, the same modules can be dropped into other Cardano governance frontends with minimal changes.

Broader Ecosystem Benefits

For Midnight adoption

This is the first governance‑focused dApp on Midnight that solves a real, visible pain point: “I can’t safely say what I really think.” It shows Compact being used for selective disclosure that is not possible on Cardano mainnet alone (where comments are either fully public or completely off‑chain). That gives future builders a concrete pattern for combining Cardano state with Midnight privacy.

For developers

The toolkit is a complete, MIT‑licensed reference implementation:

• Compact contracts for delegation proofs and anonymous credentials.

• A snapshot/proof service that turns Cardano delegation data into verifiable statements on Midnight.

• React components and APIs that other teams can literally copy into their own governance apps.

Instead of every team re‑implementing delegation checks, proof formats, and UI, they can reuse tested modules and focus on their specific governance logic. This reduces duplicated effort and pushes the ecosystem toward shared best practices for “verified but anonymous” interactions.

For Cardano governance

Over time, this changes how DReps and delegators interact:

• Delegators can give specific, evidence‑backed feedback without personal risk.

• DReps receive actionable signals about where they are failing or over‑performing.

• Community discussions rely less on rumor or personality conflicts and more on structured, verifiable input from real participants.

The long‑term effect is more informed delegation, higher expectations on DReps, and a governance culture where criticism is normal and safe instead of rare and risky.

Long-Term Vision

This project is a concrete demonstration that blockchain apps do not have to choose between “everything is public forever” and “nothing is verifiable.” Users can selectively disclose exactly the governance facts they want (that they delegated, that they are a DRep, that they meet a threshold) without exposing their identity.

If successful, this becomes a reusable pattern well beyond DRep reviews:

• grant reviews and project evaluations without doxxing reviewers,

• reputation for community moderators or working group members without tying it to a single wallet,

• any context where honest feedback or signals are needed, but public identity carries social or professional risk.

The end state we are aiming for is simple to describe but currently missing: reputation, credibility, and accountability in decentralized systems without forced doxxing. This toolkit is a concrete first step toward that norm.

[Your Project and Solution] Capabilities & Feasibility

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

Proven governance experience

Our team has direct, production experience in Cardano governance. We helped build and maintain 1694.io, one of Cardano’s main DRep campaign platforms (1,000+ active users), so we already work with the exact user base this proposal targets. That gave us first‑hand exposure to:

• how DReps present themselves and how delegators currently evaluate them,

• the absence of structured, credible negative feedback,

• the technical constraints of integrating wallets, governance data, and UI at scale.

We have also contributed to GovTool (specifically the proposal outcomes section), which deepened our understanding of how governance data should be modeled and surfaced to users across different frontends.

Technical expertise across the full stack

This project touches multiple layers: privacy patterns, Compact contracts on Midnight, Cardano indexer integration, React UI, and wallet flows with Lace. Our team is organized so each of these areas has a clear owner:

• Lead full‑stack developer — Responsible for overall architecture, Compact contract design, Cardano/Midnight integration, and code quality across modules.

• UI/UX designer — Focused on making privacy choices understandable: checkboxes, warning states, and Lace connect flows that ordinary delegators can actually use without misconfiguring their privacy.

• Three junior developers — Each assigned to a module track:

  • one on Compact contract implementation and tests,

  • one on frontend components (badges, review forms, whistleblower flows),

  • one on integration + automated testing (snapshot service, API, demo app).

This structure gives us:

• clear module ownership (each of the four modules has a named driver),

• redundancy (more than one person familiar with the core stack),

• and realistic execution capacity for a 3‑month delivery window.

We are not learning governance or these codebases from scratch; we are extending systems we already ship and maintain, using technologies (Cardano indexers, React, wallet connectors) we work with day‑to‑day.

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

• Lead Developer – 5,500 USDM
  • ~100 hours over 3 months at ~55 USDM/hour.
  • Responsibilities:
    • Overall architecture and security/privacy design.
    • Implement and review Compact contracts and off‑chain services.
    • Integrate with 1694.io‑style frontend and Lace.
    • Final code review and acceptance for all modules.
• Developer Apprentices (batch of 3 juniors) – 3,000 USDM (shared)
  • ~100 hours total across the batch at ~30 USDM/hour.
  • Responsibilities:
    • Implement and refine React components (badges, forms).
    • Glue code between frontend, APIs, and snapshot/credential services.
    • Tests, example configs, and documentation under my supervision.
  • This is intentionally structured as hands‑on onboarding into Cardano/Midnight: every task is paired with code review, written guidance, and direct feedback, so the batch gains real governance‑dApp experience while contributing useful work. On boarding developers is at the core on of Cardano Center Nairobi.
• UI/UX Design support – 1,000 USDM
  • Focused design sprints to:
    • turn privacy options into clear, low‑risk UI (checkboxes, badges, warnings),
    • produce a small design system other projects can reuse.
• Infrastructure, tooling, and incidental costs – 500 USDM
  • CI/CD, test environments, hosting for demo instances, and small services used during development.

Alignment with milestones

• Month 1 (3,000 USDM): architecture + Module 1 skeleton + initial UI – primarily lead dev + some design.
• Month 2 (4,000 USDM): Module 2, UI library, end‑to‑end flows – mix of lead dev and apprentices.
• Month 3 (3,000 USDM): docs, polish, 1694‑style integration, final demo – all roles involved, led by me.

Most of the budget (≈8,500 USDM) goes directly to human time (my work + apprentices), with a small portion reserved for design support and the infrastructure needed to deliver and demonstrate the toolkit.

[Final Pitch] Value for Money

How does the cost of the project represent value for the Midnight ecosystem?

This proposal delivers a complete, reusable governance privacy toolkit and a real integration demo for 10,000 USDM, which is low cost relative to:

• Scope:

  • 2 Compact contracts (delegation proofs + anonymous credentials),

  • 2 off‑chain services (snapshot/proof builder + credential issuer),

  • a React component library,

  • a 1694‑style demo app,

  • full docs and examples.

• Reusability:

  • The toolkit is MIT‑licensed and designed as modules, not a one‑off dApp.

  • Any Cardano governance frontend (GovTool, new community dashboards, future DRep portals) can reuse:

    • the contracts and proof formats,

    • the REST API contracts,

    • the React components,

    • and the integration guides.

  • Each new adopter gets “verified‑but‑anonymous” reviews and whistleblowing at near‑zero marginal cost.

• Leverage of existing work:

  • I already maintain 1694.io and contribute to GovTool; we are not starting from scratch on governance data, UX, or infrastructure.

  • The 1694‑style integration is effectively a reference deployment others can copy, reducing their build time from months to days.

• Developer growth as part of delivery:

  • A portion of the budget is used to onboard 2–3 new developers into Cardano/Midnight via real tasks (components, tests, docs) under my review.

  • This increases the pool of people who can maintain and extend the toolkit long after this funding round, without extra cost to Catalyst.

• Clear, testable outputs:

  • Each milestone is tied to concrete artifacts (contracts, services, UI library, docs, demo videos, GitHub tags) that can be independently verified.

  • There is no “research only” phase; every month produces usable code and visible progress.

For 10,000 USDM, Catalyst funds not just a single feature on one site, but a standard building block for private, accountable governance that can be adopted across the Cardano ecosystem.

[Self-Assessment] Self-Assessment Checklist

I confirm that the proposal clearly provides a basic prototype reference application for one of the areas of interest.

Yes

I confirm that the proposal clearly defines which part of the developer journey it improves and how it makes building on Midnight easier and more productive.

Yes

I confirm that the proposal explicitly states the chosen permissive open-source license (e.g., MIT, Apache 2.0) and commits to a public code repository.

Yes

I confirm that the team provides evidence of their technical ability and experience in creating developer tools or high-quality technical content (e.g., GitHub, portfolio).

Yes

I confirm that a plan for creating and maintaining clear, comprehensive documentation is a core part of the proposal's scope.

Yes

I confirm that the budget and timeline (3 months) are realistic for delivering the proposed tool or resource.

Yes

[Required Acknowledgements] Consent & Confirmation

I Agree

Yes