Small Grant: CoreSync-rs

Sia Foundation Small Grant Proposal: CoreSync-rs

Introduction

Project Name:
CoreSync-rs

Name of the organization:
ILE Labs
We are a veteran Web3 infrastructure and Rust development team specializing in low-level execution environments, cryptographic tooling, and high-performance Rust infrastructure.

Core Team & Proof of Work:

Our team (operating as ILE Labs) has a proven track record of shipping highly technical developer infrastructure across multiple ecosystems. Recent delivered open-source projects include the foc-devkit (Filecoin FVM testing framework), mx-tx-simulator (MultiversX transaction simulator), and the stylus-debug-suite (Arbitrum Rust toolkit).

Describe your project:
CoreSync-rs is an open-source, cryptographic synchronization and differential sync engine built natively in Rust. It directly targets the high-priority small-file repacking and syncing use case for decentralized storage networks.

When users or applications attempt to sync thousands of small files or perform differential updates (where only a small portion of a file changes), standard storage uploads are highly inefficient. CoreSync-rs solves this by providing a highly optimized, client-side Rust engine that calculates cryptographic diffs (e.g., using rolling hashes/rsync algorithms) and handles intelligent file repacking. By operating entirely locally in memory-safe Rust, it ensures that only the minimum required delta bytes are prepared for network upload, drastically reducing overhead and improving sync speeds.

How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
The Foundation’s mission of a user-owned internet requires decentralized storage to be as fast and seamless as centralized cloud providers (like Dropbox or Google Drive). The biggest bottleneck for user-owned storage applications is managing continuous syncs of dynamic data (like application state, databases, or changing documents).

CoreSync-rs solves this by giving application developers a high-performance Rust primitive that makes “Dropbox-style” differential syncing possible on decentralized networks. By efficiently repacking small files and computing localized diffs before upload, we remove the friction of dynamic data storage, making it vastly more practical for developers to build highly responsive, user-owned applications.

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

Building a memory-safe cryptographic differential sync engine requires deep protocol-level engineering. The budget reflects the mathematical complexity of implementing custom rolling-hash algorithms and zero-copy FFI bindings in Rust, ensuring it is production-ready for enterprise applications.

Breakdown:

  • $4,500: Core Rust Sync Engine MVP (Implementing basic rolling hash algorithms (e.g., Rabin fingerprinting) and in-memory delta generation for local files).
  • $3,500: Small-File Repacking Module (Prototyping the memory logic for batching small file payloads to match decentralized storage block sizes).
  • $1,800: Documentation & Initial C-Bindings (Creating a comprehensive property-based test suite and basic FFI bindings to prove the Rust core can be integrated externally).

What is the high-level architecture overview for the grant? What security best practices are you following?
CoreSync-rs is a standalone, client-side Rust library. It does not run a daemon or expose network ports. It takes local file paths/buffers as input, computes Blake3/rolling hashes, generates cryptographic deltas using a custom Merkle-diffing architecture, and outputs optimized byte arrays ready for network transmission.
Security Best Practices: The engine is written in safe Rust, preventing memory leaks, buffer overflows, and segmentation faults. It operates entirely offline and does not handle network keys or wallets, ensuring zero attack surface regarding user funds or network exploits. Furthermore, we employ fuzzing and property-based testing to guarantee the cryptographic diffs never corrupt the original data structures.

Integration with Sia Tools:
CoreSync-rs acts as a local middleware layer. Once it computes the optimized delta payloads, it passes the byte-arrays to the official Sia SDKs (e.g., sia_storage or @siafoundation/sdk) for actual network transport. Furthermore, we rely on indexd to track and pin the manifests of these incremental delta chunks, ensuring applications can easily query file histories before passing the chunks back to CoreSync-rs for reconstruction.

What are the goals of this small grant? Please provide a general timeline for completion.
Goal: Deliver a Phase 1 MVP (Minimum Viable Primitive) of the open-source Rust library capable of local differential syncing and small-file repacking.
Timeline (2 Months):

  • Month 1: Implement the rolling hash, differential delta computation engine, and develop the small-file repacking and batching logic.
  • Month 2: Finalize initial C-bindings, documentation, and submit the final milestone report.

Who is the target user for your project?
Application developers and SDK maintainers who need to build continuous synchronization, backup, or dynamic state-management tools on top of decentralized storage networks.

What are your plans for this project following the grant?
This Small Grant is strictly Phase 1 (The Local Computation Engine). By intentionally limiting the scope of this grant to the core cryptography and repacking logic, we ensure a highly realistic delivery within 6 weeks.

Once we successfully deliver this MVP and prove our capacity to the Foundation, we plan to apply for a Standard Grant (Phase 2). Phase 2 will integrate this local engine directly with network layers, build out native WASM bindings for browser usage, and create direct integrations with standard ecosystem SDKs.

Potential risks that will affect the outcome of the project:
Risk: Cross-platform compilation issues (Windows/macOS) for the Rust FFI bindings.
Mitigation: We will utilize strict GitHub Actions CI/CD pipelines to ensure the library compiles successfully across all major operating systems before marking any release as stable.


Development Information

Will all of your project’s code be open-source?
Yes. 100% of the code will be open-source under the MIT / Apache-2.0 dual license and published to crates.io.

Leave a link where code will be accessible for review.
https://github.com/ILE-Labs/core-sync-rs

Do you agree to submit monthly progress reports?
Yes, we agree to submit monthly progress reports on the forum.


Email: [email protected]
Any other preferred contact methods: Telegram @charlesCode / Forum DM

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.

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

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

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.

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.

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.