# Small Grant — The Ovaseer

Grants Proposed
1

Introduction

Project Name

The Ovaseer — Immutable Audit Record Archive on Sia

Name of the Organization or Individual Submitting the Proposal

Abuo Favour Opiah

Systems architect and full-stack developer specializing in decentralized infrastructure, privacy-critical systems, and user-owned data architecture. Core expertise spans React, Node.js, cryptographic key management, and decentralized storage integration. Currently engineering medical records backup systems on Sia (onsafile.com PWA), demonstrating measurable improvements in data resilience for clinics and healthcare providers in resource-constrained regions. Passionate about enabling auditors, NGOs, and compliance teams in underserved communities to maintain immutable, tamper-proof records that survive institutional pressure and state interference.

  • GitHub: yucky-dev

Describe your project.

The Ovaseer is an open-source audit record archiving system that stores immutable compliance documentation on Sia’s decentralized network via indexd. Auditors, NGOs, and independent compliance teams upload audit reports, financial statements, healthcare incident logs, and regulatory findings to The Ovaseer. Records are encrypted end-to-end, stored immutably via indexd, indexed by The Ovaseer’s lightweight React dashboard, and retrievable with cryptographic proof of storage.

The Ovaseer is a pure application layer sitting on indexd. It receives audit file uploads (PDF, CSV, JSON), computes content hashes, encrypts with user-held keys, streams encrypted content directly to indexd’s immutable blob storage, and stores metadata (timestamp, auditor, institution ID, compliance category, content hash) in a local, sandboxed database. The Ovaseer maintains no proprietary archive; it defers entirely to indexd for immutable storage and retrieval.

The MVP delivers a production ready Clients side interface with end-to-end encryption, batch upload support, full text search, institutional access controls, cryptographic proof of storage verification, a lightweight web dashboard, complete deployment guides, and pilot integration with 3 real institutional partners. Clients side interface

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

The Sia Foundation’s mission is user-owned data. The critical barrier blocking this mission in critical sectors is the absence of affordable, decentralized record archiving infrastructure that requires no infrastructure management from end users.

Compliance documentation—audit reports, medical records, financial statements, incident logs—is currently archived in centralized systems: expensive enterprise software (SAP, Netsmart), cloud services (AWS, Google Drive), or local servers. In resource-constrained regions, institutional pressure, regime change, corruption, or conflict routinely result in record deletion, alteration, or disappearance. Auditors and compliance teams have no way to ensure their documentation survives institutional or political threats.

The Ovaseer removes that barrier entirely. Users store audit records on Sia via indexd, retaining full encryption key ownership. Records are immutable, globally distributed, and accessible only to authorized parties. The data path is: auditor → The Ovaseer (local encryption) → indexd (immutable blob storage). The Ovaseer never touches plaintext content; it stores encrypted data only. Users need no infrastructure; indexd is the Sia Foundation’s zero-knowledge storage layer, requiring no user-managed hosts or storage provisioning.

The market need is urgent and real. No open-source, self-hosted, decentralized audit archive exists built on indexd. Enterprise audit software costs $500–$5,000/month and locks institutions into centralized custody. Auditors in Nigeria, Kenya, Bangladesh, and Guatemala operate with no decentralized archiving option. The Ovaseer is built specifically for the Sia ecosystem’s indexd infrastructure and directly leverages it as the canonical immutable storage layer, requiring zero user-managed infrastructure.

User ownership means practical adoption. The Ovaseer delivers both: compliance teams retain encryption keys and institutional control of their records, while benefiting from Sia’s decentralized resilience, immutability, and cost efficiency, all without managing 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: $7,000 for a 12-week MVP development period (May – August 2026).
  • Workload: ~140 developer hours.
Line Item Detail Amount
Core application layer indexd integration, encryption, metadata indexing, search $4,200
Frontend dashboard React UI, access controls, proof of storage display, mobile responsiveness $1,200
Pilot deployment & testing Extended institutional onboarding, user testing, performance benchmarks $900
Documentation & open-source release Deployment guide, API docs, Docker Compose, GitHub setup $400
Contingency (2%) Buffer for unforeseen dependencies $300
TOTAL $7,000

Grant payments will be received monthly in tranches: $2,500 / $2,250 / $2,250 USD, contingent on milestone completion and code review sign-off.

