State Compression

What Is State Compression?

State compression is a technique that drastically reduces on-chain storage costs by replacing individual account records with a single cryptographic hash. Instead of storing every piece of data as a separate on-chain account (which requires rent in Solana or gas in other chains), the data is hashed into a Merkle tree and only the tree's root is stored on-chain. The full data is emitted to transaction logs, where it can be reconstructed by anyone with access to the ledger.

The concept emerged on Solana as a response to state bloat: the growing cost of maintaining millions of on-chain accounts. Developed by Solana Labs and Metaplex with support from indexer providers like Helius and Triton, state compression shipped in April 2023. It enabled use cases that were previously cost-prohibitive, such as minting millions of NFTs or creating token accounts for every user in a large application.

How It Works

At its core, state compression relies on three components: a concurrent Merkle tree stored on-chain, the Noop program for logging data, and indexers that reconstruct the current state from those logs.

1. Data (such as NFT metadata, ownership, and attributes) is hashed into a leaf of a Merkle tree
2. Leaf hashes are paired and hashed upward through the tree until a single Merkle root is produced
3. Only this root (plus a changelog buffer) is stored on-chain in an account managed by the SPL Account Compression program
4. The full leaf data is emitted to Solana's transaction logs via the Noop program, making it permanently available on the ledger
5. Indexers parse these log events to build an off-chain database of current state, which applications query through the Digital Asset Standard (DAS) API

Concurrent Merkle Trees

A naive Merkle tree implementation would break under concurrent writes: if two transactions in the same slot both try to update the tree, the second transaction's Merkle proof would reference a stale root, causing it to fail. Solana solves this with concurrent Merkle trees, which maintain a changelog of recent root updates. When a transaction submits a proof against a slightly outdated root, the program can "fast-forward" the proof by applying the changelog, allowing multiple updates per slot without conflicts.

Three parameters define a concurrent Merkle tree:

• Max depth: determines the maximum number of leaves via 2^maxDepth (e.g., depth 20 supports roughly one million leaves, depth 30 supports over one billion)
• Max buffer size: the number of concurrent changes the tree can process in a single slot while keeping proofs valid (typically 64 to 2,048)
• Canopy depth: how many levels of the tree are cached on-chain, reducing the number of proof nodes that must be submitted per transaction (each proof node is 32 bytes)

The Noop Program

Solana's standard program logs truncate at 1 KB, which is too small for full NFT metadata. The Noop ("no operation") program exists solely to emit data to transaction logs without truncation. When a compressed NFT is minted or modified, the Bubblegum program calls the Noop program via cross-program invocation (CPI), which logs the full leaf data as a CPI event. Indexers parse these events to reconstruct the current state of every compressed asset.

Reading Compressed State

Because compressed data does not live in on-chain accounts, applications cannot read it through standard RPC calls. Instead, they query indexers through the Digital Asset Standard (DAS) API, a unified interface developed by Metaplex and supported by providers like Helius, Triton, and QuickNode. Key DAS API methods include:

// Retrieve a specific compressed asset
const asset = await dasApi.getAsset(assetId);

// Get the Merkle proof needed for transfers
const proof = await dasApi.getAssetProof(assetId);

// List all compressed assets owned by an address
const assets = await dasApi.getAssetsByOwner(ownerAddress);

// Search across collections
const results = await dasApi.searchAssets({
  grouping: ["collection", collectionId],
});

If an indexer goes down, the data is not lost. The entire tree can be reconstructed by replaying the transaction history from Solana's ledger, since all leaf data was logged permanently through the Noop program.

Compressed NFTs: The Flagship Use Case

Compressed NFTs (cNFTs) were the first major application of state compression, powered by Metaplex's Bubblegum program. The cost savings are dramatic:

These figures use SOL at approximately $21 (April 2023). The per-NFT marginal cost beyond tree setup is just the cost of a single transaction: 0.000005 SOL.

Adoption has been significant. Helium migrated to Solana by minting nearly one million hotspot NFTs as cNFTs, saving an estimated $33.6 million compared to Ethereum minting costs. DRiP, an art and content distribution platform, minted over 35 million cNFTs in Q4 2023 alone. By late 2023, total cNFT mints on Solana had surpassed 100 million.

How Bubblegum Works

