Secure-by-Default Zebra ↔ lightwalletd: Add RPC Cookie-File Authentication Support

Gguy: I’ve reviewed the implementation details, I think that this might be something that lightwalletd and Zebra team might need to do themselves. I’m not sure it’s the right time to do this without clear cooperation with that team.

Artkor: My current position is that it’s difficult for me to envision realistic scenarios in which Zebra and lightwalletd will be deployed separately in a way that requires a dedicated authentication scheme between them. In any case, I will prefer that change of this nature be implemented by the core backend developers of Zcash rather than external teams without a proven track record. So I reject.

Hanh: I will reject as well because I think this work, if it’s done by someone else, would need significant review by the authors of Zebra and Zallet and at the end of the day they will essentially do the work themselves. There is not much to outsource here.

Zerodartz: Agree with others. Reject.

Decentralistdan: agreed. reject due to reliance on core teams.

Laminar - The Tactical Spike: Batch Payment Infrastructure

GGuy: I personally don’t see this as a priority right now. This kind of fits in between solutions that already exist and I don’t currently see the benefits right now.

Artkor: I generally like this proposal. However, after the committee discussions, I have concluded there does not appear to be significant demand for it at this time. Recently, the community has been placing strong emphasis on demonstrated product demand. There are already custodial payroll and payout services available for Zcash. I have not seen clear evidence that this functionality is currently in high demand. So the proposal feels expensive relative to its immediate necessity. I hope the community will need to revisit this idea in the future. But at this time, I vote to reject it.

Zerodartz: It’s also my understanding that there is not much demand for it yet and maybe if it is needed in future it should be built into the wallets instead of having a special tool for it. Reject for now.

Hanh: For me, what they request in Milestone 1 is not infrastructure for batch payment but a converter between a list of payees as a CSV and converting that into payment URI. As it is this doesn’t represent the batch payment infrastructure, which would be valuable. But that’s not what it is here. I reject.

Decentralistdan: reject. Milestones not aligned with described infra work, and lack of clear demand for a standalone tool/product like this.

Gguy: I’m waiting to hear more feedback on the ability for this individual to contribute and we hope to have more information soon about the feasibility of this.

Artkor: It would help if core backend developers flagged tasks for outsourcing so the committee could better understand priorities.

Hanh: This doesn’t represent a classic way to contribute to our project, an open source project. First, you learn about the project, you communicate with the moderators, with the developers, and you find bugs that you can contribute, low-hanging fruits that you can fix and get a reputation with the project. This seems to be more like trying to pick an easy task and get a grant for that. There’s no sign of added value for these particular bugs and it feels awkward. I will reject, but it doesn’t mean that the guy who submitted this proposal can’t later submit something better after he gains some reputation.

Zerodartz: They might actually be good developers but the proposal itself is a bit much for the proposed fixes.

Decentralistdan: team seems qualified to contribute but would like to see them contribute and get involved in the open source development of Zcash independently as opposed to relying on a grant as a first step.

Decentralistdan: This definitely feels like a send to ZecHub request. In my mind this is a rejection at this price but we can discuss further.

Gguy: I agree. We’ll get in contact with the team on next steps.

Zerodartz: Would want to have more community feedback on it also.

Project Sentinel: Automated Dust Quarantine for Zodl

Artkor: I vote to reject because I don’t consider the issue described in this proposal to be relevant.

Gguy: I agree. This grant doesn’t resonate with me as a current need for Zcash.

Zerodartz: Same, reject.

Hanh: This is for transparent dust, it’s not very meaningful. Anyway, if it’s really dust, the price of spending it exceeds the fee as dictated by the zip 317. Wallets typically skip over dust inputs under that amount. I think it’s a non-issue actually.

Decentralistdan: reject. Out of scope for current funding.

Veridex: Passkey Shielded Wallets and AI Agent Payments

Hanh: I would be interested in splitting the grant in 2. First one for Passkey shielded wallet and the other for the AI agent payments.

Gguy: I vote we reject this now and we recommend the applicant split this up into two separate grants, one for the passkeys and one for the AI agents. We wouldn’t be interested in providing startup funding. If the applicant is able to resubmit as two grants we would prefer to review these applications separately.

Zerodartz: Passkeys are needed. Could this team deliver a working feature, not sure.

Decentralistdan: reject in current form.

Artkor: I appreciate the effort and the initiative to apply to our grants program, but I urge the applicant to stop here. Zcash is not an experimental playground. It is payment infrastructure that I consider part of the future of finance. I am not willing to rely on vibe-coding in this context and I would honestly feel embarrassed approving this grant.

Gguy: My concern is that the way that the application is described has more wording about how they’re going to achieve the goal when it feels like they probably could have described the implementation in the same amount of effort and it would have more clearly demonstrated a clear understanding of the work that’s required. I vote to reject.

Hanh: I reject because this submission is obviously AI generated and doesn’t show that the submitter has proper understanding of what the proposal is and how they can complete it.

Zerodartz: I understand it would be useful to have. The team doesn’t have proof of being trustworthy enough sadly.

Decentralistdan: out of scope due to AI generation proposal and lack of clarity on ability of team to execute

Artkor: I can reach out to the applicant to verify some details.

Gguy: Great, thanks Artkor.

Decentralistdan: I’m definitely open to exploring a Japan-based community building that they touch on as the second part there. And it might end up being again like a Zechub-style collab. Question for Alex: is there a restriction on lobbying as described in this application?

Alex: Lobbying isn’t allowed but the applicant is actually talking about education so no issues here.

Zerodartz: Japan community sounds like it could be good for Zcash. Would love to have community feedback and see Zcashers from Japan comment on it (if there are any out there).

Zerodartz: We are happy with their new connections made at ETH Denver. Would love to see community feedback on this new proposal also. We are also looking into some possible future plans with them at Berlin Blockchain Week.