Tells: a privacy checkup for Zcash wallets

1. Executive summary and decision snapshot

Request: Kai Chen, applying as an individual and sole developer, seeks $24,000 across four milestones over approximately four months for Tells, a local wallet-history privacy checker and pre-withdrawal warning tool. The application is under review. Funding would extend a reported TypeScript prototype into Rust, browser scanning, and a wallet integration example. [1][4]

Strongest capability evidence: The applicant describes an existing open-source library, command-line scanner, and demonstration using a real testnet wallet, with findings linked to transactions. This is more concrete than a concept-only proposal, but the supplied evidence is an applicant description rather than independent technical validation. [1]

Decision focus — inference: Value depends principally on trustworthy warnings and actual wallet use, not simply producing another scanner. Evaluation should prioritize rule validation, a committed integration partner, and testable payment conditions for the proposed deliverables. [1][4]

2. Applicant and team track record

Kai lists prior work on orthodontic mesh-collision checks, an offline point-of-sale application producing ZATCA-compliant invoices, and data pipelines published on the Apify Store. These are self-reported experience claims; the supplied evidence does not establish their quality or commercial outcomes. [1]

There are no additional team members listed. Kai would handle design, implementation, testing, documentation, user testing, and maintenance. The current Tells prototype is the strongest directly relevant work described. [1]

Prior ZCG delivery and independently verified security expertise: No grounded evidence found. This does not establish that the applicant has no prior grants or relevant expertise.

3. Proposal scope, milestones, budget, technical approach, and dependencies

Proposed funded work:

• Rust: tells-core, retaining the existing rules and test vectors, callable by librustzcash-based wallets before constructing transparent or TEX transactions.
• Browser: scanning through WebZjs without requiring a terminal.
• Integration: a wallet integration example reviewed with its maintainers.
• Analysis and testing: look-alike deposit counting, a weekly aggregate measure of mainnet pool-crossing linkability, and testing with real users. [4]

Current approach: The applicant says the scanner imports a unified full viewing key into a local view-only wallet through zcash-devtool and reconstructs shielded-pool boundary crossings from zcash_client_sqlite views. Rules examine amounts, timing, address reuse, round trips, sum matches, and pool migrations. Compact blocks provide counts of similar exits that affect link grading. Proposed withdrawal alternatives are rechecked before being suggested. [1]

Funding structure: The total, milestone count, and approximate duration are stated. Per-milestone payments, startup allocation, cost breakdown, milestone sequencing, and detailed acceptance thresholds: No grounded evidence found. Consequently, the committee cannot yet assess payment proportionality or whether the budget supports the entire scope. [1][4]

Dependencies include the named Zcash libraries and tools, WebZjs, and wallet-maintainer participation. The supplied proposal describes intended maintainer review but provides no named partner commitment. [1][4]

4. Community discussion, arguments, responses, and resolution

Strongest argument for funding: The applicant argues that generic transparent-address warnings do not identify a particular withdrawal that resembles a recent deposit. Tells would make warnings transaction-specific and offer alternatives before sending, rather than only explaining privacy loss afterward. The applicant also presents browser access and reusable wallet code as ways to make the prototype useful beyond command-line users. [1][4]

Arguments against: No grounded evidence found for substantive community objections. The supplied forum discussion contains the applicant’s introduction and a hidden reply whose content cannot support an argument. [4]

Applicant responses and resolution: The introduction clarifies the intended outputs and explicitly asks wallet developers where checks should fit and what would make warnings trustworthy. It does not document a response to a substantive challenge. Resolved technical concerns or remaining community disagreement: No grounded evidence found. Silence should not be interpreted as endorsement. [4]

5. Relevant precedents and documented outcomes

• Zcash Privacy Capsule — $46,400, declined. The committee cited an unclear use case, implementation concerns, and lack of wallet support; members questioned whether users would adopt a standalone tool and whether separate funding was warranted. Relevance — inference: This is the strongest precedent for testing Tells’ integration and adoption pathway. Its rejection does not establish that Tells has the same weaknesses, particularly given Tells’ proposed pre-send integration. [10][4]
• Zcash in the privacy stack — $5,000, approved after narrowing. The committee supported a smaller, proportionally cheaper exploratory pilot after questioning the original proposal’s cost, relevance, and reach. Two milestones are marked complete, but substantive readership or ecosystem-impact outcomes are not supplied. Relevance — inference: This supports considering a bounded experiment where value is uncertain, not a software-cost benchmark or proof that completion generates impact. [8]

6. Material risks and execution considerations

The following are evaluation inferences, not documented failures:

• Warning reliability: Amount-and-time heuristics and crowd-adjusted grades require calibration. Incorrectly reassuring users or generating excessive warnings could undermine the intended privacy benefit. Suggested actions such as splitting or rounding should demonstrate improvement under a stated threat model. [1]
• Sensitive-data handling: Viewing-key access and browser scanning make key storage, network requests, logging, and deletion behavior material security-review topics. The promise of local processing is important but is not itself a security assessment. [1][4]
• Execution concentration: A single developer covering two language implementations, browser support, integration, analytics, and user testing creates schedule and maintenance exposure. [1][4]
• Evidence-to-impact gap: A reproducible testnet demonstration can support technical feasibility, but demonstrating useful mainnet guidance and changed user behavior requires different tests from reproducing scanner findings. [1][4]

7. Material gaps and questions for the applicant

• Payment and acceptance: What amount, date, dependency, and objective acceptance test attaches to each milestone? Who independently accepts each deliverable?
• Integration commitment: Which wallet maintainer will review the work, what have they agreed to, and does delivery mean an example, a merged integration, or a released user feature?
• Accuracy and safety: What threat model, labeled cases, false-positive/false-negative measurements, and independent review will validate the grades and proposed withdrawal alternatives?
• Viewing-key protection: What data leaves the device, where are keys retained, and how will browser storage, telemetry, errors, and deletion be tested?
• Capacity and sustainability: What demonstrates readiness for Rust and WebZjs delivery, what work is deferred if the schedule slips, and what maintenance is included after the grant?
• User value: What baseline and measurable targets will show that users understand warnings and make better decisions? How will the weekly linkability measure avoid being presented as proof of deanonymization?

8. Neutral decision considerations

Committee options — inference: A full-scope award would purchase broader development but expose more funding before accuracy and integration value are established. A narrower initial phase could instead test rule parity, independent validation, and maintainer acceptance before browser and aggregate-analysis expansion. These are funding-structure options, not an approve-or-reject recommendation. [1][4][8]

Whichever structure is considered, distinguish code delivered, wallet integration accepted, and privacy benefit demonstrated. Tie payments to the first two through explicit acceptance tests, and require a credible measurement plan for the third rather than treating software completion as impact. [1][4]

9. Numbered source list

• [1] Grant Application - Tells: a privacy checkup for Zcash wallets — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/462
• [4] Grant Application - Tells: a privacy checkup for Zcash wallets — posts 1–5 — https://forum.zcashcommunity.com/t/grant-application-tells-a-privacy-checkup-for-zcash-wallets/58025/1
• [10] Zcash Privacy Capsule (ZPC) — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/304
• [8] Zcash in the privacy stack — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/339