What Is ZK Compression?
ZK Compression is a Solana primitive developed by Light Protocol in collaboration with Helius that saves accounts and token balances as compressed state that is verified with validity proofs. Instead of having to pay the rent for a whole on-chain account, you only need to keep the state fingerprint- the Merkle root-in account storage and have the actual data in Solana's cheap historical ledger. A validity proof that is validated on chain verifies that the update to the compressed account adheres to all its rules.
Imagine an audited financial statement. A bank that is evaluating a company for lending doesn't want to go and read every single receipt in a company's filing cabinets; it checks for an auditor's signed attestation that the numbers actually balance. In our scenario, the compressed account data is the filing cabinet, the Merkle root is the one page of summary, and the zero-knowledge proof is the auditor's signature. This signature is small, verifiable, and extremely difficult to forge.
Technical Implementation
In standard Solana accounts, the rent exemption deposit scales proportionally with account size and becomes incredibly expensive at scale. For instance, regular tokens accounts typically lock around 0.002 SOL. Holding tokens for one million users at any given moment would require you to have around 2,000 SOL in rent. ZK Compression significantly shrinks this footprint: 100 compressed token accounts would require just 0.00004 SOL, and only 0.2 SOL would need to be held for 100 regular tokens- that's roughly a 5,000x decrease. Furthermore, PDAs (program derived accounts) are reduced up to 160x cheaper and state costs drop by around 99%.
With every transaction that touches compressed state, a validity proof is also included that proves the accounts being referenced still exist with the current Merkle root and that the state changes are legitimate. The on-chain program is in charge of verifying that proof and then updates the root to the new state. There are specialized indexers and RPC nodes like Helius, which powers the reference implementation, that also have to be deployed to index the ledger so that users can read a compressed balance just like a regular account. By 2026 there had been over 90 million compressed accounts created and major wallet providers like Phantom are also able to read the compressed balances along with most of the big RPC providers.
How ZK Compression Compares to Ethereum
For anyone following Ethereum, these numbers will look familiar. Validity proofs are the engine driving ZK rollups. The only real difference is where that proof sits. With an Ethereum rollup, the transaction execution is shifted to an off-chain layer 2, which means users have to use bridges, trust the rollup's sequencer and face a wait time before their funds can be used on the mainnet. ZK Compression on the other hand allows execution to stay directly on-chain with Solana's layer 1. Your compressed tokens are held in the same transactions as you would have used if you were transferring regular tokens, in the same composability, and within the same 400 millisecond slot, all without the need of bridges or a separate layer that users must trust. This isn't because the compression shifts the execution of a state change, but instead the compression simply compresses that state.
Why Does ZK Compression Matter?
Let's imagine a scenario where you are a project distributing some sort of loyalty tokens to one million wallets. In this case you would need to create a token account for each user in that distribution list. With traditional tokens, that distribution would require 2,000 SOL or roughly $40,000 to be rented on Solana before a single token is even moved to a wallet. With compressed tokens, however, you would need just a few dollars in state costs to complete that same distribution. For project teams, this means that ideas that were economically unfeasible can now be considered a realistic project that is worth pursuing. Apps for consumers, points and rewards programs, and games with millions of users with tiny balances are now possible. Protocols like Jupiter and Kamino, for example, would now no longer need to worry about issuing a large invoice to rent state on Solana just to reward a user for using the protocol at some point in their history.
The downside however are some small tradeoffs. Every time a validity proof is included with your transaction, the resulting state will be larger and will require more compute power, therefore the cost per transaction goes up. This means the compression of accounts is more likely to only be feasible for projects that use a lot of account state. Another tradeoff is that to check your compressed account state, you would now need to be using specialized RPC providers, otherwise your wallet would not see any compressed accounts. This creates some reliance on providers like Helius. In terms of cost, it will usually make more sense to use regular storage unless the number of accounts is at least in the five digit space.
Does ZK Compression hide my account balances?
There is no hiding of account information with ZK Compression. Instead, "Zero Knowledge" just refers to the fact that the validity proofs are succinctly proving the validity of any state change. Any compressed account is readable just like a regular account and is also public by anyone that can access indexers.
