General Guidelines for Grant Applications

Hope we’re not too late to join the conversation, we align with the new grants framework and all 6 points in the latest update. As the Rootstock Collective needs to make sure we have sufficient return on every project we fund, including FES to evaluate performance is the right direction. We look forward to a full breakdown of how each component is weighted.

Another point we’d like to raise is around the hard gate process. With 8 steps already in place, we align with all of them, though we do have one question on Step 3: the mandatory Initial AMA before onchain submission. We’re not against the idea of an AMA, but we’re curious about its role at this specific stage, is it there to give delegates more room to ask questions, to signal builder commitment, or something else? We just want to make sure it’s genuinely adding value rather than adding time to an already thorough process.

We think that function is already being covered, and covered well, through the written discussion period on the forum. Delegates already have different strategies and styles when it comes to providing feedback, for example, DAOstar goes deep on financials and return, Tane focuses on audit and security, and so on. Builders are already expected to respond to all of this in detail, and a written exchange naturally forces more precision than a live session would. If anything, an AMA at this stage might end up being more surface-level compared to what the forum period already produces.

We also think it’s worth considering the tradeoff here, between speed, participation, and decentralization. With 8 hard gates already in the process, it might be worth asking whether Step 3 is doing something the forum period isn’t already doing.

On that note, we’d like to kindly suggest an alternative: if delegates feel a proposal has already reached a sufficient level on everything that needs to be reviewed, a simple endorsement comment for onchain submission (minimum 3 delegates) should be enough to move it forward. Similar to the model Scroll uses. This way we still have a meaningful check in place, without adding unnecessary time to the process.

1 Like

Thank you so much, @Axia for catching that, you are correct, and I had that wrong. I really appreicate you spotting that!. :folded_hands: I was looking at the acronym through a strictly ROI lens, but tracking Ecosystem Value (TVL, txs, wallets) makes a lot more sense for what we’re trying to build here. Especially since the tracked value will be a mixer of a few different moving parts rather than just a single dollar amount, it’s going to be really important for builders to understand how the Foundation is putting more emphasis weight behind TVL vs. new wallet growth. Tks!

2 Likes

Thank you so much, @tamlerner for the revised Grant Guidelines V3.2.2, it’s an excellent revision! We also so appreicate your inclusion from the delegate’s feedback with the standardizing the monthly reports, implementing the 30% terminal milestone holdback, and allowing builders to propose custom FES metrics for non-DeFi verticals completely resolves the operational and financial blind spots.

We do have just one quick question on Point 5 (FES for Non-DeFi Verticals):

If a builder proposes their own FES framework, what is the exact mechanism for “delegate approval” on the forum? To prevent high-quality proposals from stalling into a gray area, it would be helpful to establish a clear timeline - for example, if no major objections are raised within 7 days (or 10 days to allow for weekends), the framework is considered provisionally approved for the on-chain vote. This provides a SLA for the grant author and the Collective to be able to adjust any timelines and allocation of effort accordingly. Great work!

1 Like

@tamlerner Thanks for this grants patch, and for clearly incorporating feedback from delegates.

I’m supportive of the direction. The changes move the grants process toward a more outcome-driven and evidence-based framework, which should help delegates make better decisions and help the Collective be more disciplined with treasury spend.

The parts I especially like are the added focus on demand validation, clearer milestone reporting, and the post-completion holdback. Those all point in the same direction: funding projects that can demonstrate real traction, measurable progress, and credible value creation for the Rootstock ecosystem.

The demand validation requirement is especially important. As you write:

This is the right shift.

Delegates should still debate whether a project is worth funding, but potential grantees should come into that discussion with some credible evidence of demand. This should also help reduce noise by improving the quality of projects that make it to an on-chain vote. If demand validation becomes a hard gate earlier in the process, then delegates can spend less time filtering out weak or underdeveloped proposals and more time evaluating the projects with evidence of real market, user, or ecosystem pull.

I also appreciate that the cross-funding disclosure requirement is framed as transparency rather than exclusion. Many strong projects will raise from multiple ecosystems, and that is not inherently a problem. The important thing is that delegates can clearly understand what Rootstock Collective is funding, what outcomes are attributable to the Collective’s support, and whether there is any overlap in scope.

