[2604 Grant] RBTC Onboarding EventKit

Grants & Incentives
1

Proposal Content

A. Project Name:
RBTC Onboarding EventKit

B. Classification:

  • Project stage: MVP

  • Sector: Developer Tools / Infrastructure

  • Target audience: Wallets, exchanges, and dApps that support the official BTC to RBTC peg-in flow on Rootstock

Submission Date:
April 6, 2026

Founder Information

Founder name(s)

Professional background
Crackdevs is a builder collective focused on developer tooling and core infrastructure. The team works on the kinds of tools that reduce integration friction: SDKs, CLIs, templates, backend utilities, and the glue code around them.

Ifedimeji Omoniyi is a Technical Product Manager with experience across developer tooling, protocols, and infrastructure.

Ayomide Ojutalayo is a Developer Engineer focused on implementation and tooling.

Prior blockchain experience
Crackdevs focuses on developer tooling and infrastructure-oriented product work for blockchain teams. This proposal continues that direction with a narrow integration tool for Rootstock onboarding.

Team

Key team members and roles

  • Ayomide Ojutalayo — Developer Engineer

  • Ifedimeji Omoniyi — Technical Product Manager

Relevant experience and expertise

  • Building developer tooling and integration utilities

  • Designing backend event flows with retries, deduplication, and signature verification

  • Shipping open-source packages with examples, documentation, and CI

Previous blockchain/web3 projects
N/A

Media & Resources

Screenshots/mockups
N/A

Technical documentation
Current technical documentation is in the prototype repository:
https://github.com/Crackdevs/RBTC-Onboarding-EventKit

Current Progress Before Submission

Before submitting this grant, we self-funded and published a working MVP to reduce execution risk and show that this is already moving beyond the idea stage.

Public prototype / MVP:
https://github.com/Crackdevs/RBTC-Onboarding-EventKit

The current repository already covers the project foundation:

  • SDK package structure

  • webhook-worker package structure

  • example receiver applications

  • documentation scaffolding

  • CI and release workflow scaffolding

We are presenting it as a working foundation. The grant request covers the remaining work needed to take that foundation to release-grade quality: lifecycle hardening, payload and signature stability, retry and idempotency guarantees, fixture coverage, packaging, polished integration examples, and full documentation.

Traction & Metrics

TVL (if applicable)
N/A

Growth trajectory
N/A

Key achievements to date

  • Public MVP published before grant submission

  • Project has moved past the concept stage into working implementation groundwork

  • Initial architecture and package boundaries have already been validated in code

Grant Request

Total amount requested
$9,300

Milestone breakdown with associated deliverables and dates

For scheduling clarity, T0 means grant kickoff.

Milestone 1 — Lifecycle model and SDK core

Target date: T0 + 2 weeks
Amount: 2,700 USDRIF or rBTC equivalent at disbursement

Deliverables

  • Finalized canonical peg-in lifecycle model for official BTC to RBTC onboarding flows

  • Hardened backend adapter layer that normalizes official peg-in status responses

  • Typed TypeScript payloads and helpers

  • Fixture-based tests covering the shipped lifecycle states

What the existing MVP already contributes
The current prototype already includes the early foundation for the SDK package and lifecycle handling. This milestone covers the release-grade completion of that work.

Acceptance criteria

  • The SDK normalizes official peg-in status responses into one documented lifecycle model

  • The lifecycle model has clear terminal, non-terminal, and failure states

  • Fixture tests cover all shipped lifecycle states without ambiguity

Milestone 2 — Signed webhook worker

Target date: T0 + 4 weeks
Amount: 2,800 USDRIF or rBTC equivalent at disbursement

Deliverables

  • Self-hostable webhook worker

  • Signed webhook payload generation

  • Signature verification helpers

  • Retry and backoff logic

  • Idempotency keys and deduplication

What the existing MVP already contributes
The current prototype already includes the early foundation for the webhook-worker package. This milestone covers the release-grade completion of signing, retry, verification, and delivery guarantees.

