Small Grant: Osiris Protocol - Decentralized Data Layer for On-Chain DCA Automation

Grants Proposed
1

Applicant: Tom - Founder, Osiris Protocol Contact: [email protected] | Telegram: @dyonisos10 Website: https://osiris-protocol.xyz | GitHub: GitHub - Le-Caignec/Osiris · GitHub Amount requested: $10,000 USD | Duration: 3 months

What Osiris Is

Osiris is a non-custodial smart contract protocol for programmable Dollar-Cost Averaging (DCA). It is not a DEX, not a trading UI, not a yield product. It is an automation primitive: users deposit assets into a vault, configure a DCA plan on-chain (token pair, frequency, per-cycle budget, slippage constraints), and the protocol executes that plan automatically without any keeper service, API key access, or centralized component.

Execution is powered by Reactive Network’s Reactive Smart Contracts (RSCs), which implement an inversion-of-control pattern, contracts subscribe to on-chain events and react autonomously, rather than being triggered by an off-chain cron job or bot. This makes Osiris the only cross-chain DCA protocol where the automation logic itself is fully on-chain and trustless.

The protocol has four on-chain components:

Vault Contract: Non-custodial asset custody. Per-user internal accounting. Unrestricted withdrawal at any time.

Plan Registry: Stores each user’s DCA configuration: token pair, frequency, per-cycle budget, slippage constraint, volatility filter, last execution timestamp. Validated before every execution — no partial executions, no overspending.

Execution Engine (RSC): Event-driven execution via Reactive Smart Contracts. No keeper dependency. Supports origin/destination cross-chain architecture across Ethereum, Arbitrum, and Base.

Data & Indexing Layer: Structured event logs emitted on every execution. Currently indexed off-chain. This is what this grant addresses.

The Problem This Grant Solves

Osiris’s execution, vaulting, and plan management are fully on-chain and non-custodial. One layer is not: the data persistence layer. A user’s DCA execution history, plan configurations, and analytics data currently depend on off-chain infrastructure that can be censored, taken offline, or silently modified. This is an architectural inconsistency for a protocol whose entire design is built on user ownership.

By integrating Sia as the data layer, every execution record, plan backup, and analytics event becomes encrypted, blockchain-enforced, and directly accessible by users, without requiring Osiris infrastructure to be available. This closes the gap between what Osiris promises at the execution layer and what it actually delivers at the data layer.

How We Use Sia

The integration operates entirely at the application layer. No changes are required to deployed Osiris smart contracts. A lightweight Sia bridge service listens to on-chain execution events, serializes them, and writes to Sia via renterd’s Worker API. The S3-compatible endpoint allows dashboards and third-party integrators to read data using standard HTTP: no Sia SDK required.

Four integration components:

Component A - Execution Logs On every DCA swap execution: JSON record serialized (planId, tokenIn/Out, amountIn/Out, executionPrice, slippageObserved, txHash, chainId), encrypted client-side, uploaded to Sia via POST /api/worker/objects/{bucket}/{key}. Sia Merkle root stored on-chain as part of the execution event.

Component B - Plan Registry Backup On every plan create or update: full plan object (token pair, frequency, budget, slippage, filters) written to a per-user Sia bucket via renterd Worker. Encrypted with user-derived keys, only the plan owner can decrypt. Enables cross-chain portability and disaster recovery independent of Osiris infrastructure.

Component C - Analytics Layer All analytics writes (vault balances, cumulative DCA metrics, per-cycle data, cross-chain summaries) routed to Sia S3 buckets, replacing the centralized database backend. Exposed via an S3-compatible endpoint for dashboards and third-party consumers using standard HTTP.

Component D - Cross-Chain State Snapshots At ETH↔Base cross-chain execution coordination points: execution state checkpointed to Sia with a timestamp and hash commitment. A failed Sia write does not block on-chain execution, it is logged and retried asynchronously. Enables relay failure recovery without a centralized recovery service.

Security model: All data is encrypted client-side with user-derived keys before upload — Sia hosts never access plaintext. On-chain anchoring of the Sia Merkle root in each Osiris execution event provides tamper-proof integrity verification. Reed-Solomon erasure coding (30 segments, 10 required for recovery) handles host redundancy automatically via renterd Autopilot.

Timeline and Milestones

Month 1 — Foundation

  • Deploy and configure renterd node
  • Build Sia bridge service: event listener → JSON serialization → renterd Worker upload
  • Define per-user bucket schema and encryption key derivation
  • Integrate Component A: execution log storage live on Arbitrum mainnet
  • Internal testing: upload/download round-trip validated, Merkle root anchored on-chain

