Small Grant: walletd-depositd Reorg-aware Siacoin deposit event bridge for exchanges and wallet backends

Introduction

Project Name:
walletd-depositd
Reorg-aware Siacoin deposit event bridge for exchanges and wallet backends

Name of the organization or individual submitting the proposal:
Creatives Onchain

Describe your project.
walletd-depositd is a small helper service that runs beside walletd and turns walletd’s exchange-facing indexing flow into a clean, durable deposit event feed. The current exchange guide already points exchanges and wallet integrators to walletd full index mode, wallet events, and consensus updates for deposit tracking and reverted blocks. This project takes that documented flow and packages it into a simple service that stores progress safely, avoids duplicate processing, tracks confirmations, and emits backend-friendly deposit events that another service can consume right away.

The scope is intentionally narrow. walletd-depositd does not hold private keys, does not sign transactions, and does not try to become an exchange ledger. It only reads from walletd, watches a configured deposit address set, stores its chain cursor locally, and emits normalized deposit events as JSON and optional webhooks.

How does the projected outcome serve the Foundation’s mission of user-owned data?
It helps real integrations support Siacoin on the current v2 stack with less repeated backend work and less risk around deposit tracking. Instead of each exchange or wallet backend team writing and maintaining its own watcher, they get an open-source bridge built on top of the workflow Sia already documents.

Are you a resident of any jurisdiction on that list? Yes/No
No

Will your payment bank account be located in any jurisdiction on that list? Yes/No
No

Grant Specifics

Amount of money requested and justification with a reasonable breakdown of expenses:
$10,000 USD total

This is a focused small-grant build. It is one daemon, one event schema, one persistence layer, and one delivery path. It is not trying to become a wallet, a signer, or a full exchange backend.

Budget breakdown

Event schema, config format, and deposit event ID rules
12 hours
$960

Core polling engine for walletd, cursor storage, and SQLite state
34 hours
$2,720

Address matching, confirmation tracking, and normalized event creation
22 hours
$1,760

Webhook delivery with retries and idempotency support
18 hours
$1,440

Tests, recorded fixtures, and CI
20 hours
$1,600

Packaging, release binaries, container image, and example configs
6 hours
$480

30-day maintenance window
13 hours
$1,040

Total
125 hours at $80 per hour
$10,000

What is the high-level architecture overview for the grant? What security best practices are you following?
walletd-depositd runs beside an existing walletd node. It keeps a local cursor, polls the consensus updates endpoint, checks each update for configured deposit addresses, stores matched events in SQLite, and emits them as JSON and optional webhooks. The exchange guide already documents the wallet and consensus update flows for deposit tracking, so this project stays close to the official production path instead of inventing a new one.

On the security side, the tool will never hold private keys, generate seed phrases, or sign transactions. It only reads from walletd and emits deposit facts. Sensitive values like API auth and webhook secrets will be loaded from environment variables or local config and will not be written to logs. Event delivery will use deterministic event IDs and idempotency headers so downstream systems can retry safely without duplicate crediting.

What are the goals of this small grant? Please provide a general timeline for completion.
The first goal is to ship a stable deposit event daemon that can poll walletd, store its progress safely, and emit normalized deposit events for a configured address set.

The second goal is to make reorg-aware deposit tracking easier for exchange and wallet backend teams by handling cursor persistence, deduping, and confirmation tracking in one small service.

The third goal is to make first adoption easy by shipping binaries, a container image, a simple config file, and a working example of webhook delivery.

General timeline

Week 1
Build config loading, event schema, cursor storage, and the core polling client.

Week 2
Add address matching, deposit normalization, deterministic event IDs, and NDJSON output.

Week 3
Add webhook delivery, retries, idempotency handling, and confirmation tracking.

Week 4
Finish fixture-based tests, publish binaries and container image, and write first-run docs.

30-day maintenance window
Fix bugs from early adopters, improve docs, and release one patch if needed.

Milestones for judging progress

The daemon can poll updates and safely persist cursor progress.
A recorded fixture with one deposit produces one normalized deposit event.
A reverted-block fixture produces correct compensating behavior and final cursor state.
Webhook delivery works with retries and idempotency.
Linux binaries and container image are published.

What are your plans for this project following the grant?
The plan after the grant is to keep the tool small and stable first. The immediate priority is making the core bridge reliable for real exchange and wallet backend use.

