I am afraid then its a no from me. Its up for representatives of the community AKA ZCG to decide how to dispense of the money. At a minimum, it should be up to ZCG which community project to audit.
Let’s turn this into a question for the community: which Zcash-related projects do you all feel are the most important to audit and provide design / threat modelling support for?
zingolabs wants to be audited.
Great, tho how will it work? People of the community will suggest their favorite project to get audited and you will decide which one gets your attention first? Will there be a vote for which project the community thinks should be a priority over others? Should it go to ZCAP for a vote?
ZWL, NH, YWallet, Edge, Unstoppable, Trezor shielded (!), ZSAs, Zephyr all come to mind! Not sure if all needed but just getting a list going 
Free2z, Zgo, Zebra?
I personally think active members of the community should have discussions on the forums to decide the list of projects and try to prioritize things. I don’t think the stakes are high enough to warrant ZCAP votes. There can be certain metrics for determining which things to prioritize first (number of users, project complexity (?), whether the project has had any audits before, etc.), which I suggest people more informed than myself try to figure out here.
@earthrise included a very valuable unit of work in this proposal
Paraphrasing: I’ll observe the adoption of apps, to help decide which to focus on.
He could simply:
He wouldn’t necessarily have to slavishly “obey a number”, but he could default to auditing the most “important/widely adopted” thingie. He could explain deviations.
Maybe I am just repeating what he said in the application. I don’t recall if he declared that he would publish prevalence data.
As a community, we should first decide which goal we’re optimizing for within this project. There are several competing goals I can see being supported within the community and I’d like all of your feedback on which is the most important:
What do you all feel is the most important goal? What should we be optimizing for? Do you have a different idea for an optimization goal other than those that I’ve listed?
p.s. Thanks so much for the great feedback from everyone so far!
- … means supporting projects with priority weighted by a number of factors: high user count, likelihood of bugs, impact of security bugs on users, quality of any existing security support, potential for reputation damage to the Zcash community as a whole, and projects in the process of making security-critical design decisions.
This sounds very good to a person like me!
If you’re sending periodic updates (that won’t, god forbid, somehow be a tell explicitly or by omission for a terrible vuln in some way?) I can’t see a better way to apporach this.
The community could impose more oversight–and they probably ought to for projects with applicants with a less-established track record–but my 2 zats are for letting someone who knows what they are doing to have real flexibility in pursuing the tasks they think would be the most beneficial to everyone.
A very long time ago Taylor looked at some of my code (amateur stuff, work in progress, etc) and sent feedback - including a list of important things I’d borked and stuff to consider.
It was completely unexpected & very welcome. Just thought I’d share that, small projects also benefit from a little attention.
Out of curiosity, what was your day to day like at ECC?
Did you get up to date on research and then attempt to apply any learnings to the Zcash protocol?
Did you continuously audit every PR being made to the zcash repo (and supporting repos)?
I think this might give the community a better idea of what you will be doing for the grant and what to expect.
Overall, it’s a yes from me as I think Zcash needs more focus on security as it relies on novel cryptography.
My day-to-day has shifted a lot over the years! Some highlights relevant to the grant are (a) working closely with ECC’s Wallet Team to audit the code and set security priorities (b) auditing the Orchard protocol and some of the implementation (c) lots and lots of leading responses to bug reports that come in. There was even a term where I focused a bit on ecosystem security support, doing some review of ZecWallet-lite and smaller projects. Lately, I’ve been working with @daira on labeling all of the consensus rules in the Zcashd code to make audits faster as well as some infrastructure security things.
I did a bunch of PR review involving security-critical changes, but I wouldn’t say PR review was my main focus. ECC’s security policy is to have engineers cross-review each other’s PRs (3 reviews for consensus changes and cryptography), so PRs are already getting excellent review.
In terms of research, I’m really interested in light wallet privacy, so I’ve done a lot of reading up on the formal definitions of network privacy and various projects (Tor, different kinds of mixnets, etc.). Scattered through various tickets I have some designs for a side-channel-resistant light wallet protocol.
Edit: Oh! I forgot some of the coolest projects: I helped build kubernetes-based fuzzing infrastructure for zcashd code and some tooling to automatically find threading/locking issues!
Hi @earthrise!
The ZCG committee met and discussed your grant proposal. We’re very excited about the opportunity to have someone with your background working independently of the ZF and ECC and in partnership with the community to secure the Zcash ecosystem. Overall your proposal looks strong and you have strong support from the community, but we have not voted on it yet. There is some hesitancy within the committee for funding via a salary-like milestone approach vice funding with specific monthly milestones in mind due to not fully understanding if there is enough work in the ecosystem for a full year agreement. With this in mind, we have a couple of clarifying questions for you about your grant proposal.
In your proposal you mention “The projects I choose to audit will be at my discretion (where I think review is most needed based on usage and risk), with input taken from the community and the grant committee”. You also mention in a forum response that the first 3 months would likely encompass ZecWallet-lite, Nighthawk, and the preliminary designs for ZSAs. Noting the current absence of comments from these projects on your proposal thread, we’re curious if you have had the opportunity to communicate with them privately to gauge their willingness to partner. Can you elaborate on other ideas you have for security audits/research/etc that could help persuade the committee that there is no shortage of security related work to be done?
We do not want to approve grants that are too open-ended resulting in required salary-like payouts for less than the agreed-upon effort (i.e. paying out for 17 days of work when only 10 were necessary that month). We’re optimistic that you will find the projects and partnerships necessary to earn the full 17 days of payment each month. You suggested the outreach and auditing buckets may vary in a given month which is understandable. We also recognize that there may be months when the full 17 days of work isn’t needed or more than 17 days of work is performed. In that case we would look to adjust the milestone payouts within the total budget allocated to the grant as necessary. The new grants platform provides the ZF more flexibility in managing milestones, and the committee has been flexible with grant applicants in this manner in the past. We would like to make sure that you’re comfortable with this and are thinking about the milestone payouts as flexibly as we are.
How would you prefer to collaborate with ZCG on ongoing efforts, embargoed audit reports, our thoughts about ecosystem audit needs, etc? Perhaps a monthly meeting that occurs before applying for the current month’s milestone payout to review the efforts from the current month and planned efforts for the next along with any other agenda items?
You mean 17 days.
Yes, Thank you
I think this should be the way to go about it. Harm reduction.
You also mention in a forum response that the first 3 months would likely encompass ZecWallet-lite, Nighthawk, and the preliminary designs for ZSAs. Noting the current absence of comments from these projects on your proposal thread, we’re curious if you have had the opportunity to communicate with them privately to gauge their willingness to partner. Can you elaborate on other ideas you have for security audits/research/etc that could help persuade the committee that there is no shortage of security related work to be done?
I haven’t reached out to those projects yet – I will do so now to get their feedback on the idea!
In terms of amount of work, I actually have the opposite concern, which is that 17 days might not be enough to support the entire ecosystem and we’ll have to expand this program in the future!
It’s pretty common for audits to always run out of time, having to exclude certain things from the scope for the sake of being able to finish within the timebox. It’s somewhat of an inside joke between auditors that all the reports say “security analysis of dependencies is out of scope and left for future work”, and then that future audit never happens 
. So, even with a few projects, there’s an almost-never-ending supply of important audit work. I’ll take a look through some community projects and put together a more concrete picture of what this will look like.
This raises another question, which is whether we should include other security support work aside from audits and direct support for community projects. This would be stuff like:
I’d be happy to include some of these items as well, however it’d quickly start to need more than 17 days/month, so I’d recommend prioritizing the outreach/audits (“find, fix, and prevent bugs”) and then using any slack time for these extra projects.
We also recognize that there may be months when the full 17 days of work isn’t needed or more than 17 days of work is performed. In that case we would look to adjust the milestone payouts within the total budget allocated to the grant as necessary. The new grants platform provides the ZF more flexibility in managing milestones, and the committee has been flexible with grant applicants in this manner in the past. We would like to make sure that you’re comfortable with this and are thinking about the milestone payouts as flexibly as we are.
Yep, that makes sense to me! I predict that I’ll be able to fill the time, but in case I don’t, then of course I won’t bill for it. I also might take a couple weeks off for a vacation here and there, and in that case the payout would be delayed until all the work is finished or reduced so that you’re always only paying in proportion to the work that was actually done.
How would you prefer to collaborate with ZCG on ongoing efforts, embargoed audit reports, our thoughts about ecosystem audit needs, etc? Perhaps a monthly meeting that occurs before applying for the current month’s milestone payout to review the efforts from the current month and planned efforts for the next along with any other agenda items?
That sounds great to me, a monthly call is probably the best format!
For embargoed audits—we might not want to disclose the fact that a report is being embargoed, because that will tip attackers off that there’s a severe vulnerability in the project under review. To mitigate that risk, we could either (a) keep the identity of the project under review secret until the review is complete, or (b) publish the audit report minus the critical vulnerability. I prefer (a), since (b) is a little bit dishonest to anyone using the audit report to make a decision whether or not it’s safe to use the project. Do you have any thoughts/preferences on this?
I’ll get back to you with some more specifics on what the audit/outreach effort will look like!
In order to justify how much work there is to be done to support Zcash ecosystem security, here’s a list of projects I’d consider to be in scope and would probably be worth prioritizing in the first year.
Note that I haven’t started digging into any of the code or spoken with the developers in order to work out a relative prioritization yet. Prioritization would be based on a number of factors I mentioned above such as project activity, apparent quality of the code, amount of users, overall risk, etc.
Unless otherwise stated, I’d say all of the following would benefit from the full 10-day audit.
Edit: I’ve later added some things suggested in replies.
Wallets are on the front lines, and since they are responsible for storing users’ funds, they are what will expose the most users to the most risk, so they should be our highest security priority.
I love crypto so these will be really fun to audit. 
My vision for Zcash is to become a platform for developers to build awesome things on. That way, we can reach into totally unexpected use cases beyond payments and wallets. Eventually one such project will turn out to be a hit, and we’ll want to make sure it’s secure.
I’m probably missing a lot! @ me if you’d like to see your project added to this list. I also had the opportunity to skim through the grant application list and there are a bunch of cool ones I hope will be funded in the future, like shielded multisig once FROST is available.
I’d actually skipped over the above statement and went straight to the list of projects and thought “wallets - 2weeks each”.
Not my day job but had one (an audit) done the other month. Just wanted to add an outside opinion that those figures checkout (roughly) for all the projects listed.
Note: There’s a solid 7+ months of work as it’s listed. As previously stated it’s all about scope in this line of work. I haven’t looked at how big the codebase are but you could honestly spend a month looking at code and still pick meaningful things up. So personally I wouldn’t worry too much about lack of work. It’ll just be that the lucky teams that are around now will get more focus which is definetly never a bad thing for critical infrastructure like wallets.
@earthrise based in all the knowledge gained from app/wallet audits I wonder if it’s worth doing another round of zcashd/zebrad RPCs from the outside and making recommendations. (Full understanding existing RPCs can’t be changed). I guess that’ll become more obvious over time.
Is there place in your wallet list for Ywallet?