Validation: Arbitrum transaction hashes with Sia content hash in event data, publicly verifiable. Round-trip test results committed to GitHub.

Month 2 — Data Layer

  • Integrate Component B: plan backup on every create/update event
  • Integrate Component C: analytics layer live, centralized DB writes replaced with Sia S3 writes
  • Deploy S3-compatible dashboard endpoint
  • Publish public API documentation
  • Complete encryption model security review

Validation: Plan creation events trigger confirmed Sia backup via renterd. Dashboard endpoint functional and publicly documented. Security review report committed to repo.

Month 3 — Cross-Chain & Production

  • Integrate Component D: cross-chain state snapshots for ETH↔Base execution flows
  • Activate Base mainnet deployment with Token routing (contingent on testnet validation — see Risks)
  • Load test Sia storage layer under simulated high-frequency execution
  • Publish full integration documentation, all code open-sourced under MIT License

Validation: Base execution events with Sia snapshot hashes on-chain. Load test report published. GitHub repo fully public with MIT license applied.

Risks

renterd API changes during development Mitigation: Pin to a specific renterd version. Bridge service built with an abstraction layer isolating the renterd API surface, updates require only a single adapter change.

Token routing activation dependency for Base Mitigation: Component A (Arbitrum execution logs) is fully independent of Base activation. Components D and Base deployment are scoped to Month 3 and activate only after testnet validation confirms Token routing is stable. Month 1 and 2 deliverables are unblocked regardless.

Cross-chain state coordination complexity Mitigation: Sia write failures do not block on-chain execution. The snapshot mechanism is additive and fail-safe, failed writes are logged and retried asynchronously.

Sia host availability Mitigation: renterd Autopilot handles contract formation, renewal, and host selection automatically. Reed-Solomon (30 pieces, 10 required) provides redundancy across independent hosts without manual intervention.

Dev team bandwidth Mitigation: Core smart contracts are already deployed and require no modification. Integration scope is confined to the application layer. Month 1 can realistically be completed in 2–3 weeks, leaving buffer for blockers.

Budget

Total: $10,000 USD — disbursed $3,333/month over 3 months

  • Month 1 — Bridge service development, renterd integration, Component A: $4,000
  • Month 2 — Analytics layer, plan backup module, S3 endpoint, security review: $4,000
  • Month 3 — Cross-chain snapshots, Base activation, load testing, open-source release: $2,000

All three months represent focused, full-time development on a well-scoped integration. Core contracts are already deployed, no smart contract rebuild required.

Open Source

All code produced under this grant will be released under MIT License, compliant with the Sia Foundation’s licensing requirements (effective November 28, 2025). This covers the bridge service, integration schemas, data models, and any smart contract modifications. API documentation released under CC-BY 4.0. No closed-source components. All deliverables committed to GitHub - Le-Caignec/Osiris · GitHub at the completion of each milestone.

Reporting

Monthly progress reports will be posted in this thread and in the Grants category of the forum. Each report will include:

  1. Milestone status vs. the timeline above
  2. GitHub commits / PRs for the period
  3. On-chain evidence of Sia activity (transaction hashes, Sia contract IDs)
  4. Any blockers and how they were resolved
  5. Planned work for the following month

Why This Matters for Sia

DeFi protocols generate large volumes of structured data, execution logs, user configurations, state transitions, analytics streams. Nearly all of it lives in centralized databases today. Osiris integrating Sia is the first production instance of a DeFi protocol replacing its centralized data backend with Sia. The open-source bridge service becomes a reusable template for others doing the same. Every DCA execution stored to Sia is a concrete, on-chain example of user-owned financial data: a direct expression of the Foundation’s mission.

Happy to answer any questions here or on Telegram (@dyonisos10).

2

Hello, welcome.

renterd-projects are currently on freeze as indexd is around the corner. It is best you wait for that.

Kudos.

1 Like
3

Hello @dyonisos10 - welcome to the Sia Community! As pcfreak30 mentioned, we’re awaiting indexd at the end of the month instead of encouraging projects centered on renterd at this stage. We don’t want to set projects up to start on something they’d have to pivot away from later.

I’ll keep this proposal in the ‘Proposed’ category for you to return to for an update once indexd is available. When it is ready for review again, please tag me.

Thank you for your patience & understanding.

4

Hi @dyonisos10 - the new guidelines have been posted:

After reviewing, please tag me to either look over your edited proposal or to let me know if this proposal should be moved to ‘Inactive.’

5

Hi @mecsbecs,

Thanks a lot for the update and for sharing the new guidelines, the clarity is very helpful.

