Openzcash.org | public transparency

@Michae2xl, first, I want to recognize the amazing work you have done with OpenZcash.org. Bringing grants, proposals, voting, recipients, disbursements, meeting minutes, budgets, and Lockbox activity into a coherent, source-linked public view is an outstanding contribution. The addition of the open-source ZCG Copilot makes that work even more useful.

Your description of the original “pain”—having to move among spreadsheets, GitHub, the Forum, and other sources just to understand the current state of the ecosystem—resonated strongly with me. Entirely independently, I had arrived at essentially the same underlying observation from the perspective of the ZCG grant workflow.

As I explained in my ZCG election thread, too much of the current “system” consists of people manually connecting GitHub applications and labels, Forum discussions, Google Sheet records, meeting minutes, and separate operational processes. Each source is valuable and should be preserved, but the relationships among them are difficult to follow consistently.

Now, as a new ZCG committee member, I want to attack that problem head-on. I have been building an independent prototype called Zcash Community Grants Decision Support to explore how the committee’s review process could become more systematic, evidence-grounded, and publicly understandable.

I see this work as highly complementary to OpenZcash—not as a replacement or competing dashboard.

OpenZcash does an exceptional job of making the wider ecosystem legible: what has been proposed, funded, approved, paid, discussed, or put to a vote. My prototype is deliberately narrower and more focused on the ZCG committee’s decision process for a particular application. Put simply, OpenZcash helps answer, “What is happening across the ecosystem?” The decision-support prototype helps organize, “What evidence should the committee examine before deciding this specific proposal?”

The feature I am most excited about is the public, AI-generated Committee Briefing for applications under review. Each briefing is assembled from the available indexed public record for that application, including:

  • The canonical application record, GitHub proposal, comments, labels, requested amount, scope, and status.
  • The primary Forum discussion and supporting Forum references, sampling substantive contributions across the discussion rather than looking only at the opening post.
  • Relevant Google Sheet grant, milestone, payment, and historical registry records.
  • ZCG meeting minutes and recorded decision history.
  • Related, revised, or resubmitted applications.
  • Prior applications and grants associated with the applicant or team, where those relationships can be established responsibly.
  • A balanced selection of relevant approved and declined proposals, including documented outcomes or reasons for rejection where that evidence exists.
  • Material contradictions, unresolved questions, and missing evidence that may affect confidence in the applicant, budget, scope, milestones, or likelihood of delivery.

These records are processed individually for keyword and semantic retrieval, allowing the system to connect related evidence even when different sources use different language. The model is then instructed to use only the supplied evidence, cite every material factual claim, distinguish documented facts from inference, and state clearly when the record does not support a conclusion. It cannot treat a “completed” label as proof of impact, and it is specifically prohibited from making an autonomous approve-or-reject recommendation.

The resulting briefing covers the request and decision snapshot, team history, scope, milestones, budget, technical approach, community arguments and applicant responses, relevant precedents, material risks, unresolved questions, neutral decision considerations, and a numbered source list. The exact evidence used is preserved with the report, and the briefing can be marked stale when the underlying evidence changes.

This creates value on both sides of the committee process. Committee members receive a repeatable, cited review packet instead of each person reconstructing the record independently. The public can inspect the same evidence, citations, limitations, and questions that informed the briefing.

I do want to be precise: these are AI-generated decision-support artifacts from an independent prototype. They are not official ZCG evaluations, committee consensus, or funding decisions. Human judgment remains essential, and the responsibility for each decision remains with the committee.

I would love to see these efforts continue to reinforce one another. OpenZcash makes the Zcash ecosystem far easier to understand at a glance; the https://zcg.pgpz.org/ prototype explores how individual grant deliberations can become more comprehensive, traceable, and transparent.

4 Likes