Changes to Grants Mechanism and Alignment to Delivery: for discussion. Should be read in conjunction with proposals submitted 24/1 and 27/1

Changes to Grants Mechanism and Alignment to Delivery: for discussion.

These changes align to Proposals 1,2 & 3 submitted previously by the same author.

This proposal means that all grants with existing funding lines be re-evaluated against the same criteria changes that would be applied to future funding proposals.

1. Milestone-Based Grant Delivery and Accountability

To ensure grants create measurable growth (and to protect the ecosystem), Terra grants under the BD program and going forward should be delivered as milestone-based tranches rather than a single upfront transfer.

Structure:

  • Stage 0 — Onboarding tranche (small): released on acceptance to cover initial deployment/setup and public documentation.

  • Stage 1 — Delivery tranche: released when agreed core functionality is shipped on Terra (mainnet contracts/feature live), with public links and basic operational readiness (monitoring, incident contacts).

  • Stage 2 — Adoption tranche: released when the project demonstrates measurable adoption outcomes on Terra over a defined window (e.g., 2–4 epochs), using the shared BD metrics (net inflows, TVL, volume/fees, retention).

  • Stage 3 — Expansion tranche : released for additional integrations (Eris/TLA eligibility, Creda market integration, Strategic/Competition Pool participation, partnerships).

Principles:

  • Grants are earned through delivery and adoption, not promises.

  • Milestones are clear, objective, and time-bounded.

  • If milestones aren’t met, tranches are delayed or re-scoped—not politicized.

Why this helps Terra now: It makes “growth spending” survivable: we fund what works and stop funding what doesn’t—without drama.


2) Distribution & Ecosystem Contribution Score (Grant Value-for-Money)

Projects receiving BD support should be evaluated not only on shipping code, but also on distribution and ecosystem contribution—i.e., whether they actively bring users and activity onto Terra in a measurable way.

To avoid incentivizing spam, this proposal uses a Contribution Score based on outcomes and verifiable signals (not “likes” alone). This score is used to:

  • assess whether follow-on grant tranches should be released,

  • prioritize listing in Competition Pools,

  • and justify continued BD support.

Contribution Score inputs (suggested weighting):

A) On-chain outcomes (primary, hardest to fake)

  • Net new wallets interacting with the project on Terra

  • Retention (wallets active again after 7/30 days)

  • Net inflows attributable to the project’s onboarding path

  • Volume/fees generated (with wash-trade filters)

  • Liquidity quality: time-weighted TVL, not snapshots

B) Verified outreach (secondary, auditable, not spam)

  • Number of unique referrals that complete a defined on-chain journey (bridge → swap → LP/supply), using tracked links/codes

  • Educational assets shipped (guides, walkthroughs, short tutorials) that map to on-chain completion metrics

  • Community events (AMAs, demos) tied to measurable participation (tracked sign-ups → on-chain completions)

C) Social presence (tertiary, capped)

  • Social impressions/engagement can be included but is capped and only counted when paired with on-chain conversions (e.g., click-through → on-chain completion).

  • No rewards for raw posting frequency.

Guardrails (to keep it respectable):

  • The highest weight is always on-chain outcomes.

  • Outreach signals must be verifiable (tracked links + on-chain completion), not self-reported screenshots.

  • Clear disqualification for manipulation (fake accounts, wash volume, bot farms).

Reporting: Scores and underlying metrics are published via Terra Pulse weekly so the community can see which projects are delivering real value

**3.Governance ask (non-blocking)**Bottom of Form

  1. Approve changes to granting mechanics and distribution score

I think this proposal focuses mainly on increasing the burden for teams to apply for and receive grants, but it doesn’t address the core problem we’re actually facing.

The real issue today is not a lack of accountability frameworks, but a lack of high-quality teams applying in the first place, combined with an increase in low-effort or AI-generated applications with little original value.

We already have clear guidance on what we expect from serious applicants, including how to avoid these issues, outlined here:
https://medium.com/@PhoenixDirective/grants-for-developers-building-on-terra-phoenix-8c368961d0ec

Most of the concerns raised in this proposal are already covered there. As such, this proposal doesn’t meaningfully solve the current bottleneck and, in my view, doesn’t add much beyond what’s already in place.

Thanks again for the feedback, the proposal was to be read (as I had said) in the context of the other 3 props I have uploaded, including BD and ongoing alignment or otherwise with Astroport… I accept the comments but I would counter by saying that if the granting mechanics were truly working then some of the projects that have taken funds would have delivered on their committments; they have not ..but I won’t name them as thats already been said on X and TG… again I’d ask that the prop is read in conjunction with the others for broader context