SAIHM-Zcash Shielded-Identity Adapter

Community Grants Applications
1

Organization Name

SAIHM Project
https://saihm.coti.global

How did you learn about Zcash Community Grants

Research during open-source AI memory protocol grant-pipeline development; ZCG identified as the canonical funding channel for Zcash-aligned privacy infrastructure work.

Requested Grant Amount (USD)

$50,000

Category

Integration

Project Lead

  • Name: SAIHM Project (pseudonymous public-facing)

  • Role: Sole maintainer + architect

  • Background: Author of IETF Internet-Draft draft-saihm-memory-protocol-00 (Independent Submission stream); OpenSSF Best Practices Passing badge submission (project 12898, 100%, 64/64); @saihm/mcp-server reference implementation on npm; designer of the cryptographic-erasure primitive saihm_forget. Years of professional engineering on commercially-deployed encryption and key-management systems.

  • Responsibilities: All technical design, implementation, documentation, community engagement (written/async), and milestone delivery for this grant.

Additional Team Members

None or N/A. Sole-maintainer Apache-2.0 project; external Zcash-community reviewer engaged only for milestone M5 review.

Project Summary

A Rust adapter that lets Zcash z-address holders use their shielded-key derivation as the sovereign identity for SAIHM AI memory cells — extending Zcash’s privacy primitives into the AI memory layer.

Project Description

SAIHM (Sovereign AI Horizontal Memory) is an Apache-2.0 open-source AI memory protocol that gives users portable, cryptographically erasable memory across AI vendors. The reference implementation (@saihm/mcp-server on npm) is live and exposes eight Model Context Protocol tools (remember, recall, forget, status, share, revoke_share, governance propose + vote).

This grant funds the design, implementation, and open-source release of a SAIHM-Zcash Shielded-Identity Adapter: a Rust crate built against librustzcash that lets a Zcash z-address holder derive the sovereign identity used to encrypt SAIHM memory cells. The adapter does NOT require on-chain Zcash transactions for SAIHM operations — it uses shielded-key derivatives as private-key material at the SAIHM identity layer. The result is a single sovereign substrate (the user’s Zcash z-address) that the user can use both for shielded payments AND for sovereign AI memory identity, with consistent privacy properties across both surfaces.

Proposed Problem

Most AI memory implementations bind user identity to AI vendor accounts (Google, OpenAI, Anthropic, Microsoft) — which means the vendor controls the identity surface, can revoke it, and can be compelled to disclose the user-identity-to-data mapping. Even where the AI vendor offers user-controlled encryption, the identity is typically a custodial key managed by the vendor or a centralized authentication provider.

For privacy-sensitive AI usage (journalists, human-rights defenders, dissidents, healthcare professionals, regulated industries), this is a structurally weak posture. The user has no sovereign, censorship-resistant identity primitive to anchor AI memory ownership against.

Zcash z-addresses already solve this for payments: shielded keys are user-controlled, mathematically anonymous, and censorship-resistant. There is currently no published reference pattern for using z-addresses as sovereign-identity primitives in non-payment applications.

Proposed Solution

The SAIHM-Zcash Shielded-Identity Adapter provides:

  1. A Rust crate (saihm-zcash-identity) built against librustzcash that derives SAIHM cell-encryption identity material from a Zcash z-address holder’s shielded-key chain.

  2. An MCP integration layer that lets the SAIHM reference implementation (@saihm/mcp-server) optionally use this Zcash-bound identity, alongside its existing identity options.

  3. A demo + walkthrough showing end-to-end: user has a z-address, derives SAIHM identity, writes cells, recalls cells, cryptographically erases cells — all with Zcash-anchored sovereignty.

  4. A CONTRIBUTING.md per librustzcash style guides.

  5. Documentation pattern that Zcash developers can adapt for other non-payment privacy applications.

Solution Format

Software (Rust crate + npm-published MCP integration), written documentation, demo walkthrough, contributing guide, forum/issue-tracker engagement (written-only).

Dependencies

  • librustzcash (Apache-2.0; canonical Zcash Rust toolkit)

  • @saihm/mcp-server (Apache-2.0; existing SAIHM reference implementation on npm)

  • No external collaborator dependencies; sole-maintainer-developed with one external Zcash-community reviewer engaged only at M5

