Working paper · Solana state compression · revised continuously
Accounts without rent: measuring ZK compression on Solana
Figures in this paper are recomputed from the Solana ledger each time the page is opened.
AbstractLight Protocol's ZK compression moves account data out of rent-paying on-chain accounts and into the transaction ledger, leaving only a Merkle root on chain. We report how heavily its four programs are used at the time of reading (§2), characterise a sample of recent compressed-token transactions, and provide an editable cost model comparing ordinary rent with compression fees (§3). We close with the mechanism and its limits (§4), including the point most often misunderstood: the "ZK" here proves validity, not secrecy.
Every account on Solana must hold a minimum balance, the rent-exempt reserve, proportional to its size. For a single token account this is small; for an airdrop to a hundred thousand wallets it is a real budget line, locked until each account is closed.
ZK compression offers another arrangement. Account contents are hashed into a Merkle tree1 and the full data travels inside the transaction that writes it. An indexer replays the ledger to reconstruct accounts, and a short zero-knowledge proof convinces the chain that a given account is part of the tree when it is used.
The practical questions are empirical. Is anyone actually using it? What do those transactions look like? And for a given workload, how much is saved? The sections below answer each with numbers read live, rather than figures copied from announcements.
Nothing on this page requests a wallet connection, signature or secret. All inputs are public addresses already on chain, and the calculator runs entirely in your browser.
2Measurements
Light System txs…per 24 h
Compressed-token txs…per 24 h
Token-account rent…SOL, from RPC
Median compute…CU per compressed-token tx
Table 1. Headline figures. Daily counts marked est. are extrapolated from the observed rate because the 3,000 most recent signatures did not reach back a full day.2
2.1 Program activity
Program
Role
Txs / 24 h
Failed
Last seen
Counting recent signatures…
Table 2. Transactions touching each Light Protocol program. Program addresses link to Solscan.
2.2 A sample of compressed-token transactions
Reading transactions…
Figure 1. Instruction mix (dark) and invoking top-level programs (light) across the most recent compressed-token transactions, parsed from program logs.
Reading transactions…
Table 3. Individual transactions in the sample. "Invoked by" is the outermost program that reached into compression.3
3Cost model
Let n be the number of accounts, k the accounts written per transaction, r the rent-exempt reserve, and f the per-transaction fee. Ordinary accounts cost n·r plus ⌈n/k⌉·f; compressed accounts replace rent with a small rollover charge per account and add a network fee per transaction. Rent is returned when an account is closed; compression fees are spent.
The reserve r is read from Solana when the page loads. The compression parameters default to Light Protocol's published values and are editable, because they change. Treat the output as an estimate for budgeting, not a quote.
Parameters
e.g. one per airdrop recipient
Fee parameters
charged when a tx writes to a state tree
funds the next tree once this one fills
Component
Ordinary
Compressed
Waiting for the live rent figure…
Table 4. Up-front cost for the parameters at left. USD at the current Jupiter SOL price.
4Mechanism and limitations
State trees. Each compressed account becomes a leaf hash in a concurrent Merkle tree held by the Account Compression program. Only the root and a small queue occupy on-chain space.
Ledger data. The full account contents are emitted in the writing transaction. Indexers such as Photon read the ledger and serve the current state of every account.
Validity proofs. To spend or update an account, the client fetches a compact zero-knowledge proof of inclusion and submits it; the Light System program checks it.
Foresters. Registered nodes drain queues and roll full trees over to fresh ones. The per-account rollover fee pays for that work.
4.1 Where it suits
Airdrops and reward distributions to many wallets
Per-user records written infrequently
Very many small balances
4.2 What it costs you
Every use needs a proof from an indexer, so applications depend on Photon or an equivalent
Higher compute per transaction (Table 1)
Most exchanges require tokens to be decompressed before trading
It does not hide anything. Balances, owners and transfers remain fully public on the ledger; the proof attests correctness only.
A Merkle tree commits to many items with one root hash; any single item can be shown to belong with a short path of sibling hashes.
Counts come from getSignaturesForAddress, up to three pages of 1,000 per program. Busy programs exhaust that window in under a day, hence the extrapolation.
Instruction names are taken from Program log: Instruction: lines. Transactions that reference compressed tokens without logging an instruction are listed as such.
Sources: Solana mainnet RPC for signatures, transactions and rent; Jupiter for the SOL/USD price; Light Protocol documentation for default fee values. This is a measurement and explainer, not a recommendation to adopt or invest in anything.