Acceptance criteria

  • Webhook payloads are signed and verifiable

  • Duplicate state changes do not trigger duplicate downstream processing

  • Retry behavior is deterministic and documented

  • The worker can be configured without application-specific code changes

Milestone 3 — Reference integrations and test suite

Target date: T0 + 6 weeks
Amount: 2,000 USDRIF or rBTC equivalent at disbursement

Deliverables

  • One wallet-backend example

  • One exchange / deposit-processor example

  • End-to-end lifecycle tests

  • CI workflow

Acceptance criteria

  • Both examples run successfully with documented setup

  • CI passes consistently

  • The examples show exact app-side state transitions for deposit tracking and completion handling

Milestone 4 — Docs, packaging, and release polish

Target date: T0 + 7 weeks
Amount: 1,800 USDRIF or rBTC equivalent at disbursement

Deliverables

  • npm packaging

  • Quickstart

  • Webhook payload specification

  • Integration guide

  • Short post-release bug-fix window

Acceptance criteria

  • Package is installable from npm

  • A reviewer can follow the docs and run a sample flow without guesswork

  • Webhook format and verification steps are fully documented

  • Release artifacts are versioned and usable without relying on internal setup knowledge

Amounts per milestone in desired coin/token: USDRIF, rBTC

  • M1: 2,700 USDRIF or rBTC equivalent

  • M2: 2,800 USDRIF or rBTC equivalent

  • M3: 2,000 USDRIF or rBTC equivalent

  • M4: 1,800 USDRIF or rBTC equivalent

Mission & Vision

How your project aligns with Rootstock ecosystem goals
RBTC Onboarding EventKit improves the developer-side reliability of the official BTC to RBTC onboarding flow.

The onboarding path already exists. What many product teams still need is a reusable way to turn peg-in status changes into backend actions they can trust. That includes updating deposit records, marking funds as available, notifying users, and reducing support uncertainty around deposits in progress.

This proposal stays close to that real workflow. It does not introduce a new bridge, a new hosted service, or a new protocol. It strengthens a flow Rootstock already has by making it easier for other teams to integrate correctly.

Product Details

Core features and functionality
RBTC Onboarding EventKit will ship as two open-source packages.

1. TypeScript SDK

The SDK will provide:

  • a canonical peg-in lifecycle model

  • typed status payloads

  • lifecycle normalization helpers

  • webhook signature verification helpers

  • integration utilities for backend applications

2. Self-hostable webhook worker

The webhook worker will provide:

  • polling against the official status backend

  • signed webhook delivery

  • retry handling

  • idempotency keys

  • deduplication

  • configurable webhook destinations

Technical architecture

  • TypeScript packages published to npm

  • One lightweight worker process for polling and webhook delivery

  • No hosted infrastructure in the grant scope

  • Fixture-based lifecycle tests and CI

  • Reference integrations that show real application usage

Integration with Rootstock
This project is purpose-built for the official BTC to RBTC peg-in flow on Rootstock.

Version 1 is intentionally limited to:

  • native BTC to RBTC peg-ins

  • fast-mode peg-ins only where the official backend already exposes the required statuses

This tight scope is deliberate. It keeps the project realistic within budget and avoids drifting into quote routing, LP selection, full peg-out support, or broad bridge abstraction.

Security considerations

  • Signed webhook payloads for authenticity

  • Idempotency keys and deduplication to prevent double-processing

  • No custody of user funds

  • No key management beyond webhook signing configuration

  • No hosted-service exposure introduced by the grant deliverable

Description

Core problem being solved
The current onboarding flow gives end users a manual way to check peg-in progress, but products that support BTC to RBTC onboarding need more than a manual status page.

A wallet, exchange, or application usually needs to know when a peg-in:

  • has been detected

  • is still pending

  • has completed

  • has failed

Without a reusable integration layer, each team ends up building and maintaining its own polling logic, status mapping, retry handling, and webhook delivery. That repeated work is inefficient and easy to get wrong.

Solution overview
RBTC Onboarding EventKit packages the missing integration layer on top of the official peg-in flow.

