Compliant Book-Keeping for DAOs through “Proof of Trusted Origin:” A Technical Guide

Isaac Patka, Sofia Cossar, Eric Alston, Primavera De Filippi, Frederick Dudley, Fatemeh Fannizadeh, Jake Hartnell, Rolf Hoefer, Aaron Lane, Will Papper, Joshua Tan, & Michael Zargham

The Problem

As novel organizational and socio-technical architectures, Decentralized Autonomous Organizations (DAOs) continue proliferating. Even after a somewhat turbulent 2022 for the blockchain industry, recent reports show that DAOs have continued growing exponentially in resources and membership. DAOs treasuries hold approximately USD 25 billion, and 6.7 million token holders manage governance. While DAOs’ underlying purpose or activity vary widely, they all share at least one thing: reliance on “human contributions” for development and maintenance. Even those conducting the bulk of their operations on-chain require, from time to time, software developers to write code and deploy smart contracts and moderators to manage communication platforms for the community. In exchange for their efforts, DAOs may offer contributors token-based compensation or retroactive public goods funding. For example, they can allocate up to 50% of their treasuries to Product & Development expenses. However, transactions on permissionless and public blockchain networks are, by default, transparent. While transparency contributes to greater auditability, this technical feature can erode contributors’ right to payment privacy, recognized in most countries as a fair labor practice. It is now possible to conduct private transactions in blockchain systems by relying on privacy-preserving networks such as Z-Cash or Monero or resorting to privacy pools in tumblers such as TornadoCash. Yet, DAOs and their contributors may want to ensure that the privacy-preserving tool of their choosing exposes them only to “trusted” entities by avoiding transactions with entities involved in fraudulent or malicious activities. 

The Question

How can DAOs compensate their contributors in a privacy-preserving way while ensuring they only interact with “trusted” entities? 

The Solution 

We propose “Proof of Trusted Origin” and “Compliant Book-keeping” as mechanisms to ensure DAOs can compensate their contributors while respecting their right to payment privacy and shielding them against interactions with fraudulent or malicious entities. This technological solution relies on privacy pools and cryptographic proofs called “notes.” 

While Monero and Z-Cash are examples of privacy-preserving cryptocurrencies, token mixers or tumblers operate higher up in the tech stack. They are decentralized platforms designed with the intent to conceal or obfuscate users’ transaction history. They do so by mixing users’ deposited funds into a common pool and allowing users to withdraw amounts into a new wallet address. As a result, third parties cannot specifically link a deposit address with a withdrawal address. Tornado Cash, launched in 2019, is an example of a decentralized, non-custodial token tumbler running on any network compatible with the Ethereum Virtual Machine.

To understand how end users would interact with Tornado Cash before the publicly hosted website was taken down in 2022, one must split the workflow described in the whitepaper into three instances: deposit, wait, and withdrawal. 

  • Deposit: To deposit funds, end users navigate the website and select Ether or an ERC-20 token and the amount they want to send from a set of pre-established possible amounts. The website also provides a random key or a random 256-bit number (a “deposit note”) that can be downloaded in .txt format as a backup. That “note” serves as proof of the “anonymity set” the end user’s transaction belonged to. An “anonymity set” is a batch of transactions waiting for withdrawal in the Tornado Cash smart contract denominated in the same token and for the same amount as the end user’s withdrawal request (e.g., 1 ETH). The end user then pays a gas fee and sends the deposit transaction to the Tornado Cash smart contract address on the Ethereum network alongside a hash of the generated “note.”
  • Wait: After depositing, end users are recommended to wait a certain period of time before withdrawing their funds to reduce the chance that a third party might link the end users’ deposit and withdrawal transactions. While there is no fixed required waiting time, developers originally recommended waiting at least 24 hours. In practice, the waiting time is determined by the recent transaction volume in the smart contract, as well as the size of the anonymity set more generally, both of which influence the extent to which a given payment out of the smart contract can be probabilistically linked to a given original payment into the pool. 
  • Withdrawal: To withdraw funds, end users go back to the Tornado Cash website and select the same token and amount they originally deposited. They must also select between two withdrawal methods: a wallet or a relayer. When choosing a wallet, the end user adds a recipient address that is untraceable and unlinkable to any prior transaction history yet with sufficient ETH to cover the gas fee. Adding ETH to the withdrawal address creates a “chicken and egg dilemma” and can compromise anonymity; thus, end users might opt for a relayer. If so, users do not need to pre-fund the withdrawal account and instead pay a fee to the relayer to process the withdrawal on their behalf, enhancing privacy as a result. Another piece of data users must submit is linked to the original “deposit note.” In simple terms, the “deposit note” becomes split into two halves, one acting as a “secret” and the other acting as a “lock.” When the end user sends the withdrawal request to the Tornado Cash smart contract, they also provide a hash of the “lock” and a zero-knowledge proof (zkp)  generated using both the “secret” and the “lock.” This zkp proves the withdrawal is linked to a valid deposit and that the deposit has not been spent yet. After verifying the proof, the smart contract sends the funds to the recipient’s address.  

