Bringing a token you already launched to Arc

Expanding an existing token to Arc is not a deployment problem, it is a supply-accounting problem wearing a deployment costume. The contract takes an afternoon. Deciding which representation of your token is the real one, how supply is counted when it lives in three places, and how holders know which address to trust takes far longer, and is where projects get this wrong. Creating a token from scratch is a different job and lives at [/arc/mint-tokens-on-arc](/arc/mint-tokens-on-arc).

This page covers Arc in its first weeks of mainnet. The decision framework below is stable; which specific messaging and bridge providers have shipped Arc support is not, so where that is still settling we say so and tell you where to check. Last reviewed: September 2026.

What are the three ways to bring a token to Arc?

Three models are viable. A canonical bridged representation, where a bridge holds the token on its home chain and mints a claim on Arc. A native deployment, where you deploy a fresh contract on Arc with its own supply. And a burn-and-mint adapter, where the token is destroyed on the source chain and reissued on Arc so circulating supply across all chains stays constant.

Each produces a different answer to "how many of these exist," and that answer is what your listings, dashboards, auditors and community all work from.

Which model should you choose?

Choose burn-and-mint if your token has meaningful market value and is tracked by third parties, because it is the only model where supply across chains stays constant without anyone maintaining a spreadsheet. Choose a canonical bridged representation if you want speed and accept a bridge as a permanent dependency. Choose an independently minted native deployment only if you genuinely intend two separate assets.

The last option is the one to be careful about. Deploying an unconnected contract on Arc with the same name and symbol as your existing token creates a second asset that markets will treat as the same thing until a price divergence proves otherwise. Projects choose it because it is the least work, then spend a year explaining the divergence.

Arc's design pushes toward burn-and-mint for anything monetary. Arc is Circle's Layer-1 where gas is paid in USDC, and its flagship asset arrives by exactly that mechanism. On a chain whose native asset has an issuer maintaining constant cross-chain supply, a token whose supply floats per chain looks anomalous to whoever evaluates it.

What does a burn-and-mint adapter look like in practice?

A burn-and-mint expansion needs one contract on each chain and one authority both trust. The source adapter takes custody of tokens and burns them; the destination adapter mints an equal amount only on a valid message from the source. The token contract on Arc must grant mint and burn rights to the adapter and nothing else.

// Illustrative shape only. Do not deploy without an audit and a
// message-verification layer you have reviewed line by line.
interface IArcTokenAdapter {
    /// @notice Burns `amount` on this chain, emitting a message for `dstChainId`.
    function bridgeOut(uint256 amount, uint256 dstChainId, address to) external;

    /// @notice Mints `amount` to `to`. Callable only by the verified messenger.
    function bridgeIn(bytes calldata message, bytes calldata proof) external;
}

The hard part is not this interface. It is the message-verification layer underneath: who signs, how many of them, what happens when a message is replayed, and what your recovery path is when the messenger stalls with tokens burned on one side.

The established providers answer that differently, and the answer becomes a permanent property of your token rather than a vendor choice you can quietly reverse. Wormhole verifies messages with a fixed set of nineteen Guardian nodes, thirteen of which must sign. Axelar runs a proof-of-stake validator network that co-authorises messages with threshold signatures. LayerZero, on which the widely used omnichain fungible token standard is built, makes verification a per-application configuration: you choose the verifier networks and the threshold among them, so your token's security is a parameter you set and own. Hyperlane is explicit about the same trade-off, with pluggable security modules the deploying team defines outright.

Which of those have shipped Arc support is a different question from how they work, and is genuinely still moving weeks after Arc's September 16, 2026 mainnet launch. Check the provider's own supported-networks page on the day you commit, not a comparison article, and confirm the deployment is mainnet rather than testnet only. The transport options are compared at /arc/bridges-compared.

If your token is a standard ERC-20 with no mint function and no upgrade path, this model is unavailable without a migration. That is a constraint, not a detail, and worth checking before you promise an Arc launch date. /arc/token-standards covers what the standards do and do not permit.

What actually breaks when a token goes multichain?

