Grants Program Marketing Skill

For: DAO contributors, protocol marketing leads, grants committee members
Philosophy: A grants program is only as good as the builders it attracts. Marketing is the filter that brings signal, not noise.

How to Use This Skill

MODULE 1 — Program Design & Positioning

Trigger: Building a new grants program or redesigning an existing one.

Step 1: Program Strategy Intake

Ask if not provided:

• What is the protocol/DAO? (brief description and mission)
• Goal of the grants program? (ecosystem growth, developer adoption, community tools, research, marketing/content)
• Budget available per round? (in USD or token equivalent)
• Typical grant size range? (micro: <$5K / mid: $5K–$50K / large: $50K+)
• Who do you want building? (developers, content creators, researchers, community builders)
• Current round/version? (V1 launch vs. V3 iteration)

Step 2: Program Positioning Statement

Craft the grants program identity:

GRANTS PROGRAM POSITIONING
──────────────────────────
Program Name: [Protocol] Grants — [V# or Season name]
Tagline: [1 line that signals who this is for and what's possible]
Mission: "We fund [TYPE OF BUILDERS] who are building [OUTCOME] on [PROTOCOL]."
Scope: [What we fund] vs [What we don't fund] — be explicit
Differentiator: [What makes our grants better/different from Gitcoin, Optimism RPGF, etc.]

Real examples for calibration:

• ✅ "We fund builders who make [Protocol] the communication layer for every dApp."
• ✅ "[Protocol] Grants: Security infrastructure for protocols that can't afford to get hacked."
• ❌ "We support the community in building on our ecosystem." (too vague — anyone could say this)

Step 3: Grant Tiers Design

Step 4: Grants Page Copy Structure

ABOVE THE FOLD
├── Program name + season
├── Tagline
├── Total funding available this round
└── CTA: "Apply Now" + deadline

WHAT WE FUND
├── Category 1 with 2–3 examples of ideal projects
├── Category 2
└── Category 3

WHAT WE DON'T FUND (critical — saves everyone time)
├── [Example: pure speculation/trading tools]
├── [Example: projects without a working prototype]
└── [Example: retroactive funding for completed projects]

HOW IT WORKS (timeline)
├── Applications open: [date]
├── Review period: [X weeks]
├── Results announced: [date]
└── Funding disbursed: [mechanism — USDC, token, milestone-based]

PAST GRANTEES (social proof)
└── 3–5 short spotlights with outcomes

APPLY NOW
└── Link to application form + contact for questions

MODULE 2 — Applicant Acquisition

Trigger: Program exists but needs more or better applicants.

Channel Strategy for Grants Awareness

Twitter/X (highest reach in Web3):

• Announce with a thread — problem + solution + what we fund + apply link
• Tag ecosystem accounts, developer tools, and relevant hackathon winners
• Pin the application tweet for the full round duration
• Post "we're still accepting applications" reminder at 50% and 75% of deadline
• Use: #Web3Grants #BuildOnX #[ProtocolName]

Discord (highest conversion):

• Post in #announcements of your own server
• DM server admins of complementary protocols to post in their #resources or #opportunities channel
• Join developer-focused servers (ETHGlobal Alumni, Developer DAO, Buildspace Alumni) and share in appropriate channels

LinkedIn (underused in Web3, high signal for serious builders):

• Post grants announcement targeting "blockchain developer," "Web3 developer," "smart contract engineer"
• Frame as a career/funding opportunity, not just "crypto stuff"

Direct Outreach (highest quality applicants):

• Identify 10–20 builders who have built adjacent projects and DM personally
• Message hackathon winners from ETHGlobal, Chainlink, or relevant ecosystem events
• Reach out to developers who have forked or starred your GitHub repos

Content to create during application window:

• "Types of projects we want to fund" thread (with examples)
• "Q&A: Common questions about applying" post
• "We funded [grantee] — here's what they built" spotlight to show real outcomes

Application Form Optimization

Keep it short. Every extra field = fewer applications.

Minimum viable application:

1. Project name and one-line description
2. What are you building? (200 words max)
3. How does it benefit [Protocol] ecosystem?
4. Team background (GitHub, prior work)
5. Requested amount + budget breakdown
6. Timeline with milestones
7. Contact info

Remove: unnecessary legal language, complex multi-stage forms, anything that requires >30 min to complete for micro grants.

MODULE 3 — Application Review Framework

Trigger: User needs a systematic way to evaluate grant applications.

Review Scorecard (0–5 per criterion)

APPLICATION REVIEW: [Project Name]
Reviewer: [Name] | Date: [Date]

CRITERION                    SCORE (0–5)   NOTES
─────────────────────────────────────────────────
1. Ecosystem Fit             [  ]     Does this directly benefit [Protocol]?
2. Team Credibility          [  ]     GitHub, past projects, doxxed/anon?
3. Technical Feasibility     [  ]     Can they actually build this?
4. Originality               [  ]     Novel vs. copy of existing project?
5. Milestone Clarity         [  ]     Are deliverables specific and measurable?
6. Budget Reasonableness     [  ]     Fair for the scope of work?
7. Long-term Value           [  ]     Will this still matter in 12 months?

TOTAL: [  ] / 35

RECOMMENDATION:
☐ Approve as submitted
☐ Approve with modifications (specify below)
☐ Request more information
☐ Reject (reason required)

NOTES FOR COMMITTEE:
[Free text]

Review Red Flags

Reject or flag immediately if:

• No GitHub profile or prior technical work (for dev grants)
• Budget request has no breakdown ("we need $20K for development")
• Project could be built without a grant (VC-backed teams asking for grants)
• Copy-paste of another protocol's existing tool
• Team has received a grant before and didn't deliver
• Vague milestones ("we will build the platform" — when? what exactly?)

Interview Questions (for shortlisted applicants)

1. "Walk me through how this integration actually works technically."
2. "What's the biggest risk to this project and how do you mitigate it?"
3. "Why build on [Protocol] vs. alternatives?"
4. "What happens to this project if the grant runs out?"
5. "Have you talked to potential users? What did they say?"

MODULE 4 — Communications & Announcements

Trigger: Need to announce grants round, results, or grantee spotlights.

Round Launch Announcement (Thread format)

Tweet 1 (Hook):
"[Protocol] Grants [V#] is open. [Total $] available for builders who [SPECIFIC OUTCOME].

We fund [TYPE 1], [TYPE 2], and [TYPE 3].

Here's everything you need to know 🧵"

Tweet 2: What we fund (with real examples)
Tweet 3: Grant tiers and amounts
Tweet 4: Timeline (open → review → results → funding)
Tweet 5: Past grantees + what they built (credibility)
Tweet 6: How to apply (link + deadline)
Tweet 7: "Tag a builder who should apply 👇"

Results Announcement Template

Subject/Hook: "[Protocol] Grants [V#] — [X] projects funded, [$Y] deployed"

We reviewed [X] applications over [Y] weeks.
[Z] projects made the cut.

Here's what we're funding and why:

[Project 1 — 2 sentences: what it is + why we chose it]
[Project 2 — same]
[Project 3 — same]
...

Total deployed this round: [$X]
Ecosystem impact expected: [brief vision]

Applications for [V#+1] open [date].
We're looking for builders who [specific need for next round].

Grantee Spotlight Template

BUILDER SPOTLIGHT: [Name/Team]
Project: [Name]
Grant size: [Optional — disclose if protocol is transparent]
Built: [What they delivered]

[2–3 sentences on the problem they solved]

[1 quote from grantee about the experience]

Live at: [link if applicable]
GitHub: [link]

This is what we fund at [Protocol] Grants.
Applications open [date → link]

MODULE 5 — Impact Reporting

Trigger: End of round or quarterly reporting to DAO/community.

Grants Impact Report Structure

[PROTOCOL] GRANTS — [ROUND/SEASON] IMPACT REPORT

OVERVIEW
├── Round: V#
├── Applications received: [X]
├── Projects funded: [X]
├── Total deployed: [$X USD / X tokens]
├── Average grant size: [$X]
└── Round duration: [dates]

FUNDED PROJECTS
[For each project: name, category, amount, status, deliverables met Y/N]

ECOSYSTEM METRICS
├── GitHub stars / forks generated by grantees
├── Users/transactions generated (if measurable)
├── Integrations shipped
└── Follow-on funding raised by grantees

LEARNINGS THIS ROUND
├── What worked: [specific examples]
├── What didn't: [honest assessment]
└── Changes for next round: [concrete improvements]

TREASURY USAGE
└── [Optional: transparency on how funds were managed]

NEXT ROUND PREVIEW
└── Focus areas, budget, timeline, application link

General Quality Rules

1. Clarity converts. Vague grants programs get vague applicants. Be extremely specific about what you fund.
2. Show past results. "We funded X and they built Y" is the best acquisition tool you have.
3. Respect builder time. Long applications signal you don't value their time.
4. Follow up with rejected applicants — they often become great future grantees when their project matures.
5. Publish results even when uncomfortable. Projects that failed to deliver should be documented — it builds DAO credibility.

Grants Program Marketing Skill v1.0
Built for DAO contributors and protocol marketing leads running grants programs that attract real builders.