### Terms and Conditions
- [x] I agree to the [Grant Agreement](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded
- [x] I agree to [Provide KYC information](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD
- [x] I agree to disclose conflicts of interest
- [x] I agree to adhere to the [Code of Conduct](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and [Communication Guidelines](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284)
- [x] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
- [x] I agree that for any new open-source software, I will create a `CONTRIBUTING.md` file that reflects the high standards of Zcash development, using the [`librustzcash` style guides](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference.
- [x] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any [merge](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), [branch](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), [pull request](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and [commit](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the `librustzcash` repository.
- [x] I agree to post request details on the [Community Forum](https://forum.zcashcommunity.com/c/grants/33)
- [x] I understand it is my responsibility to post a link to this issue on the [Zcash Community Forums](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.
### Application Owners (@Octocat, @Octocat1)
@orb.ism
### Organization Name
orb
### How did you learn about Zcash Community Grants
Through friends invested in Zcash, and the Discord community
### Requested Grant Amount (USD)
$46,400
### Category
Non-Wallet Applications
### Project Lead
```project-lead.yaml
Name: Orb
Role: Dev/UX
Background: 20+ years software development, engineering, SecOps, SysOps, DevOps, UX/UI development, and more
Responsibilities: Software development, and providing a modular UI that can be modified easily to match the different usage needs of different user types.
```
### Additional Team Members
```team-members.yaml
Name: Moon
Role: Dev
Background: 10+ years Solidity development, 20+ years software development, SecOps, Infrastructure, SysAdmin.
Responsibilities: Additional EVM support, software development, infrastructure architecture, audits.
```
### Project Summary
**(Time Capsule / Notary / Deadman Switch utilizing ZEC)**
A Privacy Capsule: a client-side encrypted “vault” that lets journalists, lawyers, compliance teams, researchers, and everyday users seal information, prove it existed at a point in time, and optionally disclose it later - without leaking sensitive content by default.
**Privacy Capsule combines three workflows:**
- Notary / Proof-of-Existence (timestamp a file/message hash on Zcash)
- Sealed Capsules (encrypted messages / references that remain private)
- Time-based release + Deadman Switch (unlock/release rules with explicit user intent)
Emphasis: this is not a surveillance product. It is voluntary disclosure tooling designed for people who require privacy and credible proofs.
### Project Description
## Why Zcash?
**Zcash’s privacy focus makes it a compatible home for:**
- sensitive-source workflows (journalism)
- privileged communications (legal)
- audits and attestations with controlled disclosure (compliance)
- integrity proofs for research and publishing
Privacy Capsule turns “privacy as a feature” into “privacy as a usable workflow.”
## What I’m Building
### **1) Notary + Proof Bundles (Core)**
- User selects a file or text (client-side).
- App computes a hash locally and anchors a commitment on Zcash.
- App generates a Proof Bundle (copyable + downloadable) containing:
- content hash
- txid
- block height + timestamp reference
- verification instructions
- Provide an open-source verifier (CLI + simple web verification page).
The above ultiamtely doubles as a receipt; the proof bundle is both the proof that it worked, and the key to the verifier.
Bundle provision will depend on user's submission model. Options for delivery will be tied to whether it was done via networks that are virtual machines (Ethereum -> erc721 NFT with metadata attached; MD can live fully on-chain, as can SVG media or html/js content in `animation_url`), traditional centralized tech (QR code sent to email), or other methods such as a pure binary/hex proof file.
Example of hex: `5a50435001|sha256:<contentHash>|txid:<txid>|height:<blockHeight>|time:<timestamp>|commitment:<zcashMemoOrOpReturnCommitment>`
Verifier would decode, re-hash the content, check against hash matches, and verify the txid/block data against the node/indexer.
Public (external party) verification models can be considered, so a tally of live capsules can be taken, with option to "hide" the capsule if a user wishes to keep it out of the public count.
### **2) Encrypted Capsules (Client-side first)**
- Encrypt content in the browser (keys never sent to server).
- Store encrypted payload (or payload reference) in user-controlled storage.
- Anchor only commitments + minimal metadata required for operation (rate limits, non-sensitive logs).
### **3) Time Release + Deadman Switch + Other Methods**
Designed to be a multi-option lock/release model. Model selected during setup process and prior to final submission.
- Time-release: “unlock at date/time” or “unlock at block height.”
- Deadman switch: “if I don’t check in every N days, release to designated recipients.”
- Other methods: password, identity unlocks (email, ecnryption string, user auth), shielded memo with ascii string, etc.
- Release can mean: send encrypted payload to recipients, email/webhook notifications, or publish a reveal key (configurable and explicit).
**Deadman-switch execution triggers:**
- Permissionless on-chain calls (anyone can call release() once conditions are met)
- Decentralized automation networks (e.g., Chainlink Automation/Gelato)
- Redundant self-hosted watchdog bots (multi-provider/Tor-capable) for maximum reliability.
Additional considerations would be surrounding transactions that initiate conditions that lead to a time capsule's creation. Examples would be timer countdowns, or waiting for a specific kind of transaction from a specific address(es) to trigger it.
**Also enforced via encoding the rules in the contract state + signatures:**
- Check-in rule: checkIn() updates lastSeen; release() is allowed only if block.timestamp > lastSeen + N.
- Recipients: stored as hashes/IDs (or emitted on release); payload/key is encrypted for them.
- Multi-sig equivalent: require M-of-N approvals (EIP-712 signed approvals or on-chain approve() calls) before release() can execute.
- Other criteria: add gates like “not before date X,” “only after block height H,” “requires auditor key,” “cooldown window,” etc.; release() checks all conditions.
Note: using EVM states to enforce actions and/or other decentralized mechanisms is primary preference at this time, but not set in stone.
### **4) Org Features (Potentially high-value users)**
- Team vaults (eg. 2-of-3 approvals to unlock/export)
- Policies (retention, export templates, audit log of exports)
- Export packs designed and formatted for legal/compliance use
## Success Criteria
- Production release (usable v1) with docs + threat model + reproducible verification steps (documentation provided)
- Publicly available, open-source verifier tooling.
- At least 3 pilot users/orgs testing end-to-end workflows (preferably: journalism, legal, compliance)
- Proof Bundles used successfully in real “show me proof” scenarios (publishing with timestamp, audits, dispute resolution)
### Proposed Problem
People who handle sensitive information, such as journalists, lawyers, compliance teams, researchers, and everyday users, currently lack usable and truly privacy oriented tooling to:
1. seal information and subsequently
2. prove it existed at a specific point in time
3. optionally disclose it later without leaking the content by default
Existing notarization and disclosure workflows either compromise privacy (public timestamping of readable content) or lack credible, verifiable proofs that hold up in "show me proof" scenarios such as publishing disputes, audits, and legal review.
Separately, decentralization offers functionality that addresses many societal needs, but suffers from an ideology-first identity, as opposed to a UX-first mentality when presenting to the public. Our tooling built on blockchains are always ignored as soon as the identifier, "blockchain," or, "crypto," are mentioned, because of associations with bad players, and negative consequences that are always louder, and more apparent in social media and news media. Public opinion is negative of the idea, without having experienced provided positive utility.
### Proposed Solution
## 2. Proposed Solution
Privacy Capsule is a client-side encrypted vault built on Zcash that combines three workflows into one product:
*Privacy Capsule combines three workflows:*
1. *Notary / Proof-of-Existence (timestamp a file/message hash on Zcash)*
2. *Sealed Capsules (encrypted messages / references that remain private)*
3. *Time-based release and/or Deadman Switch (unlock/release rules with explicit user intent)*
It turns Zcash's privacy properties into a usable workflow for high-stakes use cases; privacy as a primary feature.
Separately, it provides tooling that does not emphasize the tooling under the hood, so much as the utility and UX. Once the users have a positive experience, they may choose to pop the hood and take a look. Secondary discovery of functional tech that contributes to society in a positive manner, will directly influence and encourage positive sentiment towards the network the tooling is running on.
### Solution Format
The deliverable is software: a production v1 release shipped in two forms.
*Privacy Capsule will be delivered as:*
- *a ZEC-OS program (native app experience inside the experimental OS UI)*
- *a standalone web app (for broader adoption, and integration into future app suites)*
Alongside the apps, the project ships an open-source verifier (CLI + simple web verification page), Proof Bundles (copyable/downloadable receipts), documentation, a threat model, and an outreach kit for pilot onboarding.
Considerations for standalone apps may be considered for future versions. Privacy negation by virtue of marketplace standards compliance with app stores may discourage this approach, but further research to offload problematic areas off-device can be considered (limit setup options to guaranteed privacy paths during lock UX, based on device being used).
### Dependencies
**Technical (already in place from ZEC-OS):**
Zebra node (with zcashd archived to height 3,220,000), an RPC over the validated chain state, an indexer, a parser that computes pool states, and PostgreSQL for node + processed data storage. Backups every 6 hours for PostgreSQL, weekly for all other data.
**Additional technical:**
Zcash network for anchoring commitments, and an EVM/decentralized automation layer for release logic.
*"Permissionless on-chain calls (anyone can call release() once conditions are met)"* and *"Decentralized automation networks (potentially Chainlink Automation/Gelato, or state-machine driven EVM deploys)"*, plus *"Redundant self-hosted watchdog bots (multi-provider/Tor-capable) for maximum reliability."* **Resource/collaboration:** infrastructure budget for hosting, scaled node, private RPC, storage, and monitoring; external security review; and if possible, 3 pilot users/orgs (preferably in journalism, legal, and compliance) to validate end-to-end workflows.
### Technical Approach
## 5. Technical Approach
Content is hashed client-side and a commitment is anchored on Zcash, producing a Proof Bundle containing the content hash, txid, block height/timestamp, and verification instructions - verifiable via an open-source CLI + web verifier that re-hashes content and checks it against on-chain data. Encrypted Capsules are handled in the browser so keys never reach the server, with only commitments and minimal non-sensitive metadata anchored on-chain. Release logic is enforced in contract state + signatures, as stated in the proposal (copy-paste):
*- Check-in rule: checkIn() updates lastSeen; release() is allowed only if block.timestamp > lastSeen + N.*
*- Recipients: stored as hashes/IDs (or emitted on release); payload/key is encrypted for them.*
*- Multi-sig equivalent: require M-of-N approvals (EIP-712 signed approvals or on-chain approve() calls) before release() can execute.*
*- Other criteria: add gates like 'not before date X,' 'only after block height H,' 'requires auditor key,' 'cooldown window,' etc.; release() checks all conditions.*
Tooling/stack: Next.js (ZEC-OS shell), Zebra, custom RPC/indexer/parser, PostgreSQL, EVM smart contracts with EIP-712 signed approvals, and decentralized automation (Chainlink/Gelato) plus redundant self-hosted watchdog bots.
### Upstream Merge Opportunities
No plans to merge at this juncture, and veyr keen on integrations after v1 is actualized.
Streamlined wallet UX will be crucial to overall UX.
### Hardware/Software Costs (USD)
$0
### Hardware/Software Justification
No dedicated hardware purchases are requested — the project runs on the existing ZEC-OS stack already built and operated by me.
The software stack relies on open-source components (Next.js, Zebra, archived zcashd, PostgreSQL, custom RPC/indexer/parser, plus open-source EVM tooling and signature libraries), so there are no proprietary licensing costs. Any incremental hardware/software needs (scaling the node, additional storage) are folded into the infrastructure service line rather than billed as capital expenses, keeping the budget lean.
Current fully functional stack:
- Zebra (and a zcashd node archived up to height 3,220,000)
- an RPC fully leveraging the node's validated blockchain state
- an indexer
- a parser that also computer pool states
- PostgreSQL to store both node states and processed data
### Service Costs (USD)
$5,000
### Service Costs Justification
Service costs can be summer up with 2 line items in our budget:
1. *Infrastructure (hosting, scaled node, private RPC, data storage, monitoring): $2,000*
2. *External security review (scope-limited): $3,000*
Infrastructure spend is required to host the apps, run a scaled Zcash node with a private RPC endpoint that the Notary and Capsule flows depend on, persist processed chain data in PostgreSQL, and run uptime monitoring for the deadman-switch watchdog bots. Specifying this as a redundant self-hosted watchdog bot array (multi-provider/Tor-capable) for maximum reliability at this time.
Security review is justified by the threat surface - Privacy Capsule targets sensitive-source workflows (journalism), privileged communications (legal), and audits and attestations with controlled disclosure (compliance), where a vulnerability in encryption, key handling, or release logic could expose sources or invalidate legal proofs.
Infrastructure costs exceeding estimate would be compensated from the development side, so the service-cost ask is a hard ceiling rather than an open-ended draw. Financial viability review post release will be mandatory.
### Compensation Costs (USD)
$41,400
### Compensation Costs Justification
Development compensation can be broken down as requiring 600 hours of work (25hrs/week, 20 weeks) at $69/hr.
This covers full-stack work across the ZEC-OS program, the standalone web app, the open-source verifier (CLI + web), client-side encryption, the time-release/deadman-switch contract layer, threat modeling, documentation, and pilot onboarding.
I am going with a conservative $69/hr rate for a scope that spans frontend, backend, node/indexer integration, EVM contract work (EIP-712 signed approvals, M-of-N release logic), and security-sensitive design for high-stakes users.
All funding is tied to milestone deliverables. Milestones can be more granular on request.
### Total Budget (USD)
$46,400
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
- **Cryptographic and key-management surface.**
Client-side encryption, recipient-targeted key wrapping, and EIP-712 signed approvals are all places where a subtle bug becomes a catastrophic failure for the exact users this targets (journalism, legal, compliance). The external security review partially mitigates key-handling and threat-model risks, by not relying solely on the in-house developers.
- **Deadman-switch reliability.**
Release depends on a mix of permissionless on-chain calls, third-party automation mechanisms and self-hosted watchdog bots. Any one path can fail silently (missed check-in, RPC outage, gas spike, network censorship), and getting the redundancy logic correct - without producing false-positive releases - is non-trivial. User messaging on network and system reliability is imperative during user onboarding. Supplementing watchdog model with multiple online backups will help mitigate some of this.
- **Cross-chain / EVM dependency.**
Anchoring on Zcash while enforcing release rules in EVM contract state introduces coordination complexity, gas-cost volatility, and an additional attack surface. If the EVM-side approach proves untenable, the lock/release model has to be rebuilt on an alternative substrate mid-project. If a user decides to use EVM tech, it will create a UX consideration for using multiple wallets for multiple signatures, on multiple networks. Extra steps = more complicated UX considerations.
- **Sustainability assumptions.**
The post-grant model relies on usage fees and a possible sliding gas scale to cover operating costs. If fee uptake lags, infrastructure (node, RPC, monitoring, watchdogs) becomes an ongoing personal cost. Infrastructure overruns post hard-launch would force financial model reconsiderations. Tl;dr: capitalism.
- **Regulatory and jurisdictional exposure.**
Timestamping, controlled disclosure, and deadman releases interact with evidence rules, data-protection law, and lawful-intercept regimes that vary by jurisdiction. The product is explicitly voluntary-disclosure tooling, but pilot users (especially legal/compliance) will need clear guidance on what the Proof Bundle does and does not legally establish. Unclear if this is a risk or a feature.
- **Verifier trust and independence.**
The verifier must be reproducible and runnable without relying on the project's own node/indexer; if users have to trust the applicant's RPC to verify, the "credible proof" property is weakened. Keeping the verifier truly independent (and well-documented) is a continuous design constraint, not a one-time deliverable. Further considerations would be to collaborate with other RPC providers, or allow users to provide their own endpoints to use in the app (exposed features to user).
### Potential Side Effects
- **Misuse for coercion or evidence-laundering.** A tamper-evident "prove this existed at time T" tool can be weaponized. E.g., backdating claims via pre-anchored decoy hashes, or constructing deadman releases designed to coerce recipients. The UX/UJ and docs need to be explicit about what a Proof Bundle does and does not establish; clear messaging is tantamount in-app.
- **False sense of legal weight.** Pilot users (especially in legal/compliance) may treat Proof Bundles as standalone evidence when they only prove hash existence at a block height, not authorship, authenticity, or chain-of-custody, which could lead to overreach in disputes or filings. Proof bundles may need to be wrapped with additional identity related provisions if necesasary.
- **Reputational and regulatory blowback on Zcash.** High-profile misuse (illicit dead-drops, harassment capsules) or jurisdictional pushback against privacy-preserving notarization could attract negative attention to the broader Zcash ecosystem, even though the product is explicitly voluntary-disclosure tooling. Example: Wikileaks led to potential endangerment of life, and international tensions. It is up to the user to decide moral weight, the tool in and of itself is just a mechanism.
### Success Metrics
- **Shipped v1 + open-source verifier.**
Production release with docs, threat model, and a reproducible verifier (CLI + web) that anyone can run independently of the project's own infrastructure.
- **Real pilot usage.**
At least 3 pilot users/orgs (preferably across journalism, legal, and compliance) running end-to-end workflows. Not just signups, but actual sealed capsules, anchored proofs, and at least one successful release event.
- **Proof Bundles used in real "show me proof" scenarios.**
Documented cases of Proof Bundles being referenced in publishing timestamps, audits, or dispute resolution by external parties.
- **Operational reliability.**
Verifier reproducibility rate of 100% on shipped bundles, deadman-switch check-ins/releases firing correctly in test + pilot conditions, and zero critical security findings outstanding from the external review at launch.
### Startup Funding (USD)
$13,000
### Startup Funding Justification
Startup funding is needed because the team is stepping away from paid client work to focus on Privacy Capsule full-time for the duration of the build. Without runway, the 25hrs/week Ă— 20-week commitment to a high-stakes, security-sensitive product simply isn't sustainable for independent developers.
The grant funds direct, milestone-tied development, the infrastructure required to run a scaled Zcash node, private RPC, storage, and deadman-switch monitoring, and an external security review appropriate to the threat model of journalism/legal/compliance users.
None of the funding goes to overhead, marketing, or speculative scope — it's a focused ask to ship a production v1, an open-source verifier, and real pilot deployments.
As cypherpunks and privacy-focused builders, we're committed to this work regardless; startup funding is what lets us do it properly, in the open, and on a timeline that actually ships a product to users that need this kind of service.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): $0 - startup funding covers first phase.
Expected Completion Date: Week 5 from project start
Partially Role Played User Stories:
- "As a journalist, I want to anchor a content hash on Zcash and receive a copyable Proof Bundle, so that I can later prove my draft existed at a specific point in time without revealing its contents."
- "As an independent verifier, I want to run an open-source CLI against a Proof Bundle, so that I can validate authenticity without trusting the issuer's infrastructure."
- "As a researcher, I want to publish a timestamped commitment alongside my paper, so that priority and integrity are provable after the fact."
Deliverables:
- Product spec and UX prototype for the Notary flow (ZEC-OS program + standalone web app)
- Client-side hashing and Zcash anchoring pipeline
- Proof Bundle format v1 (hex string, downloadable file, with delivery paths for QR/email and ERC-721 metadata)
- Open-source verifier v1: CLI + simple web verification page, with documentation
- Sample Proof Bundles and reproducible verification steps
Acceptance Criteria: A pilot tester can anchor a hash via the app, receive a Proof Bundle, and an independent third party can verify it end-to-end using the open-source CLI without relying on project-controlled RPC.
- Milestone: 2
Amount (USD): 14,400
Expected Completion Date: Week 11 from project start
Potential Role-Played and/or Real User Stories:
- "As a lawyer, I want to seal privileged content in a client-side encrypted capsule with a time-based release rule, so that designated recipients only see it under conditions I define."
- "As an at-risk researcher, I want a deadman switch on my capsule, so that critical findings are released to trusted recipients if I don't check in for N days."
- "As a source-protective journalist, I want my encryption keys to never leave my browser, so that the project itself cannot read my capsule contents."
Deliverables:
- Client-side encryption flow (keys generated and held in-browser; only commitments + minimal metadata anchored)
- Time-release rules ("unlock at date/time" and "unlock at block height")
- Deadman switch (beta): checkIn() / release() logic with EIP-712 signed approvals and M-of-N gating
- Recipient delivery options: encrypted payload, webhook/email notification, or published reveal key
- Draft threat model and security hardening plan
- Beta release + updated docs
Acceptance Criteria: Pilot users can create encrypted capsules with at least one time-release and one deadman configuration; release() fires correctly under test conditions and is blocked when conditions are unmet; the draft threat model is published for community review.
- Milestone: 3
Amount (USD): 19,000
Expected Completion Date: Week 20 from project start
User Stories:
- "As a compliance lead, I want a team vault with 2-of-3 approvals to unlock or export, so that sensitive evidence isn't dependent on a single team member."
- "As an auditor, I want export packs formatted for legal/compliance use with retention policies and an audit log, so that I can hand over verifiable evidence in dispute resolution."
- "As a pilot org operator, I want monitoring and redundant watchdogs on my deadman capsules, so that release conditions are evaluated reliably even if one path fails."
Deliverables:
- Org features: team vaults, M-of-N approvals, retention policies, export templates, audit log of exports
- Hardening: test suite, edge-case coverage, monitoring, redundant watchdog bots (multi-provider/Tor-capable)
- External scope-limited security review and resulting fixes
- Public v1 launch with docs, finalized threat model, and outreach kit for pilot onboarding
- At least 3 pilot users/orgs (preferably across journalism, legal, compliance) running end-to-end workflows
Acceptance Criteria: v1 is publicly available with complete docs, threat model, and verifier; the external security review is complete with no outstanding critical findings; ≥3 pilot users/orgs have executed end-to-end workflows (anchor → seal → release/verify); at least one Proof Bundle has been referenced in a real "show me proof" scenario (publishing, audit, or dispute).
```
### Supporting Documents
```files.yaml
Here is the original grant application I wrote out, in .md format, aggregated:
# Grant Application: Privacy Capsule
**(Time Capsule / Notary / Deadman Switch utilizing ZEC)**
This is an application for funding to build a Privacy Capsule: a client-side encrypted “vault” that lets journalists, lawyers, compliance teams, researchers, and everyday users seal information, prove it existed at a point in time, and optionally disclose it later—without leaking sensitive content by default.
**Privacy Capsule combines three workflows:**
- Notary / Proof-of-Existence (timestamp a file/message hash on Zcash)
- Sealed Capsules (encrypted messages / references that remain private)
- Time-based release and/or Deadman Switch (unlock/release rules with explicit user intent)
This is not a surveillance product. It is a voluntary disclosure tooling designed for people who need privacy and credible proofs.
## Background
I have already built ZEC-OS, a NextJS “operating system” GUI emulator with windowed apps (price, charts, explorer, stats, etc) powered by my own stack. I’m running Zebra (with zcashd node archived up to height 3,220,000), an RPC fully leveraging the node’s validated blockchain state, an indexer, a parser that also computer pool states, and PostgreSQL to store both node states and processed data. The system already parses and stores historical chain data locally, supports real-time refresh, and is structured to ship additional “programs” inside the OS (can be considered apps).
**Privacy Capsule will be delivered as:**
- a ZEC-OS program (native app experience inside the experimental OS UI)
- a standalone web app (for broader adoption, and integration into future app suites)
considerations for standalone mobile app can be considered in the future.
## Why Zcash?
**Zcash’s privacy focus makes it a compatible home for:**
- sensitive-source workflows (journalism)
- privileged communications (legal)
- audits and attestations with controlled disclosure (compliance)
- integrity proofs for research and publishing
Privacy Capsule turns “privacy as a feature” into “privacy as a usable workflow.”
## What I’m Building
### **1) Notary + Proof Bundles (Core)**
- User selects a file or text (client-side).
- App computes a hash locally and anchors a commitment on Zcash.
- App generates a Proof Bundle (copyable + downloadable) containing:
- content hash
- txid
- block height + timestamp reference
- verification instructions
- Provide an open-source verifier (CLI + simple web verification page).
The above ultiamtely doubles as a receipt; the proof bundle is both the proof that it worked, and the key to the verifier.
Bundle provision will depend on user's submission model. Options for delivery will be tied to whether it was done via networks that are virtual machines (Ethereum -> erc721 NFT with metadata attached; MD can live fully on-chain, as can SVG media or html/js content in `animation_url`), traditional centralized tech (QR code sent to email), or other methods such as a pure binary/hex proof file.
Example of hex: `5a50435001|sha256:<contentHash>|txid:<txid>|height:<blockHeight>|time:<timestamp>|commitment:<zcashMemoOrOpReturnCommitment>`
Verifier would decode, re-hash the content, check against hash matches, and verify the txid/block data against the node/indexer.
Public (external party) verification models can be considered, so a tally of live capsules can be taken, with option to "hide" the capsule if a user wishes to keep it out of the public count.
### **2) Encrypted Capsules (Client-side first)**
- Encrypt content in the browser (keys never sent to server).
- Store encrypted payload (or payload reference) in user-controlled storage.
- Anchor only commitments + minimal metadata required for operation (rate limits, non-sensitive logs).
### **3) Time Release + Deadman Switch + Other Methods**
Designed to be a multi-option lock/release model. Model selected during setup process and prior to final submission.
- Time-release: “unlock at date/time” or “unlock at block height.”
- Deadman switch: “if I don’t check in every N days, release to designated recipients.”
- Other methods: password, identity unlocks (email, ecnryption string, user auth), shielded memo with ascii string, etc.
- Release can mean: send encrypted payload to recipients, email/webhook notifications, or publish a reveal key (configurable and explicit).
**Deadman-switch execution triggers:**
- Permissionless on-chain calls (anyone can call release() once conditions are met)
- Decentralized automation networks (e.g., Chainlink Automation/Gelato)
- Redundant self-hosted watchdog bots (multi-provider/Tor-capable) for maximum reliability.
Additional considerations would be surrounding transactions that initiate conditions that lead to a time capsule's creation. Examples would be timer countdowns, or waiting for a specific kind of transaction from a specific address(es) to trigger it.
**Also enforced via encoding the rules in the contract state + signatures:**
- Check-in rule: checkIn() updates lastSeen; release() is allowed only if block.timestamp > lastSeen + N.
- Recipients: stored as hashes/IDs (or emitted on release); payload/key is encrypted for them.
- Multi-sig equivalent: require M-of-N approvals (EIP-712 signed approvals or on-chain approve() calls) before release() can execute.
- Other criteria: add gates like “not before date X,” “only after block height H,” “requires auditor key,” “cooldown window,” etc.; release() checks all conditions.
Note: using EVM states to enforce actions and/or other decentralized mechanisms is primary preference at this time, but not set in stone.
### **4) Org Features (Potentially high-value users)**
- Team vaults (eg. 2-of-3 approvals to unlock/export)
- Policies (retention, export templates, audit log of exports)
- Export packs designed and formatted for legal/compliance use
## Success Criteria
- Production release (usable v1) with docs + threat model + reproducible verification steps (documentation provided)
- Publicly available, open-source verifier tooling.
- At least 3 pilot users/orgs testing end-to-end workflows (preferably: journalism, legal, compliance)
- Proof Bundles used successfully in real “show me proof” scenarios (publishing with timestamp, audits, dispute resolution)
## Milestones (5 months)
### **Milestone 1 (Week 5)**
- Spec + UX prototype
- Notary flow (hash -> Zcash anchor)
- Proof Bundle format v1
- Verifier v1 (CLI + docs)
**Deliverables:** demo, docs, verifier repo, sample proof bundles
### **Milestone 2 (Week 11)**
- Encrypted Capsules (client-side)
- Time-release + Deadman switch rules (beta)
- Threat model draft + security hardening plan
**Deliverables:** beta release + docs + threat model draft
### **Milestone 3 (Months 3-4)**
- Org features (team vaults, export templates)
- Hardening: tests, edge cases, monitoring
- Public launch + outreach package for pilot onboarding
**Deliverables:** v1 launch + docs + outreach kit
## Budget Summary
- Development: 600 hours (25hrs/week, 20 weeks) @ $69/hr = $41,400
- Infrastructure (hosting, scaled node, private RPC, data storage, monitoring): $2,000
- External security review (scope-limited): $3,000
- Total: $46,400
- All funding is tied to milestone deliverables. Milestones can be more granular on request.
Infrastructure costs exceeding estimate would be compensated from Development side.
This architecure will be designed around an existing set fee for usage, which would additionally be able to potentially cover deployment costs if there is a sliding gas scale for using models such as EVM in the workflow for lock and/or release mechanisms/conditions.
Once live, a revisit on operating costs would be crucial/fundamental, with usage fees potentially being directed towards operating costs, as outlined below in Sustainability Plan.
## Sustainability Plan
- Core verification + basic notarization remains free.
- Paid tiers cover org features, higher limits, export packs, alerts/webhooks, and support.
- Longer-term: API + integrations for teams that need repeatable, auditable proof workflows; will require funding revisit, or operations reconsiderations.
## Closing Thoughts
Privacy Capsule is designed to make Zcash’s privacy useful in day-to-day high-stakes workflows—without turning it into a surveillance system. I welcome all feedback, and am keen to answer questions publicly.
Thank you for considering this proposal.
```