Yes, I’m still actively working on this. I’ve read the new framework carefully and I already have a substantially reframed version of the proposal in mind that fits the “Building with SDKs” theme (shifting the deliverable to a reusable Sia Data Layer SDK for DeFi protocols, with Osiris as the reference implementation).

Before tagging you with the edited version, I’ve just sent an email to [email protected] with a couple of specific questions to make sure the reframed scope is eligible under the new rules, I’d rather clear those up first than waste the committee’s time. Aiming to get everything ready well ahead of the April 22 deadline.

Thanks again for the patience, more very soon.

6

This is an edited version of the original proposal submitted March 10, 2026 (“Osiris Protocol - Decentralized Data Layer for On-Chain DCA Automation”), reworked in accordance with the new funding guidelines published April 10, 2026. Scope eligibility under the new guidelines has been pre-confirmed by @mecsbecs via email. The original proposal was renterd-centric; this edited version pivots the deliverable to a reusable, SDK-native template built on the Sia Storage SDK and indexd, with Osiris as the reference implementation rather than the end goal.

Summary

This grant funds a reusable, MIT-licensed Sia Data Layer SDK for DeFi protocols, an open-source template that lets any DeFi protocol replace its centralized data backend (PostgreSQL, Supabase, hosted indexers, etc.) with Sia, using the official Sia Storage SDK and indexd.

The SDK is the deliverable. Osiris Protocol serves as the reference implementation, the first production DeFi protocol to run on the SDK, giving the ecosystem a working, on-chain-verifiable case study on day one.

This is not a grant to fund Osiris itself. Osiris’s smart contracts are already deployed; the core DCA logic and multi-chain execution are outside the grant scope. The grant funds the Sia-side building block that Osiris, and any other DeFi protocol that comes after, plugs into.

Theme Alignment: Building with SDKs

The proposal fits “Building with SDKs” at every layer:

  • Built natively on the official Sia Storage SDK (Go) for all write paths

  • indexd used for object management and discovery on the read path

  • Deliverable is itself a higher-level SDK that other builders consume

  • Follows the precedent set by S5, which was built on the indexd SDK (sia-sdk-rs) - this proposal extends that pattern from content-addressed storage into the DeFi data-layer vertical

What Osiris Is (Brief Context)

Osiris is a non-custodial smart contract protocol for programmable Dollar-Cost Averaging (DCA). Not a DEX, not a trading UI, not a yield product, an automation primitive: users deposit assets into a vault, configure a DCA plan on-chain (token pair, frequency, per-cycle budget, slippage constraints), and the protocol executes automatically without any keeper, API key, or centralized component.

Execution uses Reactive Network’s Reactive Smart Contracts (RSCs) - an inversion-of-control pattern where contracts subscribe to on-chain events and react autonomously, rather than being triggered by off-chain cron jobs or bots. This makes Osiris the only cross-chain DCA protocol where the automation logic itself is fully on-chain and trustless.

Everything above is already deployed and is out of the scope of this grant. Osiris’s role here is exclusively to serve as the reference implementation that consumes and validates the SDK this grant funds.

The Problem This Grant Solves

DeFi protocols generate some of the highest volumes of structured, small-file, high-frequency data in Web3: execution logs, user configurations, state transitions, analytics streams. Nearly 100% of this data lives in centralized databases today (self-hosted Postgres, Supabase, hosted The Graph endpoints, private S3 buckets).

This is an architectural inconsistency for a category whose entire value proposition is user ownership: users own the assets on-chain but never own the history of their own activity. The data is held by the protocol, which can be censored, taken offline, or silently modified.

No production-grade template exists for migrating this workload to Sia. Individual S3-compatible integrations exist, but none are designed for the specific shape of DeFi data (many small files per user, high append frequency, per-user encryption, on-chain hash anchoring). That gap is what this SDK closes.

Osiris volunteers as the first public case study because its design makes the inconsistency unavoidable: its execution, vaulting, and plan management are non-custodial and trustless, but its data history is not. Closing the gap on Osiris produces a blueprint every other DeFi protocol can copy.

High-Level Architecture

osiris-architecture-diagram
osiris-architecture-diagram1100×780 6.58 KB

How We Use Sia

The integration operates entirely at the application layer. No changes are required to any deployed smart contract. The Sia-side work is pure SDK storage.

Component A - Execution Logs (SDK write path). On every DCA swap execution, a JSON record (planId, tokenIn/Out, amountIn/Out, executionPrice, slippageObserved, txHash, chainId) is serialized, encrypted client-side with user-derived keys, and written to Sia through the Sia Storage SDK. A content hash of the Sia object is emitted on-chain as part of the execution event for tamper-proof verification.