If the tool gets real usage, the next step would be small operator improvements like better address source refresh options and lightweight metrics, but only after the base daemon is stable.

Potential risks that will affect the outcome of the project:
Risk: reorg handling can be tricky.
Mitigation: the daemon will be built and tested around the exact reverted-block behavior described in the exchange guide, using recorded fixtures instead of assumptions.

Risk: integrators may want their own event shapes.
Mitigation: the shipped schema will stay small, stable, and versioned so teams can transform it downstream if they need to.

Risk: you may think that exchanges can build this themselves.
Mitigation: that is exactly why the tool is useful. Today, any serious integrator has to build the same durable watcher logic on top of the same documented walletd primitives. This project turns that repeated work into a shared open-source tool without needing any core merge.

Development Information

Will all of your project’s code be open-source?
Yes

All code developed for this project will be open-source. We do not plan to develop any closed-source code for this grant.

Do you agree to submit monthly progress reports?
Yes

Progress reports will be submitted monthly in the forum.

Prove of Work:

Creatives Onchain is a builder collective focused on developer tooling, protocol infrastructure, and operator-facing systems for blockchain ecosystems.

A recent example of our work is Stylus Trace Studio in the Arbitrum ecosystem. It is a profiling and trace inspection tool for Arbitrum Stylus that helps developers inspect execution traces, analyze gas and ink usage, generate flamegraphs, and catch performance regressions during development and CI. This is relevant to this proposal because it reflects direct experience building low-level developer tooling with structured outputs for real engineering workflows.

Links:
https://crates.io/crates/stylus-trace-studio/0.1.11
https://github.com/CreativesOnchain/Stylus-Trace


Team member backgrounds

Timothy Popoola
Role: Systems and Verification Engineer
Background: Engineer with experience building security-sensitive systems and system-level interfaces. Built FlowGuard, a non-custodial treasury management protocol for Bitcoin Cash, and architected AetheraOS, a bridge between MCP and local OS execution.
Responsibilities: Timothy will define correctness rules for deposit detection, cursor advancement, duplicate prevention, and reorg handling. He will also design adversarial tests for malformed payloads, restart safety, replay scenarios, and webhook failure handling.
Links:
https://github.com/winsznx/flow-guard
https://flow-guard-delta1.vercel.app
https://github.com/winsznx/AetheraOS
https://aethera-os.vercel.app

Christian Ndu
Role: Core Implementation Engineer
Background: Backend and full stack engineer with experience across TypeScript, Go, and Rust, with experience shipping developer tooling and backend systems.
Responsibilities: Christian will implement the core walletd-depositd daemon, including polling, cursor persistence, event normalization, confirmation tracking, webhook delivery, and the test suite.
Link:
https://github.com/khrees2412

Musa Habeeblai
Role: Protocol and Security Reviewer
Background: Blockchain and protocol engineer with experience in zk systems and production-grade protocol work.
Responsibilities: Musa will review the tool against documented walletd indexing and consensus update behavior, with focus on reorg handling, event correctness, secret safety, and keeping the tool strictly observational.
Link:
https://github.com/beebozy

Akeem Adelanke
Role: Project Manager and Integrator Enablement Lead
Background: Experience in developer onboarding, crypto programs, and community operations across NEAR, Creatives DAO, Mintbase, and Arbitrum.
Responsibilities: Akeem will own delivery planning, milestone tracking, release readiness, coordination across the team, and concise operator-facing documentation so adoption is straightforward for exchanges and wallet backends.
Link:
https://x.com/cr8tivesonchain

Hello @CreativeOnchain, our proposals are required to be presented following a monthly structure - could you revise your timeline to match a monthly breakdown instead of a weekly one? It’s unclear from your proposal if this is a 1 month or 2 month grant proposal.

Please confirm by tomorrow/Thurs. 12th by 12pm ET to have this proposal presented at the Committee meeting next week.

Hi @mecsbecs , the weekly timeline is cumulative to 1 month we just broke it down further. Yes we will like to have the proposal presented. Thank you.

1 Like

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee has decided to reject your proposal citing the following reasons:

  • If there is an unaddressed need for an exchange, the Foundation will handle it internally.

We’ll be moving this to the Rejected section of the Forum. Thanks again for your proposal, and you’re always welcome to submit new requests if you feel you can address the Committee’s concerns.