Contributor bounty program

Given the partial success of the previous bounty program and the lack of contributors to the organisation right now. Outlining tasks and offering incentives seems like the best way to bootstrap contributors.

For those not familar with the previous iteration, we saw two independent teams of academics come together to build out the proposed analytics tool bounty; to identify poor usage of the protocol that voids privacy. They named it Tutela, the submission went over and beyond the expectations and requirements. The other bounty was orchestrated around writing in-depth technical documentation for tornado’s low level circuitry, which was partially started but never finalised. Below are several tasks to align contribution and amend inefficiencies in the organisation.


Difficulty: Medium | Reward: $5,000


Throughout the lifecycle of tornado’s tooling there as never been efforts to undertake easy integration of the protocol. If individuals want to integrate the protocol to applications, they have to execute a tedious workload expanding from defining typechains to handling proof generation.

The benefits of incentivising easy integration of protocol, opens up many possibilities where developers can leverage the protocol to build privacy-perserving applications; such as a wallet. Furthermore it helps individual developers learn the flow of how tornado functions through pre-defined functions and helpers.


Create a Typescript library, to allow the ability to deposit and withdraw to the classic anonymity sets. This includes defining an unique typechain for all the associated parameters.

It is recommended to use websnark to handle proof generation, to not bloat memory requirements for integration. Additionally use the fixed-merkle-tree library to build the deposit tree. Logic for this is already defined in the cli and the classic-ui repositories, applicants should use this as influence or reference.


Submissions are handed by creating a new repository on the community git and submitting the compiled source as a package to npm. Applicants should minimalise unneccesary commits and add clear commentary to each push. Submissions should also be well documentated, describing how to build from source, install and import the package and use each associated functions.

Relayer deployment tutorial

Difficulty: Medium | Reward: $3,000


Relayers are a paramount component of tornado’s functionality in breaking the link between source and destination addresses, a lack of relayers effects the reliability to obtain privacy using the protocol. While it is feasible that the number of relayers deployed is relative to fee capitalisation, and thus withdrawals. The protocol faces contigencies of not fufilling it’s premise if there is a concentration in relayer topology, there should be approachable resources to facilitate onboarding.

Furthermore, the potential risks of operating the relayer software should be outlined alongside recommended methods to veil operations ensuring the ability to maintain the role of a relayer from outside intervention.


Write an indepth tutorial describing a step by step basis of deploying a relayer on multiple or a single network. The document should cover:

  • Requirements (software, hardware and costs)
  • ENS and DNS configuration
  • Relayer deployment on a single network
  • Relayer deployment on multiple networks using an nginx proxy
  • Privacy perserving deployments using Whonix

There is already minimal documentation on the process of deloyment on the community git’s classic-relayer repository, applicants should use this a basis of influence or reference.


Applicants should adhere to comprehenisble and concise grammar when authoring the guide, and should approach it towards any individuals who don’t have expierence in development or operation systems management.

Submssions are handled by creating a pull-request on the community git’s docs repository.

Discourse Ethereum authentication

Difficulty: Medium | Reward: $1,500


Discourse by default requires operation of an STMP server to authenicate registrations by email, this is not an complimentary process to privacy.


Integrate the possbility of registering and signing into an account on a Discourse instance by connecting an Ethereum wallet, and signing a message. Display the user’s verified address on their forum profile.


Fork the Discourse source code integrate logic to handle a web3 provider, and on registration and sign in require a message to signed to prove owneship of the address in question. Replace email key mappings in the database store with Ethereum addresses. Create a repository on the community git and document the logic thoroughly.

It is recommended to use Ethers.js to approach the handling of provider and message signing but individuals are free to take their own course of implementation if they believe it is more beneficial. It should be not be understated, that implementations that depend on other services are not desirable.

Cli improvements


Difficulty: Medium | Reward: $2,000


Given how ineffective it is to process multiple deposits or withdrawals with the cli, there is a clear benefit to suport consecutive transactions. Not only would it make the tool more efficient than the frontend but it would incentivise the use of, and strengthen - the lower anonymity sets.


