Zcash Sapling Parameters Availability Hardening

Zcash Sapling Parameters Availability Hardening

Declined

This project improves the reliability of shielded transactions across the Zcash ecosystem by eliminating a single point of failure in how some wallets and SDKs obtain Sapling proving parameter files required for private spends. Today, runtime downloads from a single host can fail due to slow, blocked, or corrupted transfers, leaving users unable to complete payments even when the network is otherwise functioning. The team will implement upstream multi-origin, hash-verified fallback logic in librustzcash, add adversarial regression tests to simulate real-world HTTP failures, and provide two additional independently hosted HTTPS mirrors with automated integrity checks. By addressing the issue at the shared dependency layer, all downstream wallets benefit automatically, improving availability and first-spend success rates without introducing new trust assumptions, reducing support burden for wallet teams, and strengthening overall confidence in shielded ZEC payments. Applicant is requesting $30,000. Gguy: I personally have concerns about the need for this work. I think there are already solutions which developers are using and I don’t think it would be beneficial to fund an upstream PR of this nature at this time. Hanh: To me it’s a minor issue because it impacts Sapling and not being able to find parameters can be solved at the application layer in several ways. It could be embedded in the application. It could be sourced from a website. It could be sourced from the application website. That’s a choice that the user takes or the application takes. Having it pushed into the librustzcash is not going to help much even if it happens (even though I highly doubt that it would happen because this is not the philosophy of the library). We don’t hardcode anything in the library. I don’t see much value in doing so. So I reject as well. Artkor: I appreciate that the applicant regularly surfaces and opens issues raised by core developers in repositories but I personally have serious reservations about outsourcing work on such infrastructural questions. Hanh: Well these are issues open on GitHub on the project but I haven’t followed exactly who opened the issue but we should bear in mind that anyone can open an issue on a project. It doesn’t necessarily mean that it’s a good issue. Zerodartz: It seems a bit overpriced and not necessary for Zcash right now. Gguy: I think historically we’ve have learned that there has to be caution with funding applicants to work on core infrastructure code that’s going to require detailed reviews and core developers time to review and merge. This is one of those cases where it’s hard to see a net benefit when the proposed solution and work would likely need continued and ongoing feedback for core devs to even stand a chance of being merged. Decentralistdan: reject due to cost and reliance on external Zcash core team Declined (unanimous)