Component B - Plan Registry Backup (SDK write path). On every plan create or update, the full plan object is encrypted client-side and written to a per-user Sia bucket via the Sia Storage SDK. Only the plan owner can decrypt. Enables cross-chain portability and disaster recovery independent of Osiris infrastructure.

Component C - Analytics Layer (SDK write + indexd read path). All analytics writes (vault balances, cumulative DCA metrics, per-cycle data, cross-chain summaries) go through the SDK to Sia, replacing Osiris’s centralized database backend. Exposed to downstream consumers via an S3-compatible read endpoint and indexd-based discovery, dashboards and third parties use standard HTTP with no Sia-specific client code.

Component D - Cross-Execution State Snapshots (SDK write path). At cross-execution coordination points, state is checkpointed to Sia with a timestamp and hash commitment. Sia write failures are additive and fail-safe: they do not block on-chain execution, they are logged and retried asynchronously. Enables relay failure recovery without a centralized recovery service.

Security model. All data is encrypted client-side with user-derived keys before upload, Sia hosts never access plaintext. On-chain anchoring of the Sia content hash provides tamper-proof integrity verification. Reed-Solomon erasure coding (30 pieces, 10 required for recovery) handles host redundancy automatically via renterd Autopilot.

Timeline and Milestones

Month 1 - SDK Foundation and First Integration

  • Scaffold the Sia Data Layer SDK on top of the official Sia Storage SDK

  • Define the many-small-files bucket schema and per-user encryption key derivation

  • Implement retry / resume / schema-versioning primitives

  • Wire Osiris execution-log writes (Component A) through the SDK - first real integration on Arbitrum mainnet

  • Internal testing: encrypted write → decrypted read round-trip validated, content hash anchored on-chain

Validation: Arbitrum transaction hashes with Sia content hashes in event data, publicly verifiable. Round-trip test suite committed to GitHub. SDK published as a tagged pre-release.

Month 2 - Data Layer Completion and Public SDK v1.0

  • Wire plan backup writes (Component B) through the SDK

  • Wire analytics writes (Component C) through the SDK; Osiris retires its centralized database dependency

  • Deploy S3-compatible read endpoint; integrate indexd-based discovery

  • Publish v1.0 of the SDK with full public API documentation

  • External review of the encryption model

Validation: Plan creation events trigger confirmed Sia-backed writes. Osiris analytics dashboard live against the Sia-backed endpoint. SDK v1.0 published under MIT. Security review report committed to repo.

Month 3 - Production Hardening and Template Release

  • Implement cross-execution state snapshots (Component D)

  • Load test under simulated high-frequency DeFi write volumes

  • Publish the standalone “DeFi → Sia migration guide” and adoption kit (example repos, integration checklist)

  • Final documentation pass; release the reusable template

Validation: Load test report published. Template repo live and linkable from the Sia community page. GitHub repo fully public with MIT license applied throughout.

Risks

Sia SDK evolution during development. Mitigation: pin a specific SDK version; introduce a thin adapter layer so SDK updates become a single-file change downstream. Already a standard practice in the Osiris codebase.

indexd API surface still maturing. Mitigation: SDK is usable with or without indexd from day one. indexd integration is added as an optional discovery path once its API surface stabilizes, not a blocking dependency on any milestone.

Scope creep into non-Sia blockchain complexity. Mitigation: explicit scope boundary (this document). Osiris’s multi-chain execution is pre-existing and out of scope. The grant covers only the Sia-side SDK, bridge service, and template.

Sia host availability. Mitigation: renterd Autopilot handles contract formation, renewal, and host selection automatically. Reed-Solomon (30 pieces, 10 required) provides redundancy across independent hosts without manual intervention.

Dev team bandwidth. Mitigation: Osiris core contracts are already deployed, no smart-contract rebuild. Integration scope is confined to the application layer. Month 1 can realistically be completed in 2–3 weeks, leaving buffer.

Budget

Total: $10,000 USD: disbursed $3,333/month over 3 months

  • Month 1 - $4,000: SDK core, bucket schema, encryption key derivation, Component A integration

  • Month 2 - $4,000: Components B and C, S3 read endpoint, indexd integration, public SDK v1.0 release, security review

  • Month 3 - $2,000: Component D, load testing, migration guide, adoption kit

Budget reflects focused, full-time development on a well-scoped, SDK-first integration. Osiris core smart contracts are already deployed, no smart-contract rebuild required.

Post-Grant Plan

Technical roadmap post-grant. The SDK continues as a standalone open-source project independent of Osiris:

  1. Additional DeFi protocol reference integrations (perps, lending, stableswap) — actively recruiting early adopters from existing conversations in the Reactive Network ecosystem

  2. Rust port of the SDK, following the precedent of sia-sdk-rs

  3. Deeper indexd integration as its API surface matures

  4. Contribution back to the Sia Storage SDK itself where the bridge work surfaces reusable primitives

