Solana State Compression: How Compressed Accounts Cut Payment Application Costs 1000x

Every account on Solana costs rent. A standard SPL token account requires roughly 0.002 SOL in rent-exempt deposits: about $0.21 at current prices. That sounds negligible until you need a million of them. Loyalty point distributions, payment receipt logs, airdrop campaigns, and micropayment channels all require creating accounts at scale, and at $0.21 each, one million accounts costs over $200,000 in rent alone.

Solana's state compression changes the economics entirely. By storing account data as leaves in Merkle trees rather than as full on-chain accounts, compression reduces per-account costs by 400x to 5,000x depending on the method. That same million accounts drops from $200,000 to as little as $500. For payment applications, this is the difference between a viable product and an impossible one.

How State Compression Works

Standard Solana accounts store their full data in validator memory. Every validator in the network holds a complete copy of every account, and the account owner pays rent (currently 6,960 lamports per byte for two years of rent-exempt storage) to keep that data alive. This model works well for accounts that need frequent reads and writes, but it is wildly expensive for data that is written once and read rarely.

State compression inverts the storage model. Instead of storing full account data in validator memory, the data is hashed and inserted as a leaf in an on-chain Merkle tree. Only the tree's root hash lives in validator state. The raw data itself is written to Solana's ledger (the permanent transaction log), making it recoverable by replaying history but removing it from the expensive per-validator storage layer.

Concurrent Merkle Trees

A naive Merkle tree implementation would break under Solana's throughput. Every time a single leaf changes, the root changes, and every other pending proof becomes invalid. Solana solves this with concurrent Merkle trees: a variant that stores a changelog buffer of recent root updates on-chain. When a transaction submits a proof against a slightly stale root, the program fast-forwards the proof using the changelog entries, keeping it valid even after other leaves were modified in the same block.

Tree configuration is set at creation and cannot be changed afterward. Three parameters define the tree: max depth (determines capacity as 2^depth leaves), max buffer size (the changelog size, controlling concurrent update capacity), and canopy depth (how many levels of proof nodes are cached on-chain to reduce per-transaction proof sizes).

The Canopy Trade-off

Every transaction that modifies a compressed account must include a Merkle proof: the sibling hashes along the path from the leaf to the root. For a depth-20 tree, that is 20 hash nodes at 32 bytes each (640 bytes), which eats into Solana's 1,232-byte transaction size limit. The canopy caches the top N levels of the tree on-chain, reducing the number of proof nodes a transaction must include from maxDepth to (maxDepth minus canopyDepth).

Higher canopy means smaller transactions and better composability (more room for other instructions in the same transaction), but it also means more on-chain storage and higher tree creation costs. The Metaplex documentation recommends keeping (maxDepth minus canopyDepth) at 10 or less for maximum composability with marketplace and DeFi programs.

The Cost Breakdown

State compression exists in two generations on Solana. The first, introduced in 2023, uses the Metaplex Bubblegum program for compressed NFTs. The second, launched in 2024 by Light Protocol (now part of Helius), extends compression to arbitrary accounts using zero-knowledge proofs. Both achieve dramatic cost reductions, but the numbers differ.

Compressed NFTs via Bubblegum

The Bubblegum program stores NFT metadata hashes in concurrent Merkle trees. The upfront cost is creating the tree account; per-NFT costs approach zero.

Minting one million compressed NFTs costs roughly 13.5 SOL total (tree creation plus transaction fees): about $1,400 at current prices. The same number of standard NFTs would require approximately 24,000 SOL ($2.47 million). That is a reduction of roughly 1,800x.

ZK Compressed Token Accounts

ZK Compression, built by Light Protocol and now maintained by Helius after their June 2026 acquisition, extends compression beyond NFTs to arbitrary account types: token balances, program-derived addresses, identity records, governance positions. It uses zero-knowledge validity proofs to verify state transitions, keeping proof size constant at 128 bytes regardless of tree depth.

Why 400x instead of 1,000x? The headline reduction depends on what you are comparing. Compressed NFTs via Bubblegum achieve 1,800x+ reductions because standard NFTs require three separate accounts (mint, token, metadata). ZK compressed token accounts achieve ~400x because they only replace the single token account. For applications that create complex multi-account structures (loyalty programs with metadata, receipt logs with associated PDAs), the aggregate reduction easily exceeds 1,000x.

