What Are Compressed NFTs?

Introduction

Compressed NFTs are NFTs designed to make very large collections economically practical by changing where NFT data lives and how it is verified. In a conventional NFT design, each asset usually gets its own dedicated on-chain state, which is simple to reason about but expensive to create at scale. Compressed NFTs take a different path: they keep a compact cryptographic commitment on-chain and rely on proofs plus indexed data to recover the full asset state. The stakes are straightforward. If you want to mint a few thousand collectibles, ordinary NFT storage may be acceptable. If you want to mint hundreds of thousands or millions of assets for a game, ticketing system, loyalty program, or large consumer campaign, the ordinary model becomes too costly and too heavy.

That makes compressed NFTs easier to understand if you start with the problem they solve rather than with the implementation details. The problem is not “how do we make NFTs different?” The problem is: how do we preserve verifiable ownership and updates without paying to store every asset in its own full on-chain account? The core answer is to store commitments on-chain instead of storing all asset details there directly.

On Solana, this idea is implemented through state compression, the Bubblegum program from Metaplex, and on-chain concurrent Merkle trees managed through account-compression infrastructure. In that design, a compressed NFT, often called a cNFT, is represented as a hashed leaf in a Merkle tree rather than as a standalone on-chain account. The result is a large reduction in minting cost (often by orders of magnitude compared with standard NFTs) while keeping the asset cryptographically tied to on-chain state.

Why do NFT minting and storage costs spike as collections scale?

A normal NFT is easy to picture because the storage model matches the object model. One token, one set of accounts, one place to look for ownership and metadata pointers. That directness is a strength. Wallets and marketplaces can inspect the chain, read the relevant accounts, and reconstruct the asset without much extra machinery.

But this simplicity is expensive because blockchains charge for state. If every NFT needs its own account structure, then minting cost grows roughly with the number of NFTs you create. That is tolerable for scarce art collections. It is much less tolerable for use cases where the NFT is not a luxury object but a lightweight record: an in-game item, an event credential, a badge, or a mass loyalty asset. In those settings, the economic unit is not “one rare collectible”; it is “millions of low-value digital objects.”

Compressed NFTs attack exactly that cost center. Instead of treating each NFT as a fully separate piece of on-chain state, they treat many NFTs as entries inside a shared authenticated data structure. The chain stores enough information to verify that an entry is valid, current, and authorized, but not all of the detailed asset data in the same way a traditional NFT account model would.

This is the key idea to hold onto: compression does not mean the NFT becomes unverifiable. It means verification is moved from direct account inspection to proof-based inclusion in a committed data structure.

How does a single Merkle-root commitment make many NFTs verifiable?

The data structure doing the work is the Merkle tree. A Merkle tree is a tree of hashes where each leaf is a hash of some underlying data, and each parent is a hash of its children. If you know the tree’s top hash (the root) and you have the sibling hashes along a path from one leaf to the root, you can verify that the leaf belongs to that tree without having to store or read every other leaf.

That property is what makes compression useful. Instead of storing one complete on-chain account per NFT, the system stores a Merkle root on-chain. Each NFT becomes a leaf in the tree. To prove that a specific NFT exists with a specific owner and state, a client presents the leaf data plus a Merkle proof showing how that leaf reconstructs the current root.

Here is the mechanism in plain language. Imagine a tree holding a large collection of NFTs. If Alice owns one of them, her NFT’s essential state is hashed into a leaf. The chain does not need to remember Alice’s entire NFT in a dedicated account. It only needs to remember the current tree root, because that root commits to all leaves at once. When Alice transfers the NFT, the system verifies the old leaf against the current root, checks authorization, computes the updated leaf reflecting the new owner, and updates the tree to a new root. The root changes because the committed state changed.

This is why compressed NFTs are cheap in a way ordinary NFTs are not. The chain is paying to maintain a compact commitment to a large set of assets, not a fully independent storage footprint for each one.

Where is the NFT data stored in a compressed‑NFT design?

A common misunderstanding is to hear “off-chain” and assume “untrusted.” That is too crude. The real distinction is between data availability and data integrity.

