I have submitted a Zcash Community Grants application for a ten-week, $8,500 project to fix three documented transaction-history integrity defects in zcash_client_sqlite.
The target issues are:
librustzcash #2918: the public transaction history view exposes a nullable trust status that caused one downstream mobile SDK to fail an entire history query.
librustzcash #3005: unusable stored raw transaction data prevents the wallet from requesting a valid copy.
librustzcash #3009: shielded outputs can remain without sent-note attribution when the funding account becomes known after storage.
The deliverables are narrow upstream Rust pull requests, deterministic regression fixtures, idempotency and compatibility tests, and validation through at least one official mobile wallet SDK. The project does not assume that every wallet user currently encounters all three cases; it addresses known states in the shared wallet backend that can otherwise remain permanently stale.
Budget and schedule:
$2,500, weeks 1–3: failing fixtures and maintainer-reviewed repair designs.
$3,500, weeks 4–7: three focused upstream implementations and regression coverage.
$2,500, weeks 8–10: mobile SDK validation, integration notes, and final report.
I welcome feedback from librustzcash, Zcash Swift/Android Wallet SDK, and Zallet maintainers on the proposed repair boundaries and downstream validation path.
On your grant proposal, two of the three issues this application targets, librustzcash #3005 and librustzcash #3009 were opened by Kris Nuttycombe (ZODL) on 25 August as follow-up issues to librustzcash #3006 (Maintain transparent recognition under address-book growth via a durable involvement index)
The third issue, librustzcash #2918, is a one-line change to a view definition in zcash_client_sqlite’s wallet database.
What is your relationship with the librustzcash maintainers? Have you discussed these issues with @nuttycom, and if so, has he indicated whether he intends to address them himself as part of the #3006 work, or whether he’d welcome someone else doing so?
Hi @craftsoldier, thank you. This is a fair and important question.
I have not previously worked directly with the librustzcash maintainers, and I had not discussed #3005 or #3009 with @nuttycom beforehand. I identified these two items as open follow-up issues while reviewing #3006 and the related wallet-state problems.
Following your question, I asked @nuttycom whether he intends to work on these issues and whether external contributions would be welcome:
I will share an update here when he responds. If work on these issues is already planned, I will avoid duplicating it and instead focus, in coordination with the maintainers, on areas where an external contribution would be useful.
I also agree that #2918 is small in terms of the code change itself. The work around it is not limited to the one-line change; it also includes a regression test that reproduces the failure, compatibility checks against existing wallet databases, and downstream validation in a mobile SDK.