HOW IT WORKS
From parachain NFT to EVM in four clear steps.
This page unpacks what happens in the UI and on-chain at each stage of a cross-chain NFT transfer, based on the TRD/PRD.
1. The bridge pipeline
A four-stage pipeline that maps directly to the app status: compose, submit, bridge, verify.
01 • Compose
User selects source parachain, NFT, and destination chain. The app uses the asset registry to determine the correct XCM instructions or pallet calls for that route.
02 • Submit
The composed call is sent to the user's wallet (Polkadot extension or EVM wallet). After signing, the app tracks inclusion and finality on the source chain.
03 • Bridge
Hyperbridge executes the cross-consensus hop, locking/burning the NFT on the source side and preparing or minting the destination representation.
04 • Verify
The verification logic confirms that the destination chain shows the expected owner and token, then updates the UI and history as "destination confirmed".
2. Architecture at a glance
The bridge coordinates three main pieces: a Polkadot parachain leg, the Hyperbridge leg, and the destination chain. The diagram below mirrors the TRD's system overview.
Parachain side
User wallet ↔ parachain RPC. XCM / pallet call moves the NFT into the bridge context on Asset Hub or an NFT parachain.
Example: Polkadot → Asset Hub.
Hyperbridge & EVM side
Hyperbridge contract locks/burns on source and mints/unwraps on the destination EVM chain, emitting events used for status.
Example: Ethereum / Base.
Source
Asset Hub (Polkadot)
NFT #123 in collection 42 owned by Alice.
Destination
Base (EVM)
Wrapped ERC-721 token with same metadata, owned by Alice's EVM address.
3. What the user experiences
- Step 1 – Connect wallets: The user connects a Polkadot wallet (for parachains) and, if needed, an EVM wallet. The header and bridge panel reflect which sides are connected.
- Step 2 – Choose route: Source chain, NFT collection/item or ERC-721 contract/tokenId, and destination chain are chosen from options allowed by the asset registry routes.
- Step 3 – Review fees and confirm: Estimated fees (XCM weight + Hyperbridge/EVM gas) are shown. The user confirms and their wallet pops up to sign.
- Step 4 – Watch status update: The status widget walks through "Compose XCM message" → "Submit on source parachain" → "Hyperbridge EVM leg" → "Confirm destination NFT" with explorer links when tx hashes are known.
- Step 5 – View history: Completed and in-progress transfers appear on the history page, keyed by user address and route.
4. What happens on each chain
Parachain leg
The app uses Dedot/PAPI to connect to the selected parachain, builds an XCM or pallet call to move the NFT into the bridge context, and submits it via the user's Polkadot extension. Finality is tracked via subscriptions.
Hyperbridge leg
On the EVM side, Hyperbridge contracts lock or burn the NFT (or wrapped representation) and emit events. The frontend can query these via viem/ethers or an HTTP API, updating status to "bridge in progress" and then "destination pending".
Verification layer
A verification loop (pure frontend in the MVP) periodically checks both chains for finality and ownership. Once the destination NFT is visible with the expected owner, the transfer is marked as "destination confirmed".
5. Data model and statuses
Each transfer is tracked as a typed object (id, route, asset, addresses, tx hashes, timestamps) with a simple status machine:
- Pipeline states: idle → selecting → estimating → signing → source pending → source finalized → bridge in progress → destination pending → destination confirmed → complete or error.
- What the user sees: human-readable labels, progress indicators, and explorer links for both source and destination, plus any error messages if a stage fails.