Vision The vision for Exlist is for it to be the standard source of data for decentralized applications wishing to reference verified lists of onchain addresses associated with stolen funds (ie, hacks). At its core Exlist is a multisig smart contract that contains updatable lists of Ethereum addresses that can be called on by any other smart contract, managed in an open and transparent fashion. Background In order to know if mixed or shielded funds (such as onchain withdrawals from Tornado Cash, Railgun, Privacy Pools, ZK Wormholes, Nocturne, zkBob, Aztec or others) are associated with hacks, any zk application (such as Proof of Innocence or Sandscreener) needs a reputable list of blocked addresses to choose from to reference. Problem statement In order for public exclusion lists to be generally accepted and trusted, they require a reasonably reputable system to ensure that the addresses are 1) easily validated, 2) up-to-date and 3) not being added, removed or blocked by malicious participants.<br><br>The Public Exclusion Lists should be able to be stored in both a decrentralized and free (or cheap) manner. The lists should be maintained in a coordinated manner that is open source, well documented, standardized and technologically compatible with software that wishes to use it. Who it benefits

Table of Contents :open_book: Overview Components Roles Roadmap Other Resources 1. Project Overview :page_facing_up: Exlist is an open source onchain exclusion list of Ethereum addresses. It is a multisig smart contract that contains updatable lists, allowing applications to call on it to return sets of blockchain addresses that have been associated with hackers and hacked funds. A robust governance system ensures the integrity of the exclusion list by keeping the data current and accurate.

*Notes migrated from: https://docs.google.com/document/d/1dyGqvWF_vF_0F6L6x_hQb-NOws5fxAokLNiKQlYSvZM/edit on june 18 Sug 30, 2023 How to move forward with SandscreenerBased on the news last week solutions in the future will just block all addresses from TC, nobody will seek POI Build zk into exclusion list- can prove anon by creating zk proof within the circuit. Sandscreener did it in a specific way with TC, this would be more general purpose. In most cases you are screened by your addy which is already exposed so no use case there. Makes sense to build an exlist inside of the system (like pp or zkrollup), not always possible with existing systems. Contact Aztec about exlist Can build on https://app.sismo.io/ Exlist is an open source chainalysis Exlist proj is more data analysis than zk

Onchain Exclusion Lists Problem Statement The proliferation of zero knowledge products like mixers and rollups allow cryptocurrency users more opportunities for privacy than ever before. Unfortunately, it is often the case that tokens are deemed suspicious by default if associated with privacy enhancing technology of any kind. Projects, firms and individuals should feel comfortable accepting mixed or shielded funds, and have the option to reject funds that are associated with hacks, all while upholding the sender's privacy. In order to know if mixed funds (such as onchain withdrawals from Tornado Cash, Railgun, zkBob, Aztec or others) are associated with hacks, any zero knowledge application (such as Proof of Innocence or Sandscreener) needs a definitive list of blocked addresses to reference. The integrity of the Exclusion List data is essential to the adoption of Exlist. In order for public exclusion lists to be generally accepted and trusted, they require a reasonably reputable system to ensure that the addresses are 1) easily validated, 2) up-to-date and 3) not being added or removed by malicious actors. The Sandscreener Public Exclusion Lists should be able to be stored in both a decrentalized and free (or cheap) manner. The lists should be maintained in a coordinated manner that is open source, well documented, standardized and technologically compatible with software that wishes to use it.

Exlist Users An exploration of potential applications that could use or generally benefit from an Exclusion List Project Name Website Specification Notes Privacy Pools Website Mixer

Table of Contents :open_book: Project Overview Technical Components Project Components Project Roles Other Resources 1. Project Overview :page_facing_up: Sandscreener is an open-source Proof of Innocence tool. It allows users to easily prove via zero-knowledge technology that cryptocurrency withdrawn from Tornado Cash is not associated with an address on an exclusion list, without revealing the source of their funds.

