BlockchainAppMaker

NFT

Cross-chain NFT marketplace development: moving and selling NFTs across chains

A cross-chain NFT marketplace lets a buyer on one chain purchase, or move, an NFT that lives on another. That is different from a multichain marketplace, which simply lists NFTs from several chains side by side. Cross-chain requires a messaging or bridging layer, and that layer is where most of the cost and nearly all of the risk sits.

Multichain versus cross-chain

Multichain marketplaceCross-chain marketplace
What users seeListings from several chains in one UIBuy or move an NFT regardless of which chain it or the buyer is on
SettlementOn the NFT's own chain; buyer switches networkPayment on one chain, delivery on another, coordinated by messages
Extra infrastructurePer-chain indexers and contractsPlus a bridge or messaging protocol and relayers
Main riskOperational complexityBridge or message-layer compromise

If side-by-side listings are enough, read multichain NFT support or the white-label multichain platform guide. This page covers true cross-chain flows.

How NFTs move between chains

Lock and mint

The original NFT is locked in a contract on the source chain. A message tells the destination chain to mint a wrapped representation. Moving back burns the wrapped copy and unlocks the original. Simple, but the locked originals become a honeypot, and the wrapped token is only as trustworthy as the bridge.

Burn and mint (native multichain NFTs)

The collection is deployed on several chains from the start. Moving a token burns it on the source and mints the same token ID on the destination. There is no pool of locked assets, and the token is "native" everywhere. Standards such as LayerZero's ONFT and Wormhole's NFT bridging patterns, and Chainlink CCIP's cross-chain token examples, support this design.

Cross-chain purchase without moving the NFT

The buyer pays on their chain (often with a stablecoin); a message instructs a contract on the NFT's chain to complete the sale and deliver to the buyer's address there, or to bridge the NFT afterwards. Some marketplaces instead use solvers or relayers who front the purchase on the NFT's chain and get repaid on the buyer's chain, which is faster but adds a trusted or bonded intermediary.

Choosing a messaging layer

Common options include LayerZero, Wormhole, Chainlink CCIP, Axelar and Hyperlane. They differ in how messages are verified (oracle and relayer sets, guardian committees, decentralized oracle networks, configurable security modules), which chains they reach, and cost. Questions to ask:

  • Who verifies a message, and how many parties must collude to forge one?
  • Can you configure your own verification, or are you bound to the protocol's defaults?
  • What happens if a message fails or is delayed? Can users recover stuck assets?
  • Does the protocol have a public audit and incident history?

Bridges have been the largest single category of crypto losses, including the Ronin and Harmony bridge hacks in 2022. See ethereum.org's bridge overview for the trust models.

Marketplace components

  • Per-chain NFT contracts (or a native multichain collection) and per-chain marketplace contracts.
  • A cross-chain router that sends and receives messages and enforces who may mint or release.
  • Indexers for every chain, plus a unified ownership view that tracks where each token currently lives.
  • Status tracking for in-flight transfers, with retry and refund paths.
  • Royalty logic that works the same on every chain.

For scaling context, see our post on interoperability and Layer 2, and for marketplaces that pull listings from other venues, NFT aggregator development.

User experience across chains

The technology only matters if the buyer does not have to understand it. Good cross-chain marketplaces hide most of the machinery:

  • Pay with what you have. Quote prices in a stablecoin or the buyer's native token, and handle the conversion and delivery behind one confirmation.
  • Show delivery status. Cross-chain messages take from seconds to many minutes depending on the protocol and source chain finality. Show progress and an expected time, not a spinner.
  • Pay gas for the destination leg. Users should not need gas tokens on a chain they have never used; bundle the destination fee into the price.
  • Keep a single ownership view. A user's profile should show every NFT they own across chains, with the current location of each.

As a reasoned estimate, adding one cross-chain purchase flow between two EVM chains to an existing marketplace takes a small team two to four months, including audit; each additional chain is cheaper than the first but still needs its own testing and monitoring.

Build sequence

  1. Decide whether you truly need cross-chain transfers or only multichain listings.
  2. Pick two chains and one messaging protocol; prove the flow on testnets.
  3. Design failure handling before the happy path: timeouts, retries, refunds.
  4. Audit the router and NFT contracts together; message-handling bugs are the classic exploit.
  5. Add rate limits and pause controls for the bridge path.
  6. Expand chains only after the first pair has run cleanly in production.

Frequently asked questions

Is a bridged NFT the same as the original?

With lock-and-mint, it is a wrapped claim on the locked original. With burn-and-mint native collections, it is the same token ID reissued on the new chain. Collectors and marketplaces often treat wrapped versions as less valuable.

Can royalties work across chains?

Only if each chain's contract reports the same royalty and marketplaces on each chain honor it. Configure EIP-2981 consistently in every deployment.

What is the biggest risk?

The message layer. If an attacker can forge a message, they can mint or release NFTs at will. Choose verification carefully and cap exposure.