Technical Approach

Three-layer design. Identity layer: Rust crate uses librustzcash to derive a SAIHM identity-key from a Zcash z-address’s shielded-key chain. Cell-encryption layer: the existing SAIHM cell-encryption flow accepts this Zcash-derived identity in place of (or alongside) its existing identity types; no SAIHM protocol change is required — only an additional identity provider. MCP integration layer: a configuration switch lets SAIHM operators select Zcash-bound identity for cells they want anchored to a shielded-key holder.

Implementation language: Rust for the identity crate (per Zcash ecosystem norms); TypeScript for the MCP integration layer (per SAIHM’s existing surface).

Style and contribution practices: follow librustzcash style guides as required by ZCG; merge/branch/PR/commit conventions per librustzcash CONTRIBUTING.md.

Upstream Merge Opportunities

  • The SAIHM-Zcash adapter is a new standalone crate (saihm-zcash-identity) released under Apache-2.0; no fork of existing Zcash repositories is required.

  • Documentation patterns + sample code may be useful as community-contributed examples to librustzcash’s example-applications surface; will offer the demo + walkthrough as a community contribution at M6 if Zcash maintainers are interested (written-only coordination).

  • If the demo surfaces opportunities for upstream-improvable APIs in librustzcash (e.g., cleaner identity-derivation primitives for non-payment use cases), findings + suggested patches will be submitted as written contributions via standard PR + issue channels.

Engagement format (explicit clause)

All deliverables and community engagement are written and asynchronous. The maintainer commits to written/async/from-home work-product delivery and does not commit to:

  • In-person meetings, summits, conferences, hackathons (Zcon, etc.)

  • Live video calls, on-camera interviews, podcasts, webinars, AMAs, panels

  • Travel of any kind under this grant

  • Synchronous live-streamed demos

All communication is via GitHub Issues/PRs, Zcash Community Forum threads, and email — all written. The maintainer is responsive on written channels within standard business windows. The mandatory ZCG forum cross-post is written-only and will be maintained.

Budget

Line item Amount (USD)
Hardware/Software $1,000
Service Costs (Zcash-experienced external reviewer at M5; testnet/infra) $4,000
Compensation (sole-maintainer, six months part-time engineering) $45,000
Total $50,000

Hardware/Software Justification: Negligible — sole-maintainer using existing equipment. The $1,000 line covers project-specific software licenses, snarkVM/Zcash-rust toolchain dependencies, and any specialized testing infrastructure.

Service Costs Justification: $4,000 funds an external Zcash-community-experienced reviewer engagement at milestone M5 to validate the cryptographic design and librustzcash integration quality before final release. Remaining covers Zcash testnet faucet/infrastructure for end-to-end testing.

Compensation Justification: $45,000 supports the sole maintainer for approximately six months at a sustainable part-time rate consistent with US senior open-source-contractor rates. Maintainer is project lead, designer, implementer, documentation author, and forum-engagement contact.

Previous Funding (ZCG)

No.

Other Funding Sources

Yes. The maintainer is the principal investigator on several parallel-pipeline open-source-grant applications for the broader SAIHM project, all of which are structurally non-overlapping with this Zcash-specific scope:

  • Filecoin Foundation Open Grant (submitted) — SAIHM storage-tier hardening

  • NLnet NGI Zero Commons Fund (submitted) — SAIHM protocol-spec hardening + cross-vendor adapters

  • Open Collective via Open Source Collective fiscal host (submitted) — general operating support

  • OpenSSF Alpha-Omega (draft) — US-firm cryptographic audit + formal verification

  • Sovereign Tech Fund (draft) — EU-firm cryptographic audit + ETSI engagement + EU-language localization

  • OTF Internet Freedom Fund (draft) — repressive-environment threat model + adversarial review

  • FLOSS/fund (draft) — annual baseline operating support

  • Emergent Ventures (draft) — personal-velocity threat model + cross-vendor adapters

  • COTI Builders Program (draft) — COTI-V2-specific deliverables including separate COTI-integration-boundary audit

  • Aleo Developer Grants (draft) — Aleo zk-SNARK erasure-proof circuit

