Solana ZK Compression: Making On-Chain Storage 1000x Cheaper

On-chain storage is the single largest cost for applications that need to track millions of users. On Solana, every account requires a rent-exempt deposit of roughly 0.002 SOL, which means a token airdrop to one million wallets would cost around 2,000 SOL in rent alone. ZK compression, developed by Light Protocol and Helius Labs, solves this by moving account data off-chain while keeping cryptographic commitments on-chain, verified through zero-knowledge proofs. The result: the same airdrop costs a fraction of a SOL.

This article explains how ZK compression works at an architectural level, what it costs in practice, what tradeoffs it introduces, and how it compares to other approaches for reducing on-chain storage overhead.

What Problem Does ZK Compression Solve?

Solana stores all account state in memory, which makes reads fast but storage expensive. Every account must hold a minimum SOL balance (rent-exempt deposit) proportional to its size. A standard SPL token account is 165 bytes and requires roughly 0.00204 SOL. A 100-byte program derived address (PDA) costs about 0.0016 SOL. These deposits are refundable when accounts are closed, but they lock capital for as long as the account exists.

For applications serving thousands of users, rent costs are manageable. For applications targeting millions (loyalty programs, airdrops, DePIN device registries, gaming inventories), they become prohibitive. A gaming platform with ten million players holding in-game tokens would need over 20,000 SOL locked in rent deposits just for token accounts.

ZK compression eliminates this bottleneck by replacing on-chain account storage with a compact cryptographic commitment: a Merkle tree root hash. The full account data lives in Solana's ledger (the transaction log), which is far cheaper than account storage. Each state transition is validated by a zero-knowledge proof that confirms the data is correct without requiring validators to store it.

How ZK Compression Works

ZK compression is not a rollup or a sidechain. It runs directly on Solana L1. Transactions execute in the Solana Virtual Machine (SVM) just like any other transaction, but the accounts they operate on are stored differently.

Compressed Accounts

A compressed account contains the same fields as a regular Solana account (owner, lamports, data) but is not stored in the validator's account database. Instead, the account data is hashed using the Poseidon hash function (chosen for its efficiency inside zero-knowledge circuits) and inserted as a leaf in a Merkle tree. Only the tree's root hash lives on-chain as a regular Solana account.

