# Exclusion List "Exlist" Product Requirements

| | |
|---|---|
| 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 | *Dapp & Protocol Developers* - Developers benefit from access to data to pull into their dapp instead of having to bootstrap and manage lists on their own.<br><br> *Crypto Services* - Services that receive cryptocurrency, such as a DEX/CEX, benefit from being able to easily comply with regulation. <br><br> *Cryptocurreny Users* - All users, whether they are choosing to opt into proof of innocence systems or not, will want to be reasonably assured that the integrity of the exclusion list data is exhaustive and trustworthy, since a fully adopted list deployment will affect every mainnet transaction. An accurate list will allow users (with the help of downstream applications) the choice to opt out of anonymity sets with other users (such as hackers, etc).|
| Assumptions | A system which offers accurate, up-to-date onchain exclusion lists will provide a foundation for the rest of the ecosystem to integrate and build on. We assume incentives exist for people to both contribute to the list integrity and to integrate the lists (and apps using the list data) once they are trusted. A solution is technically feasible, and will rely upon reputation and good ongoing governance/participation for success.|
| Product architecture and components | - Multisig smart contract that contains the merkle root of the lists <br> - An open github repository that houses the cleartext lists (and potentially acts as service that tracks contributions and/or provides some level of sybil resistance) <br> - An IPFS hash created from those lists and pinned (open to other decentralized data storage solutions as well) <br> - A merkle root written to the smart contract to make the lists onchain <br>- Governance: An admin owns the smart contract and delegates editor(s) to update it with the most recent list (exact mechanisms need to be figured out further)
| Core features |- *Exclusion Lists*: Up-to-date and accurate exclusion list(s) of addresses associated with malicious hacks.<br><br>- *Onchain data*: Onchain representations of the exclusion list data for smart contracts to call. <br><br>- *Transparent Governance*: A method of maintaining the lists in an open and transparent way that contributes to the perceievd integrity of the exclusion list data.
| User experience (UX) and user interface (UI) | _User Definition(s). How the user will interact with the product and how the interfaces will look and behave_
| Acceptance criteria | - Multiple lists: Different lists can be created by users, ie not limited to only one list<br> - Ability for Prover to choose which list they opt into <br> - Ability for Auditor to choose which list they prove against <br> - Voting: a system of collectively choosing which lists (new ones and updated ones) should be written to the smart contract and which should not be. <br> - Friction to participate in governance should be as low as possible without opening up to spam attacks<br>- Governance participants cannot "buy" their way in-- they must be vouched for in some way<br>- Incentive to store address list in a decentralized fashion (in the case of IPFS, what is the incentive to pin the list hash?) <br>- Incentive to maintain (and/or update) address list <br>- Any governance/coordination token that exists must not have secondary market value (for legal reasons) <br>- Must be on all (or most) chains, L2's etc
| Scope | Chain analysis companies may choose to use Exlist, but Exlist is not a chain analysis tool itself and does not provide any analysis tooling beyond providing data in the form of reasonably up-to-date lists.<br><br>In all or most cases lists included in Exlist will be only the initial hacked address and not subsequent funded addresses. For example, if account X is added to the list and then funds from that account are transferred to account Y, and then to account Z, only the inclusion of account X in the list is sufficient. We believe that in the case of unshielded (ie onchain) transactions, there is already sufficient readily available data for services to conduct their own analysis without the aid of this tool.
| Open questions | -Who are the users and how should they be defined for the purpose of developing Exlist further?<br>- How will sustainable and incentivized governance be configured?<br>- How will members of Exist governance vote / align on consenus?<br>- How will potential conflicts among the participants be addressed and resolved?<br>- How decentralized should Exlist be when considering certain centralization/decentralization tradeoffs.<br>- What is the exact barrier to entry to creating lists? Should anyone be able to or very few people?<br>- How often should the lists be updated? (ie, hackers can send funds to a non-listed address faster than Exlist can update the lists)<br>- What is the anticipated growth of hacked addresses over time, and will Exlist remain performant in storing them?<br>- Should Exlist be an EIP?
| Notes | Further reading:<br>- [Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium published 9 Sept 2023](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364) <br> - [Exclusion List Problem Statement](https://hackmd.io/@sandscreener/B1PJTBZdn) <br> - [Twitter: why people might prefer whitelisted Privacy Pools over using a cex](https://x.com/samkazemian/status/1699928335240053215?s=20)<br><br>Relevant Projects:<br>- [Lit Protocol - decentralized key management network](https://developer.litprotocol.com/v2/)<br>- [Jokerace - Contests for communities to make, execute, and reward decisions](https://jokerace.xyz/)<br>Hats Protocol