Overall, I think this is a positive step toward making Rootstock Collective grants more accountable, more measurable, and better aligned with growing the network.

Long term, that is what will strengthen Rootstock’s position as the leading Bitcoin sidechain for builders and users!

1 Like

We have a question about this.

How do you suggest a grant applicant should proceed, and what should we, as delegates, demand? Should the applicant set up a private meeting and invite the delegates, should the AMA be held on the proposer’s official X account open to everybody, should the AMA be coordinated with you from the Collective’s side, or in some other way?

Strong direction @tamlerner. These 6 points address real gaps in V3.2 and I’m supportive of moving forward.

I have questions on this:

Does the LOI requirement apply uniformly across all tiers, including Seed (<$3K)? I think requiring a named integrator LOI for a sub $3K grant feels disproportionate, has the team considered tier-adjusted thresholds for the evidence required?

And at what step in the application flow must Demand Validation be submitted, before or after the off chain proposal?

Thank you!

1 Like

Hello @tamlerner , will you still be publishing the revised v3.2.2/v3.3 on the Forum, as you mentioned a couple of weeks ago, are you still looking for more feedback from delegates? Tks!

2 Likes

Hey everyone, thank you for the patience and for keeping the pressure on with good questions, going through them one by one below :backhand_index_pointing_down:

@Axia

  • We’re not building a heavy fraud-detection layer, not worth it for our size right now but
  • Wallets will need repeat activity over time, not just creation
  • TVL gets cross-checked against on-chain data, not self-reported numbers - via FES dashboard that will go live soon. MVP is already live and being tested internally.

@DAOstar_gov

  • No separate audit fund or marketplace for now, too much overhead for where we’re at
  • Leaning direct-to-auditor, but tied to audit-readiness rather than the initial tranche
  • On the holdback, we love the instinct, folding it into the terminal milestone review instead of stacking a second mechanism on top

@Ignas

  • Not introducing formal top-down targets on top of the Strategic Themes for now since the public FES dashboard should surface ecosystem-level signal once it’s live :slight_smile:
  • We’d rather have a handful of well-aligned grants than a tracking exercise/filtering noise for now.

@seedgov

  • The Initial AMA is really aimed at people outside the forum, folks who aren’t deep in Discourse or the dApp yet
  • It’s a discovery moment, a chance for them to meet the founders and find their way to the dApp through that - and to be honest also a bit more of a personal touch.
  • Not meant to duplicate the forum discussion, more of a wider door in

Appreciate everyone digging into this with us, keep the thoughts coming if anything here doesn’t sit right :folded_hands:

5 Likes

:loudspeaker: Grants Guidelines V3.3 - Now Enforced

Status: Enforced, effective immediately
Supersedes: V3.2
Full PDF document available upon request

We’ve updated the Grants Guidelines to close a few gaps identified since V3.2 - mainly around proving real demand before funding, tightening how we measure impact, and being more transparent about funding sources and security history. Below is a summary of every substantive change. If a section isn’t mentioned, it hasn’t changed.


:new_button: New Requirements

1. Demand Validation is now a hard gate (Section 3.1, Step 2)
Off-chain proposals must now include a Demand Validation section before a project can proceed to the Initial AMA. Evidence required depends on sector:

  • Dev tooling / infrastructure: at least one named integrator LOI, or documented interest from a top Rootstock dApp
  • Consumer applications: waitlist size or MVP usage data
  • Payments / infrastructure integrations: counterparty signoff on integration scope
  • Seed tier (<$3K): a lighter-weight equivalent is acceptable (e.g. documented user interviews, signed pilot interest form)

Proposals without this evidence will not proceed.

2. Cross-Funding Transparency (new Section 6)
Builders must now disclose any concurrent or prior funding for the same project or overlapping scope — including funding from other DAOs, protocols, institutions, and from within the Rootstock ecosystem itself (Rootstock Labs, or a prior RootstockCollective grant wave). This is a transparency requirement, not an exclusion criterion. Required as part of the off-chain proposal.

3. Prior Security Incident Disclosure (Section 8)
Projects must now disclose any prior security incidents involving the founding team, protocol, or codebase being extended — on Rootstock or any other chain — including what happened, impact, and remediation taken. This applies regardless of whether the incident is publicly known.