August Met with a DEX to discuss First draft of social media plan- soft launch July 2023 Sandscreener is an open-source Proof of Inncence tool. It allows users to easily prove via zero-knowledge technology that cryptocurrency withdrawn from Tornado Cash is not associated with an exclusion list, without revealing the source of their funds. The last month saw a few updates to how Sandscreener functions. Before we get to those, we must first mention the creation of the Sandscreener Medium, without which you would not be reading these updates. We'd like to be posting on Mirror primarily (or at least in parallel), but are experiencing some issues with ENS that can hopefully be resolved in the future. For now, we hope to continue providing monthly insights into Sandscreener development. Now, onto the updates!

This document lays out the differences between two ZKP Proof of Innocence tools, Sandscreener and Chainway's Proof of Innocence. Learn more about Sandscreener here, and Proof of Innocence here. Aspect Sandscreener Proof of Innocence Validity Guarantee Instant. A proof is recorded if it has been performed against real & verified input data (i.e., a real Tornado Cash deposit and a verified blocklist).

Chain Analytics The app traces onchain transfers and alerts if funds in the deposit address came from exclusion list Upload exclusion list directly through app Allow Editor role to upload the exlusion lists directly to through the Sandscreener app.

Mission Statement The Sandscreener Journal is a monthly publication that summarises the development process over the course of each month. It was established to provide transparency, document progress and encourage open collaboration in the project. Step 1: Draft https://hackmd.io/@sandscreener/Bka-S67On During the month the Communication Manager takes notes on the achievements on the team. After the last day of the month the Communication Manager uses those notes to create a draft of the journal entry. Step 2: Feedback

TLDR: we cannot mint an SBT in a decentralized way because we can only prove "per withdrawal nullifier", not per real address (the proof constrains the nullifier, not the withdrawal address). Instead, we can record a successful proof "per nullifier". The desired goal of the soulbound token (SBT) in sandscreener was to serve as a certificate of innocence that is minted once and forever for a given Tornado Cash (TC) pool user and blocklist. Such a token should then be accepted by any protocol that is interested in user innocence only in regards to the specified blocklist. Let's see why the described approach is difficult to implement in a decentralized system (decentralized system here implies the permissionless minting of an innocence SBT, e.g., granted by an on-chain proof of innocence). Firstly, let's take a look at which data in the proof of innocence is verifiable onchain: Data Verifiable On-Chain Explanation Example Exploit

System Description Participants There are three types of users in Sandscreener: Auditor - entity that owns a centralized Service and is interested in screening its users. It maintains the backend & frontend of Sandscreener. Editor - the community that provides the blocklist. Editors are supposed to be the members (or groups of members) of the community trusted both by Auditor and Users. User - a regular user of the Service who previopusly deposited to Tornado and needs to be screened by the Auditor to continue using the Auditor's Service. System Components Frontend - provides the Auditor, Editor and User with the convenient UI to perform their corresponding tasks

Sandscreener is a full-stack set of tools that enables a Tornado Cash user (User) to anonymously prove to an interested party (Auditor) that the User's deposit address is not in a blocklist specified by a verified third party (Editor). Original Tornado Cash In the original Tornado Cash, the User is proving that they have deposited funds into a smart contract pool to be able to withdraw the said funds. The withdrawal is performed after some delay and goes to a user's address different from their deposit address. Since the proving process does not leave any record and is anonymous, it effectively decouples the deposit and the withdrawal addresses. Upon the User's deposit, the Tornado Cash generates a deposit ID whose hash is stored publicly in the Tornado contract and a withdrawal ID that is known only to the User (generated in the frontend and recorded by the User). The deposit and withdrawal IDs are cryptographically linked, so it is easy to verify their relation by performing certain hashing operations. Therefore, from the viewpoint of Tornado Cash, when a user comes to withdraw their funds from the pool, they must prove that there is a publicly recorded deposit ID hash for what they claim to be a withdrawal ID. Zero-knowledge proof (ZKP) is used for it to keep the User's deposit ID unknown to Tornado Cash and any external observer. The ZKP is performed on the user end (inside the frontend). The User feeds the deposit and withdrawal IDs into the ZK prover. The prover outputs a true or false value that essentially says that: This withdrawal ID is indeed linked to some anonymous deposit ID; That anonymous deposit ID's hash was indeed recorded in the Tornado Cash contract. The User is then allowed to perform the withdrawal to their other address.