Standard Grant: Depass - Decentralized & User-Controlled Password Manager

Grant Proposal: Depass - Decentralized & User-Controlled Password Manager

1. Introduction

  • Project Name: Depass: Decentralized & User-Controlled Password Manager

  • Name of the organization or individual submitting the proposal: Zrow

  • Describe your project.
    Depass will be designed as a highly secure, user-centric password management desktop application focused on privacy, data ownership, and flexibility. It empowers users by providing robust tools for generating, storing, and organizing sensitive credentials within an encrypted, decentralized environment. The core value proposition lies in giving users complete control over their data through two deployment models: a fully self-hosted option for maximum sovereignty, and an optional, convenient cloud service built on the same security principles.

    Key features include:

    • Hierarchical Credential Organization: Users can create a nested folder structure (tree view) to logically organize their password “cards.”
    • Comprehensive Credential Cards: Each card stores essential information: Title, URL, Username, Password, TOTP Secret (for 2FA), Date Modified, and free-form Notes.
    • Integrated TOTP Authenticator: Securely store and generate Time-based One-Time Passwords (2FA codes) directly within the application, eliminating the need for a separate authenticator app for stored accounts.
    • Client-Side Encryption: All user data is encrypted and decrypted locally on the user’s device using robust cryptographic methods. The backend service and storage layer only ever handle encrypted blobs, ensuring zero-knowledge architecture.
    • Decentralized Storage Backend (Initial Focus: S5): User vaults (encrypted data blobs) will be stored on the S5 decentralized storage network. This enhances data resilience, censorship resistance, and fundamentally places data control in the user’s hands, away from centralized providers.
    • Initial Platform: Desktop Application: The first implementation will be a cross-platform desktop application built using Electron.js, providing a native experience on Windows, Linux, MacOs.

  • Who benefits from your project?
    Depass primarily benefits:

    1. Privacy-Focused Individuals: Users seeking alternatives to traditional password managers that store sensitive vaults on company-controlled servers. Depass offers verifiable data ownership and control.
    2. Technically Proficient Users & Self-Hosters: Individuals who prefer running their own infrastructure gain a powerful, open-source password manager they can deploy and manage entirely, ensuring maximum privacy and autonomy.
    3. Security-Conscious General Users: Provides a user-friendly desktop interface combined with strong encryption and decentralized storage principles, offering a compelling blend of security and usability.
    4. The Decentralized Ecosystem: Demonstrates a practical, high-value use case for decentralized storage networks like S5, contributing to the ecosystem’s growth and adoption.
  • How does the project serve the Foundation’s mission of user-owned data?
    Depass is fundamentally aligned with the mission of user-owned data. By leveraging client-side encryption and decentralized storage (S5):

    1. Eliminates Centralized Trust: Users do not need to trust a central company with their encrypted vault. The data resides on a distributed network.
    2. Direct User Control: Access is controlled solely by the user’s keys/seed phrase. Only the user can decrypt their data.
    3. Self-Hosting Reinforces Ownership: The option to self-host provides the ultimate level of data sovereignty, where the user controls both the software and the storage interaction.
    4. Open Source Transparency: The code’s open nature allows anyone to audit the security mechanisms and verify that data handling aligns with user-ownership principles.
  • 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

2. Development Information

  • Will all of your project’s code be open-source?
    Yes, the entire codebase for the Depass desktop application and any associated backend components developed under this grant will be released under a permissive open-source license (MIT).
  • Leave a link where code will be accessible for review.
    Repository will be created upon grant approval and linked in the first progress report.
  • Do you agree to submit monthly progress reports?
    Yes, we commit to submitting detailed monthly progress reports directly in the forum. These reports will cover achievements against milestones, challenges faced, solutions implemented, and plans for the subsequent month. Furthermore, each major milestone completion will be accompanied by a video demonstration showcasing the results (or a code execution walkthrough if a UI demo is not applicable for that specific milestone).
  • Demo Day:
    Upon completion of the 3-month grant period, we will provide comprehensive compilation instructions for the software application, accompanied by a detailed video demonstration illustrating the step-by-step build process and utilization procedures.

