Small Grant: CoreSync-rs

Grants Rejected
1

Sia Foundation Small Grant Proposal: CoreSync-rs

Introduction

Project Name:
CoreSync-rs

Applicant Information:

ILE Labs — ILE-Labs · GitHub

We are a Rust-focused blockchain infrastructure team specializing in low-level execution environments, cryptographic tooling, and high-performance systems. Recent open-source work includes foc-devkit (Filecoin FVM testing framework), mx-tx-simulator (MultiversX transaction simulator), and stylus-debug-suite (Arbitrum Rust toolkit).

Prior Sia experience: We set up and ran a full local Sia stack — renterd, indexd, and PostgreSQL — to validate the live SDK integration path for this project. The setup process, resolved technical blockers (including the GeoIP database requirement, a binary URL patch for indexd, and the localhost vs 127.0.0.1 signature mismatch in sia_storage 0.9.1), and the complete verified integration runbook are documented here:

Describe your project.

CoreSync-rs is an open-source Rust library that implements local differential sync for decentralized storage. When a file changes, standard tools re-upload the entire file. CoreSync-rs uses content-defined chunking (FastCDC) to hash each piece locally, diffs against what the remote already has via indexd, and uploads only the bytes that are actually new. The engine hands off to the official Sia SDK for actual transport — it does not replace Sia’s networking or storage layer.

60 KB file, 10 KB append → upload ~11 KB instead of 60 KB.

The local engine is complete, tested, and wired to live Sia services via the sia-sdk feature flag.

How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?

User-owned storage must match the responsiveness of centralized cloud providers to achieve adoption. The biggest friction point for dynamic data — syncing databases, documents, or application state — is that every change triggers a full re-upload. This makes continuous sync on decentralized networks impractical for real applications.

CoreSync-rs removes that friction by computing the minimum delta payload locally before any bytes hit the network. Developers building Dropbox-style applications, backup tools, or collaborative document editors on Sia get a reusable Rust primitive that makes their storage layer efficient without requiring them to implement chunking and diffing themselves. Every byte saved in transit is a direct improvement in the user experience of applications built on user-owned infrastructure.

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

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

Grant Specifics

Amount of money requested and justification with a reasonable breakdown of expenses:

Total Requested: $9,800 USD

Item Amount
SDK integration hardening and indexd persistence layer $4,500
Small-file repacking module and delta batching logic $3,500
Integration documentation, examples, and test suite $1,800

The core chunking and diff engine is already complete and tested. This grant funds the remaining production work: hardening the live sia-sdk integration path, completing the indexd manifest persistence layer, building the small-file repacking module, and producing integration documentation and examples for developers building on Sia.

What is the high-level architecture overview for the grant, i.e. how does your project build on Sia? What security best practices are you following?

CoreSync-rs is a local-first Rust library. It does not run a daemon, expose network ports, or handle wallets or keys. The data flow is:

Local file → FastCDC chunking → SHA-256 manifest
           → diff against indexd-stored remote manifest
           → assemble delta payload (changed chunks only)
           → sia_storage SDK → upload to Sia
           → indexd → persist updated chunk manifest

The project builds on Sia through two official integration points:

  1. sia_storage SDK (sia-sdk feature flag) — used for chunk upload to Sia Storage. Authenticated via the official POST /auth/connect flow. Confirmed working against a local renterd node.

  2. indexd — used to store and retrieve chunk manifests per file, enabling diff computation on subsequent syncs. Confirmed working against a local indexd instance (PostgreSQL-backed).

Security practices: Written entirely in safe Rust. No unsafe blocks. Operates offline until the upload step — no network access during chunking or diff computation. SHA-256 chunk hashing with integrity verification before any delta is accepted. All credentials loaded from environment variables, never hardcoded.

Architecture detail: core-sync-rs/ARCHITECTURE.md at main · ILE-Labs/core-sync-rs · GitHub
Integration detail: core-sync-rs/docs/INTEGRATION.md at main · ILE-Labs/core-sync-rs · GitHub

What are the goals of this small grant? Please provide a general timeline for completion.

Goal: Deliver a production-ready Phase 1 of CoreSync-rs — a stable open-source Rust library with a verified live integration path against Sia Storage and indexd.

Month 1:

  • Complete and harden the sia-sdk live integration path (StorageBackend and ManifestStore backed by real Sia services)
  • Complete the small-file repacking and delta batching module
  • Run and document the full end-to-end demo with real output against live Sia services
  • Deliverable: cargo run --example sia_live_demo --features sia-sdk produces verified differential sync output against real Sia Storage and indexd

Month 2:

  • Complete integration documentation and developer examples
  • Finalize test suite including live integration tests
  • Submit final milestone report with benchmark data showing bandwidth savings
  • Deliverable: Public GitHub release tagged v0.1.0 with full documentation, integration guide, and example applications

Who is the target user for your project?

Application developers building continuous sync, backup, or dynamic state-management tools on Sia — specifically those who need efficient handling of frequently-changing files without re-uploading unchanged data on every sync cycle.

What are your plans for this project following the grant, including development, maintenance, and adoption?

