> 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/curation/curation-guidance.md).

# Curation Guidance

Hello Curator, and thank you for helping us uphold the quality of proposals for the Catalyst Pilot! Your role is crucial: you help the Catalyst Team review submitted proposals so that only compliant ones move through to the Decision stage.

This is a focused mission, identify and flag non-compliant proposals. This guide covers the expectations, the compliance documents, and the reward structure.

***

#### 📣 An Important Disclaimer for All Participants

**🧑‍⚖️ For Our Curators**

This paid Curation stage is an invite-only initiative for a selected pool: e.g. Fund14 and Fund15 moderators, Cardano Ambassadors, and Milestone Reviewers. We are entrusting this task to you in recognition of your proven experience and deep understanding of the Catalyst process.

**TL;DR:** Only invited Curators from this pool are eligible for reward payments. General public sign-ups are not part of this pilot.

**🌱 For the Wider Cardano Community**

Public flagging is not open in this pilot, it is parked for a future iteration. If you're passionate about proposal quality, you can still help by discussing proposals in the community channels (Discord, Telegram, X) or by submitting [a direct support ticket here](https://catalystiog.zendesk.com/hc/en-us/requests/new) and choosing 'Feedback: Misconduct Report' from the type-of-inquiry dropdown. Your voice matters and helps inform voters and proposers alike.

***

#### ⚖️ Terms & Conditions

