Skip to main content
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.
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 instead. Registering an issuer-controlled asset as an ownerless token removes your ability to set rate limits, pause transfers, or manage the bridge connection.

​
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 CrossChainTokens. A pre-existing ERC-20 registered as custom BURN_MINT relies on its own denylist plus the service-level layer.

​
Comparison

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