From cc1362e549187803ab47fd6fc3279c02607d7397 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jann=20M=C3=BCller?= Date: Wed, 8 Jan 2025 10:21:57 +0100 Subject: [PATCH 1/3] documentation: start work on new document --- doc/architecture-new.md | 61 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 doc/architecture-new.md diff --git a/doc/architecture-new.md b/doc/architecture-new.md new file mode 100644 index 0000000..6935c5c --- /dev/null +++ b/doc/architecture-new.md @@ -0,0 +1,61 @@ +# System Design + +This document describes the design of the regulated stablecoin proof-of-concept (POC). + +## Overview + +The POC consists of two components that make up the functionality of the regulated stablecoin. +The first component is CIP-XXX (TODO: Cip No. and link), which gives us a unified standard for managing different programmable tokens, comparable to some of the better-known ERC standards on Ethereum. +The second component is a concrete instance of such a programmable token, namely a policy that checks each transfer of tokens in its domain to ensure that the sender is not on a list of sanctioned addresses. +The policy also allows the issuer of the programmable token to seize funds from sanctioned addresses. + +TODO: Diagram relationship CIP/policy + +Both components are implemented in Plutarch. Besides the on-chain scripts, the POC also includes: + +* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses +* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters +* A simple user interface that implements the use cases using browser-based wallets +* An OCI image with the on-chain code, the off-chain code and the UI + +With the OCI image it is possible to run the complete system locally with just a single command. +There is no need to install the build toolchain or to operate a cardano node or related infrastructure. +The image can even be used to interact with existing deployments of the POC. + +## High-Level Interactions + +## On-Chain Scripts + +* CIP related +* Policy related + +### Performance + +### Complexity + +### Yielding Patterns + +* Sequence diagrams explaining which script yields to what + +## Off-Chain + +### Docker Image, Deployment + +### Blockfrost + +### Lifecycle + +* 2 phases: Deployment, operations + +Each of the two components (programmable tokens, regulated stablecoin) requires an initial transaction that creates the on-chain data which is referenced on every interaction with the programmable tokens. +The initial transaction creates the registry nodes and mints the NFTs that are used to prove authenticity to the on-chain scripts. +In the POC, the initialisation procedures for programmable tokens and for the regulated stablecoin are contained in a single transaction. + +### Security + +The deployment phase relies exclusively on the command-line (CLI). +It builds a +It does not use the web interface. +Therefre + +## Limitations of POC \ No newline at end of file From c3f0ba313d05e2c309aad724e244e0ab450eee35 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jann=20M=C3=BCller?= Date: Wed, 15 Jan 2025 09:53:49 +0100 Subject: [PATCH 2/3] Intro and a diagram --- doc/architecture-new.md | 49 ++++++++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 8 deletions(-) diff --git a/doc/architecture-new.md b/doc/architecture-new.md index 6935c5c..8b20a20 100644 --- a/doc/architecture-new.md +++ b/doc/architecture-new.md @@ -5,27 +5,60 @@ This document describes the design of the regulated stablecoin proof-of-concept ## Overview The POC consists of two components that make up the functionality of the regulated stablecoin. -The first component is CIP-XXX (TODO: Cip No. and link), which gives us a unified standard for managing different programmable tokens, comparable to some of the better-known ERC standards on Ethereum. +The first component is [CIP-0143](https://github.com/colll78/CIPs/tree/patch-3/CIP-0143), which gives us a unified standard for managing different _programmable tokens_, comparable to some of the popular ERC standards on Ethereum. + The second component is a concrete instance of such a programmable token, namely a policy that checks each transfer of tokens in its domain to ensure that the sender is not on a list of sanctioned addresses. The policy also allows the issuer of the programmable token to seize funds from sanctioned addresses. +We will call this policy the Access Control Policy (ACP). + +### CIP-0143 + +At its core, CIP-0143 describes a registry of programmable token policies and a mechanism for finding the right script whenever one of the programmable tokens is minted, burned, or transferred to another user. + +```mermaid +--- +title: Relationship between CIP-0143 and Access Control Policy +--- + +flowchart LR + cip[CIP-0143] + + policy[Access Control Policy] -TODO: Diagram relationship CIP/policy + other_policies@{shape: procs, label: "Other policies"} + style other_policies fill:#eee; -Both components are implemented in Plutarch. Besides the on-chain scripts, the POC also includes: + cip -->|forwards access checks to| policy + cip --> other_policies +``` -* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses -* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters -* A simple user interface that implements the use cases using browser-based wallets -* An OCI image with the on-chain code, the off-chain code and the UI +CIP-0143 supports a wide range of programmable token policies, including non-financial ones such as royalty collection schemes for NFTs. -With the OCI image it is possible to run the complete system locally with just a single command. +### Contents of this repository + +TOOD: Move to readme + +This repository contains +* Prototype implementation of CIP-0143 in Plutarch +* Prototype implementation of Access Control Policy in Plutarch +* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses. Based on sc-tools and cardano-api. +* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters. +* A user interface that implements the use cases using browser-based wallets. Based on next.js and lucid. +* An OCI container image with the on-chain code, the off-chain code and the UI + +With the container image it is possible to run the complete system locally with just a single command. There is no need to install the build toolchain or to operate a cardano node or related infrastructure. The image can even be used to interact with existing deployments of the POC. +TODO: Instructions for running the POC locally. + ## High-Level Interactions ## On-Chain Scripts +For each of the two components (CIP and ACP) there is a principal validation script that encodes the script's logic and vetoes any transaction that does not meet the specification. +The principal validation scripts use the [stake validator design pattern](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR.md). + * CIP related * Policy related From d9b5db68dd1cc7154047e56b1d391db249438877 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jann=20M=C3=BCller?= Date: Thu, 16 Jan 2025 15:39:16 +0100 Subject: [PATCH 3/3] Update README --- README.md | 73 +++++++------- doc/architecture-new.md | 94 ------------------ doc/architecture.md | 208 ++++++++++++++++++++++------------------ 3 files changed, 155 insertions(+), 220 deletions(-) delete mode 100644 doc/architecture-new.md diff --git a/README.md b/README.md index 132b8db..0e08e1d 100644 --- a/README.md +++ b/README.md @@ -8,55 +8,60 @@ The POC is based on [CIP-0143](https://github.com/colll78/CIPs/blob/patch-3/CIP- # Architecture -The system is designed so that all actions except the initial deployment of the programmable logic UTxOs can be performed through a web UI with browser-based wallets. The REST API therefore exposes a number of endpoints that produce fully-balanced-but-not-signed transactions. The intention is for the caller (web UI) to sign the transactions with the web-based wallet and submit them to the network. The backend uses blockfrost to query the blockchain. As a result, the server is pretty light-weight and does not even need its own database or a full cardano node. +See [doc/architecture.md](doc/architecture.md) -# Usage - -There is a CLI tool `wst-poc-cli` that performs the initial deployment of the system and runs the REST server. A signing key file is needed for the initial deployment but not for the operation of the server. A blockfrost token is needed for both the initial deployment. - -(TO DO - document CLI operations) - -# FAQs - -## How is this system different from Djed? - -Djed is an algorithmic stablecoin that is backed by Ada. In Djed we keep the entire reserves of the stablecoin in a UTxO that is controlled by the Djed contract. Every user of Djed can verify that the reserves exist and that there is enough Ada to pay out all Djed holders. +## Contents of this repository -This POC implements a _fiat-backed stablecoin_. This means that the reserves exist in a bank account outside of the blockchain, and we have to trust the issuer of the stablecoin that every token that's been issued on-chain is backed by one USD in the bank account. +This repository contains +* Prototype implementation of CIP-0143 in Plutarch +* Prototype implementation of Access Control Policy in Plutarch +* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses. Based on sc-tools and cardano-api. +* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters. +* A user interface that implements the use cases using browser-based wallets. Based on next.js and lucid. +* An OCI container image with the on-chain code, the off-chain code and the UI -From a technical perspective, not having to manage the reserve on-chain makes the design of this POC somewhat simpler: We don't need to maintain a global state (the Djed UTxO) that all orders have to synchronise with. The challenge in this POC lies in the programmable token logic. +With the container image it is possible to run the complete system locally with just a single command. +There is no need to install the build toolchain or to operate a cardano node or related infrastructure. +The image can even be used to interact with existing deployments of the POC. -## How does the system scale? - -The core idea of the regulated stablecoin is to run a check every time the owner of some amount of regulated tokens changes. This check is performed by the _transfer logic script_, a plutus program that consults a list of sanctioned addresses to ensure that the receiving address is not on it. - -The list of sanctioned addresses is the only data structure that (a) needs to be read from by every transaction of the transfer logic script and (b) gets changed regularly during the operation of the stablecoin. - -All other factors (number of scripts, script budget, max. number of transfer checks per transaction and so forth) are fixed and do not depend on the number of users. +# Usage -It is important to note that the list of sanctioned addresses scales in space (number of UTxOs), but working with the data structure is done in constant time due to the way the data is laid out. +The easiest way to get started is by running the [wst](https://github.com/input-output-hk/wsc-poc/pkgs/container/wst) image locally: -There is also no risk of UTxO congestion as the "system outputs" are used as reference inputs and not spent by user-to-user transfers. Each user-to-user transfer is processed independently. +```bash +docker run --rm -p 8080:8080 --env WST_BLOCKFROST_TOKEN=previewXYZ ghcr.io/input-output-hk/wst:pr-67 manage 08a8d0bb8717839931b0a594f7c28b0a3b7c78f6e9172e977e250eab7637d879.0 start +``` -### Sanctioned Addresses +Then open [localhost:8080/mint-authority.html](localhost:8080/mint-authority.html) in the browser. -The list of sanctioned addresses is stored on-chain as a [_linked list_](https://github.com/Anastasia-Labs/plutarch-linked-list). This means that each entry (address) in the list is represented as a single transaction output that includes the address itself as well as a pointer to the next address in lexicographical order. +Some notes +1. `podman` or others can be used instead of `docker` +2. `previewXYZ` must be replaced by a valid [blockfrost token](https://docs.blockfrost.io/#description/tokens) for the preview network +3. The tag `pr-67` corresponds to PR 67 +4. `08a8d0bb8717839931b0a594f7c28b0a3b7c78f6e9172e977e250eab7637d879.0` is the transaction input that was used to initialise the deployment on the preview network. -When checking a transfer, the transfer logic script is provided with a single reference input containing the relevant entry in the ordered linked list. +# Contributing -The transfer transaction does not spend the linked list output, therefore the same linked list output can be used by many transactions in the same block and across multiple blocks. +## Backend -#### How many sanctioned addresses are there? +* Run the tests with `cabal test all` +* Enter the nix shell with `nix develop` -Publicly available data on Tether (the largest fiat stablecoin) indicates that Tether has a total of [1990 sanctioned addresses](https://dune.com/phabc/usdt---banned-addresses), out of [109 million on-chain wallets](https://tether.io/news/how-many-usdt-on-chain-holders-are-there/) (Dec. 2024). This suggests that about 0.002 percent of addresses need to be blacklisted. +## Frontend -If our system achieved the scale of Tether then we would need about 1200 UTxOs to store the linked list. At current Ada prices this would amount to 1800 USD in min Ada UTxO deposits, an amount that will be refunded in its entirety when the linked list is deleted. +```bash +cd frontend +npm install +npm run dev +``` -USDC, another fiat-stablecoin, currently has [264 blacklisted addresses](https://bloxy.info/txs/events_sc/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48?signature_id=257159) and 3m users, with a blacklist ratio of about 0.009 percent. +[!IMPORTANT] +Please make sure that the UI can be exported to a set of static assets. +This is necessary for the OCI image. +In particular, the command `npm run export` should succeed. -# Contributing +## Issues -* Run the tests with `cabal test all`. -* Run `cabal run wst-poc-mock-server` to start a mock server that serves fake data +Check out [the issue tracker](https://github.com/input-output-hk/wsc-poc/issues) Bug reports and contributions are welcome! diff --git a/doc/architecture-new.md b/doc/architecture-new.md deleted file mode 100644 index 8b20a20..0000000 --- a/doc/architecture-new.md +++ /dev/null @@ -1,94 +0,0 @@ -# System Design - -This document describes the design of the regulated stablecoin proof-of-concept (POC). - -## Overview - -The POC consists of two components that make up the functionality of the regulated stablecoin. -The first component is [CIP-0143](https://github.com/colll78/CIPs/tree/patch-3/CIP-0143), which gives us a unified standard for managing different _programmable tokens_, comparable to some of the popular ERC standards on Ethereum. - -The second component is a concrete instance of such a programmable token, namely a policy that checks each transfer of tokens in its domain to ensure that the sender is not on a list of sanctioned addresses. -The policy also allows the issuer of the programmable token to seize funds from sanctioned addresses. -We will call this policy the Access Control Policy (ACP). - -### CIP-0143 - -At its core, CIP-0143 describes a registry of programmable token policies and a mechanism for finding the right script whenever one of the programmable tokens is minted, burned, or transferred to another user. - -```mermaid ---- -title: Relationship between CIP-0143 and Access Control Policy ---- - -flowchart LR - cip[CIP-0143] - - policy[Access Control Policy] - - other_policies@{shape: procs, label: "Other policies"} - style other_policies fill:#eee; - - cip -->|forwards access checks to| policy - cip --> other_policies -``` - -CIP-0143 supports a wide range of programmable token policies, including non-financial ones such as royalty collection schemes for NFTs. - -### Contents of this repository - -TOOD: Move to readme - -This repository contains -* Prototype implementation of CIP-0143 in Plutarch -* Prototype implementation of Access Control Policy in Plutarch -* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses. Based on sc-tools and cardano-api. -* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters. -* A user interface that implements the use cases using browser-based wallets. Based on next.js and lucid. -* An OCI container image with the on-chain code, the off-chain code and the UI - -With the container image it is possible to run the complete system locally with just a single command. -There is no need to install the build toolchain or to operate a cardano node or related infrastructure. -The image can even be used to interact with existing deployments of the POC. - -TODO: Instructions for running the POC locally. - -## High-Level Interactions - -## On-Chain Scripts - -For each of the two components (CIP and ACP) there is a principal validation script that encodes the script's logic and vetoes any transaction that does not meet the specification. -The principal validation scripts use the [stake validator design pattern](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR.md). - -* CIP related -* Policy related - -### Performance - -### Complexity - -### Yielding Patterns - -* Sequence diagrams explaining which script yields to what - -## Off-Chain - -### Docker Image, Deployment - -### Blockfrost - -### Lifecycle - -* 2 phases: Deployment, operations - -Each of the two components (programmable tokens, regulated stablecoin) requires an initial transaction that creates the on-chain data which is referenced on every interaction with the programmable tokens. -The initial transaction creates the registry nodes and mints the NFTs that are used to prove authenticity to the on-chain scripts. -In the POC, the initialisation procedures for programmable tokens and for the regulated stablecoin are contained in a single transaction. - -### Security - -The deployment phase relies exclusively on the command-line (CLI). -It builds a -It does not use the web interface. -Therefre - -## Limitations of POC \ No newline at end of file diff --git a/doc/architecture.md b/doc/architecture.md index 0ded592..f135f9e 100644 --- a/doc/architecture.md +++ b/doc/architecture.md @@ -1,92 +1,116 @@ -# Architecture - -## Transactions - -The proof-of-concept must facilitate the following *transaction families*: - -1. Modify the access list. Replace the root of the merkle tree with a new hash. -2. Transfer ownership of regulated token from one address to another -3. Send regulated token back to token issuer (seizing funds) - -Each of those transaction families will be implemented as a stake validator and "yields to" scripts for minting and spending policies. - -Note that we don't consider the "setup transactions" here. For example, creating the initial access list, minting the access list NFT, first transfer of programmable token to programmable token validator. These are technically necessary to take the protocol from POC to product, but they are not required for the demonstration. - -### 1. Modifying the access list - -Transaction inputs -- UTxOs (spending) - - Old access list UTxO -- UTxOs (reference) - - Validator script - -Transaction outputs -- Access list UTxO - - Datum: New access list (root of merkle tree) - - Value: Access list NFT - - Address: Validator that yields to stake script - -Transaction logic -- Redeemer: - * Min UTxO value - * Index of input in list of inputs -- Conditions - * Signature of token issuer must be present - * No minting or burning of access list tokens - * New access list outputs meets the requirements - -### 2. Transfering ownership - -Transaction inputs -- UTxOs (spending) - - Old token locking validator - -- UTxOs (reference) - - Validator script - - Access list UTxO with root of merkle tree - -Transaction outputs -- Token locking UTxO - - Datum: New owner - - Value: - -Transaction logic -- Redeemer: - * Min UTxO value - * Index of input in list of inputs - * Index of access list in list of reference inputs - * Proofs of non-membership in merkle tree for current owner and new owner -- Conditions - * Signature of current owner must be present - * Both proofs of non-membership are valid - * No minting or burning of programmable tokens - -### 3. Seizing funds - -Transaction inputs -- UTxOs (spending) - - Old token locking validator -- UTxOs (reference) - - Validator script - - Access list UTxO - -Transaction outputs -- Token locking UTxO - - Datum: Owner = minting authority - -Transaction logic -- Redeemer: - * Min UTxO value - * Index of input in list of inputs - * Index of access list in list of reference inputs - * Proof of membership of current owner in merkle tree -- Conditions - * Signature of minting authority must be present - * Proof of membership is valid - * No minting or burning of programmable tokens - -## API - -A REST API must be implemented to faciliate the construction of transactions and to perform queries of ownership. It should have one endpoint for each of the three transactions listed above to construct a balanced transaction that can be signed by the user / minting authority. - -The API does not need any kind of authentication as all the keys and related data are managed by the clients. \ No newline at end of file +# System Design + +This document describes the design of the regulated stablecoin proof-of-concept (POC). + +## Overview + +The POC consists of two components that make up the functionality of the regulated stablecoin. +The first component is [CIP-0143](https://github.com/colll78/CIPs/tree/patch-3/CIP-0143), which gives us a unified standard for managing different _programmable tokens_, comparable to some of the popular ERC standards on Ethereum. + +The second component is a concrete instance of such a programmable token, namely a policy that checks each transfer of tokens in its domain to ensure that the sender is not on a list of sanctioned addresses. +The policy also allows the issuer of the programmable token to seize funds from sanctioned addresses. +We will call this policy the Access Control Policy (ACP). + +### CIP-0143 + +At its core, CIP-0143 describes a registry of programmable token policies and a mechanism for finding the right script whenever one of the programmable tokens is minted, burned, or transferred to another user. + +```mermaid +--- +title: Relationship between CIP-0143 and Access Control Policy +--- + +flowchart LR + cip[CIP-0143] + + policy[Access Control Policy] + + other_policies@{shape: procs, label: "Other policies"} + style other_policies fill:#eee; + + cip -->|forwards access checks to| policy + cip --> other_policies +``` + +CIP-0143 supports a wide range of programmable token policies, including non-financial ones such as royalty collection schemes for NFTs. + +## High-Level Interactions + +## On-Chain Scripts + +For each of the two components (CIP and ACP) there is a principal validation script that encodes the script's logic and vetoes any transaction that does not meet the specification. +The principal validation scripts use the [stake validator design pattern](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR.md). + +* CIP related +* Policy related + +### Performance + +### Complexity + +### Yielding Patterns + +* Sequence diagrams explaining which script yields to what + +## Off-Chain + +The system is designed so that all actions except the initial deployment of the programmable logic UTxOs can be performed through a web UI with browser-based wallets. The REST API therefore exposes a number of endpoints that produce fully-balanced-but-not-signed transactions. The intention is for the caller (web UI) to sign the transactions with the web-based wallet and submit them to the network. The backend uses blockfrost to query the blockchain. As a result, the server is pretty light-weight and does not even need its own database or a full cardano node. + +### Docker Image, Deployment + +### Blockfrost + +### Lifecycle + +* 2 phases: Deployment, operations + +Each of the two components (programmable tokens, regulated stablecoin) requires an initial transaction that creates the on-chain data which is referenced on every interaction with the programmable tokens. +The initial transaction creates the registry nodes and mints the NFTs that are used to prove authenticity to the on-chain scripts. +In the POC, the initialisation procedures for programmable tokens and for the regulated stablecoin are contained in a single transaction. + +### Security + +The deployment phase relies exclusively on the command-line (CLI). +It builds a +It does not use the web interface. +Therefre + +## Limitations of POC + +# FAQs + +## How is this system different from Djed? + +Djed is an algorithmic stablecoin that is backed by Ada. In Djed we keep the entire reserves of the stablecoin in a UTxO that is controlled by the Djed contract. Every user of Djed can verify that the reserves exist and that there is enough Ada to pay out all Djed holders. + +This POC implements a _fiat-backed stablecoin_. This means that the reserves exist in a bank account outside of the blockchain, and we have to trust the issuer of the stablecoin that every token that's been issued on-chain is backed by one USD in the bank account. + +From a technical perspective, not having to manage the reserve on-chain makes the design of this POC somewhat simpler: We don't need to maintain a global state (the Djed UTxO) that all orders have to synchronise with. The challenge in this POC lies in the programmable token logic. + +## How does the system scale? + +The core idea of the regulated stablecoin is to run a check every time the owner of some amount of regulated tokens changes. This check is performed by the _transfer logic script_, a plutus program that consults a list of sanctioned addresses to ensure that the receiving address is not on it. + +The list of sanctioned addresses is the only data structure that (a) needs to be read from by every transaction of the transfer logic script and (b) gets changed regularly during the operation of the stablecoin. + +All other factors (number of scripts, script budget, max. number of transfer checks per transaction and so forth) are fixed and do not depend on the number of users. + +It is important to note that the list of sanctioned addresses scales in space (number of UTxOs), but working with the data structure is done in constant time due to the way the data is laid out. + +There is also no risk of UTxO congestion as the "system outputs" are used as reference inputs and not spent by user-to-user transfers. Each user-to-user transfer is processed independently. + +### Sanctioned Addresses + +The list of sanctioned addresses is stored on-chain as a [_linked list_](https://github.com/Anastasia-Labs/plutarch-linked-list). This means that each entry (address) in the list is represented as a single transaction output that includes the address itself as well as a pointer to the next address in lexicographical order. + +When checking a transfer, the transfer logic script is provided with a single reference input containing the relevant entry in the ordered linked list. + +The transfer transaction does not spend the linked list output, therefore the same linked list output can be used by many transactions in the same block and across multiple blocks. + +#### How many sanctioned addresses are there? + +Publicly available data on Tether (the largest fiat stablecoin) indicates that Tether has a total of [1990 sanctioned addresses](https://dune.com/phabc/usdt---banned-addresses), out of [109 million on-chain wallets](https://tether.io/news/how-many-usdt-on-chain-holders-are-there/) (Dec. 2024). This suggests that about 0.002 percent of addresses need to be blacklisted. + +If our system achieved the scale of Tether then we would need about 1200 UTxOs to store the linked list. At current Ada prices this would amount to 1800 USD in min Ada UTxO deposits, an amount that will be refunded in its entirety when the linked list is deleted. + +USDC, another fiat-stablecoin, currently has [264 blacklisted addresses](https://bloxy.info/txs/events_sc/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48?signature_id=257159) and 3m users, with a blacklist ratio of about 0.009 percent.