Sarah Jamie Lewis announces her candidacy for the Major Grants Review Committee

Dear Zcash Community,

I am posting here today to formally announce my candidacy for the Major Grant Review Committee.

Some of you will know me from my work as the Executive Director of the Open Privacy Research Society, a Canadian research non-profit that works with marginalized communities to build better technology. You may have heard about my involvement disclosing critical cryptographic vulnerabilities in e-voting software used in Switzerland and Australia. I’ve also been contributing and actively researching privacy and security issues in zcash related projects.

I began my career as a computer scientist for British Intelligence and spent a number of years working as a software-turned-security engineer for Amazon. I went onto work as an independent privacy researcher investigating everything from dark web deanonymization, to sex tech, to children’s toys. After publishing Queer Privacy in 2017, I became convinced of the need for a group that works solely with targeted communities to build technology focused on their risk models, and as such I have spent the last few years building a non-profit from the ground up.

I am announcing my candidacy today because the world needs censorship resistant, private transactions. The communities I live and work in need financial privacy. I believe that zcash has a rare combination of robust technology, a community of amazing technologists, and the beginnings of an ecosystem that can deliver on that vision.

I believe that my strong technical background and critical voice, combined with my experience building and managing a non-profit society can serve that vision well as a member of the Major Grant Review Committee.

Which brings me to my platform: Financial Privacy

  • Financial privacy demands a large number of active participants. Preference should be given to funding projects that will expand the number of ways that zcash can be used and the number of people who can use it. Projects must seek to extend their reach beyond the traditional crypto-sphere and into civil society, the arts, community support, social enterprise and activism.
  • Financial privacy demands a vigorous commitment to privacy at all levels of the stack. While security and privacy can never be a primary feature they are critical to success of the vision. I would strongly argue for the establishment of strict secure development standards and policies to be applied across all ecosystem projects at all stages of development. I would fight to ensure that the risk models of over-policed, over-targeted communities are at the forefront of such consideration as I believe the security of such communities is essential to the success of the vision.
  • Financial privacy demands transparency. After all, the thing you are supposed to be decentralizing is power. I am not a person who trusts easily nor do I think you should invest your trust in me without strict safeguards. If elected to serve on the crucial inaugural term I will seek to implement policies that demand intense scrutiny into committee decisions and grant outcomes. I would ensure the committee members are compensated fairly for the work they undertake while also ensuring that such compensation is public and subject to community review.

Disclosure: Last year Open Privacy was fortunate to receive a donation from the Zcash Foundation which we have so far used further our efforts building usable technology. In the event I was elected to serve on the committee I would excuse myself from any votes concerning any potential future funding that Open Privacy might apply or be considered for - both as a member of the committee and in my role as Executive Director at Open Privacy.

Thank you for your consideration, and I will endeavour to answer all questions posted to this thread regarding my candidacy.


@sarahjamielewis I have added a link your thread to the top post in the Megathread. Good Luck!


There is 100% you will have my support, we need an ethics freight train on this committee and I would be giving you my voting expecting you to be the voice of reason if you suspect collusion or any type of deception is taking place between other MGRC members.

Thanks for your support @PhusionPhil. While I do not consider collusion or deception between committee members to be a major risk [1], I do believe it is important that the committee sets strong policies around transparency of interests for both members, applicants and grantees such that any potential risk can be appropriately mitigated and that the outputs of such policies and mitigation processes are available for public review.

[1] I’m far more concerned about the committee providing an insufficient allocation of resources to ethical design review, security and auditing (/not evaluating these as part of the grant criteria at all or potentially worse, burdening grantees with that responsibility wholly and duplicating effort.)


If you go look at my comment on @mistfpga application you’ll see that I was quite adamant about him using his auditing knowledge and reverse engineering experience actively in the decision-making process. He brought up an interesting point though that the word audit holds a specific legal responsibility and he didn’t want to include that responsibility in his application because it would make it more complicated. So I see your concern but I think if we have someone on the team who acknowledges the importance of auditing and there’s a responsibility from the foundation to commit to those audits then it won’t be a problem.