It gives integrators:

  • one documented lifecycle model

  • one signed webhook format

  • one TypeScript package for verification and parsing

  • example integrations that show exactly how to automate app-side updates

You can already see the project foundation in the public MVP repository:
https://github.com/Crackdevs/RBTC-Onboarding-EventKit

Unique value proposition

  • It solves a real integration problem without requiring protocol changes

  • It is narrow enough to ship within the requested budget

  • It improves a live onboarding flow instead of inventing a new one

  • It is useful immediately to teams that support official peg-ins

  • It stays separate from quote tools, routing tools, Relay tools, and local dev stacks

Competitive analysis
Existing Rootstock onboarding infrastructure already helps users initiate and monitor peg-ins. Existing lower-level packages help developers interact with bridge-related components.

What is still missing is a small, reusable product layer for:

  • canonical lifecycle states

  • signed webhook delivery

  • retry and deduplication rules

  • integration-ready backend examples

This proposal does not try to replace the current backend. It builds on top of that flow and turns it into a practical developer tool.

Project Roadmap

Clear timeline with measurable deliverables

Phase 1 — Lifecycle model and SDK core

Completion target: T0 + 2 weeks
Measurable deliverables:

  • canonical lifecycle model documented

  • SDK normalizes official peg-in status responses

  • fixture tests cover the shipped states

Phase 2 — Signed webhook worker

Completion target: T0 + 4 weeks
Measurable deliverables:

  • signed payloads emitted

  • signature verification helpers shipped

  • retry and deduplication logic implemented and tested

Phase 3 — Reference integrations and CI

Completion target: T0 + 6 weeks
Measurable deliverables:

  • wallet example shipped

  • exchange / deposit-processor example shipped

  • CI passing consistently

Phase 4 — Packaging and release

Completion target: T0 + 7 weeks
Measurable deliverables:

  • npm release published

  • quickstart and integration guide complete

  • payload specification published

  • post-release bug-fix window started

Major milestones and expected completion dates

  • T0 + 2 weeks

  • T0 + 4 weeks

  • T0 + 6 weeks

  • T0 + 7 weeks

Key success metrics for each phase

  • Lifecycle normalization works from fixture inputs without ambiguity

  • Signed webhooks are verifiable and safe for backend use

  • Duplicate events do not cause duplicate downstream processing

  • Example integrations make the usage of the tool immediately clear

  • A reviewer can run the example flow by following the docs without guesswork

Performance Targets

Transaction volume
N/A

TVL (Total Value Locked)
N/A

User acquisition
N/A for direct end users, since this is developer infrastructure

Other relevant metrics

  • SDK successfully normalizes official peg-in states into one documented lifecycle model

  • Signed webhooks pass verification and deduplication tests consistently

  • CI passes across the shipped fixture and integration tests

  • A reviewer can run a sample flow in under 30 minutes using the documentation

  • Example backends can update internal deposit records correctly when a peg-in lifecycle state changes

Conclusion

RBTC Onboarding EventKit is a focused developer-tooling proposal for Rootstock’s official BTC to RBTC onboarding flow.

The current flow already lets users track progress manually. What many integrators still need is a reliable, reusable way to turn peg-in status changes into backend automation.

Social & Community

Website: crackdevs.org
Email: info@crackdevs.org
Twitter/X: crackdevs

1 Like
Additional Contributions from Delegates (A Discussion Thread)
Rootstock Collective Governance-at-a-Glance 26-04-10
2

We understand the motivation behind this proposal and that handling BTC to RBTC peg-in status is part of the integration process for teams building on Rootstock. However, from our perspective, the core question is not whether this can be improved, but whether it is a pain point significant enough for teams to adopt a shared solution instead of continuing to build their own logic.

As outlined in the proposal, teams currently need to build and maintain their own polling logic, status mapping, retry handling, and webhook delivery. While this proposal aims to standardize that process, it is not yet clear that this represents a major bottleneck for existing integrators.