Each scope is documented to be non-overlapping with this Zcash work. The Zcash-specific scope is uniquely a librustzcash-Rust adapter binding z-address-derived sovereignty to AI memory identity — a deliverable distinct from any other in flight.

Implementation Risks

  1. Cryptographic-design correctness. Using z-address-derived material as SAIHM identity must not weaken Zcash’s shielded-key security properties. Mitigation: external Zcash-community-experienced reviewer engagement at M5 explicitly validates this boundary.

  2. librustzcash API surface evolution. Zcash Rust toolkit APIs evolve. Mitigation: pin against a stable librustzcashversion for grant deliverables; document upgrade path; track upstream changes during grant window.

  3. MCP integration backward-compatibility. The Zcash-bound identity provider is added as an additional option — not as a replacement — preserving backward compatibility for existing SAIHM users.

Potential Side Effects

  1. Pattern adoption beyond intended scope. Once published, the z-address-as-sovereign-identity pattern may be adopted by applications with different threat models. Mitigation: explicit documentation of intended threat model, security boundaries, and where the pattern is NOT appropriate.

  2. Increased z-address-holder visibility. Using a z-address as identity in a long-running application could (depending on operator configuration) increase the metadata trail of that z-address. Mitigation: documented best-practice guidance to use derived sub-keys per application instance rather than the primary z-address directly.

Success Metrics

  1. saihm-zcash-identity Rust crate published under Apache-2.0 with passing test suite + fuzz coverage.

  2. SAIHM MCP integration shipped as a minor version of @saihm/mcp-server on npm.

  3. End-to-end demo reproducible from public Docker image with documented walkthrough.

  4. External Zcash-community-experienced reviewer signoff at M5.

  5. CONTRIBUTING.md per librustzcash style guides published.

  6. Forum thread on forum.zcashcommunity.com/c/grants/33 maintained throughout grant window.

Startup Funding (USD)

$0 — no upfront startup tranche.

Startup Funding Justification

Disbursement is purely milestone-based. M1 (design + spec) is the first paid milestone at $8,000 on completion; the maintainer underwrites the first-month work from personal resources, with payment on M1 acceptance. This keeps total budget arithmetic clean: Startup ($0) + Milestones ($50,000) = Total Budget ($50,000).

Milestone Details

  • Milestone: 1

    • Amount (USD): 8,000

    • Expected Completion Date: 2026-07-22

    • User Stories:

      • “As a privacy-conscious AI user with a Zcash z-address, I want a published specification of how my z-address can derive a sovereign identity for AI memory, so I can review the security model before adopting the pattern.”

      • “As a Zcash community developer, I want a published specification showing how z-addresses can serve as sovereign-identity primitives for non-payment use cases, so I can adapt the pattern.”

    • Deliverables:

      • Published written specification saihm-zcash-identity-spec.md in the public repository under Apache-2.0

      • Forum thread on forum.zcashcommunity.com/c/grants/33 posted with link to specification + open for community input

    • Acceptance Criteria: Specification reviewed by at least three community readers via the forum thread; no blocking design issues unresolved.

  • Milestone: 2

    • Amount (USD): 12,000

    • Expected Completion Date: 2026-09-22

    • User Stories:

      • “As a Rust developer, I want a saihm-zcash-identity crate built against librustzcash, so I can use Zcash-derived identity in my own privacy applications.”

    • Deliverables:

      • Rust crate saihm-zcash-identity v0.1.0 published with Apache-2.0 license + passing test suite

      • CONTRIBUTING.md per librustzcash style guides

    • Acceptance Criteria: Crate builds cleanly against pinned librustzcash; tests pass; CONTRIBUTING.md present and follows librustzcash conventions.

  • Milestone: 3

    • Amount (USD): 10,000

    • Expected Completion Date: 2026-11-07

    • User Stories:

      • “As a SAIHM operator, I want a configuration switch to use Zcash-derived sovereign identity for cells, so my users can anchor memory ownership to their z-address.”

    • Deliverables:

      • @saihm/mcp-server minor version published on npm with Zcash-identity integration

      • Backward-compatible integration: existing SAIHM users see no breaking changes

    • Acceptance Criteria: npm package builds + publishes; existing SAIHM regression test suite passes; new Zcash-identity end-to-end test passes.

  • Milestone: 4

    • Amount (USD): 6,000

    • Expected Completion Date: 2026-11-30

    • User Stories:

      • “As a curious Zcash developer, I want a reproducible end-to-end demo showing z-address → SAIHM identity → cell write → cell recall → cryptographic erasure, so I can see the pattern working.”

    • Deliverables:

      • demo-zcash-identity/ directory with Dockerfile + README walkthrough + run script, Apache-2.0

    • Acceptance Criteria: Demo runs to completion from clean Docker environment; output matches walkthrough screenshots.

  • Milestone: 5

    • Amount (USD): 8,000

    • Expected Completion Date: 2026-12-22

    • User Stories:

      • “As a Zcash community member, I want independent reviewer confirmation that the SAIHM-Zcash identity adapter does not weaken Zcash’s shielded-key security model, so I can trust the pattern.”

    • Deliverables:

      • External Zcash-community-experienced reviewer engagement complete

      • Reviewer report published openly in the repository

      • Reviewer findings remediated where actionable

    • Acceptance Criteria: External reviewer issues a written signoff statement that the adapter does not weaken Zcash shielded-key security properties.

  • Milestone: 6

    • Amount (USD): 6,000

    • Expected Completion Date: 2027-01-22

    • User Stories:

      • “As a Zcash ecosystem member, I want post-grant documentation and a maintenance commitment, so I know the work will be sustained.”

    • Deliverables:

      • End-of-grant written summary + post-grant maintenance commitment letter published in repository

      • All deliverables present in public repository

      • Forum thread closing post summarizing outcomes + linking to all artifacts

    • Acceptance Criteria: Final summary published; forum thread updated; ZCG committee can verify all deliverables are public + Apache-2.0.

