Hi @Crackdevs I voted Abstain on this proposal.
The underlying problem seems real, and I appreciate the work you have done to respond to delegate feedback. The proposal has improved since the initial discussion: the implementation concern around Rootstock-specificity appears to have been addressed, the milestones are clearer, and the team has pointed to public validation comments from external product teams including Pistachio, Deserialize, and PouchSwap.
My abstain is not because I think this is a bad idea or because there is no demand signal at all. There is some signal here.
My hesitation is that this feels like the kind of proposal that would be stronger if it came back under the updated grants process, especially with the new emphasis on demand validation as an application-stage requirement.
For a developer tooling and infrastructure grant like this one, I would like to see the demand validation move beyond “open to reviewing/testing” and closer to committed usage, a pilot, or a named integration path from teams that would realistically adopt the package after release.
I’m abstaining rather than voting against because I see the potential value, but I’d prefer to evaluate this again under the patched grants process with a clearer demand-validation package attached.
Thanks for your understanding.