# \[2603\] RelayDevkit **URL:** \ **Category:** Grants & Incentives\ **Created:** [March 12, 2026, 7:00pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772 "2026-03-12T19:00:34Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [March 12, 2026, 7:00pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/1 "2026-03-12T19:00:35Z")
## **[2603 Grant] RelayDevKit** ### Proposal Content ## A. Project Name: RelayDevKit ## B. Classification: - **Project stage:** MVP (delivered during the grant; current state is pre-build) - **Sector:** Developer Tools / Infrastructure - **Target audience:** Wallet integrators, dApp teams, and SDK/tooling maintainers building or testing **RIF Relay** integrations on Rootstock ## Submission Date: March 12, 2026 # Founder Information: - **Founder name(s):** N/A (builder collective application) - **Primary contact:** Abdulkareem Oyeneye (Project Lead) - **Professional background:** Developer tooling engineer and project manager focused on Web3 developer experience and technical delivery - **LinkedIn profiles:** Abdulkareem Oyeneye — [https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277](https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277) - **GitHub profiles:** N/A - **Prior blockchain experience:** See “Team Experience” and “Selected track record” below * * * # Team: ## Team overview **Dapps over Apps** is a collective advancing Web3 through developer tooling and education. We build practical tools that reduce developer friction and ship repeatable workflows that make integrations easier to test, maintain, and release. ## Selected track record (relevant to this grant) Each item below is included to demonstrate we can ship the exact kind of work this grant requires: reproducible tooling, developer UX improvements, and integration-grade utilities. - **VoxBridge** — Open-source VoxEdit-to-Unity/Roblox asset conversion tool for The Sandbox creator workflows - **Ox-Rollup local dev patch** — Local testing patch enabling EVM developer tools to better simulate Arbitrum-specific execution surfaces (precompile addresses and deposit transaction type behavior) - **Retrieval Tester** — Utility that measures Filecoin CID retrieval performance across multiple public gateways - **Stylus VS Code Extension** — Editor tooling to improve Rust-based Stylus smart contract development workflows - **Avatar Everywhere CLI** — Sandbox avatar-to-VRM conversion toolkit with an optional wallet ownership check before conversion - **ZecKit** — Zcash developer toolkit that standardizes a one-command local devnet workflow and CI-friendly testing for post-zcashd development ## Links (grouped, not embedded) - VoxBridge — [https://github.com/Supercoolkayy/voxbridge](https://github.com/Supercoolkayy/voxbridge) - Ox-Rollup — [http://www.ox-rollup.com](http://www.ox-rollup.com/) Repo — [https://github.com/Supercoolkayy/Ox-rollup](https://github.com/Supercoolkayy/Ox-rollup) - Retrieval Tester — [https://www.retrievaltester.com/](https://www.retrievaltester.com/) - Stylus VS Code Extension — [https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main](https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main) - Avatar Everywhere CLI — [https://pypi.org/project/avatar-everywhere-cli/](https://pypi.org/project/avatar-everywhere-cli/) - ZecKit — [https://github.com/Supercoolkayy/ZecKit](https://github.com/Supercoolkayy/ZecKit) ## Key team members and roles (for this project) - **Abdulkareem Oyeneye — Project Lead** Owns delivery planning, scope control, developer UX, documentation quality, and coordination of milestones. Link — [https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277](https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277) - **Gospel Ifeadi — Core Tooling / Smart Contract Engineer** Builds the local-stack automation glue, deployment scripts, and end-to-end test harness logic. Link — [https://x.com/gospel70800](https://x.com/gospel70800) - **Bolaji Ahmad — Infrastructure / CI Engineer** Owns Docker Compose reliability, health checks, deterministic boot ordering, and GitHub Actions template stability. Link — [https://linkedin.com/in/bolajahmad](https://linkedin.com/in/bolajahmad) - **Musa Abdulkareem — Supporting Engineer (Protocol Integration Review)** Supports integration hardening, test-case coverage for edge conditions, and review of signing/verification assumptions in relayed flows. Link — [https://www.linkedin.com/in/wisemrmusa](https://www.linkedin.com/in/wisemrmusa) * * * # Media & Resources: - **Pitch deck link (self-hosted):** N/A - **Demo video/prototype link:** N/A - **Screenshots/mockups:** N/A - **Technical documentation:** N/A (will ship as README + runbooks in the repository) * * * # Traction & Metrics: - **Current user base (if applicable):** N/A - **Transaction volume (if applicable):** N/A - **TVL (if applicable):** N/A - **Growth trajectory:** N/A - **Key achievements to date:** N/A (new build) * * * # Grant Request: ## Total amount requested: **$9,660** ## Payment preference: - **Primary:** USDRIF - **Alternate:** rBTC equivalent computed at disbursement using the program’s standard conversion method ## Milestone breakdown with deliverables and dates: **Prerequisites for reviewers/users:** Docker (Docker Desktop acceptable) and Node.js LTS (18+). **Officially supported OS:** Linux and macOS. Windows supported via WSL2/Docker Desktop where applicable, but not guaranteed. | Milestone | Target completion date | Amount (USDRIF) | Amount (rBTC) | Deliverables | | --- | --- | --- | --- | --- | | M1 — Local stack foundation | March 17, 2026 | 2,240 | rBTC equiv. | Repo scaffolding; CLI `up/down/status/logs`; local Rootstock regtest node container with health checks; deterministic test keys + funded accounts initializer | | M2 — Contracts deploy + test-token wiring | March 24, 2026 | 1,960 | rBTC equiv. | Automated deployment scripts for Relay contracts; deterministic config output; automation to provision a test token and apply required allow-list configuration for local flows | | M3 — Relay Server boot + automated registration | March 31, 2026 | 2,100 | rBTC equiv. | Relay Server starts from generated config; automated registration workflow executed as part of `up`, producing a “ready” environment | | M4 — Deterministic end-to-end tests + CI template | April 14, 2026 | 2,380 | rBTC equiv. | End-to-end harness with ≥6 scenarios; minimal sample contract; GitHub Actions template running headlessly with enforced timeouts and health checks; target CI runtime ≤18 minutes on standard runners | | M5 — Doctor + docs + npm release + bugfix window | April 21, 2026 | 980 | rBTC equiv. | `doctor` command with actionable failures and CI-friendly exit codes; quickstart + troubleshooting + reuse guide; publish npm package; 30-day bugfix window; submit one upstream docs/resources PR referencing RelayDevKit (submission guaranteed) | # Mission & Vision: ## How your project aligns with Rootstock ecosystem goals RelayDevKit reduces the engineering blocker to adopting RIF Relay by making integration reproducible and testable end-to-end. The deliverable is practical developer infrastructure: a known-good local environment, deterministic tests, and a CI template that turns Relay integration into a verifiable workflow. This enables more wallets and dApps to adopt relayed transactions confidently without requiring marketing or LOIs to justify demand. * * * # Product Details: ## Core features and functionality ### 1) One-command local Relay stack (known-good environment) RelayDevKit provides a single command that: - Boots a **local Rootstock regtest node** with the RPC profile needed for Relay testing and local deployments - Deploys required Relay contracts to the local chain - Starts a Relay Server using a generated configuration aligned with deployed contract addresses - Automates the required registration workflow so the environment is usable immediately after `up` - Seeds deterministic funded accounts for manager/worker/owner roles used in Relay flows ### 2) Deterministic integration test harness - `npx relaydevkit test` runs end-to-end tests against the local stack with fixed seeds and fixtures - Includes a minimal reference contract and scenarios that reflect common integration failures - Produces machine-readable outputs suitable for CI (JUnit/JSON) ### 3) CI template (GitHub Actions) - Copy-paste CI workflow that boots the stack and executes tests headlessly - Health checks + timeouts for determinism - Target runtime: **≤18 minutes** per run on standard runners (excluding queue time) ### 4) Preflight “doctor” - `npx relaydevkit doctor` detects common setup failures with exact remediation steps - Returns non-zero exit codes when the environment is not ready (CI-friendly) ### 5) Integration-grade documentation - 10-minute quickstart - Common failures and fixes - “How to use RelayDevKit in your wallet/dApp repo” guide - Version pinning and upgrade procedure ## Technical architecture - **CLI distribution:** npm package runnable via `npx relaydevkit …` - **Environment orchestration:** Docker Compose with pinned service versions, health checks, and deterministic boot order - **Deployment automation:** Containerized deploy pipeline so developers do not install legacy toolchains locally - **Testing:** Deterministic harness that resets local chain state between tests and uses fixed identities/fixtures - **Artifacts:** Structured logs + test reports for CI ## Integration with Rootstock - Provides a complete local stack for Relay integration work: local node + contracts + Relay Server + registration + tests - Designed so external repos can adopt by copying the CI template or reusing the harness directly ## Security considerations - Local-only scope; no mainnet operations in this grant - No sensitive secrets committed; deterministic test keys are clearly labeled “test-only” - Pinned versions reduce drift; upgrade procedure reduces unsafe ad-hoc changes - Default configuration does not publicly expose local services * * * # Description: ## Core problem being solved RIF Relay integrations are slow and error-prone because setup spans multiple components and manual steps. Developers lose time to misconfiguration, environment drift, and missing end-to-end coverage. That blocks shipping or causes regressions after upgrades. ## Solution overview RelayDevKit packages the Relay components into a reproducible local stack and adds the missing engineering layer required for reliable adoption: automated wiring and registration, deterministic end-to-end tests, CI templates, and preflight diagnostics. ## Unique value proposition - Produces a working, registered Relay environment with one command - Makes Relay integration verifiable in CI with deterministic tests - Reduces time-to-first-success and prevents regressions across upgrades - Adoption is inherent: any team integrating Relay needs a workflow like this to ship safely ## Competitive analysis Existing Relay repos and examples are component-level resources; they do not provide a complete deterministic local environment and CI harness that is ready for repeatable integration testing. RelayDevKit differentiates by shipping orchestration, automated registration, diagnostics, and CI-grade verification. * * * # Project Roadmap: ## Clear timeline with measurable deliverables **Total duration:** 7 weeks ### Major milestones and expected completion dates - **M1 (March 17):** Local node + CLI + deterministic keys/funding + health checks - **M2 (March 24):** Automated contract deployment + test-token wiring + generated config - **M3 (March 31):** Relay Server boot + automated registration workflow + “ready” status - **M4 (April 14):** Deterministic end-to-end tests + GitHub Actions template - **M5 (April 21):** Doctor + docs + npm release + 30-day bugfix window + upstream docs/resources PR submission ## Key success metrics for each phase - **M1:** `up/status/down` succeeds from scratch without manual side steps - **M2:** deploy output is deterministic and self-contained (no manual env edits required) - **M3:** relay is running and registered (environment is usable for real tests) - **M4:** tests pass deterministically locally and in CI within runtime budget - **M5:** doctor catches common failure states; docs enable first successful relay test in ≤30 minutes for a reviewer * * * # Performance Targets: ## Transaction volume N/A ## TVL (Total Value Locked) N/A ## User acquisition - Adoption indicator (non-binding): at least 3 public references (issues/PRs/screenshots) from teams using the kit or CI template within 60 days of release ## Other relevant metrics - Time to first successful relayed transaction from a clean setup: - CI determinism: **10 consecutive green runs** in the repository using the provided workflow - Diagnostic coverage: doctor detects and explains **≥8** common failure states with clear remediation * * * # Conclusion: RelayDevKit is a focused developer-tools project designed to unlock broader RIF Relay adoption by making integration reproducible, testable, and safe to ship. It delivers immediate value to wallets and dApps by reducing setup failure rates and providing deterministic end-to-end verification in CI. **Call to action:** Support RelayDevKit to remove Relay integration friction, shorten time-to-first-success, and increase confidence in Relay-enabled onboarding flows. * * * # Social & Community: - **Website:** [www.dappsoverapps.com](http://www.dappsoverapps.com/) - **Twitter/X:** [www.x.com/Dappsoverapps](http://www.x.com/Dappsoverapps) - **Discord/Telegram:** supercoolkay - **GitHub repository:** N/A (will be published on project start) * * * ---
**Author:** ![Axia](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/axia/32/576_2.png) [@Axia](https://gov.rootstockcollective.xyz/u/Axia)\ **Post date:** [March 13, 2026, 8:46pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/2 "2026-03-13T20:46:27Z")
Hello @DappsoverApps, I’m broadly supportive of well-designed dev tooling for RIF Relay. That said, I have a few concerns I’d like to understand better before forming a view **1.N/As across traction & users** Right now the proposal is essentially pre‑everything: no live repo, no current user base, no transaction volume, and no screenshots/demos. Are there any WIP repos, internal prototypes, or prior tools in this exact category (local stacks / CI harnesses for relayers) that you can point to as proof of execution quality? Also, why start this as a completely new package rather than building on/within existing RIF Relay repos? **2.Rootstock / RIF‑specific experience and coordination** So far I don’t see any direct Rootstock or RIF Relay experience in the proposal. Have you already been in touch with the RIF/Rootstock teams maintaining Relay to align on architecture? **3.Maintenance after the 30‑day bugfix window** You mention a 30‑day bugfix window after release. Given that this would be a key piece of developer infrastructure: Who is responsible for keeping RelayDevKit updated when Relay or Rootstock changes? And is there a commitment (and funding plan) to maintain this for at least 6–12 months? Thanks, Rika ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [March 13, 2026, 11:42pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/3 "2026-03-13T23:42:03Z")
Thanks @Axia . Below are the answers to your questions: ## 1) Traction Yes, **RelayDevKit is not live yet** , and we left traction as N/A because we don’t want to invent users or metrics. What we _can_ show today is execution quality on the same category of work (reproducible tooling, local stacks, CI-friendly workflows): - **Ox-Rollup local testing patch** — chain-specific behavior simulated in Hardhat/Foundry local testing. [https://github.com/Supercoolkayy/Ox-rollup](https://github.com/Supercoolkayy/Ox-rollup) - **Retrieval Tester** — reproducible testing utility with a stable runbook. [https://www.retrievaltester.com/](https://www.retrievaltester.com/) - - **ZecKit** — one-command local workflow + CI-friendly testing patterns. [https://github.com/Supercoolkayy/ZecKit](https://github.com/Supercoolkayy/ZecKit) - **VoxBridge** — shipped developer utility with real user workflow constraints. [https://github.com/Supercoolkayy/voxbridge](https://github.com/Supercoolkayy/voxbridge) - **Stylus VS Code Extension** — DX tooling shipped as an editor workflow. [https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main](https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main) - **Avatar Everywhere CLI** — packaged CLI workflow with clear inputs/outputs. [https://pypi.org/project/avatar-everywhere-cli/](https://pypi.org/project/avatar-everywhere-cli/) **Concrete proof for this grant (so it’s not “trust us”):** - We will make the RelayDevKit repo **public at the start of Milestone 1** (scaffold + compose + health checks). - By end of **M1** , anyone can verify `up/down/status/logs` working on a fresh Docker setup. - By end of **M4** , anyone can verify **deterministic end-to-end tests** running in GitHub Actions. **Why start as a new package instead of building inside existing Relay repos?** RelayDevKit is an **orchestration + verification layer** that has to compose multiple components (node + contracts + relay server + tests + CI). Keeping it separate: - avoids forcing a cross-repo refactor into a single upstream repo, - keeps maintainer review burden low, - makes version pinning and CI determinism easier to manage. We’re **not** forking or replacing Relay. We’ll upstream small fixes/docs improvements as PRs where they clearly belong. ## 2) Rootstock / RIF-specific experience and coordination We **haven’t shipped a production Rootstock/RIF Relay integration yet** , and we won’t claim otherwise. We’re also **not proposing protocol changes**. The scope is packaging and automating the _existing_ RIF Relay workflow into a reproducible local environment + CI harness. Coordination plan : - In **Week 1** , we’ll open a public RFC issue in the RelayDevKit repo documenting: stack layout, what “ready” means (including registration), node/RPC assumptions, and the acceptance tests for determinism. - We’ll tag/reach out to the Relay maintainers for feedback **before** we lock implementation details. (We can’t promise their time, but we can make the review surface small and concrete.) ## 3) Maintenance after the 30-day bugfix window What this grant funds is: build + release + **30-day bugfix window**. To reduce long-term fragility, we will: - pin container/dependency versions and publish a compatibility matrix, - add a scheduled CI run (weekly) that executes the full end-to-end suite to catch breakage early, - keep the tool thin (orchestration + tests), not a hosted service. If the ecosystem wants **guaranteed** 6–12 month maintenance, the approach is a small follow-on maintenance grant once there’s real usage data to price it correctly. We’re open to that, but we don’t want to promise long-term maintenance coverage without funding. ---
**Author:** ![Curia](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/curia/32/943_2.png) [@Curia](https://gov.rootstockcollective.xyz/u/Curia)\ **Post date:** [March 16, 2026, 5:45am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/4 "2026-03-16T05:45:25Z")
Thanks for the proposal. @DappsoverApps From what we understand, you’re proposing to build an automation kit that replaces a complex multi-step manual process with a single command for developers integrating RIF Relay into their projects. In our view this could lower the barrier for developers building on Rootstock, which could lead to more teams adopting it and ultimately benefit users by giving them more options to pay transaction fees beyond RBTC. Overall this feels like a gap in the Rootstock ecosystem that’s worth filling. That said, we want to make sure the team can actually deliver at the complexity this requires. Looking at the track record, ZecKit seems like the closest thing to what you’re proposing to build here but a full RIF Relay environment has significantly more moving parts than a Zcash devnet. Based on the team structure, it looks like Bolaji and Gospel are responsible for this part of the build, could you both share examples of prior work where you’ve handled this kind of multi-component setup at a similar complexity level? ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [March 17, 2026, 8:49pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/5 "2026-03-17T20:49:16Z")
Thank ypu @Curia . That is a fair concern, and we agree a full RIF Relay local environment has more moving parts than a basic devnet. **ZecKit** is not a lightweight devnet script. The main work was making a local workflow repeatable and CI friendly, including clean bring up and teardown, stable fixtures, and failure cases that are easy to reproduce and fix. This work was grant funded in the Zcash ecosystem and reviewed as part of that process. **[Ox Rollup local testing patch](http://www.ox-rollup.com/)** is also not a small wrapper. It is low level developer tooling that extends local environments to handle chain specific execution surfaces. In our case, we added support for Arbitrum precompiles and deposit transaction behavior inside Hardhat and Foundry so developers can run realistic local tests. This work was funded through the Arbitrum DAO grant process. Link: [https://github.com/Supercoolkayy/Ox-rollup](https://github.com/Supercoolkayy/Ox-rollup) For **RelayDevKit** , our team are accountable for exactly the “multi component reliability” part you are highlighting. These two prior projects are the closest public examples of us delivering that kind of multi component setup work under grant expectations, and we will make RelayDevKit public from Milestone 1 so reviewers can verify progress early. Thank you once again for your questions. I hope we have been able to clarify. ---
**Author:** ![jengajojo](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/jengajojo/32/487_2.png) [@jengajojo](https://gov.rootstockcollective.xyz/u/jengajojo)\ **Post date:** [March 18, 2026, 1:53pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/6 "2026-03-18T13:53:59Z")
Thank you for the proposal @DappsoverApps Since the M1 deadline (Mar 17) has passed, can you share the public repo link or a quick demo/video of the local stack? This would address the traction/prototype concern raised by @Axia I also wonder if any wallet or dApp teams been consulted on Relay pain points? Post-grant KPIs for adoption would strengthen the case imo. ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [March 18, 2026, 7:55pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/7 "2026-03-18T19:55:09Z")
Hi @jengajojo Thank you for the question. The Mar 17 date in the draft was a placeholder from an earlier version written before the forum post went live. We had to complete KYC before posting for community review, so the timeline is intended to start from the grant approval and kickoff date. We will update the milestone dates in the thread once there is an approval decision. On the repo or demo, we have not presented M1 as delivered because approval has not happened and kickoff has not started. What we can commit to is that the repository will be public from the first day of kickoff, and Milestone 1 is structured so reviewers can verify it by running the local stack and seeing a healthy status. Also, we are not relying on LOIs or partner commitments because the pain points are inherent in the current Relay integration workflow: setting up the node, contracts, relay server registration, and making it deterministic in CI. If teams share specific failure cases, we will incorporate them into the doctor checks and end-to-end tests, but delivery is not gated on that. We agree that post grant adoption KPIs would strengthen the case. We can add these as targets: • Time to first successful relayed transaction from a clean setup within 30 minutes on a first run and within 15 minutes on subsequent runs, assuming typical Docker image pull times • CI reliability shown by 10 consecutive green runs using the provided workflow on the RelayDevKit repository • At least 3 public signals of use from teams adopting the kit or CI template, such as issues, PRs, or CI screenshots • One upstream docs or resources PR submitted so developers can discover the kit from official Rootstock or RIF Relay documentation, subject to maintainer review for merging ---
**Author:** ![Ignas](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/ignas/32/436_2.png) [@Ignas](https://gov.rootstockcollective.xyz/u/Ignas)\ **Post date:** [March 19, 2026, 8:45am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/8 "2026-03-19T08:45:25Z")
Thanks for the proposal @DappsoverApps. Agree RelayDevKit targets a real friction point in the Rootstock ecosystem, onboarding and adoption. I have some concerns: Agree with @Axia ,the maintenance commitment is too short for something positioned as infrastructure. 30 days bugfix window doesn’t give much confidence for teams that might build on top of this. I think you can consider offering an extended maintenance option ( 3, 6, or 12 months) with a corresponding cost structure. There are no LOIs, no conversations on record with any wallet or dApp team in the ecosystem. Even you said: > [@DappsoverApps](#): > > Adoption is inherent: any team integrating Relay needs a workflow like this to ship safely is an assumption and the expected outcome of only 3 public references within 60 days is a bar that teammates alone could clear. I agree the problem is real, but some level of demand validation even informal would make the case much stronger that this will actually be used. One more concern is that there’s no legal entity and no clear ownership beyond the grant period. If contributors step away, it’s unclear who maintains the project or how responsibility is transferred. ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [March 21, 2026, 5:03am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/9 "2026-03-21T05:03:15Z")
Thank you! @Ignas **Maintenance** We can offer a 6 month maintenance follow on grant. 6 month maintenance follow on can be: **$1,800 total** , paid as **$300 per month** • Dependency and container updates when needed • Keep the end to end CI workflow passing and fix breakages caused by upstream changes that affect the kit • Triage issues and ship patch releases for problems that block setup or end to end testing **Demand validation and LOIs** We are not relying on LOIs because the friction is already visible in the current Relay integration workflow: node setup, contract deployment and wiring, relay server run and registration, and making it repeatable in CI. References: RIF Relay deployment workflow [RIF Relay Deployment | Rootstock Developers Portal](https://dev.rootstock.io/developers/integrate/rif-relay/deployment/) RIF Relay sample dApp workflow [How to use the RIF Relay Sample dApp SDK | Rootstock Developers Portal](https://dev.rootstock.io/developers/integrate/rif-relay/sample-dapp/) Relay server repo and run requirements [GitHub - rsksmart/rif-relay-server: This repository contains all the typescript code for the Rif Relay Server · GitHub](https://github.com/rsksmart/rif-relay-server) Relay contracts repo [GitHub - rsksmart/rif-relay-contracts: This repository contains all the rif relay contracts · GitHub](https://github.com/rsksmart/rif-relay-contracts) Sample dApp repo [GitHub - rsksmart/rif-relay-sample-dapp: Sample DApp for test relaying-services-sdk · GitHub](https://github.com/rsksmart/rif-relay-sample-dapp) We will also tighten KPIs so they require public proof beyond our own activity: • A clean setup runbook that produces a successful end to end relayed transaction, plus repeatable reruns • CI reliability shown by **10 consecutive green runs** of the provided workflow in the RelayDevKit repo • At least **3 public external usage signals** from repos or teams not controlled by us, such as issues, PRs, or CI screenshots **Ownership and responsibility** The repo and npm package will live under Dapps over Apps with named maintainers, CODEOWNERS, a tagged release process, and a maintenance runbook. The contracting party for the grant will be the same legal entity used for KYC and payment. If the DAO wants more maintainers, we are open to adding Rootstock or RIF maintainers as co maintainers after initial release or transferring ownership once the tool is stable. Thank you for your questions. We hope the above answers clarifies. Thank you ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [April 10, 2026, 9:26pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/10 "2026-04-10T21:26:34Z")
Hi @jengajojo , @Curia @Ignas @Axia , thank you for engaging with this proposal. Milestone 1 is done. **Milestone 1 completed** Repo: [GitHub - Supercoolkayy/RelayDevKit · GitHub](https://github.com/Supercoolkayy/RelayDevKit) **M1 deliverables shipped** • CLI commands implemented: `up`, `status`, `logs`, `down` • Docker Compose stack that starts a local Rootstock regtest node • Funding script that sends RBTC on regtest to the manager and worker addresses derived from `MANAGER_PRIVATE_KEY` and `WORKER_PRIVATE_KEY` • `status` verifies containers are running and confirms the node RPC is reachable • Quickstart documentation and `.env-example` included in the repo **Run instructions** 1. `npm install` 2. `cp .env-example .env` 3. Set `MANAGER_PRIVATE_KEY` and `WORKER_PRIVATE_KEY` in `.env` 4. `npm run build` 5. `npx relaydevkit up` 6. `npx relaydevkit status` 7. `npx relaydevkit logs` 8. `npx relaydevkit down` Milestone 2 will add automated contract deployment and generated config output. Thank you. ---
**Author:** ![SEEDGov](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/seedgov/32/673_2.png) [@SEEDGov](https://gov.rootstockcollective.xyz/u/SEEDGov)\ **Post date:** [April 20, 2026, 2:28pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/11 "2026-04-20T14:28:17Z")
We have carefully reviewed the proposal, along with the feedback and the responses provided, and have decided to vote against it. The proposed development introduces a potential systemic point of failure. If the kit were to contain a vulnerability, it could propagate across all projects that rely on it. Unlike other cases where a vulnerability impacts only a single project, in this scenario the risk could scale across multiple projects simultaneously, creating a broader ecosystem-wide concern. We believe this represents a significant risk, and that a solution of this nature should be approached more holistically, developed by a team with stronger expertise in similar tools, and involve a higher level of coordination, alignment and oversight from the Rootstock team. ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [April 21, 2026, 1:59am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/12 "2026-04-21T01:59:19Z")
## Update: Revised scope to reduce systemic risk by making RelayDevKit a dev and CI reference harness, not a shared runtime dependency. Now: It ships as a Docker Compose stack plus scripts and a GitHub Actions template that teams can vendor and pin, with no production import path or shared runtime library. ## **[2603 Grant] RelayDevKit** ### Proposal Content ## A. Project Name: RelayDevKit ## B. Classification: - **Project stage:** MVP (in progress) - **Sector:** Developer Tools / Infrastructure - **Target audience:** Wallet integrators, dApp teams, and SDK/tooling maintainers building or testing **RIF Relay** integrations on Rootstock ## Submission Date: April 20, 2026 # Founder Information: - **Founder name(s):** N/A (builder collective application) - **Primary contact:** Abdulkareem Oyeneye (Project Lead) - **Professional background:** Developer tooling engineer and project manager focused on Web3 developer experience and technical delivery - **LinkedIn profiles:** Abdulkareem Oyeneye — [https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277](https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277) - **GitHub profiles:** N/A - **Prior blockchain experience:** See “Team Experience” and “Selected track record” below * * * # Team: ## Team overview **Dapps over Apps** is a collective advancing Web3 through developer tooling and education. We build practical tools that reduce developer friction and ship repeatable workflows that make integrations easier to test, maintain, and release. ## Selected track record (relevant to this grant) Each item below is included to demonstrate we can ship reproducible tooling, developer UX improvements, and integration-grade utilities. - **VoxBridge** — Open-source VoxEdit-to-Unity/Roblox asset conversion tool for The Sandbox creator workflows - **Ox-Rollup local dev patch** — Local testing patch enabling EVM developer tools to better simulate Arbitrum-specific execution surfaces - **Retrieval Tester** — Utility that measures Filecoin CID retrieval performance across multiple public gateways - **Stylus VS Code Extension** — Editor tooling to improve Rust-based Stylus smart contract development workflows - **Avatar Everywhere CLI** — Sandbox avatar-to-VRM conversion toolkit with an optional wallet ownership check before conversion - **ZecKit** — Zcash developer toolkit that standardizes a one-command local workflow and CI-friendly testing ## Links - VoxBridge — [https://github.com/Supercoolkayy/voxbridge](https://github.com/Supercoolkayy/voxbridge) - Ox-Rollup — [http://www.ox-rollup.com](http://www.ox-rollup.com) Repo — [https://github.com/Supercoolkayy/Ox-rollup](https://github.com/Supercoolkayy/Ox-rollup) - Retrieval Tester — [https://www.retrievaltester.com/](https://www.retrievaltester.com/) - Stylus VS Code Extension — [https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main](https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main) - Avatar Everywhere CLI — [https://pypi.org/project/avatar-everywhere-cli/](https://pypi.org/project/avatar-everywhere-cli/) - ZecKit — [https://github.com/Supercoolkayy/ZecKit](https://github.com/Supercoolkayy/ZecKit) ## Key team members and roles (not limited to) - **Abdulkareem Oyeneye — Project Lead** Owns delivery planning, scope control, developer UX, documentation quality, and coordination of milestones. Link — [https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277](https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277) - **Gospel Ifeadi — Core Tooling / Smart Contract Engineer** Builds the local-stack automation glue, deployment scripts, and end-to-end test harness logic. Link — [https://x.com/gospel70800](https://x.com/gospel70800) - **Bolaji Ahmad — Infrastructure / CI Engineer** Owns Docker Compose reliability, health checks, deterministic boot ordering, and GitHub Actions template stability. Link — [https://linkedin.com/in/bolajahmad](https://linkedin.com/in/bolajahmad) - **Musa Abdulkareem — Supporting Engineer (Protocol Integration Review)** Supports integration hardening, test-case coverage for edge conditions, and review of signing and verification assumptions in relayed flows. Link — [https://www.linkedin.com/in/wisemrmusa](https://www.linkedin.com/in/wisemrmusa) * * * # Media & Resources: - **Pitch deck link (self-hosted):** N/A - **Demo video/prototype link:** N/A - **Screenshots/mockups:** N/A - **Technical documentation:** README and runbooks will live in the repository * * * # Traction & Metrics: - **Current user base (if applicable):** N/A - **Transaction volume (if applicable):** N/A - **TVL (if applicable):** N/A - **Growth trajectory:** N/A - **Key achievements to date:** Public repository available for review [https://github.com/Supercoolkayy/RelayDevKit](https://github.com/Supercoolkayy/RelayDevKit) * * * # Grant Request: ## Total amount requested: **$9,660** ## Payment preference: - **Primary:** USDRIF - **Alternate:** rBTC equivalent computed at disbursement using the program’s standard conversion method ## Timeline note: Milestone timing starts from the grant approval and kickoff date. ## Milestone breakdown with deliverables and timing: **Prerequisites for reviewers/users:** Docker and Node.js LTS (20 or newer). **Officially supported OS:** Linux and macOS. Windows supported via WSL2/Docker Desktop where applicable, but not guaranteed. | Milestone | Target completion | Amount (USDRIF) | Amount (rBTC) | Deliverables | | --- | --- | --- | --- | --- | | M1 — Local stack foundation | Week 2 from kickoff | 2,240 | rBTC equiv. | Repo scaffolding; CLI `up/down/status/logs`; local Rootstock regtest node container with health checks; deterministic test keys and funded accounts initializer | | M2 — Contracts deploy + test-token wiring | Week 3 from kickoff | 1,960 | rBTC equiv. | Automated deployment scripts for Relay contracts; deterministic config output; automation to provision a test token and apply required allow-list configuration for local flows | | M3 — Relay Server boot + automated registration | Week 4 from kickoff | 2,100 | rBTC equiv. | Relay Server starts from generated config; automated registration workflow executed as part of `up`, producing a ready environment | | M4 — Deterministic end-to-end tests + CI template | Week 6 from kickoff | 2,380 | rBTC equiv. | End-to-end harness with at least 6 scenarios; minimal sample contract; GitHub Actions template running headlessly with enforced timeouts and health checks; target CI runtime ≤18 minutes on standard runners | | M5 — Doctor + docs + npm release | Week 7 from kickoff | 980 | rBTC equiv. | `doctor` command with actionable failures and CI-friendly exit codes; quickstart + troubleshooting + reuse guide; publish npm package; submit one upstream docs/resources PR referencing RelayDevKit | ## Maintenance follow-on (6 months) We will propose a separate 6-month maintenance follow-on grant: **$1,800 total** , paid as **$300 per month**. Scope is capped to compatibility and break-fix only: - Dependency and container updates when needed - Keep the end-to-end CI workflow passing and fix breakages caused by upstream changes that affect the kit - Triage issues and ship patch releases for problems that block setup or end-to-end testing This does not include new feature development, custom support for individual teams, or any SLA. * * * # Mission & Vision: ## How your project aligns with Rootstock ecosystem goals RelayDevKit reduces the engineering blocker to adopting RIF Relay by making integration reproducible and testable end-to-end. The deliverable is practical developer infrastructure: a known-good local environment, deterministic tests, and a CI template that turns Relay integration into a verifiable workflow. This enables more wallets and dApps to integrate relayed transactions with less setup risk and fewer regressions. * * * # Product Details: ## Core features and functionality ### 1) One-command local Relay stack (known-good environment) RelayDevKit provides a single command that: - Boots a **local Rootstock regtest node** with the RPC profile needed for Relay testing and local deployments - Deploys required Relay contracts to the local chain - Starts a Relay Server using a generated configuration aligned with deployed contract addresses - Automates the required registration workflow so the environment is usable immediately after `up` - Seeds deterministic funded accounts for manager, worker, and owner roles used in Relay flows ### 2) Deterministic integration test harness - `npx relaydevkit test` runs end-to-end tests against the local stack with fixed seeds and fixtures - Includes a minimal reference contract and scenarios that reflect common integration failures - Produces machine-readable outputs suitable for CI (JUnit and JSON) ### 3) CI template (GitHub Actions) - Copy-paste CI workflow that boots the stack and executes tests headlessly - Health checks and timeouts for determinism - Target runtime: **≤18 minutes** per run on standard runners, excluding queue time ### 4) Preflight “doctor” - `npx relaydevkit doctor` detects common setup failures with exact remediation steps - Returns non-zero exit codes when the environment is not ready ### 5) Integration-grade documentation - 10-minute quickstart - Common failures and fixes - How to use RelayDevKit in your wallet or dApp repo - Version pinning and upgrade procedure ## Technical architecture - **CLI distribution:** npm package runnable via `npx relaydevkit …` The npm package is a CLI wrapper around pinned container images and scripts. It is not a runtime library meant to be embedded into production applications. - **Environment orchestration:** Docker Compose with pinned service versions, health checks, and deterministic boot order - **Deployment automation:** Containerized deploy pipeline so developers do not install legacy toolchains locally - **Testing:** Deterministic harness that resets local chain state between tests and uses fixed identities and fixtures - **Artifacts:** Structured logs and test reports for CI ## Integration with Rootstock - Provides a complete local stack for Relay integration work: local node + contracts + Relay Server + registration + tests - Designed so external repos can adopt by copying the CI template or vendoring the harness configuration they want to pin ## Security considerations - Local-only scope; no mainnet operations in this grant - No sensitive secrets committed; deterministic test keys are clearly labeled “test-only” - Pinned versions reduce drift; upgrade procedure reduces unsafe ad-hoc changes - Default configuration does not publicly expose local services - Include a SECURITY.md with a disclosure and patch process * * * # Description: ## Core problem being solved RIF Relay integrations are slow and error-prone because setup spans multiple components and manual steps. Developers lose time to misconfiguration, environment drift, and missing end-to-end coverage. That blocks shipping or causes regressions after upgrades. ## Solution overview RelayDevKit packages the Relay components into a reproducible local stack and adds the engineering layer required for reliable integration work: automated wiring and registration, deterministic end-to-end tests, CI templates, and preflight diagnostics. ## Unique value proposition - Produces a working, registered Relay environment with one command - Makes Relay integration verifiable in CI with deterministic tests - Reduces time-to-first-success and prevents regressions across upgrades - Removes common Relay setup and CI friction by providing a reproducible local stack and deterministic end-to-end verification ## Competitive analysis Existing Relay repos and examples are component-level resources; they do not provide a complete deterministic local environment and CI harness that is ready for repeatable integration testing. RelayDevKit differentiates by shipping orchestration, automated registration, diagnostics, and CI-grade verification. * * * # Project Roadmap: ## Clear timeline with measurable deliverables **Total duration:** 7 weeks from kickoff ### Major milestones and expected completion dates - **M1 (Week 2):** Local node + CLI + deterministic keys/funding + health checks - **M2 (Week 3):** Automated contract deployment + test-token wiring + generated config - **M3 (Week 4):** Relay Server boot + automated registration workflow + ready status - **M4 (Week 6):** Deterministic end-to-end tests + GitHub Actions template - **M5 (Week 7):** Doctor + docs + npm release + upstream docs/resources PR submission ## Key success metrics for each phase - **M1:** `up/status/down` succeeds on a clean machine with Docker and Node.js LTS installed, without requiring manual commands inside containers or manual config edits. `status` confirms the node RPC is reachable and `down` removes containers and volumes cleanly. - **M2:** `deploy` produces a single generated config output that includes the deployed contract addresses and the values needed for the local Relay Server configuration. A second run completes without manual environment edits and produces the same config format. - **M3:** After `up`, the Relay Server is running and the required local registration steps are completed, verified by `status` showing the relay as registered and ready. A scripted smoke check submits at least one relayed call against the local stack. - **M4:** End-to-end tests pass deterministically both locally and in GitHub Actions, covering at least 6 scenarios. The provided CI workflow completes within the stated runtime cap and produces machine-readable test results. - **M5:** `doctor` detects at least 8 common setup failures with actionable fixes and returns a non-zero exit code when the environment is not ready. Documentation enables a reviewer to follow the quickstart and reach a successful end-to-end relayed transaction within 30 minutes on a first run, assuming typical Docker image pull times. * * * # Performance Targets: ## Transaction volume N/A ## TVL (Total Value Locked) N/A ## User acquisition - Adoption indicator: at least 3 public external usage signals within 60 days of release from repos or teams not controlled by us, such as issues, PRs, or CI screenshots - At least 1 external repository not controlled by us successfully runs the CI template and confirms it publicly ## Other relevant metrics - Time to first successful relayed transaction from a clean setup: - CI determinism: **10 consecutive green runs** in the repository using the provided workflow - Diagnostic coverage: doctor detects and explains **≥8** common failure states with clear remediation * * * # Conclusion: RelayDevKit is a focused developer-tools project designed to unlock broader RIF Relay adoption by making integration reproducible, testable, and safe to ship. It delivers immediate value to wallets and dApps by reducing setup failure rates and providing deterministic end-to-end verification in CI. * * * # Social & Community: - **Website:** [https://www.dappsoverapps.com](https://www.dappsoverapps.com) - **Twitter/X:** [https://x.com/Dappsoverapps](https://x.com/Dappsoverapps) - **Discord/Telegram:** supercoolkay - **GitHub repository:** [https://github.com/Supercoolkayy/RelayDevKit](https://github.com/Supercoolkayy/RelayDevKit) ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [April 21, 2026, 2:06am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/13 "2026-04-21T02:06:04Z")
Thanks @SEEDGov for the review and for calling out the systemic risk clearly. We agree that risk is real when a kit becomes a shared dependency that many applications import into production. That is why we updated the scope so RelayDevKit is **not a runtime dependency**. What changed in the updated proposal • RelayDevKit is now a dev and CI reference harness, not a library that applications embed • It ships as Docker Compose plus scripts and a CI template that teams can vendor and pin in their own repos • It is for local development and CI only, with test-only keys and no mainnet operation • Versions are pinned and there are no auto-updates • We will include SECURITY.md with a disclosure and patch process, plus CI checks for dependency and build safety This keeps the benefit of the tool while reducing the shared-dependency failure mode that can propagate across downstream projects. ---
**Author:** ![Curia](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/curia/32/943_2.png) [@Curia](https://gov.rootstockcollective.xyz/u/Curia)\ **Post date:** [April 21, 2026, 4:55am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/14 "2026-04-21T04:55:04Z")
Thanks @DappsoverApps for revising the scope. This reduces the risk of issues propagating if Relay becomes standardized across the ecosystem. It now comes across more as a dev tool for creating a local testing environment and running automated checks in CI, instead of being a shared dependency used in production. That makes the scope much safer and more contained. One thing we’ve been thinking about is the actual demand for Relay integration itself. In the previous version, delegates mostly discussed the potential risks if it were widely used across projects, but that also kind of assumes that teams would actually choose to adopt it in the first place. So just curious, has the team spoken with projects or done any kind of survey or feedback collection to validate this? For example, are teams currently struggling enough with their setup or testing workflows that they would need a tool like this, or are most teams already comfortable running their own processes? Also we’d like to point out that there is no need to rush resubmitting the proposal for a vote immediately after the rescope. We think delegates need some time to properly review the changes and the discussion process itself is important. So would like to better understand the reason behind the quick resubmission after posting the updated scope in the thread. ---
**Author:** ![SEEDGov](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/seedgov/32/673_2.png) [@SEEDGov](https://gov.rootstockcollective.xyz/u/SEEDGov)\ **Post date:** [April 21, 2026, 1:32pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/15 "2026-04-21T13:32:46Z")
> [@Curia](#): > > Also we’d like to point out that there is no need to rush resubmitting the proposal for a vote immediately after the rescope. We think delegates need some time to properly review the changes and the discussion process itself is important. So would like to better understand the reason behind the quick resubmission after posting the updated scope in the thread. We agree with this point, which [we recently expressed](https://gov.rootstockcollective.xyz/t/seedgov-delegate-thread/774/3) in a proposal whose author acted in a similar manner. It is not good governance practice to modify a proposal and immediately submit it for a vote, as this does not allow for it to be analyzed and discussed. Furthermore, it should be noted that [the original proposal](https://app.rootstockcollective.xyz/proposals/20020649620005391174308698409027411175347044058711340763327230106363280231434) is still in voting period. There is no justification for proceeding with such urgency. ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [April 21, 2026, 2:20pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/16 "2026-04-21T14:20:22Z")
Thanks for the thoughtful note @Curia , and agreed delegates should take time to review the changes. **On demand for Relay integration** This is a workflow problem. The current Relay integration path is publicly documented and has multiple moving parts that teams have to keep working together in local testing and CI, including node requirements, contracts wiring, relay server setup, and registration. RelayDevKit is scoped as a dev and CI reference harness that makes that workflow reproducible and easier to verify. It is not a production dependency, and it does not assume every team will adopt it. [https://gov.rootstockcollective.xyz/t/ecosystem-grant-themes-update/288](https://gov.rootstockcollective.xyz/t/ecosystem-grant-themes-update/288) [https://dev.rootstock.io/developers/integrate/rif-relay/deployment/](https://dev.rootstock.io/developers/integrate/rif-relay/deployment/) **On the quick resubmission after the rescope** The intent was not to rush the process. Since this proposal has been under active review for several weeks and delegates were already engaging with it, we resubmitted so the on-chain version reflects the revised, safer scope rather than leaving the older version as the live artifact. Delegates should still take the time they need to review the update, and we will keep responding to questions in the thread as that review happens. ---
**Author:** ![DappsoverApps](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@DappsoverApps](https://gov.rootstockcollective.xyz/u/DappsoverApps)\ **Post date:** [April 21, 2026, 2:47pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/17 "2026-04-21T14:47:06Z")
Thanks @SeedGov Point taken, and we agree with the governance principle here. The resubmission was not meant to rush review. We updated the onchain proposal because the scope change was material and we did not want an outdated version to remain the live onchain proposal while delegates were already discussing the revised scope. We are not asking delegates to treat the resubmission as time-sensitive. Please take the time needed to review the changes in the thread first, and we will follow whatever timing the governance process and delegates prefer for considering the revised scope. Thank you. ---
**Author:** ![ChronoTrigger](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/chronotrigger/32/78_2.png) [@ChronoTrigger](https://gov.rootstockcollective.xyz/u/ChronoTrigger)\ **Post date:** [April 22, 2026, 12:45am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/18 "2026-04-22T00:45:46Z")
The revised scope addresses the propagation vector, which is a real improvement. The team questions though, are still open. @Curia already asked Bolaji and Gospel directly for examples of prior multi-component work at similar complexity, and that’s still unanswered. I’d add that the entire prior track record in the proposal sits under a single GitHub account (Supercoolkayy), which reads as one developer’s portfolio rather than a collective’s shared work. For a project proposing to ship infrastructure other teams will vendor into their repos, demonstrated joint shipping is part of the bar for this kind of work. I’d like to see a few clarifications before a vote. GitHub is listed as N/A at the team level, which is unusual for a dev tooling project. Gospel Ifeadi, named as Core Tooling and Smart Contract Engineer, is referenced only through an X handle with no LinkedIn or GitHub. And @Ignas concern about the absence of a legal entity or clear ownership post-grant reinforces the question. Who exactly is accountable, and how is that verifiable today? Until meaningful clarification is provided on these points, we cannot support this proposal. Since a new proposal is already submitted, we’ll wait for a couple days before casting a vote. ---
**Author:** ![ChronoTrigger](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/chronotrigger/32/78_2.png) [@ChronoTrigger](https://gov.rootstockcollective.xyz/u/ChronoTrigger)\ **Post date:** [April 22, 2026, 3:22am UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/19 "2026-04-22T03:22:37Z")
> [@DappsoverApps](#): > > **Gospel Ifeadi — Core Tooling / Smart Contract Engineer** > Builds the local-stack automation glue, deployment scripts, and end-to-end test harness logic. > Link — [https://x.com/gospel70800](https://x.com/gospel70800) Account not found. Can you clarify? ---
**Author:** ![DAOstar\_gov](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/daostar_gov/32/593_2.png) [@DAOstar\_gov](https://gov.rootstockcollective.xyz/u/DAOstar_gov)\ **Post date:** [April 22, 2026, 12:56pm UTC](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772/20 "2026-04-22T12:56:13Z")
Agreed with the points raised by @ChronoTrigger on track record and ownership — these were also the basis for our against [vote](https://gov.rootstockcollective.xyz/t/daostar-delegate-thread-rev/711/29) on the previous version of this proposal. We hope the team has taken the time to read the delegate rationales from that vote, as they may add useful color to the concerns being raised in this thread. One additional question we would like the team to address before reconsidering our position: are you currently active on other funded grants in other ecosystems? Given that long-term maintenance is already deferred to a separate future ask, understanding the team’s current bandwidth across commitments is relevant to assessing delivery confidence here. [Next page](https://gov.rootstockcollective.xyz/t/2603-relaydevkit/772.md?page=2)