Zcash Community Grants Meeting Minutes 05/25/2026
Zcash Community Grants Meeting Minutes 6/8/2026
4

Uhhh…so, then what does it do? :wink:

  • What this does, simply:

    • It lets people use the same private, hidden Zcash account key they already have for money to also lock and unlock their private AI memories. Think of one secret key that opens both your private wallet and your private AI notebook.

  • Why that matters:

    • Privacy: Your AI notes, preferences, and personal files stay encrypted so only you (with that secret key) can read them. No need for an email or username that links you across services.
    • Portability: You can move those encrypted memories between different AI apps or devices without changing keys or making a new account — the Zcash key is the single identity.
    • Control: If you want to stop someone’s access or make a new key, you can do it cryptographically (derive new keys) without publishing anything on a blockchain or revealing your identity.
    • Convenience: If you already back up your Zcash wallet, you automatically have the backup for your AI memories too.

  • Easy examples:

    • A doctor’s notes, medical history, or therapy journal encrypted so only the patient’s Zcash key can open them, even if stored on a cloud AI service.
    • Switching from one AI assistant to another and keeping all your personalized memory intact — no account migration needed.
    • Giving temporary access to a friend or teammate by handing them a derived key for just that memory, then revoking it later.
    • Running a private, local AI on your phone that still reads your cloud-encrypted memories because it can derive the same key from your wallet seed.

Aha! :smiley: So, then the TLDR is:

This lets you use the same private, hidden key from a Zcash shielded address to lock and unlock your AI memories, so your personal notes, preferences, and files stay encrypted and readable only by you; it removes the need for emails or usernames, makes memories portable across AI apps and devices, lets you grant or revoke access cryptographically without on-chain transactions, and ties backup and recovery to your existing Zcash wallet seed.

…and no other community has it.

5

Update: SAIHM continues to actively contribute to the various standards bodies’ efforts to the development of a single standard for sovereign AI horizontal memory. The intent is to either be that standard or already have shipped all the attributes (and more) required by the standard. Take a peek at SAIHM’s roadmap. It is a serious and impactful project that needs your support.

But what makes SAIHM functionally unique; and what advantages accrue to the community through supporting SAIHM’s efforts?

6

Thank you for submitting your proposal. Following a thorough review by the ZCG and a period for community feedback on the forum, the committee has decided not to move forward with this proposal.

We sincerely appreciate the time and effort you invested in your application and encourage you to stay involved and continue contributing to the Zcash community. Further details will be available in the meeting minutes to be posted shortly.

1 Like