# Sandscreener User Manual

## System Description

### Participants

There are three types of users in Sandscreener:

1. Auditor - entity that owns a centralized Service and is interested in screening its users. It maintains the backend & frontend of Sandscreener.
2. 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.
3. 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

1. Frontend - provides the Auditor, Editor and User with the convenient UI to perform their corresponding tasks
2. Backend - provides the necessary data for frontend (e.g., the data extracted from the Tornado smart contract that is necessary to generate a zero-knowledge proof (ZKP))
3. Register smart contract:
3.1 Stores all blocklists submitted by Editors;
3.2 Allows Audtior to approve and revoke the Editor role
3.3 Contains the verifier function that can be used by anyone to verify the resulting User's ZKP
4. Blocklist - a list of malicious blockchain addresses compiled by the community (lead by the Editor) and stored publicly in IPFS. This allows everyone to assess the resulting anonymity set by subtracting the blocklisted deposits from all the deposits in any given Tornado pool.

## Usage

All parties require a blockchain wallet to use the system frontend.

### Auditor

Auditor deploys the system on their servers and also deploys the blockchain smart contract (that automatically grants them with the admin role). The technical information for deployment is contained in the source code repository.

Frontend and backend can be integrated with Auditor's existing Service and the integration is TBD.

When Auditor connects to the frontend using the smart contract admin blockchain account, the Auditor UI section is displayed. This UI sections allows the Auditor to grant and revoke the Editor roles for a specified address. It is implied that the Auditor and Editor will communicate in advance to arrange the appointment.

### Editor

Editor compiles the blocklist and uploads it to IPFS (this action is not currently supported by the frontend and is supposed to be carried out e.g. by using any existing IPFS pinning service, but can be discussed).

Editor provides their address to the Auditor to be granted the role in the smart contract (it'll probably be a multisig wallet that is controlled by the Editor).

After the Auditor grants Editor with the role, Editor is able to store the blocklist reference (IPFS CID) in the register smart contract by using the frontend (connecting their wallet).

### User

Currently User is not authenticated in any way, but Sandscreener supports authentication (e.g., OAuth) that allows the Auditor to integrate it with their Service. It is implied that the Auditor is aware of User's previous interaction with Tornado (e.g., Auditor observed a withdrawal from Tornado to one of the User's addresses), so User can be identified by the wallet address that they use to connect to frontend.

User is supposed to have a private note that was generated by Tornado upon User's deposit into Tornado. This is crucial to be able to prove User's non-inclusion into the blocklist.

When User connects to the frontend, they are able to generate a ZKP of non-inclusion into the blocklist by chosing the Editor and providing their private note. Currently, the last blocklist submitted by Editor is used, but it is possible to allow the User to use a blocklist of their choice.

After the ZKP is generated in the frontend, it is sent to backend and verified. What happens upon the verification is TBD (in the current Sandscreener implementation it can be a record in the DB that identifies the user, proof validity, and the blocklist used).