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:
- Milestone status vs. the timeline above
- GitHub commits / PRs for the period
- On-chain evidence of Sia activity (transaction hashes, Sia contract IDs)
- Any blockers and how they were resolved
- 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).