In the Solana compressed-NFT model, the detailed NFT data is not stored in a dedicated on-chain account in the usual way. Metaplex’s Bubblegum V2 documentation explains that when a compressed NFT is minted, its data is hashed into a new leaf in an on-chain Merkle tree, while the full NFT data is recorded in the creating transaction and later updates appear as changelog-style information. To make that usable in practice, RPC providers index those transactions and expose the reconstructed asset data through the Metaplex DAS API.

So there are really two layers. The first is the on-chain commitment layer, which stores the Merkle root and enough tree state to verify updates. The second is the indexed data layer, which reconstructs what humans and applications actually want to read: owner, collection, metadata fields, creators, and similar asset information.

That means compressed NFTs preserve integrity differently from ordinary NFTs. With a traditional NFT, integrity comes from reading the dedicated on-chain accounts directly. With a compressed NFT, integrity comes from checking that the reconstructed asset data hashes to a leaf that fits the current on-chain root via a valid Merkle proof. The data may be served by an RPC or indexer, but the proof ties it back to chain state.

This also explains why compressed NFTs are not just “smaller NFTs.” They are a different storage and verification model.

Why does Solana use concurrent Merkle trees and fast‑forwarding for cNFTs?

If a Merkle tree were updated by one actor at a time with no overlap, the idea would be simple but operationally awkward. Real systems do not behave that way. Many users may mint, transfer, burn, or update assets nearly simultaneously. If every update required all other users to wait until they fetched the absolute latest proof, throughput would suffer.

Solana’s account-compression design addresses this by using concurrent Merkle trees, which support fast-forwarding proofs. The rough problem is that a Merkle proof can go stale as soon as another write changes the root. The solution is to allow stale proofs to remain usable within a bounded window, so clients and indexers do not have to recompute everything after every single update.

The practical control for this is the tree’s buffer size. Solana’s developer materials describe buffer size as an approximation of how many concurrent updates a proof can tolerate before it must be recomputed. If the buffer size is 64, then a proof may remain valid across roughly 64 updates by being fast-forwarded. This matters because compressed NFTs are only useful at scale if many operations can happen without constant proof invalidation.

This is an important place to separate intuition from guarantee. The intuition is “the system tolerates some lag between proof generation and proof use.” The guarantee is not unlimited. Once activity moves beyond the configured buffer window, the proof must be regenerated from newer tree state.

How does minting and transferring a compressed NFT work (worked example)?

Suppose a game studio wants to issue 500,000 achievement badges. With ordinary NFTs, that likely means creating a vast number of individual on-chain records. With compressed NFTs, the studio first creates a Merkle tree configured for the expected scale and activity pattern. The tree has a depth, which determines capacity; since a balanced tree of depth d can hold 2^d leaves, depth is really a capacity choice disguised as a tree parameter.

When the studio mints a badge to Maya, Bubblegum takes the badge’s relevant asset data, hashes it into a leaf, and appends that leaf into the tree. The tree root updates on-chain. The complete human-readable asset data is also present in the mint transaction so indexers can reconstruct and serve it later. Maya’s wallet or a supporting application does not scan raw transaction history by itself every time. Instead, it usually asks a DAS-capable RPC provider for the asset data and its proof.

Now Maya transfers the badge to Leo. The client fetches the current asset data and the Merkle proof for Maya’s badge leaf from an RPC that supports the DAS API or equivalent compressed-asset indexing. The client can verify the proof against the on-chain root, which checks that the leaf it was given really belongs to the committed tree state. Then Bubblegum processes the transfer: it checks authorization, updates the owner field in the leaf, computes the new hashes up the path, and writes the resulting new root. Leo is now the owner because the chain’s committed tree state says so.

Notice what happened mechanically. The transfer did not update a token account in the conventional NFT sense. It updated a tree leaf and the root derived from that leaf. That is the compressed-NFT model in one sentence.

Which Merkle‑tree parameters (depth, buffer, canopy) control capacity and usability?

Compressed NFTs on Solana are not just “put assets in a tree.” The tree has parameters, and those parameters encode tradeoffs.

The first is depth, which sets capacity. A deeper tree can hold more leaves, and therefore more NFTs, because capacity is 2^depth. This is conceptually simple: if you expect millions of assets, you need a tree large enough to hold them.

The second is buffer size, which sets how much concurrent update activity stale proofs can survive. A larger buffer makes the system more tolerant of concurrency and indexer lag, but it is still a bounded tolerance rather than a free lunch.