Have you validated demand with wallets, exchanges, or dApps that would adopt this EventKit?

3

Thank you @Curia, we agree the key issue is not whether status handling can be improved, but whether it is recurring enough in practice that a shared solution is justified.

We believe the public Rootstock materials already show that this is a concrete integration need that is not fully solved by the current user-facing flow.

1. The current official status flow is still oriented around manual checking.
The peg-in status guide tells users to open the transaction status page, paste the transaction ID, and refresh to see progress. That is useful for an individual user, but it is not a reusable backend interface for products that need to update deposit records, trigger internal actions, or notify users automatically.

2. Peg-ins are long-running enough that backend lifecycle handling matters.
The official PowPeg overview describes native peg-ins as taking about 17 hours to complete, and the PowPeg FAQ describes fast mode as roughly 20 minutes depending on LP conditions. For a flow that can remain in progress for that length of time, product teams usually need more than a manual refresh pattern.

3. Rootstock already positions wallets, exchanges, and dApps as the intended integrators for this onboarding path.
The Flyover integration overview explicitly names wallets, exchanges, dApps, DEXs, and swaps as the audience for these flows. Those teams commonly need machine-readable lifecycle updates in addition to a user-facing page, because they need to know when deposits are pending, completed, or failed inside their own systems.

4. The official stack already relies on dedicated backend status-tracking components.
The public 2wp-api repository describes the solution as a web interface plus a REST API, with a separate daemon or worker responsible for obtaining blockchain data and updating transaction status. That is evidence that status handling is already substantial enough to justify dedicated infrastructure. Our proposal does not replace that stack. It adds the missing developer-facing layer on top of it: normalized lifecycle states, signed webhooks, retries, deduplication, and backend examples.

So our point is not simply that status is important in the abstract. It is that Rootstock’s own public flow already shows long-running deposit states, product integrator use cases, and a non-trivial backend for status tracking. EventKit is meant to package the missing integration layer on top of that, so teams do not each have to rebuild the same lifecycle and webhook logic privately.

Thank you so much for the questions!

4

Thanks for the proposal, @Crackdevs.

We reviewed the MVP repository and have concerns.

The MVP already implements most of the grant deliverables. The webhook worker, SDK, and example backends are all working code. The proposal frames the remaining work as “hardening to release-grade quality,” but the gap between this and a publishable package is test coverage and documentation, not $9,300 across four milestones.

The codebase contains no Rootstock-specific code. Your reply to @Curia positions EventKit as a layer on top of 2wp-api, but nothing in the repository actually connects to it. The worker polls a generic HTTP endpoint, the lifecycle states are generic deposit states, and the signing is standard. The hard part, building a concrete adapter that works against Rootstock’s status infrastructure, is the work that would justify a grant, but it’s not in the MVP and not clearly scoped in the milestones.

We agree with @Curia on demand validation. We’d add: even setting demand aside, the treasury should fund work that is specific to Rootstock’s ecosystem and hard to build independently. A generic webhook relay doesn’t meet that bar.

1 Like
5

Hi @Crackdevs, welcome to the Rootstock Collective! Appreciate you already self funding an MVP of the SDK. I think the open question, as other delegates have brought up, is whether the SDK will have usage. I’m tagging RLabs Product Manager @tobyj so he can maybe shed some more light. Hang tight!

6

Thank you for the review @Tane We took the feedback seriously and updated both the build and the repo to address the main concern you raised.

We have made the implementation Rootstock-specific and updated the repository accordingly, so it is no longer just a generic webhook pattern. Please check again and let us know whether this now addresses the concern well enough for the proposal to proceed on-chain, or if there is still one specific gap you think needs to be resolved first. GitHub - Crackdevs/RBTC-Onboarding-EventKit · GitHub.

7

Hi @Axia , thank you - we are following up on your last comment since we did not hear from @tobyj. Please let us know if we can move forward with the proposal for on chain voting. Thank you.

8

Hi @Crackdevs you can go ahead and move forward with the onchain vote since the discussion has been on the forum for ~3 weeks.