Payment Use Cases Enabled by Compression

Before state compression, certain payment application architectures were economically impossible on Solana. The per-account rent created a floor cost that made high-volume, low-value operations impractical. Compression removes that floor.

Loyalty Point Systems

A coffee chain issuing on-chain loyalty points to 500,000 customers would need 500,000 token accounts at a cost of roughly $105,000 in rent alone. With ZK compression, the same deployment costs about $250. This makes on-chain loyalty programs competitive with traditional database-backed systems while gaining the transparency and portability of tokenized assets. Crossmint already uses compressed NFTs to power customer loyalty programs through their API infrastructure.

Payment Receipts and Invoicing

Storing payment receipts as compressed accounts creates an immutable, auditable record without the cost of full on-chain storage. Each receipt can include transaction metadata (amount, timestamp, merchant identifier, payment method) hashed into a Merkle leaf. The data remains verifiable against the on-chain root but costs a fraction of a cent per record instead of $0.21.

Airdrop Distributions

Token airdrops to large user bases historically required creating a token account for every recipient. A one-million-wallet airdrop on standard accounts costs over $200,000 in rent before factoring in the tokens themselves. With compressed token accounts, the same distribution costs about $500. DRiP has demonstrated this at scale, distributing free digital art to over 400,000 weekly recipients with costs of several hundred dollars instead of several hundred thousand.

Micropayment Channels

Micropayment applications that settle small amounts to many recipients (content tipping, per-API-call billing, streaming payments) need account creation costs lower than the payment values themselves. At $0.21 per account, payments under a dollar become uneconomical just from the account setup. At $0.0005, the floor drops low enough to support sub-cent settlement.

Who Is Using Compression at Scale

DRiP

DRiP has minted over 40 million compressed NFTs, reaching more than 1.2 million unique wallets. The platform distributes free digital art weekly, and state compression is what makes the economics work. Without it, the minting costs alone would have exceeded millions of dollars. DRiP routinely mints 3+ million NFTs per week using Bubblegum trees.

Helium

When Helium migrated its IoT network to Solana in May 2023, it needed to represent each of its roughly 991,000 physical hotspots as on-chain assets. Using compressed NFTs, the entire migration cost approximately $113. With standard NFTs, the same operation would have cost hundreds of thousands of dollars. Each hotspot NFT represents a DePIN device with associated metadata (location, earnings, network type), making compression essential for the network's on-chain representation.

ZK Compression Adoption

Since ZK Compression launched on mainnet in 2024, roughly 90 million compressed accounts have been created. For context, Solana has over 500 million standard accounts with about one million new ones created daily. Compressed accounts are growing as a share of total state, particularly for applications that create accounts in bulk.

Decompression is reversible: Both compressed NFTs and ZK compressed tokens can be decompressed into standard accounts when needed (for example, to interact with a DeFi protocol that requires standard SPL tokens). Decompression and recompression can even happen within the same transaction, enabling a "hot" and "cold" state pattern where assets stay compressed until the moment they are needed.

The Infrastructure Dependency

Compression introduces a significant architectural trade-off: standard RPC calls like getAccountInfo cannot read compressed state. Since the data lives in the ledger rather than in validator memory, applications need specialized indexing infrastructure to query it.

Digital Asset Standard API

The Digital Asset Standard (DAS) API, created by Metaplex, provides a unified interface for interacting with compressed and standard assets. Key methods include getAsset for metadata retrieval, getAssetProof for Merkle proofs needed to modify compressed state, and getAssetsByOwner for ownership queries. Providers supporting DAS include Helius, Triton, QuickNode, and Alchemy.

Photon Indexer for ZK Compression

ZK Compression uses the Photon indexer, an open-source system that tracks compressed account events, caches current account states, and generates the cryptographic proofs needed for verification. Development snapshots reduce startup time to about 15 minutes (compared to replaying the full ledger from genesis). Permissionless "forester" nodes handle tree maintenance, including rollover to new trees when existing ones fill up.

The Centralization Question

Applications using compressed state must rely on DAS-compatible RPC providers or run their own indexer. This creates a dependency layer that does not exist for standard accounts, where any Solana RPC endpoint can serve reads. For payment applications requiring high availability, this means either running indexer infrastructure in-house or depending on third-party providers for data access: a trade-off between cost savings and operational independence.

