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

A cross-chain NFT marketplace lets a buyer on one blockchain buy an NFT that lives on another blockchain. This guide explains how such a marketplace differs from a multichain one, how cross-chain purchases settle, how to choose a messaging protocol, and which components and build steps the project needs.

Multichain versus cross-chain marketplaces

A multichain marketplace shows NFTs from several chains in one interface, but the buyer still pays on the NFT's own chain. A cross-chain marketplace lets the buyer pay on one chain and receive the NFT on another, which needs a messaging or bridging layer between chains. That layer carries most of the extra cost and risk.

If listings side by side are enough, read the multichain NFT marketplace guide. The NFT bridge and multichain support guide covers bridging in depth, and this page covers marketplace purchase flows that cross chains.

How a cross-chain NFT purchase works

Pay on one chain, settle on the NFT's chain

The buyer pays on the buyer's own chain, often in a stablecoin, and the marketplace contract on that chain sends a message to the marketplace contract on the NFT's chain. The receiving contract completes the sale and sends the NFT to the buyer's address on that chain. The marketplace can also bridge the NFT to the buyer's chain afterwards.

Solvers that pay for the NFT first

Some marketplaces use solvers or relayers. A solver buys the NFT on the NFT's chain with its own funds and delivers it to the buyer, and the marketplace then repays the solver from the buyer's payment on the buyer's chain. This flow is faster, because the buyer does not wait for a cross-chain message, but the solver is an extra party, so the marketplace needs a bond or another guarantee that the solver will deliver.

Moving the NFT itself

Some marketplaces also let users move an NFT to another chain. Two designs exist:

• Lock and mint. A contract on the source chain locks the original NFT, and the destination chain mints a wrapped copy. Moving back burns the copy and unlocks the original. The locked originals sit in one contract, which becomes a target for attackers.
• Burn and mint. The collection exists on several chains from the start. A move burns the token on the source chain and mints the same token ID on the destination, so no pool of locked tokens exists. LayerZero's ONFT721 contract uses this design for new collections, while its ONFT721Adapter uses lock and mint for existing ERC-721 collections.

Choosing a messaging protocol

Common options include LayerZero, Wormhole, Chainlink CCIP, Axelar and Hyperlane. The protocols differ in three ways: how they verify messages, which chains they reach, and what each message costs. LayerZero, for example, lets each application choose its own set of verifiers, called DVNs, and its documentation tells production deployments to require several DVNs from independent operators. With a single DVN, one compromised verifier could forge messages on that route.

Ask these questions about each protocol:

• Who verifies a message, and how many parties would need to work together to forge one?
• Can the marketplace set its own verification rules, or must it use the protocol's defaults?
• What happens when a message fails or arrives late, and how do users recover stuck assets?
• Does the protocol publish its audits and its history of incidents?

Bridges are a frequent target of attacks. In August 2022, Chainalysis estimated that attackers had stolen about $2 billion in 13 bridge hacks. By Chainalysis's count, bridge attacks made up 69% of all funds stolen in 2022 up to that month, a period that included the Ronin and Harmony bridge hacks. The ethereum.org bridge overview explains the trust models.

Components of a cross-chain NFT marketplace

The blog post on interoperability and layer 2 solutions covers scaling in general, and the NFT aggregator guide covers marketplaces that pull listings from other venues.

User experience across chains

• Accept the buyer's funds. Quote prices in a stablecoin or in the buyer's native token, and handle the conversion and the delivery behind one confirmation.
• Show delivery status. A cross-chain message takes from seconds to many minutes, depending on the protocol and on how long the source chain needs to reach finality, so show progress and an expected time.
• Pay the gas on the destination chain. A buyer should not need gas tokens on a chain they have never used, so add the destination fee to the price.
• Show one ownership view. A user's profile lists every NFT the user owns, with the current chain of each NFT.

Build sequence

1. Confirm the need. Decide whether users need cross-chain purchases or only multichain listings.
2. Start small. Pick two chains and one messaging protocol, and prove the purchase flow on testnets.
3. Design failure handling first. Define timeouts, retries and refunds before the normal purchase path.
4. Audit the contracts together. The auditor should review the router and the NFT contracts as one system, because bugs in message verification caused the Wormhole and Nomad bridge exploits in 2022.
5. Add limits. Set rate limits and a pause control on the cross-chain path.
6. Expand slowly. Add a third chain only after the first pair runs without incidents in production.

The following is a reasoned estimate, not a quote. A small team needs about two to four months to add one cross-chain purchase flow between two EVM chains to an existing marketplace, including the audit. Each further chain costs less than the first, but each chain still needs its own tests and monitoring.

Frequently asked questions