> ## Documentation Index
> Fetch the complete documentation index at: https://developers.circle.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Before reading these docs, install the relevant Circle Skill to get pre-loaded context — skills are LLM-optimized and cover architecture decisions, correct flows, and common pitfalls. In Claude Code: run /plugin marketplace add circlefin/skills then /plugin install circle-skills@circle. With Vercel Skills CLI: run npx skills add circlefin/skills. Available skills: use-usdc https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-usdc/SKILL.md (balances, transfers, approvals on EVM and Solana); EURC has no skill — see https://developers.circle.com/stablecoins/what-is-eurc.md; bridge-stablecoin https://github.com/circlefin/skills/blob/master/plugins/circle/skills/bridge-stablecoin/SKILL.md (crosschain transfers via CCTP, USDC, EURC, and third-party assets); use-arc https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-arc/SKILL.md (Arc chain config, contract deployment, USDC bridging — Arc docs: https://docs.arc.io/llms.txt); use-circle-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-circle-wallets/SKILL.md (choose wallet type); use-developer-controlled-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-developer-controlled-wallets/SKILL.md (custodial wallets for payouts and treasury); use-user-controlled-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-user-controlled-wallets/SKILL.md (embedded wallets with Web2 login); use-modular-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-modular-wallets/SKILL.md (smart contract wallets with passkeys and ERC-4337); use-gateway https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-gateway/SKILL.md (unified USDC balance, nanopayments); use-smart-contract-platform https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-smart-contract-platform/SKILL.md (deploy, interact, monitor contracts). Pair any skill with the Circle MCP server for live SDK signatures, contract addresses, and chain IDs: {"mcpServers":{"circle":{"url":"https://api.circle.com/v1/codegen/mcp"}}}.
> Read the product overview first. Each product has an overview explaining when and why to use it. Read it before quickstarts.
> Pick the right wallet type. Developer-controlled (you hold keys), user-controlled (end user holds keys via PIN/social login), or modular (smart contract wallets with passkeys). See https://developers.circle.com/wallets.md.
> Use CCTP V2 for crosschain transfers. CCTP natively transfers USDC and EURC via burn-and-mint, and supports permissionless wrapping of third-party assets via lock-and-mint. V1 is legacy; always use V2 unless V1 is specified or the chain requires it (Noble, Sui, and Aptos still require V1). Migration guide: https://developers.circle.com/cctp/migration-from-v1-to-v2.md.
> Use Bridge Kit for frontend bridging. Wraps CCTP with a simpler SDK for user-facing apps. Use CCTP directly for backend transfers.
> Gas Station vs Paymaster. Gas Station sponsors gas for Circle Wallet transactions. Paymaster lets users pay gas in USDC. Different use cases — read both overviews.
> Gateway Nanopayments for sub-cent payments. Gasless USDC micropayments down to $0.000001 via x402 and batched settlement. For pay-per-request APIs, AI agent payments, streaming.
> Look up USDC addresses per chain. Never hardcode — use https://developers.circle.com/stablecoins/usdc-contract-addresses.md.
> Prefer SDKs over raw API calls. Node.js and Python SDKs handle auth, retries, and errors.
> API key required. Bearer token in Authorization header. Testnet and mainnet use separate keys and may use different base URLs depending on the product.
> Set up webhooks when available. Most operations are async. Webhooks deliver transaction confirmations and state changes.
> When calling list endpoints, paginate using pageSize and pageAfter until no nextPageAfter cursor is returned—stopping at the first page silently misses records.
> Building an AI agent? Start with the Agent Stack—Circle CLI, agent wallets, and nanopayments built for autonomous use cases: https://developers.circle.com/agent-stack.md.

# How-to: Configure a denylist provider

> Configure a per-token denylist provider on a CrossChainToken you own.

Configure the per-token denylist on a `CrossChainToken` you own. The per-token
layer is independent of the service-level denylist that Circle configures on
every blockchain—see
[Denylist layers](/cctp/expanded-assets/concepts/denylist-layers) for the
two-layer model. The service-level layer always runs; this guide only covers the
layer the CCT owner controls.

<Note>
  Only `CrossChainToken` contracts deployed as `NATIVE_CROSSCHAIN_TOKEN` have a
  per-token denylist. `BURN_MINT` and `LOCK_UNLOCK` configurations of pre-existing
  ERC-20 tokens rely on whatever screening the underlying token already
  implements.
</Note>

## Prerequisites

