NFT Bridges and Multichain Support: Adding Chains to an NFT App

An NFT bridge moves a token from one blockchain to another, while multichain support lets one app work on several chains. This guide explains how bridges and omnichain NFT standards work, then sets out seven phases for adding a chain to an NFT app you already run.

It assumes your app already runs on one chain. If you plan to license software that ships with several chains, read the multi-chain NFT marketplace guide. If you plan a marketplace where people trade across chains, read the cross-chain NFT marketplace guide.

Multichain support and cross-chain NFTs are two different jobs

Multichain support means each NFT stays on the chain where it was minted: your app reads and writes on several chains, but no token moves between them. Most of the phases below cover this job.

A cross-chain NFT can move from one chain to another, which needs an NFT bridge or a messaging protocol. Bridges add security risk, so add one only when users need to move tokens.

How an NFT bridge works

A blockchain cannot read the state of another blockchain, so a bridge passes a signed or proven message from the source chain to the destination chain, where a contract checks the message and then mints or releases a token. Bridges use one of two models:

• Lock and mint. The bridge locks the original NFT in a contract on the source chain, and a contract on the destination chain mints a wrapped copy. When the holder sends the copy back, the bridge burns it and unlocks the original. Wormhole's token bridge works this way, and so does the ONFT Adapter from LayerZero.
• Burn and mint. The source contract burns the token, and the destination contract mints the same token ID, so only one live copy exists at any time. This model needs a contract that you control on every chain, so burn and mint fits new collections built to move between chains.

In the lock-and-mint model, the wrapped copy is only as safe as the contract that holds the original. If attackers drain the lock contract or forge a message, every wrapped copy loses its backing.

Omnichain NFT standards and bridge options

An omnichain NFT is a collection designed to move between chains from the start. The table lists the main options.

Each option trusts a different set of parties to confirm messages. LayerZero lets the app owner pick the verifier networks, while Wormhole uses a set of 19 guardian nodes. Read each protocol's security docs before you choose, because the verifier set decides who could forge a transfer.

Bridge risk in numbers

Bridges hold large pools of locked assets, so attackers target them, and the largest losses in 2022 came from bridges:

• Ronin bridge, March 2022: about $625 million, after attackers took control of five of nine validator keys.
• Wormhole, February 2022: more than $300 million, through a signature check flaw on Solana.
• Harmony Horizon bridge, June 2022: about $100 million, after a multisig key compromise.
• Nomad bridge, August 2022: about $190 million, after an upgrade introduced a flaw.

Most of these losses were fungible tokens, but wrapped NFTs carry the same exposure.

Phase 1: Choose the chain and the reason

Write down the specific reason for the new chain. Examples: "Partner X's wallet supports only Base." "Our game items cost more in gas than they sell for on Ethereum." "The creators we want to reach mint on Solana." If the reason is general reach, test it with a small pilot first.

Then sort the chain into one of two groups:

• Another EVM chain, such as an Ethereum L2, Polygon PoS, BNB Smart Chain or Avalanche C-Chain, where most contract and wallet code carries over.
• A non-EVM chain, such as Solana, Flow, Tezos or Cardano, which needs a new integration with its own contracts, SDKs and indexer.

For low-fee chains that settle on Ethereum, see NFT layer 2 development.

Phase 2: Remove single-chain assumptions

Before you deploy, find every place where the code assumes one chain. Look for hard-coded chain IDs, RPC URLs, contract addresses, explorer links, token symbols and confirmation counts, and for database tables without a chain column. Replace these values with a chain registry, which holds one config object per chain for the rest of the app to read.

In the database, a token's key becomes chain ID plus contract address plus token ID. Collections, listings, sales and user wallets each need a chain field. The database migration takes the longest, and every later chain reuses the new schema.

Phase 3: Contracts and deployment

On EVM chains, deploy the same audited bytecode. The CREATE2 opcode can give a contract the same address on every chain, which keeps configuration simple. Check the differences between chains first. Some L2s price calldata differently, some chains lack certain precompiles or opcodes, and rollups handle block timestamps in their own way.

Decide how supply works across chains. If one collection exists on two chains, split the supply between the chains or move tokens with a bridge. Two separate contracts must never mint the same token IDs, because collectors would then hold duplicates.

On non-EVM chains, you write or adopt different programs: Solana uses Metaplex standards, and Flow uses Cadence contracts.

Phase 4: Indexing and data

Each chain needs event ingestion, a backfill of past events, reorg handling and metadata fetching. Set a confirmation threshold per chain, because finality differs between Ethereum, optimistic rollups, ZK rollups, Polygon PoS and Solana. Many teams buy an NFT data API for chains the API covers well and run their own indexer for the rest.

Phase 5: Wallets and user flows

• Detect the user's network and ask for a switch before a transaction starts.
• Show the chain on every item, listing and transaction.
• Charge gas in each chain's own token, or pay the gas for the user.
• Link several addresses to one profile so a user sees all holdings in one place.
• Show correct token names. Polygon's gas token has been POL since the September 2024 migration from MATIC, and BNB Smart Chain uses BNB.
• If you add a bridge, show the expected arrival time and the bridge fee before the user signs.

Phase 6: Testing and launch

1. Run the full contract test suite against a fork of the new chain.
2. Deploy to the chain's testnet and run each flow end to end: mint, list, buy, cancel, transfer and royalty payout.
3. Load-test the new indexer with a backfill and a burst of events.
4. If you change the audited contracts or config, order a short security review of the change.
5. Launch with a small set of collections, then open the chain to everyone.

Phase 7: Running several chains

Monitor indexer lag, RPC error rates and failed transactions on each chain. Follow each chain's upgrade announcements, because hard forks and sequencer changes can break the app. Compare each chain's volume with its cost every quarter. If a chain adds support work but few trades, you can drop it, as long as you announce the change early and keep existing items readable.

Frequently asked questions