Sustainability. Two-path sustainability by design:

  1. Osiris Protocol implements a small protocol fee on DCA cycle executions, on-chain and transparent, which accrues to the core team and provides durable post-grant maintenance runway for the reference integration.

  2. The SDK itself is MIT-licensed infrastructure. It is not financially tied to Osiris: once v1.0 is published, it is usable as-is by any DeFi project, with pinned Sia Storage SDK and indexd versions, and can be maintained by community contributions. A deliberate design choice - the SDK’s long-term survival does not depend on Osiris’s commercial outcomes.

Open Source

All code produced under this grant will be released under MIT License, compliant with the Sia Foundation’s licensing requirements (effective November 28, 2025). This covers the SDK, the bridge service, integration schemas, and data models. API documentation released under CC-BY 4.0. No closed-source components. All deliverables committed to https://github.com/Le-Caignec/Osiris (the SDK published as a separate, top-level package within the repo, or extracted to a dedicated repo if preferred by the committee).

Why This Matters for Sia

DeFi is one of the largest generators of structured, user-specific, high-frequency data in Web3, and it is today entirely absent from the Sia ecosystem. This is not because DeFi projects don’t care about decentralization of data, they demonstrably do on every other layer, but because the migration path is undocumented and the template doesn’t exist.

This grant changes that in three compounding ways:

  1. A concrete public template. “How to replace your DeFi protocol’s centralized data backend with Sia” becomes a documented, forkable, load-tested pattern.

  2. A live production case study. Osiris running on Sia from Month 1 onward is a visible, verifiable, on-chain example that the pattern works in production, not a proof of concept.

  3. A repeatable motion. Every additional DeFi protocol that adopts the SDK post-grant multiplies Sia’s footprint in a vertical where data volumes are large, users are sticky, and “user-owned data” is a value already being actively marketed to end users.

Every DCA execution stored to Sia becomes a concrete, on-chain example of user-owned financial data, a direct expression of the Foundation’s mission, delivered at the data layer by a protocol whose users already expect and demand ownership at every other layer.

Happy to answer any questions in this thread or on Telegram (@dyonisos10). Thank you to @mecsbecs and the Grants Committee for the clear new framework and the email pre-clarification that made this reframing possible.

7

Hello…

Um… there is some confusing things in this post.

  • First, you are still referencing renterd and that alone will put this as DOA?
  • Second, what SDK’s are you referring to? The Sia SDK primary languages are Go and Rust, with all others being FFI with rust or wasm. Theres nothing to actually port?
  • You cannot use the the sia sdk without the use of of indexd?
  • I would be very interested how how indexd accounts get made assuming you are even designing for indexd here as that both uses a seed phrase and requires approval from an indexer via the user (a SSO more/less).

So far, what I understand is you want to use Sia as a means to store smart contract protocol related data… which is fine in concept, but the rest is confusing and I think has inaccuracies.

I would recommend you re-review your proposal and try to clarify the user account stuff more with Sia which would also be a security/user safety thing.

Thanks.

8

This is an edited version of the original proposal submitted March 10, 2026, substantially reworked in line with the new funding guidelines published April 10, 2026, and further revised based on technical feedback from @pcfreak30 in this thread.

Summary

This grant funds a reusable, MIT-licensed Sia Data Layer SDK for DeFi protocols, an open-source template that lets a DeFi protocol replace its centralized data backend (PostgreSQL, Supabase, hosted indexers, etc.) with Sia, using the official Sia Storage SDK (Go) and indexd.

The SDK is the deliverable. Osiris Protocol serves as the reference implementation, the first production DeFi protocol to run on the SDK, giving the ecosystem a working, on-chain-verifiable case study on day one.

This is not a grant to fund Osiris itself. Osiris’s smart contracts are already deployed; the core DCA logic and multi-chain execution are outside the grant scope. The grant funds the Sia-side building block that Osiris, and any other DeFi protocol that comes after, plugs into.

Theme Alignment: Building with SDKs

The proposal fits “Building with SDKs” end to end:

  • Bridge service built natively on the official Sia Storage SDK (Go)

  • indexd used as the object-management layer (required, not optional) and as the discovery surface for downstream reads

  • Deliverable is itself a higher-level SDK that other builders consume

  • Follows the precedent set by S5, which was built on the indexd SDK, this proposal extends that pattern into the DeFi data-layer vertical

No renterd Worker API surface is in scope.

What Osiris Is (Brief Context)