This Small Grant funds Phase 1 — the local computation engine with verified Sia integration. Following successful delivery:

  • Phase 2 (Standard Grant): WASM bindings for browser-based applications, directory sync and watch mode, streaming reads for large files, and native integration examples with popular Sia ecosystem tools.
  • Maintenance: The repository will remain actively maintained under MIT license. Monthly progress updates will continue on the forum beyond the grant period.
  • Adoption: Integration guides targeting developers building on Sia SDKs. Community engagement via the Sia Discord to gather feedback and expand example coverage.
  • Sustainability: Phase 2 grant application and potential downstream integration by teams building on Sia who need differential sync as a dependency.

Potential risks that will affect the outcome of the project:

Risk Mitigation
sia_storage SDK API changes during development Pin SDK version in Cargo.toml. Monitor SiaFoundation/sia-sdk-rs releases. The trait abstraction layer means SDK changes require updating one adapter file only.
indexd API changes or availability The ManifestStore trait is abstracted — any API change requires updating only src/indexd_real.rs, not the core engine.
Cross-platform compilation issues GitHub Actions CI matrix covering Windows, macOS, and Linux. The sia-live HTTP compatibility path allows testing without a live stack.

Development Information

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

Yes. 100% open-source under the MIT license. No closed-source components. Third-party dependencies (fastcdc, sha2, serde, reqwest, sia_storage) are all appropriately open-source licensed.

Leave a link where code will be accessible for review:

Do you agree to submit monthly progress reports?

Yes.

Contact Info

Email: [email protected]

Other contact methods: Telegram @charlesCode

Sia-sync-core — Real-Time File Sync Engine for Sia Storage Applications
2

Hi @ILE_LABS - please revise the work timeline to follow our monthly breakdown requirement.

We’ve also reached capacity for next week’s Grants Committee meeting so the deadline for this edit is Wednesday, June 3.

3

Hi @mecsbecs, the timeline has been updated to follow the monthly breakdown requirement.

We’ll be waiting for feedback from the committee. Thanks.

4

Hi @ILE_LABS - it’s not clear in your proposal how you’re building on indexd or utilizing the SDKs (which can be accessed through our Dev Portal). Can you elaborate on how this project will do so?

Please note all edits will need to be completed by this Wednesday, June 3 at 5pm ET in order for this proposal to be considered for next week’s Committee meeting.

5

Hi @mecsbecs,

CoreSync-rs is a local data-preparation layer, not a replacement for Sia’s networking or storage tools. Its job is to compute the optimized diff/repacked payload locally, then hand that output off to the official Sia SDKs for upload and storage.

So the flow is:

CoreSync-rs → prepares the minimized payload locally
Sia SDK → handles the actual network upload and storage
indexd → can be used to track and reference the resulting chunk manifests over time

This keeps the architecture modular and aligned with Sia’s existing tooling rather than trying to replace it.

We’ll also made sure to add to the proposal the integration path clearly.

Thank you.

6

Thank you for this revision.

We’ve reached capacity for next week’s Grants Committee meeting, so this proposal will be slotted for review during the next meeting on June 23rd.

Thank you for your patience.

7

Hi @mecsbecs,

Following the earlier feedback and discussion around the SDK and indexd integration path, we’ve continued working on CoreSync-rs and now have a functional PoC for the local differential sync layer.

Repository:

The goal remains the same: keep the heavy lifting local, prepare the minimized payload in Rust, and then hand that off to the Sia SDKs and indexd rather than replacing the existing tooling.

The current PoC covers the core flow we wanted to validate, including content-defined chunking, local manifest diffing, delta assembly, and integrity verification. We’ve also updated the technical specification and repository to better reflect the integration path discussed in this thread.

We’re continuing to improve the implementation ahead of the committee review and wanted to share the progress with the community.

As always, we’re happy to receive any feedback.

Thank you.

1 Like
8

@ILE_LABS - please note, as of yesterday, we now require proof of experience building on Sia to demonstrate technical understanding of the Sia network to the Committee. Details can be found on the Grants webpage and reflected in the revised Small Grant proposal template.

Please tag me when the above has been incorporated into your proposal.

Thank you for your understanding.

9

Hi @mecsbecs,

Following the updated requirement around demonstrating experience building on Sia, we’ve continued extending the CoreSync-rs PoC beyond the local sync engine and into a live Sia environment.

We’ve successfully brought up a local Sia stack for testing and documented the process, including indexd integration, app registration, and end-to-end validation of the sync workflow.

Documentation:

This work is being incorporated into the proposal and repository as part of demonstrating direct experience building with the Sia tooling stack rather than only local data preparation.

We’re continuing to share additional updates as the integration work progresses.

Thank you.

10

Thanks for your proposal to The Sia Foundation Grants Program.

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

  • The Committee has doubts regarding the proposer’s technical understanding of Sia given the live demo includes renterd, which builders are not encouraged to use, and the lack of detail in your milestones. For example, most of your proposed deliverables appear to be integration work built around the existing FastCDC crate validated for Sia, and the milestones do not sufficiently address the challenges around repacking.

  • The Committee does not believe the scope of the project justifies the budget requested.

We’ll be moving this to the Rejected section of the Forum. Thanks again for your proposal, and we look forward to seeing you build in the Sia ecosystem.