Pre-Submission Checklist

Run this before you submit. At this stage you have a product, a plan, and a declared target, you haven't built the integration or generated any usage yet, and that's expected. So this checklist doesn't ask what you've delivered. It asks the two things review will judge from your proposal: are you eligible, and is your proposal strong enough to fund?

Answer honestly. If you can't tick a box, that's the thing to fix before you submit.

How this connects to review. The items in Section A are exactly what curators flag against at the compliance stage; if you can tick them, you clear the gate. Section B is what makes an eligible proposal a strong one, which the Decision panel scores.

A. Eligibility gate

Who you are

• One proposal. This is our only proposal, and no individual on our team, in any role (lead, member, subcontractor, or service provider), is named on another. We're not splitting across entities to get around the limit.

• Good standing. Either we've never had Catalyst funding, or our record is clean: nothing more than 90 days behind or over 12 months incomplete (unless the Fund Operator has accepted a valid reason), and no more than three active Catalyst projects. Either way, we've disclosed all our active funding commitments, and any funding, past or present, for the same or substantially similar work.

• Named, verifiable team. Every team member and key contributor is named, with their role on the project stated; their profiles (LinkedIn, GitHub, portfolio, references) are real and checkable; and we've disclosed each member's involvement across every proposal this round.

What you propose

• Eligible area. We use at least one: Oracles, Stablecoins, CIP-0113, or CIP-0170.

• Mature product. Our existing product is at TRL 5 or above, validated on a public testnet or live, and the evidence is linkable. We're not relying on the integration's maturity; that's the new work the grant funds.

• Fits the timeline. Our plan reaches mainnet within a credible 3-month build window and completes within the 4-month pilot.

The money

• Genuine new work. The budget is for future activities only, not retroactive funding, and we're not planning a prohibited use: paying or incentivising users to transact (ada giveaways, airdrops, transact-to-earn), speculation, or re-granting.

• Clear budget. Our budget has a real breakdown tied to deliverables.

Your adoption plan

• Real target. Our declared target can be defended as ambitious but realistic (the form enforces the floor; ambition is scored both ways), and we understand it is final at submission and published next to what we deliver.

• Real users. We've named where usage will come from, channels, existing users, partners, with rough volumes, including our plan for the first two weeks after going live. Our usage model is built on real external users; we understand fees from our own or sponsored wallets won't count.

• Identified dependencies. Any third parties we depend on are named with evidence the relationship exists. (The standard providers we integrate, an oracle or a stablecoin, are not partners and need no proof.)

The paperwork

• Standard read and attested. We've read the Proof of Adoption & Standard and can honestly attest our plan complies.

• Public proposal. We understand our proposal and all its contents are published publicly, along with our progress reports and results, and we've obtained any consent needed before including third-party or confidential information.

B. Will it stand out?

Eligibility gets you considered; these get you funded. The Decision panel scores a technical review and a business review, and your team runs through both.

• Team. We've evidenced why this team can deliver this specific work: relevant track record, prior shipped products, named roles, not just titles or a list of names.

• Technical. Our architecture is sound and buildable to mainnet within three months, and we've shown it, not just described it.

• Business. We've shown real demand with evidence, named our competitors and why users switch or activate, and explained durable usage. Our business case shows why usage persists after the grant, not just during the measurement period.