Cross-Chain NFT Portfolio: Three NFT Models, One View

What makes a cross-chain NFT portfolio uniquely hard is that "NFT" is one word for three unrelated machines with no shared identifier: a contract plus tokenId on EVM, a Merkle-tree entry behind an indexer on Solana, an inscribed satoshi in a UTXO on Bitcoin. A portfolio that assumes one model silently drops the other two. This guide is the cross-model NFT identity and discovery problem, the NFT-specific face of the broader multi-wallet aggregation challenge.

Why three NFT models break one view

• Three incompatible models exist: EVM (contract plus tokenId, ERC-721/1155), Solana (Metaplex account or cNFT via indexer) and Bitcoin (inscribed sat in a UTXO).
• There is no shared identifier, so each NFT keeps its native identity; don't flatten to one ID scheme.
• Aggregation is a discovery and identity problem, not a multi-marketplace feed.
• Loss happens at discovery gaps: missed cNFTs, Ordinals read with a token model, NFTs on less-common chains.
• Each model needs its own discovery method; one method can't cover all three.
• Tax is per item and per jurisdiction, unchanged by chain; aggregation just supplies the complete, correctly-identified set.

Three machines, one word

These are not variants of one thing. A tracker built on the EVM contract-plus-tokenId assumption is structurally blind to Solana cNFTs and Bitcoin Ordinals, the NFT analogue of the non-EVM aggregation problem.

The identity problem

Each model identifies an NFT differently: contract plus tokenId on EVM, a mint or cNFT asset id via indexer on Solana, an inscription on a numbered sat on Bitcoin. There is no shared identifier. A cross-chain view must hold each NFT's native identity, not force one scheme. Collapsing them to a single ID format loses provenance and can merge or drop distinct NFTs, a silent correctness failure, not a display nit.

Where assets vanish

Cross-chain NFT portfolios lose assets at discovery gaps:

• compressed Solana NFTs missed because no indexer was used;
• Ordinals missed because the tool used a token-contract model on Bitcoin;
• EVM NFTs missed on less-common chains.

It is a completeness failure amplified by model heterogeneity, the same root cause as multi-chain reconciliation, specific to NFTs.

One discovery method cannot work

Each model needs its own discovery:

• EVM needs contract and tokenId enumeration across every chain held;
• Solana needs account reads (uncompressed) plus an indexer (compressed);
• Bitcoin needs ordinal-aware UTXO tracing.

A complete NFT portfolio runs the right discovery per model and then unifies the results without flattening their native identities.

Tax is per item, per jurisdiction

Tax does not change by which chain an NFT lives on: each NFT is still its own lot with its own basis and disposal (see NFT cost basis and disposal). The aggregation layer's job is a complete, correctly-identified set so the jurisdiction-specific treatment applies to the right items. The chains differ; the per-item tax discipline does not.

Protocol and chain-specific discovery details

EVM chains: enumerating less-common networks

Beyond Ethereum mainnet, EVM NFTs live on Polygon, Arbitrum, Optimism, Base, Avalanche, and a growing set of L2s and app-chains. A tracker that enumerates Ethereum contracts/tokenIds but not Arbitrum or Base simply has gaps. The EVM standard (ERC-721/1155) is consistent, so the enumeration method is the same — the challenge is ensuring every chain the holder actually used is included. ERC-1155 adds a semi-fungible dimension: one contract address can hold multiple distinct token types at different quantities, which requires quantity-aware enumeration rather than existence-only checking.

Solana: compressed NFTs and state compression

Metaplex's state-compression standard (Bubblegum program) introduced compressed NFTs (cNFTs) in late 2022 to reduce minting costs by up to 1,000x by storing NFT data in Merkle trees on-chain rather than individual accounts. The consequence for discovery is that standard RPC account enumeration does not return cNFTs — they require an indexer (the Digital Asset Standard API, or DAS API, provided by indexers like Helius or Triton). A portfolio that does not integrate a cNFT-capable indexer will silently miss every compressed NFT the holder has received. As of 2026, compressed NFTs are widely used for gaming items, loyalty programs, and bulk creator drops.

