Protecting the Signal, Part 2: From Filtering Noise to Designing for Signal
In January, I wrote about Protecting the Signal: how Fund15 cut submissions from 1,643 to 761 by design, then moderated 761 down to 509 eligible entries, and why we published every reason a proposal didn't advance. I ended that piece with a promise: lessons learned would be adapted rapidly.
ref:
nitter.net/dannyribar/status/2009…
Fast forward to present day, with the Catalyst Pilot's curation stage to begin shortly, I want to show you what "adapted" actually looks like. The short version: everything Fund15 taught us after the fact, the pilot now publishes before anyone writes a word. And then it goes three steps further.
🗺️ The Map Is Now Handed Out in Advance
In F15, we discovered the failure modes empirically and told you about them afterwards. The pilot inverts the timeline. Every non-advancement trigger from that article now exists as a pre-declared violation type, published before submissions open:
Brief negligence ➡️ Scope Mismatch and Integration Eligibility. "Treat the brief as a binding contract" is now literal: every flag maps to a hard boundary in the Category Brief.
The self-assessment paradox ➡️ Product Maturity. "Highly experienced" claims are replaced by a Technology Readiness Level with linkable evidence. Reviewers check what you link, not what you claim.
ref:
nitter.net/dannyribar/status/2083…
Ghost credentials and broken links ➡️ Team & Credentials. Unverifiable, empty, or newly created profiles are the stated flag, in writing.
Alias detection ➡️ One Proposal, cross-checked across applicants, entities, and every named team member in any role.
Over-extension and historical standing ➡️ Cardano Standing: active project limits, delay thresholds, and undisclosed funding, all defined upfront.
Placeholder content ➡️ Insufficient Information.
Out-of-scope requests ➡️ Retroactive Funding and a published prohibited-use list.
And the part I'm most pleased with: the Pre-Submission Checklist mirrors this flag list one to one.
If you can tick them honestly, you clear the gate. Nobody can fail a rule they couldn't read. If they do - not sure we can help any more than that.
🔁 From Filtering to Repair
In F15, non-advancement was terminal. In the pilot, an accepted flag doesn't just remove a proposal: the proposer is automatically notified of the issue category, the proposal returns to draft, and there is room to fix and re-finalize before the deadline.
This is the biggest philosophical step since January.
A funnel that only filters protects the signal. A funnel that lets fixable proposals repair themselves improves it. A good project with a paperwork gap no longer dies of paperwork.
🎯 One Gate, One Panel: Lanes Stay Clean
F15's moderation carried two jobs at once: is this eligible, and is this good? The pilot splits them.
Curation is a formal stage run by an invited pool of experienced community members, evolved directly from the L2 Moderation Bounty and calibrated on its real data: first valid flag wins, every flag needs evidence pointing to the specific rule, and accuracy is rewarded, not activity.
Curators are the compliance gate.
What passes them goes to a Decision Panel of technical and business experts, scoring against defined guidance, question by question.
Curators protect the door. The panel judges what walks through it. Neither does the other's job.
📡 The Signal Doesn't Stop at the Ballot
In January I described the Level-Set: due diligence continuing into onboarding. The pilot extends that logic through the entire lifecycle.
Grants pay 40% to build, and the rest only against real, verified usage, measured in Cardano network fees: the number that is hardest to fake quietly and easiest for anyone to re-verify from public chain data.
Signal protection now runs the full arc: submission ➡️ curation ➡️ decision ➡️ delivery ➡️ payment.
Same philosophy at every step: proof over claims, rules before outcomes, evidence anyone can check.
🚀 The Outlook
Step 1 was reducing volume. Step 2 was refining the signal. Step 3, the one we're taking now, is designing for signal from the first line of the rules: published thresholds, a self-audit checklist, paid expert curation, a cure period, and payment that follows verified adoption.
The open door remains a community privilege.
It stays open.
It just comes with a map now.
The pilot's curation window is ahead of us, and like everything in a pilot, this process will teach us things we'll adapt again.
Drop your thoughts in the replies: what would you tighten, and what would you loosen?
Ears to the ground, as always.
D.
get ready:
projectcatalyst.io/apply
10,000+ applications later...
1/ every grant application we read says the same thing: "we're ready" or 'we're mature"
ready/mature compared to what? arguably - web3 has no shared answer for that. so teams overshoot, reviewers guess, and money goes to whoever sounds most confident or yaps on socials by way of popularity contest
2/ and it's not really lying (not referring to 'fake it till you make it'' here). it's just hard to say how ready your product is when there's no scale to point at. so everyone defaults to "very ready" and hopes for the best
3/ we didn't want to invent our own thing here. NASA solved this decades ago with Technology Readiness Levels, a 1 to 9 scale, and programs like Horizon Europe fund against it. we took that and adapted it for Cardano
4/ the whole adaptation is basically one line. their "relevant environment" is our public testnet. their "operational environment" is our mainnet
once you hold those two, the ladder reads itself. an idea is a 1. proof of concept, 3. running on a public testnet, 5. live on mainnet, 7. real users at real volume, 9
5/ from the Catalyst Pilot onwards, every applicant places their existing product on this ladder and links the evidence
the bar for this pilot is TRL 5 or higher. your integration can be at zero, that's fine, that's what the grant pays for: getting it from nothing to mainnet, then to real usage
6/ the part i like most: programs can now state their bar in the same language. this pilot wants 5+. some future ideation round might want 1 to 3. you'd know which door is yours before writing a single word of a proposal
7/ and being honest about a low number stops hurting you. a 3 with real evidence reads better in review than an 8 that falls apart when someone clicks the links. reviewers check what you show, not what you claim
8/ it's a first version, we adapted it for on-chain software ourselves, and it will have rough edges. read it, place your product on it, tell us where it doesn't fit/work. that's what shapes version two
docs.projectcatalyst.io/open…