The Bubblegum program (MPL-Bubblegum) is Metaplex's on-chain program for managing the lifecycle of compressed NFTs. It handles minting, transferring, updating metadata, burning, delegating authority, and verifying collections. Each cNFT is represented as a leaf in a Merkle tree, where the leaf hash encodes the NFT's metadata, owner, delegate, and collection information.

A single Merkle tree can hold millions of cNFTs, and a single collection can span multiple trees. Compressed NFTs can be "decompressed" into regular NFTs (converting the leaf into a standard on-chain account), but the reverse is not possible.

Beyond NFTs: ZK Compression

In June 2024, Light Protocol and Helius Labs introduced ZK Compression, extending state compression from NFTs to arbitrary on-chain state. Where original state compression uses standard Merkle proofs, ZK Compression uses Groth16 zero-knowledge proofs to verify state transitions. This produces constant-size proofs (128 bytes regardless of tree size) rather than proofs that grow logarithmically with depth.

ZK Compression enables compressed versions of common account types:

• Compressed token accounts: creating a token account drops from ~0.002 SOL to 0.000005 SOL, a roughly 400x reduction
• Compressed Program Derived Accounts (PDAs): a 100-byte PDA costs ~0.000015 SOL compressed versus ~0.0016 SOL standard
• Compressed identity records: decentralized identity tokens at scale
• Governance positions: compressed accounts for DAO voting records

At Accelerate 2025, Light Protocol announced batched Merkle trees for ZK Compression V2, replacing direct tree interaction with a queue-based architecture. This delivered 20x improvement for append operations, 14x for updates, and 250x for Merkle tree updates by decoupling operations from tree height.

Why It Matters

State compression addresses one of the fundamental barriers to blockchain adoption: storage cost. Applications that need to maintain state for millions of users (loyalty programs, gaming inventories, identity credentials, airdrop distributions) were previously cost-prohibitive on any chain. By reducing per-account costs by orders of magnitude, state compression makes these use cases economically viable.

The technique also has implications for data availability design in the broader blockchain ecosystem. Solana's approach of logging full data to the ledger while storing only a hash on-chain sits between full on-chain storage and external data availability layers. This guarantees that data can always be reconstructed from the chain itself, unlike rollup designs that rely on separate data availability committees.

For developers building on stablecoin or payment infrastructure, state compression reduces the cost of provisioning user accounts at scale. A payment application serving millions of users no longer needs to pay thousands of SOL in account rent. This is particularly relevant for Solana's growing stablecoin payment ecosystem, where onboarding cost directly affects unit economics.

Risks and Considerations

Indexer Dependency

Applications using compressed state cannot function without a working indexer. Every read operation and every write (which requires a Merkle proof) depends on the indexer layer. If a provider's DAS API goes down, the application loses access to compressed data until the indexer recovers or the application switches providers. While the underlying data is never lost (it can be rebuilt from the ledger), reconstruction takes time and the liveness guarantee depends on indexer infrastructure rather than the chain alone.

Proof Overhead and Composability

Every write operation on a compressed account requires submitting a Merkle proof alongside the transaction instruction. Each proof node is 32 bytes, and the number of required nodes equals maxDepth minus canopyDepth. For deep trees with shallow canopies, proof data can consume a significant portion of the transaction size limit, leaving less room for other instructions. As a rule, if maxDepth minus canopyDepth exceeds 10, composability with other programs (such as marketplace bidding systems) becomes significantly limited.

Upfront Tree Cost

While per-item costs drop dramatically, creating the Merkle tree account itself requires an upfront rent deposit. A tree sized for one million cNFTs costs approximately 8.5 SOL in rent. Deeper canopies improve composability but increase this cost further, since each cached node requires 32 bytes of on-chain storage. Developers must balance tree capacity, canopy depth, and budget when configuring trees.

Write Conflicts

Concurrent Merkle trees handle multiple updates per slot through their changelog mechanism, but same-leaf conflicts (two transactions updating the same compressed account simultaneously) will still cause one transaction to fail. Applications need retry logic for high-contention scenarios.

Decompression Is One-Way

Compressed NFTs can be decompressed into standard on-chain accounts, but regular NFTs cannot be compressed after minting. This means the decision to use compression must be made at creation time, and decompression incurs the full account rent cost that compression was designed to avoid.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.