Perhaps we could arrange a bilateral agreement between grant applicants and the community to perform a 3rd party audit but add a clause of sorts that guarantees the auditors from frivolous legal repercussions. We could define very precisely what we consider to be a pass and a fail for the audit, a fail would just require a revised application imo.

Auditing is a very overloaded term, so I’m going to break it down slightly to clarify meaning.

  • Financial Auditing: A full review of the books and operations of an entity - generally very expensive when it comes to small teams, and a major hurdle in the technical grant space as many grant committees require it. I do not think it wise to require such audits of grantees as it drastically slows the process and limits the potential pool of applicants. If there are special circumstances (i.e. very large grants) where such an audit would be prudent, I’d like to see it built into the budget of the grant.

  • Security Review / Auditing: Also a very overloaded term, sometimes part of a legal requirement (e.g. handling credit cards directly), sometimes not. It is very clear to me that several Zcash ecosystem grants have not had sufficient funding dedicated to security review and if elected I would push to have a standardized security review process be a mandatory requirement of a technical grants. This may involve funding a team dedicated to this work, or working with existing teams to conduct the reviews.

I’ll note at this point that I used to be a “Security Certifier” (and a Security Engineer) for Amazon and have extensive experience conducting security audits across a range of systems handling extremely sensitive data and managing external teams to run large scale, multi-month security engagements (both assessments and red teams) - I’ve also at this point found, reported and occasionally several vulnerabilities in existing Zcash ecosystem projects.

As such I understand the amount of work that goes into such reviews (from all sides), and even with a template and standardized process there is always going to be need for customized reviews for each grant (either when defining scope, or directly reviewing such consequences).

We could define very precisely what we consider to be a pass and a fail for the audit, a fail would just require a revised application imo.

Audits are rarely pass/fail - ideally an audit (whether financial or technical) provides an essential insight into how a system operates, what risks are prevalent, how those risks are being managed and how the system will evolve in the future.

An audit might occasionally raise a risk so severe that the programme needs to stop and immediately address it, but more often than not you end up with a long list of potential risks that need to be managed. - (see the updated Zbay Grant which acted on my suggestions to include more milestones for better tracking and managing risks as they develop.)

Ultimately, this is why I am skeptical of proposals that require the committee to work less than full time, someone needs to be keeping tracking of how the MGRC is distributing funds, what risks are at play (no grant is ever 0-risk), and how teams are dealing with them.



There seems to be a lot of security engineers applying for this. That is always a good thing. I completely agree with how you are defining audit and the amount of work they involve.

For me, I have done FIPS ( Federal Information Processing Standards) testing and actual audits for Hardware Security Modules and Datacryptors. I have farmed this testing out to companies like NGS to get our products tested too.

I have also professionally done the much more ambiguous “security audits” these normally were as part of pen testing assignments. where the whole thing was the audit and I was responsible for a specific subsection (generally runtime analysis stuff and memory data management).

Real, legal audits, cost a lot of money and take a lot of time. You cant get FIPS certifications over night and without spending a lot of money (FIPS seems the most relevant one that I have had experience with.) For nearly all financial and government security audits part of the process is using a requirements based testing model (think of software like IBM DOORS to track progress) - This could well be a step too far. You would be forcing teams to adhere to a development process. This is generally very limiting for attracting developers, it certainly was an issue where I worked. This needs to be avoided if possible.

What I would like to see (and what I think people mean when they say audit) would be a certification scheme more inline with how console games are certified.

For developers to use the zcash trademark if they need to pass a series of tests. These would be requirements and unit tests. For wallet software this might include:

  • zcash logo must not be altered.
  • change must be sent to a zaddr
  • many other requirements.

These would be general, like the case of logo usage and they would be project specific unit tests set by the MGRC, like the case of change. @PhusionPhil is this more inline with what you were thinking?

I really think certification is the way to go not audits. I mean what would be audited against? what standards? We could come up with some eventually, but certification requirements is the first step in that direction.

Defining the standards for certification and doing the testing, including milestone testing really is not that big of a deal. It is certainly not a part time job in the first year, but after the standards are defined, the testcase database made and a bug tracker put in it is not full time work. I did this back in the day for the launch of the xbox, so I have relevant experience.