Osiris is a non-custodial smart contract protocol for programmable Dollar-Cost Averaging (DCA). Not a DEX, not a trading UI, not a yield product, an automation primitive: users deposit assets into a vault, configure a DCA plan on-chain (token pair, frequency, per-cycle budget, slippage constraints), and the protocol executes automatically without any keeper, API key, or centralized component.

Execution uses Reactive Network’s Reactive Smart Contracts (RSCs), contracts subscribe to on-chain events and react autonomously, rather than being triggered by off-chain cron jobs or bots. This makes Osiris the only cross-chain DCA protocol where the automation logic itself is fully on-chain and trustless.

Everything above is already deployed and is out of scope of this grant. Osiris’s role here is exclusively to serve as the reference implementation that consumes and validates the SDK this grant funds.

The Problem This Grant Solves

DeFi protocols generate some of the highest volumes of structured, small-file, high-frequency data in Web3: execution logs, user configurations, state transitions, analytics streams. Nearly 100% of this data lives in centralized databases today (self-hosted Postgres, Supabase, hosted indexers, private S3 buckets).

This is an architectural inconsistency for a category whose value proposition is user ownership: users own the assets on-chain but never own the history of their own activity. The data is held by the protocol, which can be censored, taken offline, or silently modified.

No production-grade template exists for migrating this workload to Sia. The specific shape of DeFi data (many small files per user, high append frequency, per-user encryption, on-chain hash anchoring) requires a focused effort on top of the Sia Storage SDK and indexd. That gap is what this SDK closes.

Osiris volunteers as the first public case study because its design makes the inconsistency unavoidable.

High-Level Architecture

osiris-architecture-diagram
osiris-architecture-diagram1100×820 7 KB

User Account Architecture and Safety Model

This is the single most important design decision in the proposal. It was raised directly in thread feedback and deserves an explicit section.

The indexd account model

indexd uses a seed-phrase-backed account model. An application connects to a user’s indexd account through a connect key (app password) which the user must approve via a URL-based approval flow (effectively an SSO-like authorization step) and per-app quotas and pinned-data scope are enforced on the indexd side.

A naive design that asked every Osiris DCA user to (1) create an indexd account, (2) back up a second seed phrase in addition to their EVM wallet, (3) perform the indexd app-approval flow, and (4) keep that account alive for every DCA cycle would defeat the “set and forget” promise of Osiris and introduce real user-safety risk (extra seed phrase to lose). That design is not what this grant proposes.

In scope of this Small Grant - Model A: service-scoped indexd account

The grant scope deliberately adopts a service-scoped indexd account model, with strict user-safety guarantees provided at the encryption layer:

  • Osiris operates a single indexd account dedicated to the bridge service, with its own connect key and per-app quotas configured through indexd.

  • All DCA-related data is written within that account’s scope.

  • Each user’s data is encrypted client-side before it ever reaches the bridge, using an encryption key deterministically derived from a signed message produced by the user’s EVM wallet. The user never has to manage a second seed phrase; the EVM wallet they already use for Osiris is sufficient to derive and recover their encryption key.

  • The bridge service therefore cannot read user data in plaintext, ever. Even a fully compromised bridge leaks only ciphertext.

  • The bridge’s own indexd account credentials are stored in a standard secret-management setup (out-of-the-box for a production DeFi backend) and are rotatable.

Honest tradeoff of Model A

The indexd account is owned by Osiris in this model. If Osiris (the project) disappears, the effects are:

  • Encrypted data on Sia survives. Sia storage is not dependent on Osiris.

  • User encryption keys survive. They are derivable on demand from the user’s EVM wallet, no additional secret to preserve.

  • The indexd account binding is lost. Rebinding the surviving encrypted data to a new indexd account is a documented recovery procedure that the grant will publish as part of Month 2 docs.

This is a meaningful honest tradeoff and is stated explicitly so the committee and reviewers can evaluate it on its merits.

Out of scope, pitched as post-grant direction - Model B: per-user indexd account

The trust-minimized long-term target is a per-user indexd account model, in which each user is the direct indexd account holder and Osiris is a connected app via the standard indexd app-approval flow.

Doing this well — without adding a second seed phrase that users must manage — requires solving deterministic derivation of an indexd seed from the user’s EVM wallet signature (analogous to Sign-In With Ethereum, but producing a BIP-39 seed domain-separated for indexd). That is a non-trivial cryptographic and UX design effort that deserves focused attention rather than being buried inside a Small Grant. It is proposed here as an explicit post-grant direction and a candidate for a future Standard Grant, so that the cryptographic design, the attestation flow, and the wallet-UX trade-offs can be reviewed and discussed on their own merits with the committee and community.

How We Use Sia (Component Breakdown)

