Delegates haven’t had enough time to review and discuss this proposal yet. We voted against this proposal at this point and recommend they would resubmit one after an ample time of discussions on the forum.
At essentially zero cost and risk to the Collective (1 USDRIF checkpoint, sandbox managed entirely by RootstockLabs with 100 USD deposit caps), this is a low-friction way to explore async vault mechanics for rBTC. No reason to block it.
The current 100% allocation ceiling creates a race-to-the-bottom where builders compete on reward allocation rather than value creation. 90% is a reasonable first step that addresses the worst misalignment without dramatically restructuring incentives. We note @Manu’s argument for a fixed 50%, which has merit as a longer-term direction, but starting conservative and iterating makes sense here. No new smart contract risk since the mechanism is already implemented at the protocol level.
We recognize the team’s responsiveness to delegate feedback and the restructured Milestone 1 (15 events, $3,000), which is a reasonable starting point. The track record of 76+ events across India is credible.
We voted against for two reasons. First, the Rootstock-specific KPIs are too soft. The only on-chain metric is “10-15 new stakers per event”; the remaining metrics (wallet signups, interest forms, Telegram joins) do not reliably measure ecosystem impact. Second, the Rootstock presentation materials have not been shared for review. The existing deck contains no Rootstock content. We are not comfortable funding Rootstock education before the educational content has been reviewed by delegates. We applied the same standard to the Rootstock India proposal and believe it should apply consistently.
We would be happy to support a resubmission with revised materials and harder KPIs.
We vote for this proposal for distributions based on the report by Anode, which aligns with the need for a transparent and data-driven approach to delegate compensation. We welcome @SEEDGov joining the delegate set this cycle.
Disclaimer: we are a beneficiary of the delegate compensation via this proposal.
M2 deliverables are complete and all items we flagged were resolved. This is the valid M3 proposal as confirmed by the grantee; we voted against the duplicate which was submitted accidentally.
The revised M2 scope addresses the key concerns we raised: split routing is reprioritized, Router admin functions move behind a multisig with timelock, and a concrete audit plan is scoped for M3. The team has been responsive and the accountability mechanisms (public comparison page, fee lock until 2028) are solid.
Security audit is a necessary gate before production. $12,000 is on the higher end but the scope warrants it. The team has been responsive to our feedback on operational rigor in the forum.
We are not convinced that a team without a prior Rootstock or RIF delivery record is the right vehicle for shared developer infrastructure. A bug or vulnerability in the kit would propagate to every project that adopts it, and the M1 scope has not yet exercised any Rootstock-specific integration to build confidence against that risk.
The revised scope addresses the systemic-risk concern that drove our prior AGAINST. Our remaining concern builds on Ignas (“no LOIs, no conversations on record with any wallet or dApp team in the ecosystem”) and Curia’s related question about whether any feedback collection had validated that teams are currently struggling with Relay setup: we believe the proposal identifies friction that is not the actual bottleneck to RIF Relay adoption.
The official RIF Relay sample dApp has been stale since May 2024 with issues disabled, and we found no public evidence of a wallet or dApp team citing Relay setup as a blocker. A team with the sophistication to integrate meta-transactions end-to-end is not blocked by local dev environment assembly.
We would reconsider with concrete demand evidence: named integrators or explicit confirmation from RIF Labs that this unblocks specific identified work.
The wallet, SDK, and explorer integration were delivered, and the 12.6% retention figure meets its stated 10% target. However, the DApp integration KPI in this comment, “1+ production DApp integration live with a direct wallet integration (prioritized from popular apps with higher TVL listed on DeFi Llama)” is not met on the reading we set out earlier in the thread. Swapscout is Blockscout’s own swap interface, and Tropykus remains on testnet. The $8,000 to $3,500 reduction honestly accounts for the gas sponsorship delay but does not address the missed KPI, which was the deliverable that would have validated continued investment.
The staker data Georgia provided shows India onboarded 10 new stakers in 3 months (~3.3/month), below the 5 to 10 stakers-per-active-month benchmark set in the program’s own Asia proposal. Argentina was discontinued on the same metric (2 stakers in 9 months); the proposal does not explain why an India rate below the program’s own floor warrants different treatment. Georgia also acknowledged the count applies no minimum-stake, retention, or first-time-vs-existing filter, and the proposal does not describe how a wallet is attributed to a specific ambassador or region. With KPIs “still evolving” and no commitment to track and report those metrics in this renewal period, the program cannot be evaluated against its own north star.
No milestone in the proposal commits an external integrator to anything, and the projects cited as demand-validation evidence publish no public usage metrics, so even successful integrations could not be measured for ecosystem-impact attribution. M1 is scaffolding, M2 a signing layer, M3 Crackdevs’ own example backends, M4 release polish; every acceptance criterion is internal pass/fail that Crackdevs can tick alone. Under the effective grant guideline, unmeasurable outcomes are unfundable, and the impact path here is structurally missing.
This proposal is labeled Milestone 3, but M3 was already funded and executed in April, and the 4,500 USDRIF disbursed here matches M4’s budget, not M3’s 4,000. The team has confirmed the dApp’s milestone form offers no M4 option, and the Foundation says a fix is in progress. We vote against to keep the on-chain record accurate to the milestone actually funded, and are ready to support M4 once a correctly labeled proposal is up.
M3’s acceptance evidence is incomplete: there is no audit report for the deployed gaming contract, which the criteria required, and no on-chain proof of the RIF treasury allocation M3 called for across the cohort. The cohort itself has narrowed to two live projects, so the RIF-alignment thesis that differentiated this grant remains unproven. We are declining to fund the growth phase while the prior milestone’s evidence is open and the pipeline this stage depends on has thinned this far.
This also repeats the sequencing we flagged when M3 went on-chain before the M2 deliverables were reviewable.
We support the shift from a competitive ranking to a threshold-based model, which reduces the incentive to game relative metrics. We would welcome confirmation on the forum of which eligibility criteria apply from June onward.
Disclaimer: we are a beneficiary of the delegate compensation via this proposal.
M3 is delivered: the repository and TLS issues we flagged were fixed and verified before this went on-chain. This resubmission carries the same 4,500 USDRIF as the defeated predecessor we flagged as mislabeled, now correctly labeled Milestone 4, so the on-chain record is accurate and M4 funding can proceed.