Rootstock Collective has published a detailed guideline for submitting grant applications.
If you’re planning to apply to one of the grants waves, please do yourself the favor and read it carefully!
https://rootstockcollective.xyz/submitting-a-grant-proposal/
Please use the following template for submitting your Grants proposal!
Grants Off-chain Proposal Template
Please keep the same names for off-chain and on-chain proposals.
Suggested title:
Suggested Title: [YYMM BIG Wave X] Protocol Name
Suggested description:
Project Name:
Submission Date:
Founder Name: Feel free to include the founders’ backgrounds, LI profile
links, short bio, if you think this might help the community to vote for your Project.
Award Amount:
Project Stage:
Sector: Payments / Remittance …etc
Links to Deck / Video / Images: Paste only self-hosted links accessible to community
members.
Links to socials:
Description:
Mission:
Product: Describe your products. What are the main features? How your product adds value to the Rootstock ecosystem. And if there is synergy with other projects on Rootstock?
Team:
Traction: What are some of your key achievements (user count, community numbers, number of trx, TVL)?
Roadmap:
Conclusion:
Updates on Grant Application Process - New Path to BuildingJune 2025
Hey builders! As RootstockCollective grows and more amazing projects join our ecosystem, we’re always tweaking our processes to make things smoother for everyone. This updated framework is all about helping you get the funding you need while keeping our community standards rock-solid. Let’s build the future of Bitcoin together! 
How to Apply for a Grant
Step 1: Complete KYB Requirements
Step 2: Create Your Off-Chain Proposal (Discourse, yes here!)Post your grant proposal on Discourse using this structure:
Title Format: [YYMM Grant] Project Name - Milestone 1
Mandatory Information:
Step 3: Submit Your On-Chain ProposalAfter KYB is approved and community discussion has occurred:
Go to the RootstockCollective dApp
Stake at least 1,000 stRIF
Submit an on-chain proposal requesting only the first tranche
Include a link to your Discourse proposal
Proposal enters voting
How Do I unblock the next tranche of my Grant?After you have achieved your milestone, you can unlock your next tranche!
Requirements
Ready to build at the Collective? Let’s ship it!
Great guidelines. Wanted to hone in a bit on what measurable KPIs for milestones mean.
Generally anything that has an API counts. On-chain is definitely preferred, I would say.
But Google Analytics or other growth-focused analytics providers are also very welcome.
More difficult are hard-to-verify sources like event attendance, mind share or similar metrics where sources boil down to trusting a stated number or metric with no due corse of verification.
If builders find a way to surface verifiable metrics that’s of course a different story altogether.
Just pointing out that easy-to-verify metrics are preferable.
Dear RootstockCollective Community,
I’m thrilled to introduce our refreshed grant guidelines (V3.1), launching alongside our latest dApp update (V7.1)! 
These enhancements reflect our ongoing commitment to supporting innovative builders while ensuring our resources drive meaningful impact across the Rootstock ecosystem.
If you have already passed your KYC, you are ready to create your offchain proposal here. Here is our suggested Template:
Title Format: [YYMM Grant] Project Name.
For example: [2511 Grant 3] Amazing Protocol XYZ
Proposal Content:
A. Project Name:
B. Classification:
- Project stage (MVP, Beta, Growth, Mature)
- Sector (DeFi, Infrastructure, Developer Tools, Consumer Apps, etc.)
- Target audience
Submission Date:
Founder Information:
Founder name(s)
Professional background
LinkedIn profiles
GitHub profiles
Prior blockchain experience
Team:
Key team members and roles
Relevant experience and expertise
Previous blockchain/web3 projects
Pitch deck link (self-hosted)
Demo video/prototype link
Screenshots/mockups
Technical documentation
Traction & Metrics:
Current user base (if applicable)
Transaction volume (if applicable)
TVL (if applicable)
Growth trajectory
Key achievements to date
Grant Request:
Total amount requested
Milestone breakdown with associated deliverables and dates
Amounts per milestone in desired coin/token: USDRIF, rBTC
Mission & Vision:
Product Details:
Core features and functionality
Technical architecture
Integration with Rootstock
Security considerations
Description:
Core problem being solved
Solution overview
Unique value proposition
Competitive analysis
Clear timeline with measurable deliverables
Major milestones and expected completion dates
Key success metrics for each phase
Performance Targets: Specific, measurable goals for:
Transaction volume
TVL (Total Value Locked)
User acquisition
Other relevant metrics
Conclusion:
Summary of key points
Call to action for community support
Social & Community:
Website
Twitter/X
Discord/Telegram
GitHub repository
Note on AI Usage: We encourage applicants to use AI tools to help correct typos or improve narrative flow in their proposals. However, excessive AI-generated content that lacks authentic project voice or specific technical details will be flagged during review. The strongest proposals demonstrate genuine team expertise and project understanding that can’t be fully replicated by generative AI. Use these tools to enhance your communication, not replace your unique project perspective.
Our program focuses on projects delivering measurable value to Rootstock in the near term, with three grant tiers:
Small Grants (up to $10,000) 💡
For early experiments and marketing initiatives
Medium Grants ($10,000 - $25,000) 🌱
For working products seeking growth
Large Grants ($25,000 - $75,000 or more) 🚀
For established projects with significant impact potential
Key performance metrics include transaction volume, TVL, user adoption, developer activity, and community growth.
Key performance metrics include transaction volume, TVL, user adoption, developer activity, and community growth. While these amounts are estimative, please note that community will request detailed justification for all requested funds.
We encourage established projects to consider applying for smaller grants for targeted integrations when appropriate. These tiers are indicative but not mandatory - the focus is on demonstrating clear value relative to the requested amount.
Guidelines on approval: While we support promising projects through the application process, we cannot guarantee positive community votes even when proposals meet all guidelines. The final decision rests with the decentralized community governance process.
Process Order: KYC first → off-chain submission → on-chain proposal
Eligibility: 
U.S.-based companies/UBOs not eligible at this time (updated November 3rd 2025)
Community Period: Allow 1-3 weeks for feedback and delegate engagement on your off-chain proposal (forum).
Sharktank Sessions: Be prepared for potential live presentation opportunities on our X Spaces with moderators from the Collective, Rootstock or KOLs.
We’re excited about empowering builders expanding Bitcoin’s potential through Rootstock. We encourage you to take a good look around our website: https://rootstockcollective.xyz/ for more documentation, and of course, our amazing dapp to check the latest proposals and more! : https://app.rootstockcollective.xyz/.
Have any other doubt? Reach out to the team via the General Channels on our Telegram channels, leave your comment on the Forum thread of interest or tag us on X - we are here to help!
GLHF 
The Rootstock Collective Team
RootstockCollective funds builders who generate measurable, verifiable on-chain activity on Bitcoin’s OG sidechain.
This is the official summary of our V3.2 Grants Guidelines — covering what we fund, how we measure impact, and how to apply.
Status: Enforced — Effective Immediately
Current Version: V3.2 — supersedes all prior versions
We allocate capital to projects that drive on-chain activity, user growth, a
nd ecosystem expansion. Not promises — verifiable impact.
Core Priority Sectors Conditional Sectors (measurable ROI must be clearly defined)
Hard Exclusions — We Do Not FundWe don’t measure ROI in the traditional sense. We measure ecosystem value.
Every funded builder is tracked against the Funding Efficiency Score:
All disbursements are milestone-gated. Initial tranche is capped at 20–30% of total grant value.
| Tier | Grant Range | Initial Tranche | Milestones | Security Review |
|---|---|---|---|---|
| Seed | < $3K | 30% | 2 checkpoints | Standard |
| Scaling | $3K – $10K | 25% | 3 checkpoints | Enhanced |
| Strategic | $10K – $35K | 20% | 4 checkpoints | Full audit req. |
Funding may be paused or stopped upon: no measurable progress · lack of communication · milestone failure · misalignment with approved proposal.
These themes represent the Collective’s active priorities for FY 2026/27. Proposals aligned to these themes receive elevated attention from delegates.
RIF Economy Enablers
Projects that expand the utility, circulation, or velocity of RIF. Examples: services built on RIF protocols (RNS, RifOnChain), RIF-powered access or subscription models, new RIF liquidity pairs, tooling that creates genuine RIF demand.
USDRIF Adoption & Real-World Circulation
Direct integrations of USDRIF as a payment, savings, or settlement layer. Examples: checkout integrations accepting USDRIF, USDRIF-denominated contracts or payroll streaming, DeFi products where USDRIF is native collateral.
Collective dApp Usability Improvements
Tools that reduce friction in the governance dApp. Examples: proposal readability enhancements, mobile-optimised voting UX, delegation flows, governance activity dashboards.
Rootstock Onboarding UX
Anything that meaningfully reduces Time-to-First-Transaction. Examples: wallet abstraction, onramp integrations, EIP-7702 / chain abstraction experiments, simplified swap or bridge UI.
Contribution Score Infrastructure (Exploratory)
On-chain reputation layers tracking contributions from builders, delegates, and community members. Open, auditable designs strongly preferred.
TVL Movers — Meaningful Capital Attractors
DeFi protocols, liquidity layers, lending markets, or yield products with a credible path to attracting on-chain capital. Must include TVL targets. Minimum expected FES: 1.5× within 12 months.
Each step is a hard gate — skipping any step disqualifies the application.
Step 01 — Pre-Screening & KYC / KYB
Submit your project information and complete identity verification via our onboarding form. Contact: compliance@rootstockcollective.xyz
Step 02 — Off-Chain Proposal on Discourse
After pre-screening approval, publish your proposal in the Grants section for community discussion (1–3 weeks).
Step 03 — Initial AMA
Present your project publicly. Open Q&A with delegates. Mandatory before on-chain submission.
Step 04 — On-Chain Proposal
Submit via app.rootstockcollective.xyz/proposals. Requires 1,000 stRIF minimum + ~$2-5 USD in rBTC for gas.
Step 05 — 7-Day Community Vote
stRIF holders vote For / Against / Abstain. Quorum must be reached.
Step 06 — Initial Disbursement
Builder receives first tranche (M1) in the wallet used for in dApp/pre-screening. Same wallet required for all subsequent disbursements.
Step 07 — Milestone Reviews, Monthly Reports & AMAs
Subsequent tranches unlocked upon verified delivery. Monthly Activity Reports submitted on Discourse between each milestone.
Step 08 — Final AMA & Close
Full retrospective AMA. Post-grant obligations commence immediately — builders remain ecosystem ambassadors for 12 months minimum.
| Criterion | Weight | Notes |
|---|---|---|
| Clarity & credibility of ROI | High | Primary filter — weak ROI = instant reject |
| Measurability of outcomes | High | Unmeasurable = unfundable |
| Security awareness | High | Critical for DeFi / infrastructure |
| Alignment to 2026 Strategic Themes | High | Priority themes receive elevated weighting |
| Team capability | Medium | Track record strongly preferred |
| Ecosystem contribution | Medium | Beyond own product scope |
| Communication commitment | Medium | 12-month obligation + AMA compliance |
Grant completion does not end your obligations. For a minimum of 12 months following grant closure:
Non-compliance results in ineligibility for future grants and may be flagged publicly within DAO governance.
| Pre-Screening Form |
docs.google.com/forms/d/187Cr1… |
| Grants Forum |
gov.rootstockcollective.xyz/c/grants/5 |
| On-Chain Proposals |
app.rootstockcollective.xyz/proposals |
 KYC / KYB Questions |