Before you begin, ensure that you've:

* Obtained the `tokenId` of the `CrossChainToken` you want to configure.
* Confirmed that the wallet you'll use owns the `CrossChainToken` (the value
  returned by `owner()` on the CCT). The denylist provider can only be changed
  by the owner.

## Steps

<Steps>
  The snippets assume that `publicClient`, `walletClient`, `serviceAddress`,
  `tokenId`, and `newProviderAddress` are already initialized. Each code example
  includes only the ABI entries needed for that operation.

  Receipt-handling code is omitted for brevity, but you should wait for each
  state-changing transaction to confirm before reading the updated state or
  submitting the next transaction.

  <Step title="Choose a denylist provider">
    A denylist provider is any contract that implements:

    ```solidity Solidity theme={null}
    interface IDenylistProvider {
        function isDenylisted(address account) external view returns (bool);
    }
    ```

    Common choices:

    * **Reuse Circle's screening list.** Read the service-level provider from the
      local `CrossChainTokenService` and configure your CCT to use the same one.
      Per-token screening then matches Circle's central list.
    * **Bridge a FiatToken denylist.** Wrap an existing FiatToken's `isBlacklisted`
      view in an `IDenylistProvider` adapter (Circle ships
      `FiatTokenDenylistAdapter`).
    * **Implement your own.** Any contract that exposes `isDenylisted(address)` can
      serve as a provider.
    * **Compose multiple lists.** Write a small provider that combines results from
      several upstream lists using a logical OR.

    The CCT has a single provider slot. Setting a new provider **replaces** the
    previous one. If you want both Circle's list and your own, deploy a composite
    provider that calls both internally.
  </Step>

  <Step title="Discover the CrossChainToken address">
    ```typescript TypeScript theme={null}
    const serviceAbi = [
      {
        name: "resolveTokenAddress",
        type: "function",
        stateMutability: "view",
        inputs: [{ name: "tokenId", type: "bytes32" }],
        outputs: [{ name: "token", type: "address" }],
      },
    ] as const;

    const tokenAddress = await publicClient.readContract({
      address: serviceAddress,
      abi: serviceAbi,
      functionName: "resolveTokenAddress",
      args: [tokenId],
    });
    ```
  </Step>

  <Step title="Set the denylist provider">
    Call
    [`updateDenylistProvider`](/cctp/expanded-assets/references/contract-reference)
    on the `CrossChainToken` with the address of your chosen provider.

    ```typescript TypeScript theme={null}
    const updateDenylistProviderAbi = [
      {
        name: "updateDenylistProvider",
        type: "function",
        stateMutability: "nonpayable",
        inputs: [{ name: "newProvider", type: "address" }],
        outputs: [],
      },
    ] as const;

    await walletClient.writeContract({
      address: tokenAddress,
      abi: updateDenylistProviderAbi,
      functionName: "updateDenylistProvider",
      args: [newProviderAddress],
    });
    ```

    The contract emits `DenylistProviderUpdated(oldProvider, newProvider)`.
  </Step>

  <Step title="Verify the new provider">
    ```typescript TypeScript theme={null}
    const denylistProviderAbi = [
      {
        name: "denylistProvider",
        type: "function",
        stateMutability: "view",
        inputs: [],
        outputs: [{ name: "", type: "address" }],
      },
    ] as const;

    const current = await publicClient.readContract({
      address: tokenAddress,
      abi: denylistProviderAbi,
      functionName: "denylistProvider",
    });

    if (current.toLowerCase() !== newProviderAddress.toLowerCase()) {
      throw new Error("Denylist provider was not updated");
    }
    ```
  </Step>

  <Step title="Disable per-token screening (optional)">
    To remove per-token screening, set the provider to `address(0)`:

    ```typescript TypeScript theme={null}
    const updateDenylistProviderAbi = [
      {
        name: "updateDenylistProvider",
        type: "function",
        stateMutability: "nonpayable",
        inputs: [{ name: "newProvider", type: "address" }],
        outputs: [],
      },
    ] as const;

    await walletClient.writeContract({
      address: tokenAddress,
      abi: updateDenylistProviderAbi,
      functionName: "updateDenylistProvider",
      args: ["0x0000000000000000000000000000000000000000"],
    });
    ```

    After the transaction confirms, read `denylistProvider()` and verify that it
    returns `address(0)`.

    The service-level layer continues to apply. There is no way for a CCT owner to
    opt out of the service-level layer.
  </Step>
</Steps>