ZK Compression V2: Batched Merkle Trees

The next generation of ZK Compression, announced at Solana Accelerate 2025, introduces batched Merkle trees that dramatically improve throughput. V2 uses height-32 trees (up from height-26 in V1) with a dual-queue architecture separating append operations from updates.

Performance improvements are substantial: append operations are 20x faster than V1, update operations are 14x faster, and Merkle tree update operations are 250x faster. The system uses bloom filters for uniqueness verification and supports up to five update operations per single transaction, with instruction data for tree updates compressed to fewer than 200 bytes.

Comparison with Ethereum L2 Data Compression

Ethereum and Solana approach the cost problem from opposite directions. Solana compresses state on L1 to avoid per-account rent. Ethereum rollups move execution to L2 and post compressed state diffs back to L1, using EIP-4844 blob transactions (introduced in the March 2024 Dencun upgrade) as a cheaper data availability layer.

The key architectural difference: Solana compression keeps everything on a single layer without bridging, while Ethereum rollups create separate execution environments that require bridges for cross-rollup interaction. For payment applications, Solana's approach avoids the bridge security model and settlement delays that come with moving assets between layers. Ethereum's approach provides stronger data availability guarantees (the full L2 state is independently verifiable) but introduces liquidity fragmentation across L2s.

Trade-offs and Limitations

Proof Size and Transaction Limits

Each compressed state modification requires a Merkle proof that consumes transaction space. For a depth-20 tree with canopy depth 13, the proof requires 7 hash nodes (224 bytes). This is manageable for simple transfers but limits how many other instructions can fit in the same 1,232-byte transaction. ZK Compression mitigates this by using constant 128-byte proofs regardless of tree size.

Immutable Tree Configuration

Tree depth and buffer size are set at creation and cannot be changed. If a payment application outgrows its tree capacity, it must create a new tree and manage state across multiple trees. Forester nodes automate this rollover process in the ZK Compression stack, but applications using raw Bubblegum trees must handle it themselves.

Read Latency

Reading compressed state requires querying an indexer rather than making a direct RPC call. This adds a network hop and introduces dependency on indexer availability and freshness. For payment applications with strict latency requirements, this additional layer must be accounted for in system design.

Composability Constraints

DeFi protocols and DEXs built on standard accounts cannot natively interact with compressed state. Assets must be decompressed before use in these protocols. While decompression and recompression can occur in the same transaction, this adds complexity and compute cost compared to operating with standard accounts throughout.

Architectural Parallels: Solana Compression and Spark VTXOs

Solana achieves cost reduction by moving account data off validator memory and into the ledger, using Merkle proofs to verify state. Spark, a Bitcoin Layer 2, arrives at a similar economic outcome through a different architecture: its VTXO (Virtual Transaction Output) model keeps value representations off-chain entirely, anchored to Bitcoin L1 through pre-signed exit transactions and FROST threshold signatures.

Both approaches solve the same fundamental problem: full on-chain accounts are too expensive for high-volume payment operations. Solana compresses state while keeping it on L1. Spark moves state off-chain while preserving self-custody through cryptographic guarantees. The trade-offs differ: Solana trades indexer dependency for L1 composability, while Spark trades operator liveness requirements for zero on-chain footprint during normal operation. For payment applications, both achieve sub-cent per-transaction economics, making micropayments and bulk distributions viable on their respective networks.

Building with Compression

For developers evaluating state compression for payment applications, the decision framework depends on the use case. Bulk-mint scenarios (loyalty tokens, receipt NFTs, airdrop distributions) are straightforward with Bubblegum. Applications requiring compressed token balances with frequent updates benefit from ZK Compression's constant proof sizes and PDA support.

The ZK Compression documentation provides integration guides and SDKs for building with compressed accounts. For Solana token extensions compatibility and broader payment infrastructure patterns, the compressed token program supports any SPL or Token-2022 mint. Phantom and Backpack wallets already support compressed tokens natively, reducing the UX friction of adoption.

Developers building payment applications on Bitcoin can explore the Spark SDK documentation for an alternative approach to reducing payment costs through off-chain state management with self-custodial guarantees.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.