How to: Monitor Blocklist Compliance

The USDC contract enforces blocklist restrictions at runtime. The Memo and Multicall3From contracts route transactions while preserving the original msg.sender through the CallFrom precompile; your monitoring must attribute these to the original sender. Subscribe to Blocklisted and UnBlocklisted events to maintain a local copy of the blocklist.

Prerequisites

Before you begin:

Access to an Arc RPC endpoint (https://rpc.testnet.arc.io) or WebSocket (wss://rpc.testnet.arc.io)
Familiarity with Ethereum event log filtering and transaction tracing
A local database or cache for storing blocklisted addresses
Understanding of your regulatory obligations (AML/CFT screening requirements)

Contracts and addresses

Contract	Address	Purpose
USDC	`0x3600000000000000000000000000000000000000`	Native stablecoin with built-in blocklist
Memo	`0x5294E9927c3306DcBaDb03fe70b92e01cCede505`	Attaches metadata to transfers; preserves `msg.sender`
Multicall3From	`0x522fAf9A91c41c443c66765030741e4AaCe147D0`	Batches multiple calls; preserves `msg.sender`

Steps

Step 1. Understand blocklist enforcement

Arc enforces the USDC blocklist across multiple stages of the transaction lifecycle:

Stage	When it applies	Behavior
Pre-mempool	Transaction submitted to RPC node	If the sender is blocklisted, the RPC node rejects the transaction. No gas is consumed and no receipt is returned.
Pre-execution	Transaction executes after entering mempool	If the sender became blocklisted between submission and execution, the transaction is rejected. No gas is consumed and no receipt is returned.
Runtime transfer check	`transfer` or `transferFrom` is called	If either the `from` or `to` address is blocklisted, the call reverts.

Step 2. Monitor blocklist events

Subscribe to the Blocklisted and UnBlocklisted events on the USDC contract to maintain a real-time view of restricted addresses.

import { Contract, JsonRpcProvider } from "ethers";

const USDC_ADDRESS = "0x3600000000000000000000000000000000000000";
const provider = new JsonRpcProvider("https://rpc.testnet.arc.io");

const usdc = new Contract(
  USDC_ADDRESS,
  [
    "event Blocklisted(address indexed account)",
    "event UnBlocklisted(address indexed account)",
  ],
  provider,
);

// Subscribe to blocklist changes
usdc.on("Blocklisted", (account: string) => {
  console.log(`Address blocklisted: ${account}`);
  addToLocalBlocklist(account);
});

usdc.on("UnBlocklisted", (account: string) => {
  console.log(`Address unblocklisted: ${account}`);
  removeFromLocalBlocklist(account);
});

Build transfer history from the system emitter (0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE), not the ERC-20 contract (0x3600000000000000000000000000000000000000). Native USDC transfers emit no log at the ERC-20 address, so filtering on the ERC-20 address alone misses them. An ERC-20 transfer() emits from both addresses, so filtering on both double-counts every ERC-20 transfer.

Step 3. Include Memo and Multicall3From in your monitoring scope

The Memo and Multicall3From contracts use the CallFrom precompile to execute calls on behalf of the original sender. The blocklist is still enforced (the CallFrom precompile checks the original sender’s blocklist status), but compliance monitors must attribute activity correctly.

If you only monitor direct from addresses in transaction receipts, you will miss the true sender for transactions routed through Memo or Multicall3From. You must inspect calls to these contracts and attribute them to the original msg.sender.

import { Interface, JsonRpcProvider, Log } from "ethers";

const MEMO_ADDRESS = "0x5294E9927c3306DcBaDb03fe70b92e01cCede505";
const MULTICALL3FROM_ADDRESS = "0x522fAf9A91c41c443c66765030741e4AaCe147D0";
const USDC_ADDRESS = "0x3600000000000000000000000000000000000000";
const SYSTEM_EMITTER = "0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE";
const TRANSFER_TOPIC =
  "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef";

const provider = new JsonRpcProvider("https://rpc.testnet.arc.io");
const erc20Interface = new Interface([
  "event Transfer(address indexed from, address indexed to, uint256 value)",
]);

async function checkTransactionCompliance(txHash: string): Promise<void> {
  const tx = await provider.getTransaction(txHash);
  if (!tx) return;

  const receipt = await provider.getTransactionReceipt(txHash);
  if (!receipt) return;

  const originalSender = tx.from;

  // Flag if the transaction is routed through Memo or Multicall3From
  const isRoutedTransaction =
    tx.to?.toLowerCase() === MEMO_ADDRESS.toLowerCase() ||
    tx.to?.toLowerCase() === MULTICALL3FROM_ADDRESS.toLowerCase();

  if (isRoutedTransaction) {
    // Attribute all Transfer events in this transaction to the original sender
    const transfers = receipt.logs.filter(
      (log: Log) =>
        log.address.toLowerCase() === SYSTEM_EMITTER.toLowerCase() &&
        log.topics[0] === TRANSFER_TOPIC,
    );

    for (const log of transfers) {
      const parsed = erc20Interface.parseLog({
        topics: log.topics as string[],
        data: log.data,
      });
      if (!parsed) continue;

      // Screen the original sender, not the contract address
      await screenAddress(originalSender, txHash);
      await screenAddress(parsed.args.to as string, txHash);
    }
  }
}

Step 4. Build a transaction decision tree

Use the following logic to determine whether a transaction involves a blocklisted address:

Check	Condition	Action
1. Direct sender	`tx.from` is in blocklist	No action needed: rejected at pre-mempool and pre-execution stages before mining.
2. Transfer recipient	`Transfer` event `to` is in blocklist	Flag: `transfer`/`transferFrom` will revert
3. Routed transfer recipient	`tx.to` is Memo or Multicall3From AND any Transfer `to` is in blocklist	Flag: runtime transfer check will revert

interface ComplianceResult {
  flagged: boolean;
  reason?: string;
}

async function evaluateTransaction(txHash: string): Promise<ComplianceResult> {
  const tx = await provider.getTransaction(txHash);
  if (!tx) return { flagged: false };

  // Check 1: Direct sender
  if (await isBlocklisted(tx.from)) {
    return { flagged: true, reason: "Sender is blocklisted" };
  }

  const receipt = await provider.getTransactionReceipt(txHash);
  if (!receipt) return { flagged: false };

  // Check 2-5: Inspect Transfer events for blocklisted recipients
  const transfers = receipt.logs.filter(
    (log: Log) =>
      log.address.toLowerCase() === SYSTEM_EMITTER.toLowerCase() &&
      log.topics[0] === TRANSFER_TOPIC,
  );

  for (const log of transfers) {
    const parsed = erc20Interface.parseLog({
      topics: log.topics as string[],
      data: log.data,
    });
    if (!parsed) continue;

    const to = parsed.args.to as string;
    if (await isBlocklisted(to)) {
      return { flagged: true, reason: `Recipient ${to} is blocklisted` };
    }
  }

  return { flagged: false };
}

Step 5. Integrate compliance vendor APIs

Connect your monitoring pipeline to Elliptic or TRM Labs for automated risk scoring and sanctions screening. These vendors provide Arc-compatible APIs for real-time transaction analysis.

// Example: screen an address against a compliance vendor API
async function screenAddress(
  address: string,
  txHash: string,
): Promise<boolean> {
  const response = await fetch(
    "https://api.your-compliance-vendor.com/screen",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${process.env.COMPLIANCE_API_KEY}`,
      },
      body: JSON.stringify({
        address,
        chain: "arc",
        transactionHash: txHash,
      }),
    },
  );

  const result = await response.json();
  return result.risk_level === "high";
}

For vendor-specific integration details, see Compliance vendors. When your own system submits a USDC transfer, also check receipt.status after it confirms. A blocklist revert is onchain: the transaction is included and gas is consumed, but state rolls back. Monitoring Blocklisted events won’t catch reverts that already occurred; receipt.status === 0 is the authoritative signal.

Exchanges

On/off-ramps

Wallets

DeFi

Relayers and paymasters

Infrastructure

Run a node

How to: Monitor Blocklist Compliance

Prerequisites

Contracts and addresses

Steps

Step 1. Understand blocklist enforcement

Step 2. Monitor blocklist events

Step 3. Include Memo and Multicall3From in your monitoring scope

Step 4. Build a transaction decision tree

Step 5. Integrate compliance vendor APIs

See also

​Prerequisites

​Contracts and addresses

​Steps

​Step 1. Understand blocklist enforcement

​Step 2. Monitor blocklist events

​Step 3. Include Memo and Multicall3From in your monitoring scope

​Step 4. Build a transaction decision tree

​Step 5. Integrate compliance vendor APIs

​See also

Prerequisites

Contracts and addresses

Steps

Step 1. Understand blocklist enforcement

Step 2. Monitor blocklist events

Step 3. Include Memo and Multicall3From in your monitoring scope

Step 4. Build a transaction decision tree

Step 5. Integrate compliance vendor APIs

See also