All write paths use the official Sia Storage SDK (Go) and operate through indexd against the service-scoped account described above. All user-facing payloads are encrypted client-side with EVM-wallet-derived keys before upload.

Component A - Execution logs. On every DCA swap, a JSON record (planId, tokenIn/Out, amountIn/Out, executionPrice, slippageObserved, txHash, chainId) is encrypted and written via the SDK. A content hash of the resulting object is emitted on-chain as part of the execution event for tamper-proof integrity verification.

Component B - Plan registry backup. On every plan create or update, the full plan object is encrypted and written via the SDK, scoped per user. Only the plan owner can decrypt. Enables cross-chain portability and disaster recovery independent of Osiris’s own application-layer infrastructure.

Component C - Analytics layer. Vault balances, cumulative DCA metrics, per-cycle data, and cross-chain summaries are written through the SDK, replacing Osiris’s current centralized database backend. Exposed to downstream consumers via indexd-based discovery and an S3-compatible HTTP veneer, dashboards and third parties use standard HTTP with no Sia-specific client code.

Component D - Cross-execution state snapshots. At cross-execution coordination points, state is checkpointed via the SDK with a timestamp and hash commitment. Sia write failures are additive and fail-safe: they do not block on-chain execution, they are logged and retried asynchronously.

Timeline and Milestones

Month 1 - SDK foundation, indexd account model, first integration

  • Scaffold the Sia Data Layer SDK on top of the official Sia Storage SDK (Go)

  • Implement the service-scoped indexd account bootstrap: connect flow, app-password storage, per-app quota configuration

  • Implement the EVM-wallet-signature-derived client-side encryption key derivation (domain-separated, with documented security argument)

  • Define the many-small-files bucket schema, retry / resume / schema-versioning primitives

  • Wire Osiris execution-log writes (Component A) through the SDK, first real integration on Arbitrum mainnet

Validation: Arbitrum transaction hashes with Sia content hashes in event data, publicly verifiable. Encrypted write → decrypted read round-trip test suite committed to GitHub. SDK published as a tagged pre-release.

Month 2 - Data layer completion, security review, public SDK v1.0

  • Wire plan backup writes (Component B) through the SDK

  • Wire analytics writes (Component C) through the SDK; Osiris retires its centralized database dependency

  • Deploy the S3-compatible read veneer on top of indexd-based discovery

  • Publish v1.0 of the SDK with full public API documentation, including the account architecture writeup and the documented recovery procedure for the Model-A tradeoff

  • External review of the encryption model and the account architecture

Validation: Plan creation events trigger confirmed Sia-backed writes. Osiris analytics dashboard live against the Sia-backed endpoint. SDK v1.0 published under MIT. Security review report committed to repo.

Month 3 - Hardening, Component D, template release, post-grant direction writeup

  • Implement cross-execution state snapshots (Component D)

  • Load test under simulated high-frequency DeFi write volumes

  • Publish the standalone “DeFi → Sia migration guide” and adoption kit (example repos, integration checklist)

  • Publish a focused technical note on the per-user indexd account direction (Model B) as an open design problem and candidate follow-on work

Validation: Load test report published. Template repo live and linkable from the Sia community page. Model-B technical note committed to repo as a starting point for post-grant discussion.

Risks

Sia Storage SDK evolution during development. Mitigation: pin a specific SDK version; thin adapter layer so SDK updates become a single-file change downstream.

indexd API surface still maturing. Mitigation: design the Data Layer SDK’s indexd interaction behind a small internal interface so that indexd API changes are absorbed in one module. Coordinate with the indexd maintainers on any breaking changes observed during the grant period.

Service-scoped indexd account single-point-of-failure. Mitigation: standard secret-management for the account credentials; document the user recovery procedure (re-decryption of surviving Sia-resident ciphertext under a fresh indexd account) as part of Month 2 docs; pitch the per-user indexd account model as post-grant direction.

Scope creep into non-Sia blockchain complexity. Mitigation: explicit scope boundary (this document). Osiris’s multi-chain execution is pre-existing and out of scope.

Dev team bandwidth. Mitigation: Osiris core contracts are already deployed. Integration scope is confined to the application layer. Month 1 can realistically be completed in 2–3 weeks, leaving buffer.

Budget

Total: $10,000 USD — disbursed $3,333/month over 3 months

  • Month 1 - $4,000: SDK core, indexd account bootstrap, wallet-signature-derived encryption key derivation, bucket schema, Component A

  • Month 2 - $4,000: Components B and C, S3-compatible read veneer, public SDK v1.0, security review, account architecture documentation

  • Month 3 - $2,000: Component D, load testing, migration guide, Model-B technical note

