Why the track record looks like one GitHub account
Supercoolkayy is the setup repo we use to publish and bootstrap work. Other team members contribute where needed, and the individual engineer accounts are below so contributions and accountability are verifiable.
On proof of delivery quality for this specific scope
Milestone 1 is already shipped and public as a runnable local Rootstock regtest stack with the CLI and funding initializer. Anyone can inspect the code and run it end to end. https://github.com/Supercoolkayy/RelayDevKit
Accountability and ownership
Abdulkareem is accountable for delivery and releases. Rest of the team is accountable for the stack automation and the deploy and test harness parts of the scope. The contracting party for payouts is the same legal entity used for KYC and payment in the grants process, and the repository will have named maintainers and tagged releases so responsibility is clear after the grant.
We have read the delegate rationales from the previous vote and we have responded to the open concerns in this thread, including the rescope, ownership, maintenance, and team verification.
On bandwidth, we are not currently active on any other funded grants with live milestone deadlines in other ecosystems. RelayDevKit is not competing with another grant delivery for the same engineers.
Hi @DappsoverApps . Thank you for clarifying that RelayDevKit is not competing with another grant delivery for the same engineers.
As a follow-up āsince DappsoverApps is a collective, if a team member became unavailable during the grant period, what does ensuring continuity of delivery or mitigation look like?
Hi @DAOstar_gov , thank you for the follow up question. We have a good number of engineer in Dapps over Apps so if a team member becomes unavailable, it is easy for other engineers in the collective to take it up from there since all our work is public and open source. Please let us know if you have any more questions. Thank you.
A quick update on my position as this thread has evolved. My initial concern was around systemic security risk, which the scope revision from runtime dependency to vendored harness meaningfully addressed.
My second concern was team accountability, specifically whether the named members were identifiable and verifiable beyond a single GitHub account. I did some due diligence on my own, including reaching out to several team members directly, and Iām comfortable with where that sits now.
What Iām still not convinced on is return on investment, and @Curia has been asking the right question in a couple of posts now. Is Relay integration actually a bottleneck builders are hitting in practice, or is demand being inferred? The proposal still carries no LOIs, no survey data, and no specific team that has said theyāre blocked today. At $9,660 for the build plus $1,800 for six months of maintenance, this is a meaningful slice of treasury that would need to displace other projects competing for the same pool.
@DappsoverApps, before this goes back to a vote, can the team share any concrete signals from Rootstock builders that Relay setup and CI is a real friction point worth solving now? Conversations with two or three teams that would commit to using the kit would be important.
Hi @ChronoTrigger , we asked for feedback on rootstock discord channel, in the support section and we received a few valuable in sight from builders. You can follow the discussion on rootstock discord (support section).
Please we will like to confirm from you and other delegate if we can move forward with putting this up for on chain voting?
Thanks for sharing the Discord feedback. The responses from Stacks Aboki and FundX are helpful, and what they describe suggests there may be real onboarding gaps during the evaluation phase that can slow down potential integrations, which is consistent with what Relay is trying to address. Overall this is a positive signal, and weād like to hear from other delegates before finalizing our position.
In the spirit of making it easier for others to audit, since Discord is not the friendliest for those who donāt use it frequently, Iām pasting screenshots from Discord:
You clearly have two testimonies in favor of the solution. I wish it was more, 3-5 could be great, but at least now thereās a sample.
I think a strong signal from the messages is that for blockchains in which tx costs are not negligible, this is a concern for builders, and a local relay kit is a useful tool for simulating tx costs, without which some projects may be left in the dark and weary of adoption.
In the meantime, while other delegates pitch in, Iād suggest you to try to expand a little on your research, try to obtain more testimonies, try to get a couple projects to commit to testing your application.
The main reason is that, I think, at $9660 total for the grant, plus a future proposal of $1800 for 6mo maintenance, this is erring on the expensive side, especially considering our latest guidelines, which tighten our budget and increase scrutiny of the return on investment for grants.
Overall, I tend to be more supportive of infrastructure projects, as they lay the foundation for future growth. But Iād recommend you gather some more confidence before posting the proposal for onchain vote.
We completely agree with @ChronoTrigger here. While we appreciate the feedback received on Discord regarding the need expressed by those two builders for a tool with these features, we must consider that the budget of nearly 10k + 1.8k for six months of maintenance is a significant amount given Rootstockās current treasury situation, and we would like to verify the validation of this tool by more builders to justify the requested budget allocation.
