# Grant Application - Zcash Wallet State Integrity: Self-Healing Transaction History **URL:** \ **Category:** Applications\ **Created:** [September 11, 2026, 1:37am UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-wallet-state-integrity-self-healing-transaction-history/57545 "2026-09-11T01:37:06Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Foreveranka](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/foreveranka/32/48151_2.png) [@Foreveranka](https://forum.zcashcommunity.com/u/Foreveranka)\ **Post date:** [September 11, 2026, 1:37am UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-wallet-state-integrity-self-healing-transaction-history/57545/1 "2026-09-11T01:37:06Z")
**Revision — September 15, 2026:** The request is now **$3,000 for ten weeks** , covering only **#3005 and #3009**. The original $8,500 / three-issue scope is superseded. [Updated GitHub application](https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/422) I have removed #2918 from the funded scope. The public-view change proposed there was declined in [PR #2919](https://github.com/zcash/librustzcash/pull/2919) because nullable trust status is intentional, and the related decoding failure was addressed in [Swift SDK PR #1945](https://github.com/zcash/zcash-swift-wallet-sdk/pull/1945). My original proposal should have accounted for this. ### Remaining scope and why it matters - **[#3005](https://github.com/zcash/librustzcash/issues/3005): recover unusable stored transaction data.** Raw bytes can be present but fail to parse. That presence suppresses retrieval of a usable copy, leaving the transaction’s recognition contribution skipped. [PR #3006](https://github.com/zcash/librustzcash/pull/3006) explicitly links this follow-up. The benefit would be recoverability through the existing retrieval pipeline; this is not a claim of a fund-theft vulnerability. - **[#3009](https://github.com/zcash/librustzcash/issues/3009): repair late shielded attribution.** If funding ownership becomes known after storage, an internal shielding transfer can remain indistinguishable from an external receipt to downstream history consumers. The issue describes an offline repair using stored transaction bytes and viewing keys. It was expressly left outside #3006’s transparent-only replay scope. Both issues were opened by Kris Nuttycombe on August 25 and remain open at this revision. The related #3006 PR continued receiving commits on September 14. These are specific residuals of current wallet work. [#3004](https://github.com/zcash/librustzcash/issues/3004) supplies real-wallet context for discovery-order problems: eight stored prevout transactions paying later-imported account addresses remained unrecognized. That is not a reproduction of either remaining issue, and its fix is not included in this grant. The initial work covers reproducible fixtures on pinned baselines and coordination of the repair designs and branch dependencies, especially the #3006 dependency. ### Deliverables, budget and schedule The total request remains **$3,000 over ten weeks** , with **two requested payments** : - **$1,500 startup funding:** an advance at project commencement after grant execution and confirmation of useful non-duplicative contribution scope. It supports dedicated development time for reproduction, design and the first repair. - **$1,500 at the midpoint, targeted for the end of week five:** released after ZCG accepts reproducible fixtures and reviewed designs for both issues, the implemented #3005 repair with passing regression checks, and a linked midpoint report. Payment depends on accepted deliverables, not elapsed time alone. Weeks six through ten complete #3009, upstream review iterations, one focused official mobile SDK integration check, compatibility notes and the final report. These remain required under the same grant, with **no additional payment at completion**. **$1,500 startup + $1,500 midpoint = $3,000.** The ten weeks are a calendar delivery window, not a full-time staffing estimate. If either issue is already resolved, overlaps another contributor’s work, or cannot be reproduced on the agreed baseline, I will report that and agree the appropriate scope, budget and treatment of any advance with ZCG before proceeding with affected work or requesting the next payment. ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [September 11, 2026, 2:52am UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-wallet-state-integrity-self-healing-transaction-history/57545/2 "2026-09-11T02:52:45Z")
Hi @Foreveranka, welcome to the forum! On your grant proposal, two of the three issues this application targets, [librustzcash #3005](https://github.com/zcash/librustzcash/issues/3005) and [librustzcash #3009](https://github.com/zcash/librustzcash/issues/3009) were opened by Kris Nuttycombe (ZODL) on 25 August as follow-up issues to [librustzcash #3006](https://github.com/zcash/librustzcash/pull/3006) (_Maintain transparent recognition under address-book growth via a durable involvement index_) The third issue, [librustzcash #2918](https://github.com/zcash/librustzcash/issues/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? ---
**Author:** ![Foreveranka](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/foreveranka/32/48151_2.png) [@Foreveranka](https://forum.zcashcommunity.com/u/Foreveranka)\ **Post date:** [September 11, 2026, 10:06pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-wallet-state-integrity-self-healing-transaction-history/57545/3 "2026-09-11T22:06:17Z")
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: > > > \`queue\_tx\_retrieval\` records enhancement intent only when no \`transactions\` row …holds raw data for the txid (\`WHERE NOT EXISTS (… raw IS NOT NULL)\`), on the documented rationale that present data must not implicitly become a status request. The guard treats "bytes are present" as "data is in hand" — but a stored \`raw\` that does not parse (truncated write, or bytes recorded by an import path this crate cannot read) satisfies the guard while being unusable. Such a row is inert forever: no code path ever re-fetches it, and lenient read sites that skip unparseable raws (correctly, to avoid failing whole operations on one bad row) silently forgo whatever that transaction would have contributed. > > This is currently a tolerated-but-unhealed state rather than a corruption vector: the wallet declines a recognition and invents nothing. It becomes more visible once the transparent involvement work for #3004 lands, whose reconciliation deliberately skips unparseable raws in several places. > > Suggested fix shape (needs the owner's call on what "the wallet holds this transaction" means when the bytes are garbage): a small \`invalidate\_stored\_raw(txid)\` that NULLs the column, invoked from the sites that discover the parse failure — the existing skip logic in \`queue\_tx\_retrieval\` then does the right thing unchanged, and re-storing the fetched data re-runs recognition so downstream state self-heals. The alternative — a persisted validity marker written at \`put\_tx\_data\`, which already parses — costs a migration. Either version turns today's read-only parse sites into writers, which matters where they run inside a migration's transaction (safe, but no longer read-only over \`raw\`). > > \--- > Prepared with the assistance of Claude Code. > Co-Authored-By: Claude Fable 5 \ 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. ---
**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\ **Post date:** [September 30, 2026, 1:15pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-wallet-state-integrity-self-healing-transaction-history/57545/4 "2026-09-30T13:15:33Z")
Thank you for submitting your proposal. After careful consideration by the ZCG and a period for community comments on the forum, the committee has decided not to advance this proposal. We genuinely appreciate the work and dedication you put into your application and hope you’ll continue to participate and contribute to the Zcash community. [Meeting minutes.](https://forum.zcashcommunity.com/t/zcash-community-grants-zcg-meeting-minutes-9-28-2026/57928)