compliance@rootstockcollective.xyz |
 Twitter / X |
@RootstockColl |
RootstockCollective · Grants Guidelines V3.2 · Latest update: 6th of May 2026
Built on Bitcoin. Governed by the Community.
Thanks for putting V3.2 together, @tamlerner. It is a meaningful step forward and aligns with several positions we have been raising across grant reviews this cycle. Three additions we would like to put forward.
V3.2 weights ROI clarity and Measurability as HIGH criteria, but does not specify what evidence of demand looks like. The result is that the demand question lands on each delegate at proposal time, repeatedly. Consider adding a “Demand validation” section to the standard proposal template, with category-specific evidence types defined by the Foundation:
This converts the demand check from a delegate-level question into a pre-screening hard gate, consistent with V3.2’s posture.
V3.2’s Step 07 is structured so that “subsequent tranches unlocked upon verified delivery,” meaning every milestone gate doubles as a verification gate for the prior milestone. The gap is that the last milestone has no completion gate after it. Once the last tranche is voted through and paid, the grantee can credibly coast on completing the remaining deliverables for that milestone, since no grant is left at risk to finish shipping them. Improved post-payout observability surfaces the underperformance but doesn’t restore the lever; restoring leverage requires holding budget back, not just data.
We would suggest adding a terminal milestone of roughly 30% of the total grant: a post-completion review tranche, voted on and paid only after overall impact data is reviewed against the targets set in the proposal. This terminal milestone IS the completion gate that V3.2 currently lacks. It extends the “verified delivery” principle to the end of the grant; otherwise the V3.2 “may be paused or stopped upon milestone failure” clause is only enforceable for non-terminal milestones.
Strategic-tier grants require a full audit, but with a 20% initial tranche on a $10K-$35K grant, builders receive $2K-$7K upfront. Standard smart contract audits typically range from several thousand to tens of thousands of dollars depending on scope and codebase size, which makes audit-cost financing a structural barrier to applying at Strategic tier for early-stage protocols.
One framing that keeps the grant program scope clean: exclude audit cost from the grant ask itself, so the $10K-$35K cap covers build work only, and audits are funded through a separate channel. Uniswap’s Foundation Security Fund (UFSF) is one working reference: a $1M Uniswap Foundation initiative (administered through Areta) that subsidizes up to 100% of audit fees for selected projects via a whitelisted-provider marketplace. Curious how the Foundation is thinking about this gap.
We see V3.2 as a strong base. Happy to dig in further on any of these.
Hello @tamlerner , thank you so much for the revised Grant Guidelines. V3.2 is a very strong step toward professionalizing our grants process, which we believe is required for the maturity of the grants program and more importantly, attracting projects and builders who are committed to enhancing and strengthening Rootstock. The move to a performance-based model is welcome, but there are a few “on-the-ground” frictions in this version that might unintentionally bottleneck high-quality builders.
1. Solving the Strategic Audit Barrier: The requirement for a full audit at the Strategic Tier ($10k–$35k) is necessary, but the math doesn’t currently work for early-stage teams. A 20 % initial tranche ($2k–$7k) typically won’t cover a professional audit, meaning the most impactful projects face a massive out-of-pocket cost before they can even start.
Proposed Solution: Instead of creating a separate, complex “Audit Fund” program, as @Tane suggested, we could allow Direct-to-Auditor milestones. Note that we are supportive of Tane’s recommendation for a Security Audit program (simular to Uniswap’s UFSF), however program expense and management/oversight would have to be scoped first to determine if it’s even feasible, and with our current group of builders our builder ecosystem size might not justify a full fledge program at this point.
Ques: Can the Foundation facilitate paying the auditor directly from the project’s total grant allocation? This solves the builder’s liquidity issue without the DAO needing to manage a new, expensive sub-committee or marketplace, and it also provides a simplified solution that meets the importance of security audits without penalizing our strategic tier proposal builders.
2. Defining “Ecosystem Revenue” in the FES: The FES formula (Revenue / Funding) is a great accountability tool, but it needs a strict definition to be useful.
Our Concern: If “Revenue” is defined too narrowly (i.e. only protocol fees), a 1.5 x FES in 12 months will be mathematically impossible for many sectors, specifically B2B infrastructure.
Ques: How is the Foundation defining “Revenue” for non-DeFi projects? For example, does a service provider count total contract volume or the cost-savings they provide to the Collective? Without a standardized reporting template or RACI matrix, “Monthly Reporting” will likely vary too much to be comparable. We recommend a template is provided for the monthly reporting requirement, to ensure that each report includes the necessary sections.
3. Post-Grant Teeth: To ensure the 12-month post-grant obligations are actually met, we suggest a Performance Holdback. Releasing a final 10 % of the grant only after 3 months of live, post-completion activity ensures builders stay engaged as ambassadors.
Thks, and looking forward to hear more at our strategy session tomorrow!
This is a major step forward in providing greater predictability and objectivity to the framework, both for applicants seeking grants and for the DAO when evaluating them.
However, we do have some questions and observations.
Among the high-priority sectors listed are:
All of these verticals are clearly strategic and high-priority for the ecosystem. However, the ROI of these types of products cannot be properly measured solely through traditional metrics such as TVL, new wallets / unique users, transaction volume generated, or DAO engagement.
The impact of these initiatives tends to manifest in different ways. For example:
We believe it will be important to develop more nuanced and creative evaluation mechanisms so that the ROI of these kinds of grants, which are often indirect or enabling in nature, can still be assessed in a reasonably objective way, without relying primarily on the subjective opinions of reviewers.
Thanks for putting V3.2 together, @tamlerner . Cohort 1 grad here, holding off on submitting until the audit financing question Tané and DAOstar raised is sorted. TYKORA’s Coinspect quote was $11K, and a 20% initial tranche on a sub-$20K ask leaves the builder around $3-4K up front, against an audit fee likely in the $8-12K range.
Paying the auditor directly seems cleanest, as DAOstar suggested. Going to do KYB in the meantime so that’s not a bottleneck either.
One question: with Ignas’s LOI ask on RelayDevKit as the recent example, what’s the recommended order for solo builders preparing Strategic-tier proposals right now? Get integrator letters first, engage an audit firm first, or wait for V3.3 to land?
Will submit a multi-protocol ERC-4626 yield vault once V3.3 lands.
The idea @Tane raised of a separate earmark for audit funding, thus running outside of the usual grant rules, is interesting.
But this would be an important decision to be made, possibly by Labs and Collective in conjunction, and not just a small clarification into the current Guidelines version.
Indeed. We have spoken about this to Areta in the past, who have successfully operated an audit support fund on multiple chains including Arb and Unichain. The fund helped promissing builders secure their applications. In the end nothing is more damaging to an ecosystem than a major hack.
The important thing there is that it has a significant operational cost associated. Builders have to be tightly vetted, matched to known auditors and in the end the success of the builder isn’t directly tied to their smart contract security, unfortunately.
Still think this is a really good avenue to explore.
Thanks for the V3.2 update Tamara, strong step toward a more performance-driven framework.
One thing I’ve been thinking about is how FES holds up across very different verticals. Even with good project level metrics, outputs from DeFi, infra, or UX aren’t directly comparable, and over time capital could naturally drift toward what’s easiest to measure rather than what’s most valuable. Agree with @SEEDGov that
On a related note, it would be helpful to understand what success looks like at the ecosystem level, not per grant. I mean the strategic themes are clear, but having some sense of top-down targets could help builders align beyond optimizing for individual proposals.
For the post-grant obligations are well defined, I wonder if there’s room to complement enforcement with stronger positive incentives such as giving more visibility or advantages to builders who outperform, rather than just ensuring baseline compliance.
Very much support this notion.
The difference of “playing to win” vs “playing not to loose”.
Vastly different outcomes.
Hi everyone,
The patch will address the main points raised in the thread and during our last call, including:
— Cross-funding transparency disclosure
— Demand validation as a pre-screening requirement
— Terminal milestone / post-completion holdback (~30%)
— Standardized monthly reporting template
— Sector-specific FES adaptations
— Audit financing options for Strategic-tier builders (still under discussion)
— Positive incentives for outperforming builders
Please review the current forum thread ahead of the post if you haven’t already - as a reminder, any final input before Friday is welcome directly in here 
Hey @DAOstar_gov just want to point out that the FES formula does not include Revenue. The formula is Ecosystem Value Generated/Funding Distributed. Ecosystem value is comprised of TVL, new wallets / unique users, transaction volume generated, and DAO engagement.
@tamlerner On that note, I am wondering what guardrails you are thinking about for ensuring that the ecosystem value components are not gamed. I have seen in other ecosystems that projects can game new wallets by mass self-creating wallets. And TVL is a complex metric with many components. Defillama’s TVL calculation is a good starting point for the discussion. DefiLlama Explained: Features, LlamaSwap & More (2026)
Hey everyone - and thank you to everyone who engaged with V3.2 since it went live on May 6th. The thread, the delegate calls, and the direct messages have all been genuinely useful. We read every comment.
Below is a transparency note on what we’re incorporating into V3.3. The full updated post will replace this one once it’s finalized — but we want to be upfront about what’s changing and why before it goes live.
1. Demand Validation → new pre-screening requirement
We’re adding a mandatory Demand Validation section to the off-chain proposal template. The evidence required will vary by sector: a named integrator LOI for dev tooling and infrastructure, waitlist or MVP usage data for consumer apps, counterparty signoff for payment integrations. This converts what has historically been a delegate-level question at review time into a hard gate at the application stage, consistent with V3.2’s overall posture of measurability before funding.
2. Terminal Milestone → ~30% post-completion holdback
We’re introducing a final tranche (~30% of total grant value) that is released only after a post-completion impact review against the targets committed to in the approved proposal. This closes the gap where the last disbursement currently has no delivery gate beyond it. The “verified delivery” principle in V3.2 now extends to the full grant lifecycle.
3. Cross-Funding Transparency → mandatory disclosure! (as discussed on Delegates Coffee)
Builders will be required to disclose any concurrent or prior funding from other DAOs, protocols, or institutions for the same project or overlapping scope. This is a transparency requirement, not an exclusion criterion - it helps the community make better-informed decisions and surfaces potential attribution gaps early.
4. Standardized Monthly Reporting Template
Monthly Activity Reports will follow a required structure to ensure comparability across grantees and grant waves. The template will cover: on-chain metrics (TVL delta, tx count, new wallets), off-chain milestone progress, and a short narrative. The two-missed-reports trigger for automatic funding review remains in place.
5. FES for Non-DeFi Verticals For projects outside DeFi, builders are required to propose their own FES metrics as part of the off-chain proposal. These will be reviewed and approved or challenged by delegates during the community discussion period. Once approved, they become the binding measurement framework for that grant.
6. Positive Performance Incentives
V3.2 is enforcement-forward - which is right for accountability. But the framework should also reward builders who meaningfully outperform their targets. We’re working on a recognition and incentive layer for high-FES grantees: this includes priority consideration in future waves,public spotlights, opportunities for co-marketing, and a fast-track pathway into the Collective Builders program!
If you have input on any of the above, the thread is open until next week. If we all agree on these 6 points, the full post will be added by the end of next week as the new implemented and revised v3.2.2
