Hi @ChronoTrigger , thank you for your questions.
Bolaji and Gospel prior multi component examples
Bolaji examples that reflect multi service automation and operational glue
https://github.com/RegionX-Labs/Coretime-Notifier
https://github.com/bolajahmad/proownas
https://github.com/bolajahmad/personal-prown-node
Gospel examples that reflect multi contract systems and integration workflows
https://github.com/steven3002/Arbitrum-Stylus-Hack-Smart-Contracts
https://github.com/steven3002/Web3_Email
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.
Team GitHub accounts
Abdulkareem https://github.com/Supercoolkayy
Gospel https://github.com/steven3002
Bolaji https://github.com/bolajahmad
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.
He recently changed his username. Here’s the updated one: https://x.com/Steven_Hert
Hi @DAOstar_gov , thank you.
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.