The third is canopy height. Canopy means keeping part of the upper tree on-chain so clients do not have to submit the entire proof path themselves. This reduces proof payload size and can make transactions more composable, but it increases on-chain rent. Solana materials note that canopy height tops out at 17, and the reason this parameter matters is simple: proof data has to fit within transaction constraints. Deep trees without sufficient canopy become difficult to use because the proof path becomes too large.

These are not arbitrary knobs. They exist because compressed NFTs trade storage cost for proof-management complexity. Tree design is where that trade is tuned.

How do Bubblegum and DAS enable readable and provable compressed NFTs?

A compressed NFT is not useful merely because the on-chain root exists. Someone has to reconstruct and serve the asset data and proofs in a way applications can consume. That is why the Bubblegum program and the Metaplex DAS API matter together.

Bubblegum is the program used to create and manage compressed NFTs on Solana. It handles operations such as minting, transferring, updating, delegating, verifying, burning, and, in V2, newer features tied to the V2 leaf schema and tree design. But Bubblegum alone does not solve the developer and wallet problem of reading full cNFT state conveniently.

That is where DAS enters. The Digital Asset Standard API is a unified asset-query interface that supports standard Metaplex assets and compressed Bubblegum assets. Because compressed NFT details are indexed from transaction history and related data stores rather than read from a simple dedicated account layout, DAS-compatible RPCs make those assets queryable in a standard way. Methods such as getAssetProof exist precisely because proof retrieval is part of the normal read path for compressed assets.

This dependency has consequences. Not every RPC supports DAS. If your provider does not index compressed NFT data and expose the relevant methods, your application may be unable to display or interact with cNFTs properly even though the assets exist on-chain in the commitment sense. In other words, compressed NFTs reduce write-side cost by increasing read-side infrastructure requirements.

Which standard NFT behaviors do compressed NFTs support?

An easy mistake is to assume compression strips NFTs down to a toy version. In practice, the goal is not to remove NFT behavior but to preserve it under a different storage model.

Metaplex documents that compressed NFTs can support the familiar operations developers expect: mint, transfer, update, burn, delegate, verify, and in Bubblegum V2 additional features such as freeze and thaw, soulbound behavior, royalty-related enforcement hooks, and permanent delegates. The implementation detail is that these actions work by obtaining current asset data and validating the relevant leaf with a Merkle proof rather than by reading and mutating a conventional NFT account record.

Bubblegum V2 introduces LeafSchemaV2 and requires V2 Merkle trees created with the appropriate instruction. Metaplex explicitly notes that V2 is not backward-compatible with V1 trees. That is not a cosmetic version bump. It reflects the fact that the leaf contents define what the tree is committing to. Change the schema, and you change what it means to prove an asset’s state.

This is also where compressed NFTs connect to neighboring Solana asset designs such as MPL Core collections and plugins. V2 adds support for integration with those newer primitives, which matters because the ecosystem increasingly wants richer asset behavior without giving up scale.

How much do compressed NFTs actually save, and under what assumptions?

The strongest reason compressed NFTs exist is cost. Multiple primary sources describe the savings as orders of magnitude. Metaplex’s Bubblegum V2 documentation gives illustrative figures such as roughly 8.5 SOL in rent for a tree holding about 1 million cNFTs, implying about 0.00001 SOL per cNFT, and about 0.34 SOL for a smaller tree of 16,384 cNFTs. Solana’s explainer and developer examples similarly frame the difference as massive relative to standard NFTs.

The reason these numbers become so small is structural. A large tree spreads the fixed on-chain storage burden across many assets. You are not paying rent for a million separate NFT accounts. You are paying rent for the shared authenticated structure plus the transactions that update it.

But this should not be romanticized into “free NFTs.” The savings depend on assumptions: the tree must be correctly sized, the indexing path must exist, proofs must remain operationally manageable, and your application must accept the complexity of reconstructing asset state from indexed transaction data rather than from a simple per-asset account model.

So the real claim is narrower and more useful: compressed NFTs make mass issuance economical when your application can tolerate proof-based reads and specialized infrastructure.

When are compressed NFTs a poor fit or impractical?

The main limitation is not cryptographic weakness. It is system shape. Compressed NFTs replace expensive on-chain storage with a hybrid system that depends on on-chain commitments plus off-chain indexing.

