> For the complete documentation index, see [llms.txt](https://docs.projectcatalyst.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.projectcatalyst.io/open-funding/decision/panelist-guidance.md).
# Panelist Guidance
This page covers what the Decision Panel is deciding, how scoring works, and what we expect from panelists during the review window. The scoring questions have their own guidance attached; you'll see it next to each question in the interface.
### Are you a Decision Panelist?... what to do now
1. Access the review platform with your wallet-registered account:
2. Read the [Panelist Terms and Conditions](https://docs.projectcatalyst.io/open-funding/decision/panelist-terms-and-conditions). You'll accept them via click-wrap when registering and logging in.
3. Timeline allocated for this stage: **31 August - 11 September 2026, 06:00 UTC**
4. If you can't access the platform or complete your allocation, raise a [service desk ticket](https://catalystiog.zendesk.com/hc/en-us/requests/new) as soon as possible.
5. If you have an actual or potential conflict of interest, see Conflicts and independence below.
### Background
The Catalyst Pilot funds teams that already have a working product and want to integrate it with Cardano. Grants are between 50,000 and 200,000 ADA, from a total primary pool of 2 million ADA, and the majority of payment is tied to the adoption each team can demonstrate after launch, measured in network fees. We expect to fund somewhere around 10 teams, but read that as a working estimate rather than a commitment in either direction: fewer if the quality isn't there, more if the pool proves stronger. The hard boundary is the budget, not the count.
### Your role
Every proposal you'll see has been through curation, a public stage where the program and community checked claims against the published rules and archived clear failures. That reduces the noise; it doesn't guarantee every statement in front of you is accurate.
So you don't need to repeat all the fact-checking, but stay skeptical. Credibility is a large part of what you're scoring: if a claim doesn't hold up, score accordingly and say why in your comment. If you hit something that looks like a critical factual or eligibility problem rather than a judgment call, raise it via the service desk and the admin team will examine it.
Where your role ends: you don't approve or veto proposals, manage appeals, or communicate outcomes to proposers.
### Scoring
* Proposals are scored on two tracks, **business viability (70 points)** and **technical credibility (30 points)**, question by question **on a 1 to 5 scale**. See the full [breakdown here](https://drive.google.com/file/d/1P-sdqY_xkqfpAppsT9t8q8zYCbSO9Vs-/view). You will see this rubric directly inside the platform as you’ll be making your way through the workflows.
* Some questions carry more weight than others; the platform applies the weighting, so score each question on its own merits.
* Batches are assigned randomly, sized against the capacity you declared. You can't choose which proposals you review.
* If you serve on both sub-panels, treat each assignment separately and apply only that track's rubric.
* All panelists' scores carry the same weight, and the final "should this be funded" question sits outside the numeric total; it's only used to break ties.
* There is no deliberation round afterwards. Scores are aggregated as submitted and the outcomes are final, so in practice the scores you enter are the funding decision.
### How to approach the reviews
Score the proposal, not what you know about the team. Proposers were told to write as if nobody knows who they are, and reviews should hold them to that: a claim counts when a stranger could verify it from what the proposal provides, including reference links.
The written text alone is rarely the whole picture. Proposals point outward, to working products, repositories, audits, metrics, team profiles, and looking into those links is part of the review, not optional extra credit. A claim with a link that checks out counts for a lot; a link that doesn't support its claim should cost points, and your comment should say so.
Read the anchor descriptions before your first review, and use the full range. A 3 is a perfectly normal score, and 5s should be reserved for work that clearly earns them.
Comments are required on every question and matter as much as the numbers: they're the record of your reasoning, and a review without substantive comments won't be accepted. Teams later receive an aggregate summary of the feedback, so write comments that make sense to someone who isn't you.
One thing that trips people up on fee targets: both directions can cost points. A target set low so it can be safely beaten scores poorly, and so does one the evidence can't support. You're rating how credible the number is, not how big.
### Conflicts and independence
A conflict of interest is any direct or indirect personal, professional, financial, or organisational connection to a proposal, its team, or a competing proposal. If a proposal in your batch presents one, actual or potential, refuse it in the interface rather than scoring it. If you spot the conflict only after starting the review, stop and raise a service desk ticket so it can be reassigned.
While the window is open, don't discuss proposals or scores with other panelists or the teams behind them, and don't try to influence anyone's review. Ordinary concerns about quality, feasibility, or value belong in your scores and rationales, not in informal channels or public discussion.
Panel materials stay confidential until results are published: don't share, screenshot, record, or discuss proposal content, assignments, scores, or rationales outside your workflows. Comments must be your own judgment. Panelists cannot also be proposers in this round.
### Workload, timing, refusals
In the platform you'll see two sets of assignments: a primary batch of **\[10]** proposals, which are mandatory, and up to **\[10]** more marked as extras. The extras are optional; pick them up if your time and interest allow. When your batch arrives, do a quick pass over all of it before starting deep reviews, and refuse anything you can't judge fairly right away so it can be reassigned in time. Late refusals are the ones that hurt, since they can leave a proposal without enough reviews. Refusing a proposal doesn't count against you, and an extra you don't take on needs no explanation at all.
### Compensation
As set out in the [Panelist Terms and Conditions](https://docs.projectcatalyst.io/open-funding/decision/panelist-terms-and-conditions): a base of **\[500]** ADA for completing your batch, plus **\[75]** ADA per accepted review, extras included, capped at **\[20]** reviews and **\[2,000]** ADA in total. These are upper bounds rather than guarantees; actual workload depends on the pool of panelists actually carrying out the work. A review is accepted when it's complete, on time and carries substantive comments throughout. Administrators may check reviews before they count, and set one aside only in exceptional cases: material quality problems, late submission, or a confirmed conflict of interest. Cardano Foundation panelists take part unpaid.
### Once reviews are in
When everyone has submitted, the program aggregates the outcomes and shares the results. This pilot format is running for the first time, and we'll come back to you afterwards to collect feedback for the next version.
Thank you for taking this on.
\
\
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.projectcatalyst.io/open-funding/decision/panelist-guidance.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.