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.
I have removed #2918 from the funded scope. The public-view change proposed there was declined in PR #2919 because nullable trust status is intentional, and the related decoding failure was addressed in Swift SDK PR #1945. My original proposal should have accounted for this.
Remaining scope and why it matters
- #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 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: 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 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.