Zcash Ecosystem Security Lead

Hi Zcash community!

I’ve applied for a grant and I’d like to hear your feedback and ideas! Here’s a copy-paste of my application to save you a click.

Who am I and what’s my background?

My name is Taylor Hornby and I’ve been working to secure Zcash-related infrastructure and codebases over the past four years as a senior security engineer at Electric Coin Co. In that time, I’ve developed a good understanding of the Zcash protocol, its cryptography, and the architecture of Zcash wallets. As a result of that knowledge and experience, I am well-positioned to offer my security services to a wider set of projects across the Zcash ecosystem.

Before working on Zcash, I was an independent security consultant and researcher. I performed security audits of cryptography-focused software like encrypted filesystems, I presented my research on using cache side-channels to attack everyday programs at Black Hat USA, and I co-authored a popular PHP encryption library. For education, I have a BSc in Computer Science and a MMath in Quantum Information. You can find most of my public work and writing on https://defuse.ca/.

Description of Problem or Opportunity:

Both ECC and ZF have strong security programs, with engineers focused on security and a reputation for regularly funding third-party audits of the software they build. Zcash community projects, like those funded by grants or built by volunteers in the community, are also in need of security support.

It is too expensive to staff each project with a dedicated security engineer, and audits alone are insufficient, because they only evaluate the code at one point in time. Audit reports often come too late, after crucial design decisions have already been made, and projects can find themselves stuck with poor design choices that could have been prevented by having security support early on. Another problem with one-off audits is that you often get a different set of auditors each time, so the auditors don’t have an opportunity to build up a long-term understanding of the project’s goals and architecture.

The Zcash community needs someone they can turn to for goal-oriented security advice, and someone who can provide security review based on a deep technical understanding of their projects’ designs and code.

Proposed Solution: Describe the solution at a high level.

My proposal is to become a security engineer serving the wider Zcash ecosystem outside of ECC and ZF—at least as much of it as I reasonably can. Like any security engineer, I will provide regular security audits of ecosystem projects culminating in reports that will be published for the community to see. Going beyond audits—and this is crucial—I aim to build relationships with ecosystem project leaders and developers so that they feel comfortable asking me me for security advice, and so that I have an opportunity to help them strengthen their own internal security practices and designs.

Solution Format: What is the exact form of the final deliverable you’re creating?

There are three components to what I’m proposing: outreach, security analysis, and remediation support.

  • Outreach: I will offer regular “security office hours” to as many community projects as I can, within a timebox. Project leaders and developers will be able to join a private call with me to discuss where their project is headed, talk though security risks, get feedback on proposed designs, assistance with threat modeling, and so on. For example, this might look like a one-hour meeting each month per supported project, plus additional time for research and responding to questions over chat/email. The precise format of my outreach will adapt to what proves to work best.

  • Security Analysis: Each month, I will perform an in-depth security audit of one Zcash ecosystem project (or part of one). The deliverable will be an audit report detailing the issues found, suggested bug fixes, and other security-focused comments on the designs and code. These audits will help uncover security bugs, preventing attacks on Zcash users, and will give the Zcash community insight into the security quality of the projects we decide to fund. I’m especially excited to audit the implementation of ZSAs, wallets like Nighthawk, and other projects built on Zcash like Zbay and hardware wallets. 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. I will also publish any tooling I build to assist with analysis (fuzzers, etc.) as long as it is safe to do so.

  • Remediation Support: It is not enough to find and report security problems; developers often need advice on the best way of fixing a security issue, and someone needs to check that the patches really fix the bugs. In tandem with my outreach effort, I’ll remain available to projects after delivering my reports in order to help with remediation. To be clear, in most cases this does not mean patching bugs myself, but rather educating the developers on what the fix should be and why.

Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!

My approach to outreach is based on trust-building. I aim to show project leaders that I am technically competent and understand their business goals, over time building up trust that my security recommendations are sound and prioritized correctly given the resources available to each project. I’ll start by immediately opening up monthly “office hour” slots that anyone can attend to get help and ask questions. As I perform security assessments, I’ll onboard those projects’ developers into a private monthly call where we can discuss the project’s direction, goals, and security strategy.