Budget reflects focused, full-time development on a well-scoped, SDK-first integration. Osiris core smart contracts are already deployed, no smart-contract rebuild required.

Post-Grant Plan

Technical roadmap post-grant.

  1. Additional DeFi protocol reference integrations (perps, lending, stableswap), actively engaging early adopters from the Reactive Network ecosystem

  2. Pitching a Standard Grant follow-on focused specifically on the per-user indexd account model (Model B above), including the cryptographic design for deterministic indexd-seed derivation from EVM-wallet signatures

  3. Contribution back to the Sia Storage SDK and indexd where the bridge work surfaces reusable primitives

Communication channels. Osiris maintains a public Telegram today (@dyonisos10). Within Month 1 we stand up a dedicated Discord and a BlueSky presence covering both Osiris updates and SDK-specific developer content. Monthly public developer updates. Talks and workshops at DeFi developer venues positioning Sia as the default data layer for on-chain automation.

Sustainability, dual-path.

  1. Osiris Protocol implements a small on-chain protocol fee on DCA cycle executions (transparent, auditable on-chain), which accrues to the core team and provides post-grant maintenance runway for the reference integration.

  2. The SDK itself is MIT-licensed infrastructure. It is not financially tied to Osiris: once v1.0 is published, it is usable as-is by any DeFi project, with pinned Sia Storage SDK and indexd versions, and can be maintained by community contributions. A deliberate design choice, the SDK’s long-term survival does not depend on Osiris’s commercial outcomes.

Open Source

All code produced under this grant will be released under MIT License, compliant with the Sia Foundation’s licensing requirements (effective November 28, 2025). This covers the SDK, the bridge service, integration schemas, and data models. API documentation released under CC-BY 4.0. No closed-source components. All deliverables committed to https://github.com/Le-Caignec/Osiris (the SDK published as a dedicated package within the org, extractable to a standalone repo if preferred by the committee).

Why This Matters for Sia

DeFi is one of the largest generators of structured, user-specific, high-frequency data in Web3, and it is today entirely absent from the Sia ecosystem. Not because DeFi projects don’t value user-owned data (they do on every other layer), but because the migration path is undocumented and the template does not exist.

This grant changes that in three compounding ways:

  1. A concrete public template. “How to replace your DeFi protocol’s centralized data backend with Sia” becomes a documented, forkable, load-tested pattern, with the indexd account model explicitly addressed.

  2. A live production case study. Osiris running on Sia from Month 1 onward, a visible, verifiable, on-chain example that the pattern works in production, not a proof of concept.

  3. A repeatable motion. Every additional DeFi protocol that adopts the SDK post-grant multiplies Sia’s footprint in a vertical where data volumes are large, users are sticky, and user-owned data is a value already being actively marketed to end users.

Every DCA execution stored to Sia becomes a concrete, on-chain example of user-owned financial data, a direct expression of the Foundation’s mission, delivered at the data layer by a protocol whose users already expect and demand ownership at every other layer.

--

Thanks to @mecsbecs and the Grants Committee for the clear new framework and the email pre-clarification, and to @pcfreak30 for the technical pushback in this thread that directly shaped the account-architecture section of this revision. Happy to answer further questions here or on Telegram (@dyonisos10).

9

Hi @dyonisos10 - thank you for making these changes. This will be brought before the Committee next week.

10

Hello @dyonisos10,

The Committee was unfortunately unable to get to your proposal during today’s meeting. Your proposal has now been slotted for review during the next meeting on May 12th.

Thank you for your patience.

11

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee is requesting some additional information regarding your proposal:

  • The GitHub repository provided is for the Osiris Protocol and does not include the grant proposer as a contributor, so proof of previous work is missing from the proposal. Please provide proof of previous work specific to your developer experience to address the technical feasibility of this project.

  • There are technical concerns with the proposal: a) operating a single indexd account for the bridge service owned by Osiris represents a centralized system; b) indexd seed phrases are already domain separated, which impacts the outlined indexd account model thinking. Please update the most recent version of the proposal to address these concerns.

  • The Committee finds the “Out of scope - Model B: per-user indexd account” the more compelling direction for the project than the Model A proposed. Would it be possible to execute this project under Model B?

We’ll keep this in the Proposed section while we await your response. Thanks again for your proposal.

12

Hello @dyonisos10 - since this proposal is technically still open, as the Committee was awaiting further information, I wanted to inform you we are pausing the intake of new grants into the Grants Program for a couple of months to prioritize the completion of our long term program strategy. Project ideas are always welcome in the ‘Ideas’ subcategory of the Forum, but new proposals will not be reviewed during this pause.

The pause will be effective immediately until end of Q3.

More information can be found here: