MIMD-0023: Anti-Money Laundering

[Dodecahedr0x]

MIMD-0023: Anti-Money Laundering (AML)

Abstract

This MIMD presents a way to prevent users suspected of money laundering from using the validator. It does so by:

1. Avoiding to clone eSPL token accounts owned by suspected money launderers.
2. Preventing money launderers-signed transactions from being executed.

The limitations of this approach are:

1. It only works for eSPL token accounts. A money launderer can still create a custom program that mimics our eSPL program, and we wouldn't be able to infer that this program is actually used to manage tokens. Thr risk of this approach is low because it wouldn't benefit from the privacy coming from the set of users of the eSPL program. We could detect those approaches by monitoring post actions for those token transfers.
2. Requires blocking execution until we ensured the user is safe. Honest participants would be affected with a degraded processing speed.
3. Requires a way to permissionlessly undelegate an account. Because forbidden accounts will not complete delegation, there must be a way for users to recover they funds without going through the PER.
4. Many small transfers will go undetected. To avoid running too many checks, we only verify large transfers. This means that a launderer doing many smalls transfers will be undetected. We could prevent this by recording all in and out going amounts from all accounts and run the checks once an account reaches the threshold.

Motivation

With the introduction of Private Ephemeral Rollups (PERs), money launderers could potentially use TEEs for their operations.
This puts MagicBlock (and in the future PER operators) at risk. Preventing money launderers from using PERs is a critical security requirement.

Alternatives considered

1. API Checks

We provide a simple API that let's users create private transfers. Running the checks before returning a transaction would prevent money laudering going through the API but would not prevent launderers from using the validator directly.

2. Checks inside the TEE middleware

Since AML checks only make sense for PER, a reasonable solution would be to run those checks inside the TEE middleware.
However, the middleware only filters user interactions, but the private payment flow is orchestrated entirely from mainnet: a user signs a mainnet transaction and the PER transfers are performed automatically by the validator, without the user sending any transactions to the TEE.

3. New middleware between the TEE validator and the mainnet RPC

By preventing updates of accounts owned by suspected money launderers, we can prevent them from using the validator.
However, this solution would have a lot less context about what is being executed and would either have to fetch data from the validator (more latency) or aggressively run AML checks (expensive).

Overview

AML results are used in several components of the validator (namely chainlink and processor). To avoid duplicating checks, a new AML component is introduced. It uses a local storage for AML checks to reduce the number of calls to the AML API. It offers a single check API async fn check(address: Pubkey) -> AmlResult:

1. If a result for the given address is already in memory, get it
   1. Else, run the API and store the result in a local database and in memory.
2. Return the result

Cloning prevention

This step consists of detecting eSPL deposits that are above a certain threshold:

1. When an EATA is being cloned, look at the amount.
2. If the amount being delegated is above the threshold, run the AML check
3. If the checks fail, do not mark the account as delegated even if it is.

Execution prevention

This step consists of preventing execution of transaction coming from a launderer. Ensuring the AML checks have been run for every signers of every transactions would be to expensive, so if we proppose the following heuristic:

• If the signer is already checked in the AML service, rely on that result.
• Otherwise:
  • If the transaction contains a large enough token program transfer, run the check immediately.
  • If the transaction contains a large enough deposit into the transfer queue, run the checks immediately.
  • If the transaction involves the Magic program, Magic context and an account owned by the token program, run the checks immediately.
  • Otherwise allow the transaction to pass through.