Bitcoin Ordinals: inscription numbers vs sat tracking

Bitcoin Ordinals (the Ordinals protocol, released January 2023) assign a sequential number to each satoshi by ordinal theory, and inscriptions attach content to specific sats. The discovery method is UTXO-tracking: to know which inscribed sats a wallet holds, you trace the UTXOs that contain those sats across the UTXO set. A Bitcoin node with ord indexer software, or an API that exposes inscription data (Ordiscan, Hiro, Ordinals Explorer), is required. A portfolio that treats Bitcoin as a simple balance — summing UTXO amounts without tracking specific sats — is completely blind to Ordinals.

Common cross-chain NFT portfolio errors

Mixing ERC-721 and ERC-1155 quantities. ERC-1155 tokens can have quantity > 1 for a given tokenId; treating every ERC-1155 tokenId as a single unit overstates or understates the holding.

Applying a Solana "collection" definition from uncompressed NFTs to cNFTs. Collections in the cNFT ecosystem use a different on-chain structure (the collection mint authority in the tree config). A tool that defines Solana collections only from the standard Metaplex verified creator field may fail to group cNFTs correctly.

Ignoring inscription/sat transfer history. When a Bitcoin wallet sends all funds to a new address, it may inadvertently move inscribed sats if the wallet is not inscription-aware. The portfolio should flag this as a potential transfer of the NFT, not just a Bitcoin balance movement.

Practical guidance

1. Run model-specific discovery: EVM contract and tokenId, Solana account plus indexer, Bitcoin ordinal-aware.
2. Preserve each NFT's native identity; don't flatten to one ID scheme.
3. Treat discovery gaps as completeness failures (cNFTs, Ordinals, rare chains).
4. Unify into one view without merging distinct NFTs.
5. Keep per-item lots for tax across all models and confirm jurisdiction treatment.
6. Reconcile each model to its chain with an audit trail.

Choosing a tool for cross-chain NFTs

Koinly and Zerion both aggregate NFTs across chains to varying depth, and depth across all three models is the test. Before you trust a cross-chain NFT view, confirm the tool:

• runs all three discovery methods, EVM contract/tokenId enumeration on every chain held, a cNFT-capable Solana indexer (DAS API), and ordinal-aware Bitcoin UTXO tracing;
• preserves each NFT's native identity rather than collapsing everything to one ID format, which can merge or drop distinct tokens;
• handles ERC-1155 quantities (a tokenId can have quantity greater than one) instead of counting each as a single unit;
• treats missing cNFTs or Ordinals as a completeness gap to flag, not an acceptable omission.

An EVM-only NFT model silently drops two of the three worlds.

How Wag3s handles it

Wag3s Folio runs model-specific NFT discovery (EVM contract and tokenId, Solana account plus cNFT indexer, Bitcoin ordinal-aware UTXO), unifies them into one view without flattening native identities, and keeps per-item lots for the jurisdiction-specific tax treatment. See the Folio product page.

Further reading

• Bitcoin Ordinals Portfolio Tracking
• Solana NFT & Compressed cNFT Tracking
• NFT Portfolio Valuation
• NFT Cost Basis and Disposal Tracking
• Multi-Chain Portfolio Aggregation Beyond EVM
• Multi-Chain Reconciliation

Sources

• Three distinct NFT models: EVM ERC-721/1155 (contract + tokenId); Solana Metaplex account / compressed NFT via indexer; Bitcoin Ordinals (inscribed sat tracked via UTXOs)
• No shared cross-model identifier — native identity must be preserved; discovery is model-specific
• Completeness failures from model heterogeneity (missed cNFTs/Ordinals); per-item, jurisdiction-specific tax unchanged by chain