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 involves preventing the execution of transactions originating from a launderer. Ensuring the AML checks have been run for every signer of every transaction would be too expensive, so if we propose 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.

Handling failed checks

Once a user has been prevented from interacting with the PER, although we protected ourselves from money launderers, we still need to decide what to do next. Below are some of the possibilities.

Automatic undelegation

Once cloning has been prevented, the account is still delegated on Solana but unusable in rollups. A simple and effective approach would be to undelegate the account to avoid punishing false positives.

The downside of this approach is that since the error is internal to the validator, there is no explicit error on Solana or the PER that the user can look for. A workaround for that situation would be to add a memo transaction to the undelegation, indicating which account failed the AML test. This way, the user would eventually see an explanation in the explorer.

This undelegation can happen in two ways: either immediately after parsing the action and running AML checks, or later, via a background service. The first approach has the merit of being the fastest and could potentially use the same flow as other failing-delegation actions if we choose to always undelegate accounts with failing actions. The second keeps the chainlink component of the validator lean, but would require a ticker to check newly blocked accounts and trigger the undelegation.

Data collection

AML checks rely on the Range API, and we can hardly be more efficient internally at determining whether to block an account. However, there might be some edge cases where we should allow the account to be cloned despite failing the checks. To help inform that decision, we should collect as much information as possible when blocking accounts:

• Blocked signers. This is the primary information used by the Range API.
• Cleartext action. The delegation action that triggered the check was decrypted by the validator. Using that information, we may be able to recreate an implied token transfer that can be used as input to Range's transfer API.
• Delegation transaction. The signature of the delegation transaction can be used to trace the execution.

Manually validating checks

Once an address is blocked, it stays in a cache for some time, preventing any subsequent action from that user. If we want to allow the user to proceed anyway, we need a way to manually set the value in the cache. The simplest approach would be a simple CLI or script that we can run for specific addresses. However, especially in cases where specific apps request to unlock a user, we might want a more ergonomic interface.

The background service mentioned above could also provide a frontend to format some of the registered data related to blocking an address in a user-friendly way. By using the API tokens we provide to app admins, they would have a limited view of blocked users and be able to prevalidate some users. We need to keep the final decision with us, as we are the ones taking the actual laundering risk.