Storage Cost Note: Storage costs are excluded from the grant. The Ovaseer is designed as a stateless encryption and routing layer. No Sia storage is consumed by the archive application itself. Users upload directly to indexd at their own cost. The grant funds engineering time and pilot coordination only.

High-Level Architecture Overview & Security Best Practices

The Ovaseer acts as a three-layer encryption and routing system. All audit uploads pass through these layers before and after touching indexd.

1. Ingestion Layer (Upload & Encryption)

Users upload audit files (PDF, CSV, JSON, plaintext) via The Ovaseer web dashboard or API. Each file is encrypted locally using AES-256-GCM before leaving the user’s infrastructure.

  • Key Management: To solve multi-user and local key exposure issues, The Ovaseer utilizes a Local-Session Storage Model (IndexedDB-backed). Encryption keys are derived using PBKDF2 from a master password, but are held only in temporary, encrypted in-memory contexts or local IndexedDB namespaces, and cleared upon session termination. Shared computers isolate user contexts by utilizing institution-based key rings.
  • Flow: User (plaintext file) → The Ovaseer client (AES-256-GCM encryption) → encrypted bytes → indexd.
  • Metadata Processing: Metadata (file name, size, timestamp, auditor ID, institution, category, content hash) is stored in the local database, indexed for search. The plaintext content never reaches the backend.

2. Storage Layer (indexd Immutable Blob Storage)

Encrypted file bytes are streamed directly to indexd’s blob storage API:

  • Immutable blob persistence (content-addressable storage).
  • Global P2P distribution across Sia hosts.
  • Zero-knowledge architecture (indexd cannot decrypt or inspect content).
  • Content hash verification and Merkle proof generation.

The Ovaseer stores the blob identifier in its metadata database, keyed by institution, auditor, compliance category, and timestamp. This enables fast metadata-based lookups without touching the blob store until retrieval is triggered.

3. Retrieval & Verification Layer

On audit report retrieval, The Ovaseer queries its local metadata database for matching records, retrieves the corresponding blob identifier from indexd, requests encrypted bytes, decrypts client-side using the user’s active session key, and returns plaintext only to authorized parties.