By participating in this Program and submitting flags, you agree to the general program [Terms & Conditions](https://docs.projectcatalyst.io/open-funding/fine-print/terms-and-conditions), [Terms of Use](https://docs.projectcatalyst.io/open-funding/fine-print/terms-of-use), [Privacy Policy](https://docs.projectcatalyst.io/open-funding/fine-print/privacy-policy), and, in addition, the [Curator Terms & Conditions](https://docs.projectcatalyst.io/open-funding/curation/curator-terms-and-conditions). You accept these [via Catalyst platform](https://app.projectcatalyst.io/) on the first login through a mandatory click-wrap agreement before you can flag.

***

#### Our Mission: Flagging Non-Compliant Proposals

Your task is to identify and flag proposals that don't meet the pilot's compliance rules. When you find a violation, submit a private flag to the Catalyst Team. Flags and their outcomes are private throughout the pilot.

You are the **compliance gate**, not the scorer. Curation checks whether a proposal is *eligible and complete*. How good an eligible proposal is, its technical strength and business case, is scored separately by the Decision panel. Keep to your lane: flag what breaks a rule, and leave "is this a strong proposal?" to the panel.

***

#### Your Source of Truth: the Category Brief & Fund Rules

Your flags must be based only on the official [Category Brief](https://docs.projectcatalyst.io/open-funding/funding-basics/category-brief) and [Fund Rules](https://docs.projectcatalyst.io/open-funding/funding-basics/fund-rules) - your flags will be judged against them. These are the source of truth for all compliance. For anything about individual integrations or [Technology Readiness Levels](/open-funding/funding-basics/technology-readiness-levels.md), the [Integration Guides](https://docs.projectcatalyst.io/open-funding/funding-basics/integration-guides) carry the full context. Unlike previous funds, the pilot runs a single category, so there's one Category Brief to check every proposal against. For target-credibility flags, also use the published floors and guidance ranges in the [Proof of Adoption & Standard](https://docs.projectcatalyst.io/open-funding/funding-basics/proof-of-adoption-and-standard) (§3.1, §3.3).

***

#### Your Task: Submitting a Flag

1. The curation window runs in parallel with the submission window, with extra time after the submission deadline - see the program announcement for exact dates.
2. Check your invitation email and how to register.
3. Browse the submitted proposals on the platform - any curator can review and flag any proposal.
4. Check each proposal against the [Category Brief](https://docs.projectcatalyst.io/open-funding/funding-basics/category-brief) and the [Fund Rules](https://docs.projectcatalyst.io/open-funding/funding-basics/fund-rules).
5. If you find a clear, evidenced violation, submit a private flag through the platform. Tick each violation type that applies and add a justification that references the specific brief or rule item.

**Where to flag:** All flags are submitted directly on the [Catalyst Platform](https://app.projectcatalyst.io). Your submission is timestamped automatically, and that timestamp determines who flagged first.

**The submission form asks for:**

* **Violation checklist** - tick every violation that applies (at least one is required).
* **Mandatory rationale** - free-text evidence pointing to the exact submission field (section, character block, or link) that triggered the violation, referencing the specific Category Brief or Fund Rules item. Blind box-ticking without a rationale is prohibited.

***

#### The Violation Types Explained

Each type maps to a hard boundary in the [Category Brief](/open-funding/funding-basics/category-brief.md) or [Fund Rules](/open-funding/funding-basics/fund-rules.md). Flag a type only when you can point to specific evidence in the proposal. **If you're unsure, don't flag.**

**One thing to hold onto before you start:** this pilot gates on the maturity of the applicant's existing product, not on the integration they propose to build. The integration is exactly what the grant funds, from the ground up to mainnet, so an early-stage or not-yet-built integration is expected and is never a maturity flag.

**Violation checklist:** A predefined multi-select list of violation types mapped to the hard boundaries of the [Category Brief](/open-funding/funding-basics/category-brief.md). The curator ticks each violation that applies; at least one is required. Proposers whose proposals receive an accepted flag are notified of the issue category, and their proposal returns to draft for fixing. These are the types exactly as you'll see them in the curation form:

**Who is applying**

* **One proposal:** Each applicant may submit only one proposal. Cross-check the applicant name, entity, and declared team members against other submissions. *Does the same applicant, any member of the team, or entity appear on more than one proposal?*
* **Cardano Standing:** Check the proposal's funding disclosures (Acknowledgements) against the declared project IDs, the project website, the Milestone Module, and other sources. *Has the team failed to disclose an active funded commitment (theirs or any member's, in any ecosystem), or failed to disclose funding, past or present, for the same or substantially similar work as this proposal? Or does the team have an active Catalyst-funded project more than 90 days behind schedule or in delivery over 12 months and still incomplete (for example, overdue milestones or a proof-of-achievement past its deadline), or more than three active Catalyst projects at submission?*
* **Team & Credentials:** *Is the team not properly identified (members or key contributors unnamed, or roles not stated), or are key references (LinkedIn/portfolio/GitHub) missing or unverifiable (e.g. empty or newly created profiles)?* Judge whether the team is identified and verifiable; whether the experience is strong is the panel's to score.

**What they propose**

* **Scope Mismatch:** *Is the proposal marketing-only, dev-tooling, or otherwise outside the category scope?*
* **Integration Eligibility:** *Does the proposed integration fail to target an eligible standard / area of interest (Oracles, Stablecoins, CIP-0113, or CIP-0170), or is it built on the wrong standard?*
* **Product Maturity:** *Is the team's existing product below TRL 5, or is its maturity not evidenced?*
* **Timeline:** *Does the timeline exceed 4 months, or is it unrealistic for the proposed work?*

**The money**

* **Retroactive Funding:** *Do the requested funds cover already-completed work rather than future activities, or include a prohibited use - paying or incentivising users to transact (ADA giveaways, airdrops, transact-to-earn), speculation, or re-granting?*
* **Budget:** The form does not collect a line-item budget, so flag missing or incoherent spend-to-deliverable logic, not the absence of a detailed breakdown. *Is the requested amount unjustified by the milestone outputs - e.g. do the M1 deliverables or the high-level use of funds fail to account for the funding requested?*

**The adoption plan**

* **Target Credibility:** The declared adoption target should be defensible as ambitious-but-realistic against the proposal's own usage plan; the attestation is a proposer claim this flag disputes with evidence. *Is the target indefensible - either sandbagged artificially low to guarantee an easy clear, or inflated beyond what the team, traction, and go-to-market evidence support?*
* **Genuine Usage:** The usage model should be built on real external users. *Does it lack concrete sources of usage (named channels, existing users, or partners with rough volumes), give no first-two-weeks post-launch plan, or rely on usage from the team's own or sponsored wallets?*
* **Partner ID:** *Are the named partners, enterprises, or third parties the proposal depends on unidentified, or referenced without verifiable evidence the partnership exists?* The standard providers proposers integrate, an oracle or a stablecoin, are not partners and need no proof.
* **Technical Approach:** *Are the technical plan and architecture unclear, missing, or not credible?*

**If nothing above fits**

* **Insufficient Information:** *Does the submission lack the information the decision panel needs to evaluate capability or legitimacy (empty claims fulfilling requirements pro forma)?*
* **Other:** A clear breach of the Category Brief or Fund Rules that none of the types above captures; only use it when you can name the specific rule. *Does the proposal breach a specific Category Brief or Fund Rules item not covered above?*

**A caution on judgment calls**

Keep in mind instances where your own preferences/bias might intervene. This applies especially to **Target Credibility**, **Technical Approach**, and **Insufficient Information**, the three types where your own bar could masquerade as a violation. Flag elements only when a required element is **insufficient (so thin there is nothing to evaluate), absent or empty**, not when it's present but you'd have done it differently. Scoring how good a present answer is belongs to the decision panel.

***

#### 🚫 What not to flag

To keep the signal clean, do **not** flag:

* An early-stage, immature, or not-yet-built **integration**, that's what the grant funds.
* A design choice or approach you'd simply have made differently.
* A required answer that's present but, in your view, could be stronger, that's the Decision panel's to score.
* The standard providers a team integrates (an oracle, a stablecoin); many teams use the same ones.
* Anything you're not sure about. Uncertain is not a flag.

***

#### How Rewards Are Calculated 💰

A single reward pool incentivises accurate flagging, **capped at \[18,000] ADA**. It's based on the quality and uniqueness of your flags.

* **Pay-per-flag:** you earn **\[50] ADA** for each **accepted flag**.
* **What is an accepted flag?** The Catalyst Team reviews it, agrees the proposal clearly violates the Category Brief or Fund Rules (with your justification referencing the specific item), **and** you were the first to flag that proposal.
* **What makes a good justification?** Clear, concise, and verifiable, required on every flag. Weak or missing justifications may not be approved, even if the underlying issue is real.
  * **Bad flag (rejected):** "This proposal's budget is vague. Feels non-compliant."
  * **Good flag (accepted):** "Violates the Category Brief's requirement for a concrete 3-month milestone plan. The proposal's Roadmap only lists 'Q1 - Launch' with no detail."
  * Clear, concise, verifiable, no essay required.
* **First-reporter rule:** only the **\[first]** curator to submit an accepted flag for a proposal is rewarded. If several flag the same proposal for the same valid reason, the reward goes to whoever submitted first. Timestamps are based on platform submission time and are final; we won't adjust payments retroactively for timing disputes or system errors.
* **Demoted flags pay nothing:** once a flag on a proposal is accepted, later flags on that same proposal are demoted and unpaid (kept as corroborating data).
* **Re-flag rule:** if a flagged proposal is genuinely fixed and republished, a new accepted flag on it pays again, even from the same curator, as long as the Catalyst Team accepts it. **A curator can be rewarded for the same proposal at most twice.** This covers real resubmissions; repeatedly flagging trivial resubmissions to farm reward events is abuse (see Fair Play) and is not rewarded.
* **Individual cap:** each curator can earn a maximum of **\[1,000] ADA** (20 accepted flags × **\[50]** ADA), to encourage wide participation.
* **Program deadline:** the reviewing window generally runs in parallel with proposal submissions with a bit of extra time post submission deadline (check announcement for exact timing). Flags must be submitted by the close of the window (check program announcements when exactly), or until the **\[18,000]** ADA pool is fully allocated, whichever comes first. Flags submitted by the deadline are reviewed even if the review happens afterward, subject to the pool cap.
* **Flags are never public.** During the window, curators see no outcomes; after the stage closes, each curator is told the outcome of their own flags. Aggregate results may be published; individual flags and their authors are not.
* **Finality:** the Catalyst Team's decision on whether a flag is accepted is final and binding. There is no appeals process.
* **KYC:** payment is subject to successful KYC verification. You can flag without KYC, but you can't be paid without it.
* **Reward** **wallet:** rewards are paid to the reward address you set in your curator profile (via a separate signing action), not to your login/stake address.

**Example scenario:**

You spend an evening reviewing proposals and submit private flags for 12 of them. The Catalyst Team reviews them: 8 are accepted and you were first; 2 are valid but another curator flagged just before you (demoted); 2 are not accepted, as the proposals were fine on a closer look. **Your reward: 8 × 50 = 400 ADA.**

***

#### A Note on Fair Play, Empathy & Good Conduct

Your job is to flag, not to judge. You're an extra set of eyes helping the team focus its attention. When you flag, you're simply stating that a proposal may not meet the criteria and needs an expert review. Any attempt to abuse the system, including "ping-pong" flagging of trivial resubmissions to game reward events, or collusion with proposers, will not be tolerated and may result in forfeiture of bounties and exclusion from future programs.

Please give a clear, concise justification for each flag. There's no need to write an essay.

Thank you for helping ensure voter and panelist attention is focused on the highest-quality proposals, strengthening the entire Cardano ecosystem. ✨

Happy flagging! **The Catalyst Team**

***

\ <br>


---

# 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/curation/curation-guidance.md?ask=<question>&goal=<endgoal>
```

`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.