3. Grant Specifics

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

    • Total Amount Requested: $24,000 USD

    • Duration: 3 Months

    • Monthly Payout: $8,000 USD

    • Justification: The requested funds ($24,000 over 3 months) are allocated to cover the focused development effort required to design, build, and test the core Depass desktop application, including its features and integration with the S5 decentralized storage network. This budget represents the compensation for the primary development work needed to achieve the milestones outlined below.

    • Budget Breakdown (Estimated):

      • Personnel (Development Effort - 3 months): $23,000 (Covers architecture design, UI/UX implementation, Electron integration, app development, S5 integration, testing)
      • Infrastructure & Contingency: $1,000 (Infrastructure & Testing Costs: $1,000 (Cloud services for development/builds, hardware rental for maintaining the S5 and Sia networks, potential minor tooling/library expenses, to address unforeseen technical challenges or minor scope adjustmentss)
      • Total: $24,000
  • Timeline with measurable objectives and goals

    • Total Project Duration: 3 Months

    • Milestones:

      • Month 1: Foundational Architecture & Core Client Logic

        • Objectives: Design a universal application architecture adaptable for future browser extension and mobile versions. Define detailed data structures for credentials and folders. Implement core client-side logic for serialization/deserialization, robust encryption/decryption routines. Develop the initial functional prototype page/view for adding/editing password cards (using mock storage initially).
        • Deliverables: Architecture design document. Defined data structure specifications. Functional encryption/decryption module. Basic UI prototype demonstrating card creation/editing within a test environment. Code repository access.
        • Verification: Code review of architecture and core logic. Demonstration video showcasing the pass card creation/editing prototype and data encryption process.
      • Month 2: Desktop Application Build & Feature Implementation

        • Objectives: Integrate the core logic into an Electron.js desktop application shell. Implement the visual design and user interface. Develop the hierarchical folder structure (tree view) for organizing cards, including grouping and sorting capabilities. Implement the secure password generator feature. Integrate TOTP generation logic based on stored secrets.
        • Deliverables: Functional cross-platform Electron desktop application (alpha version). Implemented folder tree UI and logic. Working password generator module. Functional TOTP code generation for stored credentials.
        • Verification: Demonstration video showcasing the desktop application UI, folder management, password generation, and TOTP display. Code review. Internal usability testing.
      • Month 3: S5 Integration & Comprehensive Testing

        • Objectives: Integrate the application with the S5 network. Implement user onboarding/authentication flow (registration, seed phrase generation/handling). Develop synchronization logic for uploading encrypted user data to S5 and downloading/updating it locally. Conduct thorough end-to-end testing of all features, including the S5 integration, encryption, and synchronization. Refine UI/UX based on testing.
        • Deliverables: Fully integrated desktop application capable of secure user authentication and synchronization of the encrypted vault with the S5 network. Comprehensive test report. Final packaged application builds for major platforms (Windows, Linux, MacOs).
        • Verification: Demonstration video showing the complete user flow: registration/login, creating/editing data, closing and reopening the app with data successfully synced from S5. Code review. Final testing results.

4. Potential Risks & Mitigation

  • S5 Network Integration/Stability: Potential challenges in integrating with S5 APIs, or unexpected performance/reliability issues with the S5 network itself (including the mentioned risk of data loss inherent to any storage system).
  • Electron.js Complexity/Cross-Platform Issues: Challenges in building a consistent and performant experience across different operating systems using Electron.
  • Security Vulnerabilities: As a password manager, any flaw in the design or implementation of encryption, key handling, or data processing could have severe consequences.

5. Future Plans (Post-Grant Vision)

Our long-term strategic roadmap extends beyond this initial desktop application:

  • Platform Expansion:
    • Develop browser extensions (Chrome, Firefox, etc.) enabling seamless auto-capture of credentials from websites and auto-filling of login forms.
    • Create native mobile applications (iOS/Android) for on-the-go access.
  • Feature Enhancements:
    • Add support for storing secure notes.
    • Implement secure storage for payment card information.
    • Integrate Passkey (WebAuthn) technology for passwordless login to the Depass application itself and potentially management of website Passkeys.
  • Advanced Capabilities:
    • Implement secure sharing features for families or small teams with granular access controls.
    • Explore options for direct Sia network integration as an alternative or complementary backend to S5, offering users more choice.
    • Investigate premium features or support tiers if pursuing the optional cloud service model.

6. Contact Information

Hi, thanks for the proposal.

Can you show us any examples of your previous work, please?

1 Like

Nikita Orlov (StringNick (Nikita Orlov) · GitHub):
GitHub - StringNick/starknet-zig: Starknet library in Zig
GitHub - keep-starknet-strange/ziggy-starkdust: ⚡ Cairo VM in Zig ⚡
GitHub - zig-bitcoin/coconut: 🥥 Cashu wallet and mint implementation in Zig
GitHub - zig-bitcoin/bitcoin-primitives: Libraries and primitives for Bitcoin, written in Zig.

Dmitrii Putilov (dsputilov (Dmitrii Putilov) · GitHub)
GitHub - sandoxio/sandox: SanDOx is an open source IDE for the Polkadot ecosystem built as a browser app that consist of tool panels.
GitHub - Belsoft-rs/diffychat-dotrtc
GitHub - Belsoft-rs/diffychat-client

Figured I would get the elephant in the room out.

Can you describe how your plans, approach, or vision are meaningfully different to the existing project (Small Grants SecureSphere: Decentralized Password Management and Breach Monitoring) which also plans to expand after their MVP it seems.

Since you are trying to solve the same problem it would be best if you state how your project is different (assuming it is).

Kudos.

1 Like

It’s great to see existing initiatives like SecureSphere - this confirms the demand for privacy-focused tools, and healthy competition will push us all to build better products!

Unfortunately, due to the lack of build instructions in SecureSphere’s GitHub repository, we can’t test their implementation directly. However, comparing the proposals reveals fundamental differences in approach:

Storage philosophy:

SecureSphere: Stores passwords in a local database, using Sia only for backups. This creates attack vectors (local DBs can be compromised) and contradicts decentralization.
Depass: No local databases. Everything stays encrypted on Sia, always. No intermediate storage layers—just end-to-end encryption.

Sharing architecture: We’re designing Depass from the ground up to support secure password group sharing. This isn’t just a feature—it’s foundational. Without baking this into the core (like access controls and encryption workflows), retrofitting it later would break backward compatibility. SecureSphere’s proposal ignores this, limiting future team/family use cases.

Tree structure vs chaos: Depass organizes credentials in nested folders (e.g., /Work/Servers/SSH), critical for managing hundreds of accounts. SecureSphere’s flat structure becomes unmanageable when the number of passwords is large.

Killing 2FA apps: Depass launches with a built-in TOTP generator. No switching to Google Authenticator—everything lives in one secure place. SecureSphere focuses on breach alerts but misses this daily pain point.

We aim to build a product that can truly compete with centralized password managers like Bitwarden or 1Password — but with a core advantage: our solution will be fully self-hostable via an S5 node (as part of this grant). Beyond that, we plan to integrate decentralized storage through Sia once RHP4 is released, enabling a seamless experience across browser, desktop, and mobile platforms.

To support broader adoption, we’re also designing a proxy-based centralized backend. This will allow users unfamiliar with decentralized technologies or blockchains to use our password manager right away — no need to run an S5 or Sia node. Over time, we plan to implement a unified authorization system that supports S5, Sia, and our own centralized backend, making it flexible and future-proof.

We’re committed to using S5’s key-based authentication to ensure compatibility with other projects in the community, such as Vup.

Our team is highly skilled and capable of solving complex problems. The main objective of this grant is to deliver a robust and well-architected core — something that can evolve into a full-fledged alternative to leading centralized solutions, but with the unique flexibility of self-hosting, privacy, and decentralization.

What sets our product apart is its accessibility: advanced users can self-host for full privacy and control, while casual users can opt for our managed backend, which will use Sia for storage — optionally paying via SiaCoin or fiat, making it friendly even for non-crypto users.

In summary, it’s hard to say outright how our proposal is better without knowing more about the competing one — but we can speak for ourselves: we’re building something we would want to use. We have the experience, motivation, and technical ability to make it happen.

Thanks for your detailed proposal it’s always encouraging to see strong ideas in the decentralized security space.

Just to clarify a few things regarding SecureSphere:

  • Current status: What you’re seeing is the MVP version. SecureSphere is not just a password manager our long-term vision is to create a full ecosystem for data ownership and breach monitoring. The MVP showcases only the first layer of our broader architecture.
  • Local storage approach: Our decision to store data locally (with encrypted backups on Sia) was intentional. Many users prefer having offline access and faster response times without relying on a constant internet connection. The local database is fully encrypted with user-side keys, minimizing compromise risks. This hybrid model gives users control and flexibility, especially in low-connectivity environments.
  • Data sharing: Sharing between users is indeed planned. Our Enterprise version includes secure team-based data sharing including granular access control and audit logs. We chose to launch personal use first to validate the core encryption and breach monitoring functions.
  • Platform support: SecureSphere is being developed for desktop, mobile, browser extension, and a web app ensuring users can access their data from any environment. Offline-first capability remains a key advantage here.
  • Self-hosting options: We’re committed to giving users full ownership of their infrastructure. SecureSphere will support:
    • Standard self-hosted installations
    • A pre-configured Raspberry Pi image with Sia and S5 nodes
    • A cloud-hosted version where users can spin up their own SecureSphere server with minimal setup

While we share the same goal of challenging centralized solutions like 1Password and Bitwarden, our approaches differ based on the user base we’re targeting. SecureSphere is built not just for privacy enthusiasts but also for individuals and SMBs who want easy access, powerful breach monitoring, and gradual onboarding into decentralized tech without a steep learning curve.

Looking forward to seeing how both projects evolve healthy competition can only make the ecosystem stronger!

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:

  • Your comparison of DePass to SecureSphere doesn’t track correctly. For example, under Storage Philosophy you state: “Stores passwords in a local database, using Sia only for backups. This creates attack vectors (local DBs can be compromised) and contradicts decentralization.”
    • The local database is end to end encrypted.
    • Using local databases is typically done by many products for efficiency, not having to go through multiple layers to access data. This isn’t an inherently bad thing if done well.
  • We currently have an active password management app grant. Before approving a second one, we’d prefer to see how the first one delivers.

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.