On 7 March 2023, Privacy Pools, a fork of Tornado Cash, was launched on Optimism testnet, an Ethereum layer 2 scaling solution. Currently in development, Privacy Pools is an open-source project succeeding Tornado Cash which allows users to make privacy-preserving transactions while proving that the funds have not been connected to fraudulent or malicious entities. The workflow remains the same in the deposit and waiting instances periods. Yet, when end users send a withdrawal request to the smart contract, they not only provide a zkp to prove that the withdrawal is linked to a valid and unspent deposit. They can also provide another zkp to prove that a withdrawal is linked to a deposit that is part of a subset of good deposits (“proof of inclusion”) or not part of a subset of bad deposits (“proof of exclusion.”) In contrast to the original Tornado Cash, end users of Privacy Pools can now remove themselves from anonymity sets found to be associated with these activities.   

The Implementation 

DAOs and their contributors can utilize Privacy Pools to generate Proof of Trusted Origin, ensuring privacy-preserving compensations originating from trusted entities only.  

  • Deposit: The DAO decides to use Privacy Pools smart contract to pay for compensations to contributors. It chooses to deposit in one of the accepted tokens and for one of the pre-established amounts. The DAO downloads the generated “deposit note” in .txt format. For the deposit to be made, it pays the corresponding gas fee, and it sends the deposit transaction alongside the hash of the generated “deposit note.” Right after, the DAO securely delivers the “deposit note” to the corresponding contributor expecting the compensation.   
  • Wait: The contributor waits at least 24 hours to redeem their deposit. That waiting period is to reduce the correlation between deposits & withdrawals and may require longer in cases of low transaction volume. 
  • Withdraw: The contributor decides to withdraw the deposit made by the DAO through the Privacy Pools smart contract. When sending a withdrawal request, the contributor utilizes the “deposit note” to create a zkp to prove that the withdrawal is linked to a valid and unspent deposit and that it is linked to either a subset of good deposits (“proof of inclusion”) or does not belong to a subset of bad deposits (“proof of exclusion”).  

While the aforementioned process could already be executed through the Privacy Pools open-source project, a “Proof of Trusted Origin” requires an additional step whereby the contributor can obtain a .txt statement of the generated “proof of inclusion” or “proof of exclusion.” This Proof can be utilized for the purposes of accounting and compliance with regulations of specific jurisdictions where the DAO is incorporated or operating and where the contributor is based. These proofs would be subject to standard accounting practices for organizational recordkeeping. The interested organization or individual could maintain private records of contributors, payments, and proofs of trusted origin to ensure tax compliance or other regulatory objectives. 

Additionally, because of the nature of compensation as a particular type of transaction, some aspects merit deeper consideration: 

  1. If compensation ought to be paid at a specific moment or within a certain timeframe, the DAO must consider the waiting period recommended to ensure the privacy of the transaction. 
  2. DAOs and contributors may decide to denominate the compensation in stablecoins to avoid volatility risks associated with other tokens and cryptocurrencies, although this comes at the cost of accepting the counterparty risk of the stablecoin issuer. 
  3. The receipt can be redeemed by anyone who holds it, including redeemed by the sender, before the intended recipient can claim it. Given this, the system outlined herein is best for ongoing and regular payments between relatively trusted parties, not trustless payments.


The world of distributed network organizations is still rapidly developing alongside the underlying blockchain technology and smart contract affordances that form these organizations’ technical backbone. Essential to the flourishing of this novel organizational ecosystem are guarantees that traditional organizational contexts provide their employees, like privacy of payments as against third parties. While traditional organizations accord this level of privacy, they do not prevent duly authorized regulators from accessing these payment records as and where needed. This technical guide explains how decentralized autonomous organizations (DAOs) can use the technology stack provided by Privacy Pools to ensure compensation privacy while simultaneously proving that funds received did not emanate from an untrusted actor. This presents a compliant set of book-keeping practices for DAOs through using zero-knowledge proofs of trusted origin and a privacy network within the Ethereum network. Using this technology in the novel application that we describe, DAOs can obtain the same affordances available to private employers worldwide while ensuring regulatory compliance in the face of sanctioned uses of privacy pools. Thus, this technological stack will likely play an important role in fomenting legitimate and innovative employment arrangements within DAOs. However, the applications of this stack are not limited to payroll purposes.

Technical Demo Appendix

Privacy Pools

  • Step 1: Visit Privacy Pools dApp
  • Step 2: Connect both a Metamask wallet and a Note wallet
  • Step 3: Deposit into the pool
  • Step 5: Visit Withdraw page
  • Step 6: Optionally exclude certain deposits (e.g. if they are sanctioned)
  • Step 7: Complete withdrawal to a new wallet

This transaction shows funds being withdrawn to a different address


In ZKBob, one can either publicly send the Bob token or privately send the ZKbob token. Both are USD-denominated stablecoins. ZKBob works differently, as there is no blacklist for sanctioned wallets currently. Instead, limits are imposed to reduce the tool’s utility for moving dirty money.

Transaction history (only viewable to the logged-in user)