When a transaction needs to read or modify a compressed account, the client fetches the full account data and a Merkle proof from an indexer (such as Helius's Photon API), includes both in the transaction, and submits a validity proof demonstrating that the account exists in the tree with the claimed data. The on-chain program verifies the proof, executes the state transition, and updates the Merkle root.

Concurrent Merkle Trees

A naive Merkle tree implementation would break under concurrent access: if two transactions try to update different leaves in the same block, the second transaction's proof would be invalid because the first already changed the root. Solana solves this with concurrent Merkle trees, which maintain a changelog of recent root updates on-chain.

When a transaction submits a proof against a slightly stale root, the on-chain program can "fast-forward" through the changelog entries to verify the proof against the current root. This allows multiple transactions touching different leaves to land in the same block without conflicts. The changelog size (called the "max buffer size") determines how many concurrent updates a tree supports.

Tree parameters are fixed at creation: When a concurrent Merkle tree is initialized, three values are set permanently: max depth (how many leaves the tree supports), max buffer size (how many concurrent updates per slot), and canopy depth (how many proof nodes are stored on-chain to reduce proof size). Choosing these parameters involves tradeoffs between capacity, concurrency, and cost.

Groth16 Validity Proofs

ZK compression uses Groth16 zk-SNARKs over the BN254 elliptic curve to verify compressed account state transitions. Groth16 was chosen for two reasons: proof size is constant at approximately 128 bytes regardless of how many accounts are involved, and Solana has native support for BN254 pairing operations through the alt_bn128 precompile.

A single proof can attest to the existence of multiple accounts across multiple state trees, keeping proof verification cost at roughly 100,000 compute units (CU). Proof generation happens off-chain, typically by the indexer or a dedicated prover service. The client requests a proof, the prover generates it, and the client includes it in the transaction.

V2: Batched Merkle Trees

ZK Compression V2, announced at Solana Accelerate 2025, introduced batched Merkle trees. V1 trees used a depth of 26 (supporting roughly 67 million leaves). V2 trees increase the depth to 32 (over 4 billion leaves) and introduce a dual-queue architecture that separates append operations from updates.

Rather than updating the Merkle root after every individual transaction, V2 batches multiple state changes and verifies them with a single ZK proof. This reduces per-update cost by roughly 250x compared to V1, according to the development team. V1 trees remain supported for existing deployments, and new deployments default to V2.

Cost Comparison: Regular vs. Compressed Accounts

The cost advantage of ZK compression comes from eliminating the rent-exempt deposit. Compressed accounts pay only for transaction calldata (the space used in the transaction itself) and proof verification compute. The following table compares costs for common operations, using figures from Light Protocol's documentation.

Note on cost figures: These numbers come from Light Protocol and Helius, which developed ZK compression. The exact savings ratio depends on the type of account, batch size, and current network conditions. Larger batches yield higher savings ratios because the fixed cost of proof verification is amortized across more accounts.

The savings scale non-linearly because compressed accounts share a single Merkle tree. Creating the tree itself has a fixed cost, but each additional leaf adds only marginal calldata cost. This is why the savings for 100 token accounts (5,000x) are much higher than for a single account (400x). For a deeper analysis of how these costs affect payment applications, see Solana State Compression: How Compressed Accounts Cut Payment Application Costs 1000x.

Use Cases Enabled by ZK Compression

ZK compression does not change what Solana can do. It changes what is economically feasible. Several categories of applications become viable at compressed-account pricing.

Mass Token Distribution

Traditional Solana airdrops require creating a token account for every recipient, which costs roughly 0.002 SOL per wallet. An airdrop to one million recipients would cost approximately 2,000 SOL (around $300,000 at typical prices). With ZK compression, the same distribution can be done for a few SOL by batching recipients into shared Merkle trees. Projects like Merkle airdrops already use tree structures for claim-based distribution, but ZK compression extends this to token accounts themselves.

DePIN Device Registries

Decentralized physical infrastructure networks need to track thousands or millions of devices on-chain: sensors, hotspots, vehicles, energy meters. Each device typically has an associated account storing its identity, location, and reward state. At standard rent costs, a network with one million devices would need over 2,000 SOL locked in account rent. ZK compression reduces this by orders of magnitude, making it practical to register and track every device on-chain rather than relying on off-chain databases with periodic anchoring.

Gaming Inventories and In-Game Currencies

On-chain gaming faces a fundamental tension: players expect to own their items, but storing millions of in-game assets as individual on-chain accounts is prohibitively expensive. ZK compression allows games to represent every item, currency balance, and achievement as a compressed account without paying rent for each one. A game with ten million players holding inventory items can store all of that state at a fraction of the cost of traditional account storage.

Loyalty Programs

Enterprise loyalty programs with hundreds of thousands of members can use compressed token accounts to issue and track points on-chain. A 500,000-member program using standard token accounts would cost roughly 1,000 SOL in rent. With compression, the same deployment costs a fraction of a SOL. The compressed NFT approach pioneered this pattern for collectibles; ZK compression extends it to fungible tokens and arbitrary account data.

Comparison with Ethereum's Cost Reduction Approaches

Ethereum and Solana face the same underlying problem (on-chain state is expensive) but solve it differently. Ethereum's primary cost reduction strategy is moving execution off-chain via zk-rollups and optimistic rollups, which post compressed state data back to L1. Solana's ZK compression keeps execution on L1 but compresses the state storage itself.

Ethereum's EIP-4844 (proto-danksharding) introduced blob transactions, which give rollups a cheaper lane for posting data. Blobs cost roughly 1 gas per byte compared to calldata's 16 gas per non-zero byte, cutting L2 posting costs by roughly 90%. However, blob data is ephemeral (pruned after about 18 days), and L2s still require their own execution environments, sequencers, and bridge infrastructure.

ZK compression takes a fundamentally different approach: no separate execution layer, no bridge, no sequencer. The tradeoff is that compressed state depends on indexer infrastructure for data retrieval, and proof generation adds computational overhead to every transaction.

The Tradeoffs

ZK compression is not a free lunch. It introduces several constraints that developers must weigh against the cost savings.

Indexer Dependency

Reading a compressed account requires fetching its data and Merkle proof from an indexer. If the indexer is down or returns stale data, transactions will fail. This is a liveness dependency that regular Solana accounts do not have: validators can read standard accounts directly from their local state. In practice, Helius operates the primary indexer infrastructure (Photon), and the data can be reconstructed from the Solana ledger by any party, but the operational dependency is real.

Compute Overhead

Every transaction touching compressed accounts pays an additional ~100,000 CU for proof verification. For infrequent writes (creating an account, updating a balance occasionally), this overhead is negligible compared to the rent savings. For accounts with very high write frequency (thousands of updates over their lifetime), the cumulative compute cost can exceed what a regular account would have cost. Light Protocol's own documentation recommends using regular accounts for state that updates more than roughly 1,000 times.

Composability Constraints

Compressed accounts maintain atomic composability with other Solana programs, meaning a single transaction can interact with both compressed and regular accounts. However, programs that want to read compressed state must integrate with the compression protocol's instruction set. Existing programs cannot transparently read compressed accounts the way they read regular ones. This requires protocol-level integration, which limits how easily compressed state can interoperate with the broader Solana ecosystem without modifications.

Trusted Setup

Groth16 proofs require a trusted setup ceremony for each circuit. The security of the system depends on at least one participant in the ceremony honestly discarding their secret randomness. If all participants collude, it would be possible to forge proofs. This is a well-understood tradeoff in zk-SNARK systems: Groth16 offers the smallest proof sizes and fastest verification, but requires this initial trust assumption. Alternative proof systems like STARKs avoid trusted setups but produce larger proofs.

How This Compares to Bitcoin L2 Scaling

Solana's ZK compression and Bitcoin's Layer 2 strategies both aim to reduce costs, but they operate in fundamentally different design spaces. Solana compresses state on L1: execution stays on the base chain, but storage is made cheaper. Bitcoin L2s like Spark move transactions off-chain entirely, using Bitcoin L1 only for settlement and dispute resolution.

Spark, for example, uses statechains and FROST threshold signatures to enable instant transfers without on-chain transactions. The cost reduction comes not from compressing state but from avoiding on-chain interaction altogether. Where ZK compression reduces the per-account cost of on-chain state by 100x to 5,000x, Spark eliminates per-transfer on-chain costs entirely: a transfer on Spark does not touch Bitcoin L1 at all until the user chooses to exit.

These are complementary philosophies reflecting the different architectures of their base layers. Solana's high throughput and account model make L1 compression practical. Bitcoin's UTXO model and limited scripting make L2 off-chain approaches more natural.

Developer Considerations

For developers evaluating whether to use ZK compression, the decision hinges on the application's access patterns.

• Use compressed accounts for state that is created once and updated infrequently: token balances, identity records, device registrations, achievement badges.
• Use regular accounts for state that is updated frequently: order books, AMM pool state, oracle price feeds.
• Consider the indexer dependency: if your application requires guaranteed sub-second reads, the additional hop to an indexer may introduce latency.
• Account for proof generation time: generating a Groth16 proof takes longer than a simple account lookup, which may affect user experience for interactive applications.

Developers building on Solana can explore ZK compression through Light Protocol's documentation. Those interested in how different chains approach the cost problem can compare Solana's approach with Solana vs. Bitcoin L2 tradeoffs or explore Solana's stablecoin payment ecosystem to see how compression fits into broader payment infrastructure. Developers exploring Bitcoin-based approaches can review the Spark SDK documentation for a different model of cost reduction through off-chain state management.

Looking Ahead

ZK compression represents a meaningful shift in how blockchains think about state costs. Rather than accepting that every account needs a permanent on-chain footprint, it demonstrates that cryptographic proofs can substitute for direct storage while maintaining the security guarantees that on-chain state provides.

The V2 upgrade with batched Merkle trees pushes costs even lower, and as proof generation becomes faster and cheaper, the compute overhead tradeoff will continue to improve. For Solana applications targeting mass adoption (millions of users, not thousands), ZK compression is quickly becoming the default choice for state management.

Across the broader blockchain landscape, the trend is clear: whether through L1 state compression, L2 data availability layers, or off-chain protocols like statechains, the industry is converging on the principle that not every byte of state needs to live on-chain permanently. The question is no longer whether to compress state, but how.

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.