That introduces availability and integration constraints. If wallets, marketplaces, or dapps assume every NFT has standard on-chain token and metadata accounts, compressed NFTs are a mismatch. Helius’ documentation makes this explicit: compressed NFTs are not native Solana tokens in the usual account sense, and reading their attributes or collection data requires DAS-style access. That changes application loading flows and can complicate compatibility.

There are also scaling boundaries inside the compression model itself. Very large trees mean longer proof paths. Longer proof paths mean larger transactions and more difficulty fitting everything into Solana’s constraints. Practical guidance from ecosystem documentation recommends keeping tree sizes around 1 million or less for this reason. There is also contention: a single giant tree can become a hot shared resource, so multiple smaller trees may be operationally better than one enormous tree.

And there is trust surface. While integrity can be checked cryptographically, users often still rely on RPCs and indexers to serve correct, timely data and proofs. Clients can verify proofs, which protects against certain forms of tampering, but the ecosystem experience still depends on indexer completeness and availability.

What security and provenance risks should I watch for with compressed NFTs?

Compressed NFTs also create specific provenance and upgrade-trust questions because they interact with broader NFT metadata systems. Security reviews of Metaplex’s Token Metadata program have pointed out that Bubblegum compatibility paths can become systemic risks if the relevant program logic is compromised. In particular, decompression-related compatibility and creator or collection verification flows create trust dependencies on the Bubblegum program behaving correctly.

There has also been at least one documented creator-verification vulnerability in mpl-token-metadata connected to provisions used for compressed-NFT decompression, later fixed in version 1.6.3. The important lesson is not “compressed NFTs are unsafe.” The lesson is more precise: once you move authenticity and verification across multiple cooperating programs, the security model includes those integration points, not just the Merkle tree math.

That distinction matters because the cryptography of inclusion proofs may be sound while the surrounding provenance logic still has bugs or governance risk.

Are compressed NFTs a new token standard or just an implementation pattern?

It is better to think of compressed NFTs as an implementation pattern for NFTs under severe cost constraints, not as a universal replacement for all NFT standards. In the Solana ecosystem, the most important concrete implementation is Metaplex Bubblegum using state compression and concurrent Merkle trees.

That distinction matters because “NFT” is the asset concept, while “compressed NFT” describes how that asset’s state is represented and verified. The asset remains an NFT in the economic and application sense: it can have an owner, metadata, collections, delegates, and transfer logic. What changes is the persistence model.

So if you ask whether compressed NFTs are “real NFTs,” the useful answer is yes, but with a different storage contract. The system promises ownership and state verifiability through tree commitments and proofs rather than through one dedicated account per asset.

Conclusion

Compressed NFTs exist because blockchains make persistent state expensive, and ordinary NFT designs become uneconomical when the number of assets gets very large. The core move is simple to state: store many NFTs as hashed leaves in a Merkle tree, keep the root on-chain, and use proofs to verify each asset’s state.

On Solana, Bubblegum, account compression, and DAS turn that idea into a practical system. The result is dramatically cheaper minting and support for large-scale NFT applications. The cost is a more complex read path, dependence on indexing infrastructure, and a security model that includes both cryptographic proofs and the programs that interpret them.

If you remember one thing tomorrow, remember this: a compressed NFT is not an NFT with less truth. It is an NFT whose truth is proved differently.

How do you evaluate a token before using or buying it?

Check the token’s design and read-path before committing funds, then use Cube Exchange to execute the trade once you’ve confirmed the asset’s mechanics. For compressed NFTs, that means verifying on‑chain commitments (roots), the existence of a DAS/read-indexing path, and any tree parameters that affect availability or proof size.

1. Fund your Cube account with fiat or a supported crypto transfer.
2. Inspect the token or NFT: check total supply and minting rules; for compressed NFTs confirm Bubblegum/Bubblegum V2 usage, DAS read support, tree depth (capacity), buffer size (concurrency tolerance), and canopy height (proof payload tradeoff).
3. For compressed NFTs, fetch the asset data and its Merkle proof from a DAS-capable RPC or indexer (use getAssetProof or the provider’s equivalent) and verify the proof hashes match the on‑chain tree root and that creators/collection verification are intact.
4. On Cube Exchange open the relevant market or NFT listing, choose an order type (use limit orders for price control or market orders for immediate fills), review estimated fees and expected post-trade receipt, and submit the trade.