Integrate capabilities to execute multiple deposits to a anonymity set in a single command, and to process multiple withdraws by providing a list of notes.

It is recommended to handle transaction ordering sequentially and ensure confirmation of subsequent transactons is reached sufficiently before broadcasting, each request should be handled as a promise.

Possibility to use the tx-manager package for the basis of handling transaction ordering and settlement.


Applicants should adhere to clean syntax in the integration, and should not modify any other elements of the source code that do not have relevancy to the task. Submssions are handled by creating a pull-request on the community git’s tornado-cli repository.

Applicants should minimalise unneccesary commits and add clear commentary to each push. Submissions should also be well documentated, stating the reasoning behind taking the course of implementation.

Circuit documentation

Difficulty: Hard | Reward: $10,000


Tornado’s low-level circuits are a fundamental component of the protocol’s architecture, given how they are used as a core curriculum matieral in education of zero-knowledge. There should be in-depth commentary of the logic behind each circuit, helping onboarding education.


Author a technical specification of the Circom circuits for Classic and Nova, alongside NATSPEC comments to assist code readability.


Submission of the circuit specifications is handled by creating a pull-request on community git’s docs repository.

Submission of the NATSPEC commentary is handled by creating a pull-request on community git’s tornado-pool and tornado-core repositories, for each associated version of the protocol.

Applicants should adhere to an in-depth technical standard of documentation (higher-level concepts, domain objects etc) in the specification, and follow the NATSPEC guidelines for code commentary.

I think this is too constraining. More clear requirements should be set that allows the developer freedom to make their own choices. For example, a reasonable requirement may be performance on a certain class of hardware, or it may be memory usage for current mainnet trees.

I would also like to see a constraint on the SDK that severely limits number of dependencies (including transitive). The current tooling has a huge dependency graph which increases risk to the project. The dependency graph of this tool should be extremely small.

As mentioned in chat, this feels overly constraining. Why limit to ethers.js instead of something like “minimal dependency set” or something? For example, for this use case something like GitHub - paulmillr/micro-web3: Typesafe Web3 with minimum deps: call eth contracts directly from JS. Batteries included may make more sense (note: not sure if it would work, just using it as a potential example).

I have a CLI that may be a better starting point than the official one (I’ll leave that up to others to decide): GitHub - Zoltu/tornado-scripts: Some scripts for using Tornado Cash from the command line, but written in TypeScript and with fewer crazy dependencies.

It needs some love on the documentation front, and it still needs caching of the tree itself (it already caches events). It does batching of deposits (not withdraws yet, but should be very easy to add). It also is written it TypeScript, minus the code that is ripped directly from the official Tornado CLI (which are still JS, but they have rudimentary type definition files already).

How will these be funded? Is this coming from a treasury? Are the bounties paid in TORN?

I understand your critisims but you must understand the reality is that these implementations do not exist, and the individuals who will be taking on these tasks most likely won’t be well veterened in the tooling. Providing a basis for direction through “recommendations” (if you didn’t see that) is important, they are of course free to follow their own intuition if they think there is a more beneficial route.

Of course, there is a plethora of dependencies on the stack that don’t need to be there - I fully agree. That is a future facing prospect for key contributors to address and cannot simply be evaluated in an evening. Undertaking an entire dependency audit is not an easy task and minimising the toolings dependency stack is neither.

As stated in the matrix, ensuring the proposed functionality operates independently is crucial - having a reliance on external services for authentication is not an option here. It was meant to recommend Ethers.js instead of the wording insinutating that it the task is restricted to using it, I shall make the associated edits to address this confusion.

Yes, expenditures to compensate the tasks laid out in this program have to be sourced from the treasury. Which will require governance vote(s) to fulfill, I thought it would be good to at first bring discussion of the potential tasks for feedback. To answer your question, yes all amounts will be denominated in TORN but priced in the associated USD quote.

The proposed solution for reviewing and how compensation will be settled will be specified later, and there is no guarentee that the proposed amounts will be paid out - as it’s down to the discretion of govenance.