4. Terminal Milestone Withheld Until Post-Completion Review (Section 7)
A final tranche of ~30% of total grant value is now withheld until a post-completion impact review confirms delivery against the committed targets. This closes the previous gap where the final milestone had no completion gate.


:gear: FES & Measurement Changes (Section 4)

Anti-Gaming Safeguards

  • New wallets must show repeat on-chain activity over a 30-day window to count toward FES — wallet creation alone doesn’t qualify
  • TVL is now cross-checked against on-chain data via the FES Dashboard, not self-reported by grantees
  • The FES Dashboard is live internally, with public release planned as it matures

FES for Non-DeFi Verticals (new subsection)
Projects outside DeFi now propose their own FES metrics as part of the off-chain proposal (e.g. developer adoption for SDKs/tooling, query volume for analytics/dashboards). Delegates can challenge the proposed metrics during the community discussion window. If no objection is raised within 7 calendar days, the proposed framework is automatically approved and becomes the binding measurement standard.


:tada: New: Positive Performance Incentives (new Section 13)

Grantees who meaningfully exceed their committed FES targets are now eligible for:

  • Priority consideration in future grant waves
  • Public spotlight features across Collective channels
  • Co-marketing opportunities
  • Fast-track pathway into the Collective Builders program

Outperformance is assessed at the Final AMA against the original Value Commitment Plan.


:wrench: Process Clarifications

Denomination Clarified (Section 7)
Grants are requested and disbursed in USDRIF as standard. A different denomination (e.g. rBTC) may be requested where genuinely needed, with justification in the off-chain proposal and approval as part of the on-chain vote.

Eligible Sectors — Events/Marketing Exclusion Clarified (Section 3)
Format alone doesn’t determine eligibility: an in-person or event-adjacent component doesn’t exempt a proposal from the events/marketing hard exclusion if the core deliverable is attendance or awareness rather than a measurable on-chain outcome. Ambiguous cases are resolved by delegates during the off-chain discussion period.

Initial AMA - Purpose Expanded (Section 10)
Clarified that the Initial AMA is not a repeat of the written forum discussion — it’s a live, public-facing moment closer to a co-marketing soft-launch, presented alongside the Collective (and Rootstock Labs where relevant). AMAs are coordinated and scheduled by the Collective once a proposal clears pre-screening. Recordings are published to YouTube and announced on X.


Questions? Reply below !

The Rootstock Collective Team


:link: Pre-Screening Form docs.google.com/forms/d/187Cr1…
:speech_balloon: Grants Forum gov.rootstockcollective.xyz/c/grants/5
:chains: On-Chain Proposals app.rootstockcollective.xyz/proposals
:e_mail: KYC / KYB Questions compliance@rootstockcollective.xyz
:bird: Twitter / X @RootstockColl
6 Likes

This is a substantial improvement, as it provides much greater clarity on issues that had remained unclear!

Good clarification! Thanks. These metrics make a ton of sense.

1 Like

Very interesting data here to keep in mind in the case of a proposal. I think this update substantially improves the governance framework. I especially find value in the separation between delivering a product and demonstrating that the product generates value for the ecosystem. Which I consider crucial when validating the product concept with the community. This demand validation as a prior step to funding seems especially relevant. Requiring concrete evidence (such as an LOI from an integrator) reduces the risk of funding technically correct infrastructure that has no real users. In the same vein, I consider it positive that TVL and new wallets are now measured using on-chain data and repeated activity, reducing incentives to inflate metrics. Genuine activity = real participant.

I also see it as correct to retain approximately 30% of the grant until a later impact review. This better aligns the builder’s incentives with the final result and not just with the delivery of milestones. A vision similar to a “construction contract” in Law, where the quality of the product is judged by its finished result and not by the short-sighted perspective of meeting these objectives or checkpoints.

If I could contribute something to the conversation; my main suggestion would be to define more precisely what constitutes success when the proposal depends on third-party adoption. An LOI demonstrates intent, but not necessarily effective integration or sustained use.

Overall, I consider that V3.3 represents an important step towards a more evidence-based capital allocation, where technical execution is necessary, but verifiable impact ends up being the true criterion for success.