[2603] RelayDevkit

Grants & Incentives
1

[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

  • 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)

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

  • 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

  • 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

  • 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

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:

    • ≤30 minutes first run (includes initial image pulls)

    • ≤15 minutes subsequent runs

  • 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:

2 Likes
Rootstock Collective Governance-at-a-Glance 26-03-12
2

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

1 Like
3

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):

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.

1 Like
4

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?

1 Like
5

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 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

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.

6

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.

1 Like
7

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

8

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:

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.

9

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
RIF Relay sample dApp workflow How to use the RIF Relay Sample dApp SDK | Rootstock Developers Portal
Relay server repo and run requirements GitHub - rsksmart/rif-relay-server: This repository contains all the typescript code for the Rif Relay Server · GitHub
Relay contracts repo GitHub - rsksmart/rif-relay-contracts: This repository contains all the rif relay contracts · GitHub
Sample dApp repo GitHub - rsksmart/rif-relay-sample-dapp: Sample DApp for test relaying-services-sdk · GitHub

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

10

Hi @jengajojo , @Curia @Ignas @Axia , thank you for engaging with this proposal. Milestone 1 is done.

Milestone 1 completed

Repo: GitHub - Supercoolkayy/RelayDevKit · GitHub

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.