> ## 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.

# Ownerless and custom tokens

> The two integration models CCTP for non-USDC supports for making a token crosschain.

Two integration models exist for taking an existing token crosschain: ownerless
tokens and custom tokens. Anyone can register either type. The two models differ
in who controls the resulting bridge connection and whether Circle can
intervene.

## Ownerless tokens

An ownerless token is an existing token registered for crosschain use under an
ownerless connection. Ownerless tokens are intended for community assets without
an active issuer.

Connections start ownerless. At registration, no owner or operator can be set on
the resulting `TokenManager`. Circle can assume operatorship or ownership later
in special circumstances.

Ownerless connections have no rate limits or maximum transfer amount by default.
Circle can add controls only if the bridged token reaches a meaningful total
value locked (TVL) threshold and has a reliable price oracle.

On the home blockchain the `TokenManager` uses `LOCK_UNLOCK`. On remote
blockchains, CCTP for non-USDC deploys a wrapped `CrossChainToken` and the
`TokenManager` uses `NATIVE_CROSSCHAIN_TOKEN`, which uses mint and burn.

<Warning>
  Ownerless tokens are designed for assets with no issuer or active controller. If
  you issue or have authority over the token, use the
  [custom token model](#custom-tokens) instead. Registering an issuer-controlled
  asset as an ownerless token removes your ability to set rate limits, pause
  transfers, or manage the bridge connection.
</Warning>

## Custom tokens

A custom token is registered by a developer who keeps full control of the
crosschain connection. The deployer sets the owner and operator at registration,
configures rate limits and max transfer amount, and holds the pauser role.
**Circle cannot assume control of a custom-registered connection.** Custom
tokens are intended for issuer-controlled assets, for example, fiat-backed
stablecoins and RWAs.

The issuer chooses `BURN_MINT` or `LOCK_UNLOCK` for the source blockchain's
`TokenManager`. Remote blockchains always use `BURN_MINT`. If you use
`LOCK_UNLOCK`, apply it on only one blockchain—using it on multiple source
blockchains causes transfer errors when assets route between more than two
blockchains. The issuer grants the local `TokenManager` the minter role on
tokens using `BURN_MINT`. The per-token denylist (layer 2) applies only to
protocol-deployed `CrossChainToken`s. A pre-existing ERC-20 registered as custom
`BURN_MINT` relies on its own denylist plus the service-level layer.

## Comparison

| Aspect                    | Ownerless                                                                                          | Custom                                                                                   |
| ------------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Who can register          | Anyone                                                                                             | Anyone                                                                                   |
| Ownership at creation     | No owner or operator                                                                               | Deployer sets owner and operator                                                         |
| Circle override           | Circle can assume operatorship or ownership in special circumstances                               | Circle has no control over the connection                                                |
| Configurable rate limits  | No (no rate limits by default; Circle may add controls if TVL and price oracle thresholds are met) | Yes                                                                                      |
| Configurable denylist     | Remote CCT inherits service denylist; no self-serve override                                       | Service-level denylist applies; CCT layer 2 only on protocol-deployed `CrossChainToken`  |
| Home `TokenManagerType`   | `LOCK_UNLOCK`                                                                                      | `BURN_MINT` or `LOCK_UNLOCK` (issuer's choice; use `LOCK_UNLOCK` on one blockchain only) |
| Remote `TokenManagerType` | `NATIVE_CROSSCHAIN_TOKEN`                                                                          | `BURN_MINT`                                                                              |
| Token contract on remote  | Deployed by CCTP for non-USDC as a `CrossChainToken`                                               | Deployed by the issuer directly or through the protocol on each blockchain               |
| Typical token             | Ownerless community asset                                                                          | Issuer-controlled (stablecoins, RWAs)                                                    |

## Choosing a model

The two models exist to support two distinct integration shapes:

* **Choose ownerless** when you don't own or operate the underlying token and
  want to bridge an unmanaged asset without taking on bridge governance.
  Ownerless connections run on default parameters and stay ownerless unless
  Circle assumes control to respond to a security incident or protocol-level
  change.
* **Choose custom** when you issue the token (or otherwise have authority to
  manage it) and want to make your token crosschain with full, unilateral
  control over rate limits, pause, and upgrades. Custom connections give you
  authority that Circle cannot override. The per-token denylist is available
  when you deploy a `CrossChainToken`; existing ERC-20 custom registrations rely
  on your token's own controls plus the service denylist.

The protocol guarantees that any pre-existing token has at least one ownerless
bridge available, while still letting issuers run their own bridge when they
need to.