The Ovaseer Application Context
┌────────────────────────────────┐
┌───────────────────────┐        │  Local Secure Session Context  │
│  Auditor / Compliance │  ───>  │  - AES-256-GCM Encryption      │
│  (Plaintext / Upload) │        │  - Local Metadata DB (IndexedDB│
└───────────────────────┘        └────────────────┬───────────────┘
│
▼
┌─────────────────────┐
│       indexd        │
│  - Immutable Blobs  │
│  - Merkle Proofs    │
└─────────────────────┘

Security Practices

  • End-to-End Encryption: All audit files are encrypted client-side with AES-256-GCM before upload. The backend never handles plaintext.
  • Zero Infrastructure Leaks: indexd credentials are saved via environment variables on the client/system and never exposed via API responses.
  • Institutional Isolation: Each institution is given a separate, sandboxed namespace within the metadata database.
  • Immutability Verification: Sia Merkle proofs are fetched and displayed to users. Users can independently verify stored objects using Sia’s native tools.

Goals and Timeline

MONTH 1: Core Application Layer

  • Week 1–2: indexd SDK integration and encryption module
    • Write indexd client (blob upload, retrieval, proof verification).
    • Implement AES-256-GCM encryption/decryption pipeline and PBKDF2 key derivation.
  • Week 3–4: Metadata indexing and search
    • Design The Ovaseer metadata schema (institution, auditor, category, timestamp, content hash, blob identifier).
    • Implement full-text search (file name, auditor, institution) with local query caching.
  • Deliverable: Core library with indexd integration, encryption, and search. Passing unit tests. GitHub repository live.

MONTH 2: Frontend Dashboard & Access Controls

  • Week 5–6: React dashboard and upload UI
    • Single-page React app (upload form, file list, search interface).
    • Real-time encryption progress feedback and batch upload support.
  • Week 7–8: Access controls and proof of storage display
    • Role-based access (auditor, reviewer, institutional admin).
    • Merkle proof display with independent verification instructions.
  • Deliverable: Production-ready frontend. Usability testing with 3 pilot institutions begins early to account for real-world onboarding friction.

MONTH 3: Pilot Deployment & Documentation

  • Week 9–10: Pilot institutional onboarding and iterations
    • Extend timeframe for institutional integration with 3 real partner organizations (NGO, clinic, audit firm).
    • Measure upload speed, search latency, key recovery friction.
  • Week 11–12: Final hardening and release
    • Complete Docker Compose deployment setup (Linux/macOS/Windows).
    • Write comprehensive deployment guide and API documentation.
  • Deliverable: Production-grade open-source release with active pilot deployments.

Target User Cohort

The Ovaseer serves three critical user cohorts in underserved regions:

  • Independent Auditors (40%): Operate in environments where audit reports are pressured, redacted, or disappeared. Serve healthcare clinics, NGOs, and financial services. Need affordable, immutable record archiving without centralized custody.
  • NGO Finance & Humanitarian Teams (35%): Manage donor-funded programs where funding bodies demand auditable financial records. The Ovaseer provides immutable proof of financial integrity against corruption allegations.
  • Healthcare & Medical Record Institutions (25%): Independent clinics and rural hospitals documenting patient safety incidents, sterilization records, and incident reports.

Post-Grant Strategy & Sustainability

The Ovaseer is designed as a three-phase project:

  • Phase 2 — Enterprise Compliance Features: Multipart upload support, batch processing, advanced metadata attributes.
  • Phase 3 — Ecosystem Integration: Contribute audit archiving patterns to the Sia developer community, integrate with S5 for media-rich files, and publish to the ecosystem directory.
  • Sustainability Model: Self-funded/freemium, self-hosted deployment. Since The Ovaseer runs directly on indexd with no central server fees, the application is sustainable with low to zero ongoing hosting costs.

Potential Risks & Mitigations

  1. indexd API Changes: Pin to a specific indexd release during development and isolate the client behind a clean API.
  2. indexd Metadata Query Latency: Implement client-side caching of metadata queries and limit the results in memory.
  3. Key Management Inconvenience: Implement a “recovery key” configuration allowing offline key-backed export mechanisms while preserving the zero-knowledge baseline.

Development Information

2

Hi @Yucky-dev - thank you for your proposal. It will be reviewed by the Committee at next week’s meeting.

3

Thanks for your proposal to The Sia Foundation Grants Program.

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

  • The Committee would like to get more clarity on your business model: can you explain how you expect for the data gathered through this project to be used in future by the intended target user groups? What ‘current state of the art’ web2 tools are being used as your reference point for this project?

  • Additionally, given the kind of data being collected, the Committee wonders if there could be potential compliance issues here, which was not mentioned as a risk for the project. What kind of compliance would your target users expect through this audit record archiving system?

  • Lastly, please elaborate on your domain expertise. It appears you have your three institutional partners selected already, and including them in your proposal would add further context for the Committee on your background in this space.

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

4

The Ovaseer — Sia Foundation Committee Response

1. Business Model & Future Data Use

The Ovaseer is not designed as a data-harvesting platform or centralized SaaS archive. The project’s business model is based on providing infrastructure tooling for immutable, user-controlled audit archiving rather than monetizing institutional data.

The data stored through The Ovaseer remains fully owned and controlled by the institutions and auditors uploading it. The application itself does not aggregate, inspect, resell, or centrally retain plaintext records. Audit files are encrypted client-side before upload to indexd, and only encrypted blobs plus minimal searchable metadata remain accessible within the application context.

Long-Term Use by Target Users

The intended long-term use of stored data by target user groups is operational and evidentiary rather than analytical:

  • Immutable audit trails for regulatory or donor reporting
  • Tamper-resistant financial and operational documentation that survives institutional turnover
  • Long-term compliance archives with cryptographic proof of integrity
  • Incident and accountability records that cannot be retroactively altered
  • Verifiable evidence during disputes, investigations, or institutional transitions

Concrete Examples:

  • A humanitarian NGO needs to prove that financial disbursement records from a prior administration were not altered — donors increasingly demand immutable proof of fund integrity.
  • A rural healthcare clinic needs to preserve sterilization adverse event logs and incident reports that survive local infrastructure failure or staff turnover.
  • An independent auditor operating across fragile institutional environments requires cryptographically verifiable archival of findings that cannot later be retroactively modified under pressure.

Why Decentralized Storage Matters for This Use Case

Unlike centralized audit platforms (AuditBoard, SAP GRC, CaseWare), The Ovaseer’s decentralized model removes a critical institutional vulnerability: the platform provider itself becomes a single point of failure. With traditional SaaS, the vendor holds infrastructure control and can be compelled to alter, delete, or deny access to records—either by legal pressure, regime change, platform bankruptcy, or institutional coercion.

Sia’s indexd architecture means The Ovaseer is not a single point of failure. Records are distributed across a global P2P network, encrypted to the point where indexd itself cannot inspect them. This is operationally meaningful for auditors and compliance teams in Kenya, Nigeria, Guatemala, and Bangladesh—jurisdictions where institutional or political pressure on audit findings and accountability records is a documented risk.

Current State-of-the-Art Web2 Reference Tools

The Ovaseer’s operational model and user experience are informed by existing enterprise audit and compliance platforms. However, these centralized tools have fundamental architectural limitations that The Ovaseer addresses through decentralized storage.

Reference Tools & Their Limitations:

1. SAP GRC (Governance, Risk & Compliance)

  • What it does: Centralized audit management, findings tracking, remediation workflows, evidence attachment
  • Target users: Large enterprises, multinational corporations
  • Cost: $500–$5,000/month per organization
  • Limitation: Records stored in SAP data centers with centralized custody. Institutions depend entirely on SAP infrastructure availability, access control, and vendor neutrality. High cost makes it inaccessible to small auditors, NGOs, and independent clinics.

2. AuditBoard

  • What it does: Cloud-based audit workpaper management, risk assessment, findings documentation, audit trail logging
  • Target users: Internal audit teams, mid-market organizations
  • Cost: $3,000–$10,000/year per organization
  • Limitation: Centralized cloud infrastructure (AWS). Access depends on platform availability. Audit evidence exists only within AuditBoard’s system; no portable cryptographic proof of authenticity. Users cannot verify that findings have not been altered server-side.

3. CaseWare

  • What it does: Audit engagement management, workpaper organization, financial audit evidence storage, cross-engagement search
  • Target users: Audit firms, accounting practices
  • Cost: License-based ($5,000–$20,000/year)
  • Limitation: Requires local or cloud infrastructure management. Evidence stored in proprietary format; limited portability. No cryptographic proof of data integrity or immutability.

How The Ovaseer Replicates & Improves Upon These Platforms

Feature SAP GRC / AuditBoard / CaseWare The Ovaseer
Evidence Upload & Storage Centralized cloud or licensed infrastructure Encrypted client-side, stored on Sia’s immutable P2P network (indexd)
Findings & Metadata Indexing Platform-managed database Local metadata database (IndexedDB), user-controlled, no central server
Search & Discovery Server-side full-text search Client-side full-text search + metadata indexing (faster, no data exposure)
Access Control Role-based access (built-in, platform-managed) Institution-managed role-based access (same UX, no platform lock-in)
Proof of Authenticity Audit logs (vendor-controlled, can be altered) Merkle proofs from indexd (cryptographically verified, immutable)
Data Ownership Vendor holds custody; users depend on vendor policies Users hold encryption keys; full data ownership and portability
Cost $500–$10,000/month or high licensing Infrastructure costs only (indexd storage), support/premium features
Infrastructure Requirement Vendor-managed Decentralized (no single point of failure)

Key Operational Features Inherited from Web2 Tools (But Decentralized)

The Ovaseer borrows proven UX patterns from enterprise audit tools while removing vendor dependency:

  1. File Upload & Batch Processing — Like AuditBoard’s evidence attachment workflow, but encrypted before upload and streamed directly to indexd
  2. Metadata-Based Organization — Like CaseWare’s audit engagement structure, but stored locally and indexed for institutional-level control
  3. Full-Text Search — Like SAP GRC’s finding search, but computed client-side without exposing plaintext to a backend
  4. Role-Based Access Control — Like enterprise audit tools’ permission models, but managed by institutions, not the platform
  5. Proof of Integrity Display — A feature enterprise tools lack: Merkle proof verification showing cryptographic proof that stored records have not been modified

Why The Ovaseer is Viable for Underserved Users

The critical insight is that enterprise audit tools (SAP GRC, AuditBoard, CaseWare) work well for well-funded organizations, but are inaccessible and unsuitable for the jurisdictions where The Ovaseer is needed:

  • Cost barrier: $5,000–$10,000/year is prohibitive for independent auditors and small clinics in Nigeria, Kenya, Guatemala
  • Infrastructure barrier: Requires stable internet, cloud account setup, vendor lock-in
  • Trust barrier: In politically volatile environments, institutions cannot trust records to US-based cloud providers
  • Immutability gap: No existing enterprise tool offers cryptographic proof of record integrity; all depend on vendor integrity and are vulnerable to platform-level tampering

The Ovaseer fills this gap by combining the usability of existing enterprise tools with the resilience of decentralized storage and cost efficiency of P2P infrastructure.

Sustainability Model

The Ovaseer’s sustainability is infrastructure-oriented rather than data-oriented. Because the system operates as a lightweight application layer on top of indexd, operational costs remain low. The long-term model combines:

  • Optional enterprise support and onboarding services for organizations scaling deployments
  • Paid deployment assistance for institutions lacking technical capacity
  • Premium compliance tooling (advanced reporting, multi-organization coordination, audit workflows) in later phases
  • Managed deployments for organizations that prefer hosted infrastructure over self-hosting

The project does not depend on monetizing user records or centralized custody of audit data.

2. Compliance Considerations & Regulatory Framework

Yes, compliance considerations are important for a system handling audit records, healthcare incident documentation, and institutional archives. The proposal should have more explicitly identified regulatory and operational compliance as a project risk area, and this response addresses that gap.

The Ovaseer is designed primarily as an encrypted archival and integrity layer rather than a full compliance management platform. The intended users are expected to integrate it as part of their broader compliance workflows, particularly in situations where immutability, retention guarantees, and proof of record integrity are operationally critical.

Primary Compliance Expectations from Target Users

Target users across healthcare, NGO finance, and independent audit sectors expect:

  • Record integrity and tamper resistance — cryptographic proof that stored documents have not been altered
  • Retention and long-term archival durability — records remain accessible and intact for 5+ years
  • Controlled institutional access — role-based access ensures only authorized personnel can retrieve sensitive records
  • Verifiable chain-of-custody — audit trails and Merkle proofs demonstrating storage integrity
  • Immutability guarantees — once archived, records cannot be retroactively modified by institutional pressure or infrastructure compromise

Sector-Specific Compliance Frameworks

Depending on jurisdiction and operational context, this overlaps with:

Sector Regulatory Framework Compliance Need
Healthcare HIPAA (US), UK Data Protection Act, ECOWAS healthcare privacy standards Patient safety incident documentation, adverse event logs, sterilization records with 5–7 year retention
NGO/Humanitarian Donor reporting standards (USAID, World Bank, bilateral donors), anti-corruption frameworks Immutable financial disbursement records, audit trails, program evaluation evidence
Independent Audit International Standards on Auditing (ISA), local accounting board standards Finalized audit findings, evidence workpapers, management letter observations with 7+ year retention
Financial Services Basel III, local central bank audit requirements Transaction audit records, compliance evidence, incident documentation

How The Ovaseer Addresses Compliance Exposure

The Ovaseer is intentionally architected to minimize compliance exposure by reducing centralized data custody:

  • Files are encrypted client-side before upload
  • The application is designed so plaintext records are never visible to the backend or to indexd itself
  • Encryption keys remain user-controlled and institution-managed
  • No central audit log of who accessed what records — only user-side access records
  • Institutional isolation ensures one organization’s records cannot leak across institutional boundaries

However, the project does not claim automatic regulatory certification or turnkey legal compliance across jurisdictions. Institutions remain responsible for determining whether their operational usage aligns with:

  • Local retention policies and deletion obligations
  • Consent requirements for data subjects
  • Data residency regulations
  • Breach notification obligations
  • Staff training and access audit requirements

The Immutability/Deletion Tension

One important consideration is that immutable decentralized storage introduces tension with regulations (e.g., GDPR right to deletion) that may require data modification or removal. To address this, The Ovaseer is intentionally designed for archival categories where long-term immutability is desirable and legally appropriate:

  • Finalized audit reports (no longer subject to changes)

  • Compliance evidence (incidents, findings, resolutions)

  • Incident documentation (once investigation is complete)

  • Financial disbursement records (immutable proof of transaction integrity)

  • Not suitable for: Raw personal health information requiring deletion, consent-revocation workflows, or mutable operational documents

Planned Compliance Mitigations (Phase 2+)

As the project matures, compliance-related features planned for later phases include:

  • Configurable metadata minimization — institutions can control what metadata is indexed and searchable
  • Institution-controlled retention settings — define archival duration and auto-expiration of metadata pointers
  • Encrypted export and migration tooling — institutions can export all records under their encryption keys for portability or deletion
  • Optional self-hosted deployment modes — organizations with data residency requirements can run The Ovaseer on local infrastructure
  • Compliance documentation and audit trail — clear records of which staff accessed which documents, with timestamps

The project’s goal is not to replace institutional compliance governance, but to provide a decentralized archival foundation that strengthens data ownership, record integrity, and resilience against unauthorized alteration or disappearance.

3. Domain Expertise & Institutional Pilot Context

My background is primarily in decentralized application architecture, encrypted storage systems, and privacy-oriented infrastructure engineering. Over the past several years, I have focused on building lightweight systems that operate reliably in resource-constrained environments, particularly systems where users require stronger ownership guarantees over sensitive records and operational data.

My technical work spans React, Node.js, client-side cryptographic workflows, decentralized storage integration, and application-layer infrastructure design. A major focus of recent work has been understanding how decentralized storage can solve practical institutional problems — beyond speculative blockchain use cases.

Onsafile: Proof of Institutional Adoption in Healthcare

This proposal is informed by active development and pilot deployment of Onsafile, a Sia-integrated medical records backup platform focused on encrypted archival resilience for clinics and healthcare providers in underserved regions.

Onsafile experience exposed recurring operational challenges shared across healthcare, NGO, and audit environments:

  • Unreliable local infrastructure — clinics operating without redundant servers or backup systems
  • Risk of record loss or alteration — no institutional controls preventing staff from deleting or modifying patient records
  • Limited IT budgets — clinics cannot afford enterprise EHR backup solutions ($2,000–$10,000/year)
  • Dependence on centralized cloud platforms — AWS, Google Drive, Dropbox are often financially inaccessible or require internet bandwidth unavailable in rural areas
  • Institutional turnover risk — when clinic leadership changes, prior documentation often disappears or is inaccessible

These challenges informed both the technical architecture and the operational model of The Ovaseer.

The Three Pilot Organizations: Operational Context & Buy-In

The three pilot organizations represent the core target user segments. While formal contracts are not yet executed, these are active prospective collaborators with explicitly stated needs and operational willingness to participate in the 12-week development cycle:

Pilot 1: Rural Healthcare Network (West Africa)

Context: A network of 5 independent clinics (~40 clinical and administrative staff across 2 countries) currently managing medical incident documentation through fragmented local storage — USB drives, spreadsheets, paper records stored in office cabinets.

Operational Problem:

  • Sterilization adverse event logs and patient safety incident reports exist only as paper or unencrypted local files
  • When clinic directors change or staff turn over, critical incident documentation is lost or becomes inaccessible
  • Donors and government health authorities increasingly demand proof of incident tracking and resolution
  • No audit trail exists demonstrating that incident records have not been altered after the fact

Why They’re Interested in The Ovaseer:

  • They need immutable, encrypted archival that survives staff turnover and infrastructure failure
  • They require donor-reportable proof that incident documentation is authentic and unmodified
  • They want to move away from paper-based compliance without trusting cloud providers with unencrypted patient safety data
  • They understand Sia through Onsafile conversations and are explicitly interested in decentralized alternatives to centralized cloud backup

Their Role in Pilot:

  • Provide real incident documentation and workflow context
  • Validate encryption usability for clinic staff with limited technical training
  • Test metadata indexing against real healthcare categories (incident type, severity, outcome)
  • Measure adoption friction in low-bandwidth environments
  • Provide feedback on access control workflows for multi-clinic institutional hierarchies

Pilot 2: Independent Audit & Compliance Team

Context: A small audit firm (~8 auditors) operating independently across 3 countries, currently managing finalized audit findings and management letter observations through email, encrypted USB drives, and local spreadsheets.

Operational Problem:

  • Audit findings exist in multiple formats and storage locations with no centralized archive
  • When auditors move between assignments or clients, access to prior findings becomes fragmented
  • In politically volatile environments, pressure exists to retroactively modify audit findings or “soften” critical observations
  • No cryptographic proof exists that audit findings have remained unchanged since initial delivery to clients
  • International clients increasingly require SOC 2 / ISAE 3402 evidence of data integrity controls

Why They’re Interested in The Ovaseer:

  • They need immutable, auditable archival demonstrating that findings have not been altered under pressure
  • They want to demonstrate to international clients that audit evidence is stored with cryptographic integrity guarantees
  • They require a self-hosted solution that does not depend on centralized audit software providers (which may be pressured or compromised)
  • They operate in jurisdictions where institutional pressure on auditors is real; decentralized immutability provides professional protection

Their Role in Pilot:

  • Provide real audit findings and categorization workflows
  • Validate search and metadata indexing against audit discovery and retrieval workflows
  • Test proof-of-storage verification and explain Merkle proofs to audit clients
  • Provide feedback on institutional access controls for multi-team audit organizations
  • Serve as early reference customer for enterprise adoption phase

Pilot 3: Humanitarian NGO (Finance & Program Evaluation)

Context: A humanitarian NGO (~80 staff across 4 countries) managing program evaluations, financial disbursement records, and donor reporting through Google Drive, Dropbox, and email. Their finance team manages $15M+ in annual funding.

Operational Problem:

  • Financial records are fragmented across personal email accounts and shared cloud storage
  • Donors and bilateral funding agencies increasingly demand immutable proof of financial integrity and program outcomes
  • When program directors change or organizations restructure, access to historical financial and evaluation records becomes inconsistent
  • No audit trail exists proving that financial records have not been retroactively altered
  • Corruption allegations against prior administrations sometimes involve claims of fabricated financial records — they need cryptographic proof of authenticity

Why They’re Interested in The Ovaseer:

  • They need immutable, encrypted archival of financial disbursement records and program evaluation data
  • They want to demonstrate to donors that financial records are stored with cryptographic integrity — essential for securing future funding
  • They require self-hosted or decentralized infrastructure that does not depend on US-based cloud providers (relevant in some jurisdictions)
  • They understand decentralized systems through conversations about data sovereignty in humanitarian contexts

Their Role in Pilot:

  • Provide real financial and evaluation datasets with operational metadata (disbursement category, program, fiscal year, approval chain)
  • Validate search and retrieval workflows against donor reporting timelines
  • Test institutional access controls for multi-office, multi-currency financial teams
  • Measure upload and retrieval performance at various bandwidth constraints
  • Provide feedback on compliance documentation needed for donor audits

Validation Goals Across All Pilots

The three pilots are designed to validate:

  1. Encryption and retrieval usability — Can clinic staff, auditors, and finance teams use AES-256-GCM encryption workflows without extensive training?
  2. Metadata indexing practicality — Do full-text search and category-based filtering meet real institutional discovery workflows?
  3. Onboarding friction in low-resource environments — How much technical support is required for organizations with limited IT capacity?
  4. Operational value of immutable decentralized archival — Do the security and resilience benefits justify the operational changes required?
  5. Institutional isolation and access controls — Can The Ovaseer enforce proper boundaries between organizations and roles without adding friction?
  6. Performance and cost — Does indexd storage performance meet retention and retrieval SLAs across different institutional scales?

Domain Expertise Summary

My expertise in this space is centered on building secure, user-owned infrastructure systems that can realistically function for organizations operating outside well-funded enterprise environments. This is less traditional enterprise compliance consulting and more applied infrastructure engineering for the Global South and resource-constrained contexts.

The broader motivation behind The Ovaseer is practical: bringing decentralized storage into environments where data integrity and institutional resilience have direct real-world consequences, while keeping the operational model simple enough for small organizations to adopt without dedicated infrastructure teams.

The three pilot organizations represent authentic stakeholder feedback from ongoing conversations about immutable archival problems in healthcare, audit, and humanitarian finance — not hypothetical use cases, but operational pain points that have been explicitly articulated and are waiting for a decentralized solution.

5

I’ve addressed the Committee’s concerns and submitted the necessary revisions.

P.S. You previously mentioned that the proposal would remain in the “Proposed” section, but I noticed it has now been moved to “Rejected.” I’d appreciate some clarification on this change.

6

Hello @Yucky-dev - thank you for your response.

Can you elaborate on your relationship with Onsafile?

Moving this proposal to ‘Rejected’ was in error and it has been moved back.