Sure but micromanagement is not part of this either. 6 week to 3 month milestones with community reports should not be an issue for the MGRC. Just tie funding to passing milestones. Then define passing the milestones based of unit tests and predefine requirements outline at grant approval time.

I think the work will be oddly weighted with it occurring in fits and spurts. so for 4 weeks there might be nothing to do, then you might be full time for 2 weeks. then part time for 2 weeks then nothing for 6 weeks. We just dont know. So there needs to be flexibility in the candidates.

I would love to hear what you think on this.



1 Like

While I agree with you, to some extent, that certification standardization is a front-loaded process, I also think that tracking grants along any such standard is a very minor portion of what I would consider the work of the committee. These are the ideal cases and the major work of the committee needs to be focused on where these tests fail.

Referring back to a reply I gave in the main thread on the MGRC I think it likely that the committee will be called upon to spent a lot of time responding to deviations from the milestones and ensuring that grant money is invested effectively - I feel the need to emphasize that that often means the most work happens when things don’t go to plan:

I also think it is worth pointing out that even if we were to accept the idea that the work of the committee might taper off once all the processes and procedures have been put in place, time still needs to be spent building and field testing those processes and procedures in the first place. We can debate the potential steady states of the review committee, but we must acknowledge that the initial term will very much be not a steady-state, it will require dedicated effort from committee members (and with planning that effort should eventually become sublinear to the number of grants). As you put it:

It is certainly not a part time job in the first year

Some more specific thoughts:

This seems explicitly outside of the scope of the MGRC given that it has no authority over the zcash trademark (while I could see such a scheme in the future of the MGRC, I don’t think it is a wise use of the MGRC time or resources in the initial few years).

As I mentioned, I don’t think audits are the most effective mechanism for evaluating grant recipients or outcomes but there are several domains in which audits can and might be considered (although these would primarily be financial / organizational audits and I will stress again that I think these should be the exception to applicants, not the rule)

That being said, I will clarify:

The MGRC is in a position to help set standards of excellence and practice - and back that up with funding to help teams reach those levels.

Privacy and Anonymity are very peculiar risk models that aren’t served well by most commercially focused security review processes. As Zcash starts gathering a larger number of apps promising the mitigations of such risks I think it is vital that we don’t repeat the mistakes we have seen in other ecosystems and in the early days of the zcash app ecosystem where anonymity is heralded and then apps fall over and expose users at the first hurdle or inappropriately promise anonymity in the name of zcash while doing little to mitigate risks outside of the ones that zcash can protect against.

I think this includes an expectation (and funding of):

  • Ethics Review for studies and software (see the Zbay link in my previous post for an example) to discover and capture risks. Grantees (and the committee) have a responsibility to ensure that they aren’t harming the communities they are purporting to support - this means setting up and engaging in ethics reviews and responding to the outcomes. Sometimes this will mean stopping a grant, other times it will be reworking it. I have lost count of the number of community groups, charities and marginalized people I know who will not touch cryptocurrency because earlier groups showed up promising the world, parachuted in a bunch of half working technology and then left those groups to clean up the mess. We need to be better than that.

  • Design Review milestones than include explicit risk models and mitigations. One of my biggest fears around Zcash is we end up with a large ecosystem in 5 years that does nothing to advance financial privacy or censorship, and Zcash suffers the same fate as many other privacy ecosystem projects - offering great privacy at one layer while ignoring all others.

  • Peer Review of new technologies and software outside of traditional academia and industry committees (e.g. community review where grants are targeting specific groups) - the MGRC should act as a bridge between various parts of the ecosystem, connecting and encouraging work between groups to avoid rework and encourage reuse and integration.

All of that is why I think it is important to push for an active and full time inaugural committee; some of these processes will shape out, others won’t. But developing them in concert with grant applicants, recipients and the community at large is going to take dedicated time and effort. Anything beyond is speculative.


The certification scheme would very much appeal to me. Thank you for clarifying the audit process for the community as well as myself @sarahjamielewis

1 Like