I can talk all day about my security audit process, but I’ll keep it brief here. I start by understanding what the target software or protocol does and brainstorming all the things that could possibly go wrong, as well as goals that an attacker might have and what security properties users value (i.e. a threat model). Then, I read as much of the relevant design docs and code as I can, keeping notes of anything that looks like a weakness or might be used in an unintended way. I make multiple passes over my notes and the code to try to confirm any noted weaknesses as real issues. Finally, I write up the report, noting the issues I found and making other comments, like suggesting code changes that would speed up future audits and tests that would be worthwhile to add. It’s a creative process that involves both checking for well-known kinds of vulnerabilities and making attempts to break security in novel ways.

Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?

I expect to be able to meet the deliverables without direct assistance from ECC or ZF (aside from the funding!). As long as the designs and code are open, I’ll be able to carry out the audits and make recommendations.

I will be dependent upon project developers to fix critical bugs before the audit reports can safely be made public. I recommend following a maximum-90-day embargo policy, except in cases where it genuinely takes more than 90 days to fix the bug or if the risk is severe. Reports that detail minor unfixed bugs may be released prior to patching, since it’s reasonable for projects to de-prioritize those fixes relative to other work. If an audit report is embargoed, it will still be delivered to the grant committee for evaluation so that my funding can be disbursed.

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?

If I spread my attention too thinly across too many projects, each one might not get the in-depth attention it needs. I can avoid that by prioritizing high-user-count or community-suggested projects, being clear about audit scope in each audit report, and timeboxing my audits and outreach efforts for each project.

There are some kinds of cryptography and code that I’m not qualified to audit. In particular, I don’t understand zero-knowledge proof protocols very well, nor the in-depth elliptic curve math, so I would not feel qualified to audit an implementation of Halo and some kinds of circuit optimizations. Whenever I encounter something that I don’t feel qualified to audit, I’ll make a note of that in my report and do the best that I can, taking it as a learning opportunity.

Since this project relies on relationship-building between myself and community projects, if I were to be hit by a bus, the built-up trust would need to be rebuilt by whoever takes over this project. If this project proves to be a success, I am hoping to expand it to include more people; a kind of “Project Zero” for the Zcash ecosystem.

Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.

The public audit reports will reveal bugs in Zcash community software, and this might be misconstrued by detractors to discredit Zcash projects’ security. This would be in error, because all projects have bugs, and finding and fixing them shows that the security program is working. Reports will be written as carefully as I can to avoid misquoting.

A common error in security is to be too alarmist and to shut down progress rather than providing safe paths forward. That’s why it’s important that I meet with project developers to understand their goals and tailor my advice to the level of resources they have, with an understanding of their users’ threat models.

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?

The community should expect to see audit results published on a monthly cadence (these may be embargoed for 90 days in case of unresolved critical bugs). The content of the audit reports should convince the developers and any security engineer that I understood and thoroughly evaluated the designs/code that were in scope of the audit.

Zcash community project developers should be asked how useful my outreach and support has been, and they should rate me as helpful, polite, and be willing to recommend working with me to other Zcash projects.

I based the formal deliverables below on audit reports being completed; I’m open to ideas from the community for other ways to formally track progress on the outreach efforts.

Compensation total budget / total proposed USD value of grant:

$204,000 USD

Please provide justification for the total compensation budget:

My rate for security consulting is $1000USD/day. The industry standard is $500-$3000/day, the high-end of that range being common for cryptography-focused auditing. My budget breaks down into 12 months, each month being composed of:

  • $10,000 for 10 days of in-depth security analysis applied to a specific Zcash community project, with a written report delivered to the project’s developers and later published.
  • $2,000 for remediation assistance overhead on average (2 day-equivalents).
  • $5,000 for outreach efforts (5 days).

This works out to 17 days per month at a cost of $17,000 USD per month, for a total commitment of $204,000 USD over a year. Each month’s budget is only to be paid out after the work has been completed.

The exact allocation of time may change slightly based on needs, for example it might turn out to be better to spend more time on outreach and less on auditing in a given month. Or, it might sometimes make more sense to do two shorter audits in a month rather than one large one. Any changes to what I’ve written here will be discussed with the grant committee.

Milestone 1 - estimated completion date:

08/31/2022 09/30/2022

Milestone 1 - USD value of payout upon completion of deliverables:


Deliverable 1.1:

Audit Report #1

Milestone 2 - estimated completion date:

09/30/2022 10/31/2022

Milestone 2 - USD value of payout upon completion of deliverables:


Deliverable 2.1:

Audit Report #2

…and similar for Milestones #3 through #12.