Three things break, reliably. Supply accounting, because "total supply" stops being a single number any one contract can report. Liquidity, because the same trading interest is now split across venues on two or more chains. And holder comprehension, because every additional address your token has is another a scammer can imitate.

Supply accounting is the one that causes public embarrassment. A totalSupply() call on your Arc contract returns the Arc-side figure only. Aggregators that sum naively overstate you; ones that read only your home chain understate you. Decide before launch which number is the headline figure, publish the methodology, and give aggregators one source to query. Under burn-and-mint the correct headline is source-chain supply minus tokens held by the adapter, plus every chain's minted balance, and someone on your team should be able to reproduce it on demand.

Liquidity fragmentation is the one that costs money. A thin Arc pool produces worse execution than the home-chain pool, and traders who discover that keep trading on the home chain, which keeps the Arc pool thin. Seeding an Arc pool at a size that supports real trades is a capital commitment, not a formality; /arc/initial-liquidity covers how to size it.

Holder confusion produces losses you will be blamed for. The week you announce an Arc deployment is the week fake Arc contracts for your token appear, on every chain expansion.

What governance and communications work does this require?

At minimum: a recorded decision on which model you are using and why, a published canonical address list, a supply methodology anyone can verify, and one announcement channel holders are told in advance to treat as authoritative. If your token has onchain governance, minting rights on a new chain are a governance action, not an operations task.

Write the address list before the deployment, not after. Publish it where your holders already look, pin it, and repeat the address in every announcement rather than linking to a page that can be spoofed. The most effective anti-phishing measure available to a token team is boring repetition of the correct address in channels the team controls.

Then the credibility question. From a holder's point of view, a new deployment is a new contract with new permissions controlled by a team that now has mint rights on two chains. Locking the liquidity you seed on Arc, and locking or vesting any team allocation on the destination chain, is the part strangers can verify. /arc/lock-liquidity-on-arc covers the mechanics on Arc.

What does an expansion checklist look like?

Decide the model and record the reasoning. Confirm your existing contract supports it. Choose and review the messaging or bridge layer. Deploy and verify the Arc contract. Publish the canonical address list. Seed and lock liquidity. Publish the supply methodology. Announce, with the address repeated inline. Monitor for impostor contracts in the first week, when they appear.

Verify the Arc contract's source before you announce the address, not after. On the explorer a verified contract shows a source-code tab and a read/write interface built from the ABI; an unverified one shows bytecode only, which reads as a red flag on a new chain whether or not it is one.

Does bridging my token to Arc create new tokens?

Under burn-and-mint, no: an equal amount is destroyed on the source chain, so aggregate supply is unchanged. Under lock-and-mint, new units exist on Arc but are backed one-for-one by locked units on the source chain, so circulating supply is unchanged while total minted units rise. Under an independent native deployment, yes.

Can I use the same contract address on Arc as on my home chain?

Sometimes. Arc is EVM-compatible, so deterministic deployment applies in principle: CREATE2 derives an address from the deployer, a salt and the init code, so identical inputs give an identical address on any EVM chain. Most teams rely on the widely deployed deterministic-deployment proxy at 0x4e59b44847b379578588920cA78FbF26c0B4956C, which Foundry uses by default, and whether it exists on Arc is a one-line check rather than something to assume — call eth_getCode against that address on Arc's RPC and see whether bytecode comes back. If it does not, anyone can push it there with the standard presigned deployment transaction. Either way, a matching address is a nice-to-have for holder recognition, not a substitute for publishing the address list.

What happens to my token's price when it lists on a second chain?

If the representations are fungible through a working bridge, arbitrage holds them together and the difference is execution quality on each venue. If they are not fungible, prices are independent and can diverge indefinitely, which is the strongest argument against the independent-deployment model.

Do I need to redeploy my governance and staking contracts?

Only if you want those functions on Arc. Many teams keep governance on the home chain and treat other chains as trading venues. Say so explicitly, because holders on Arc will otherwise assume they can participate.

How long does an expansion realistically take?

The contract work is days. Reviewing the messaging layer, settling the supply methodology, getting governance approval and preparing communications are where the calendar goes. Teams that treat it as a deployment task ship in a week and spend the next month on damage control.