> ## 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. # 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 configure 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 configured for crosschain use under an ownerless connection. Ownerless tokens are intended for community assets without an active issuer. Connections start ownerless. At configuration, 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](#custom-tokens) instead. Configuring 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 configured by a developer who keeps full control of the crosschain connection. The deployer sets the owner and operator at configuration, configures rate limits and max transfer amount, and holds the pauser role. **Circle cannot assume control of a custom-configured 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 configured as custom `BURN_MINT` relies on its own denylist plus the service-level layer. ## Comparison | Aspect | Ownerless | Custom | | - | - | - | | Who can configure | 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 configurations 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.