How was the project timeline determined?

Audits are intensive work, so one per month is a reasonable cadence for a lone security engineer. I’m asking for a commitment to funding at least a full year of these audits and outreach—as long I keep delivering great work—because I am not trying to sell 12 individual audits, I want this to be a forward-looking security program for the Zcash ecosystem. A long time horizon will allow me to build up a deep understanding of projects’ tech stacks and solidify the relationships that are crucial for this project to be a success. To take on this role, I’ll also have to relinquish my responsibilities at ECC, and that’s only a reasonable step for me to take if I know that I have funding secured for at least a year.


In case it needs to be made explicit, everyone is in favor of this, yes? The idea of security help and checks for third party apps has been talked about for quite some time. Seems like this is a big part of the solution.


@earthrise’s appears very qualified from the information released. Rates are very (very) reasonable (thanks @earthrise!). I assume all the likes from members of ECC and ZF also support this. Very easy yes.

@ZcashGrants typically contracting security work is expensive. As this project progresses, and conditional on the results, when the topic of longer term funding comes up we should seriously consider it.


Reliable security consulting services are a very important missing link so far in the ecosystem, an emphatic YES from me.


@earthrise Hi Taylor, are you still going to be employed by the ECC during your grant?
If so, what is your relationship with the ECC team working on the same type of software (wallets, …).

Personally, I’d prefer to have a candidate who doesn’t work for the ECC or the ZF for third-party security audits.


See this

Just want to express 100% support to this grant proposal


Ah ok. Sorry, I missed that part.


I am in favor! Perhaps security advisor and audits for ZCG too?


I’m excited that this could enable the ECC to hire another POS engineer.

1 Like

I think we should trust @earthrise 's discretion on this point, it seems like he’s committing to some sort of impact rubric for purposes of selecting projects?


Do we have a list of project candidates? I am not sure there are 12 projects in the pipeline.


Do we have a list of project candidates? I am not sure there are 12 projects in the pipeline.

I’d like the community’s feedback on which projects to audit and support first! My inclination is to first audit Nighthawk and ZecWallet-lite, since they seem to be used the most used.

Note that the 12 audits won’t all be of separate projects—some projects will need repeated audits due to their size, and projects should be re-audited after shipping substantial new features/changes.


I am in favor! Perhaps security advisor and audits for ZCG too?

As part of my outreach efforts, I’d be happy to provide advisorship to ZCG, ZF, and ECC on the security status of community projects and on where best to direct funding in support of Zcash users’ privacy and security!


I think we should trust @earthrise 's discretion on this point, it seems like he’s committing to some sort of impact rubric for purposes of selecting projects?

Thanks! I’m asking for the community to give me leeway on selecting the projects that I feel are most urgent to support. A number of factors go into that decision: the likelihood of bugs, the amount of users that would be affected by the bugs, the potential severity of the bugs, the potential reputation damage to the Zcash project as a whole caused by the bugs, the quality of any existing security program the project has, and of course community input.

It would be a mistake to commit right now to exactly which projects I’m going to audit—those decisions are going to be informed by cursory code analyses and conversations with project developers. The first three months will likely encompass ZecWallet-lite, Nighthawk, and the preliminary designs for ZSAs.


I like the principle of security audits. My concerns have to do with the logistics. It seems that the proposal is akin to hiring a person for a year without knowing who he reports to, or what exactly he is going to work on.
I’d be more comfortable if the proposal was offering to work on audits one by one. You could build a track record and the community could decide which ones to fund.


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.

I want to echo this.

1 Like

FWIW, in this case, I do not mind the more open ended style. Taylor has a super long track record from what I know, finding many of the most critical bugs in the Zcash protocol.

Also, it is not true he would have nobody to report to. All grantees report to the community, ZF, and the court of public opinion.

ZCG approves or denies grants. I don’t think they should be responsible for assigning work to grantees. Imo it should be up to the community and grantee to discuss their grant application, and if necessary, try to improve it to satisfy reasonable concerns.


(repost as replied to the wrong post)

I think the earliest example is this double-spending bug that Taylor found in the Zerocash protocol, back before Zcash launched when Zerocash was being productionized as the Sprout protocol:


I believe @earthrise to be trustworthy having both sufficient intention and capability, to have earned trust.


I think the person in question matters, and I think that @earthrise 's CV speaks for itself. Unneeded oversight is just friction.