Limitations

Before using ZK Compression to scale your application state, consider the following limitations of compressed accounts:

• Larger Transaction Size

• High Compute Unit Usage

• Per-Transaction State Cost

General Recommendation

Consider which accounts in your application benefit from ZK Compression and which don't. You can use both types for different parts of your application!

It may be preferred for an account not to be permanently compressed if:

• The account gets updated very frequently within a single block (e.g., shared liquidity pools in a DeFi protocol).

• You expect the lifetime number of writes to the same account to be very large (>>1000x).

• The account stores large amounts of data, and you need to access a large part of it (>1kb) inside one on-chain transaction.

Larger Transaction Size

Solana's transaction size limit is 1232 Bytes. Transactions exceeding this limit will fail. ZK Compression increases your transaction size in two ways:

• 128 bytes must be reserved for the validity proof, which is a constant size per transaction, assuming the transaction reads from at least one compressed account.

• You must send the account data you want to read/write on-chain.

High Compute Unit Usage

System CU usage:

• ~100,000 CU for validity proof verification, which is a constant size per transaction, assuming the transaction reads from at least one compressed account

• ~100,000 CU system use (state tree Poseidon hashing et al.)
• ~6,000 CU per compressed account read/write

Example: a typical compressed token transfer uses around 292,000 CU.

Higher CU usage can:

• Lead to usage limits: The total CU limit per transaction is 1,400,000 CU, and the per-block write lock limit per State tree is 12,000,000 CU.

• Require your users to increase their priority fee during congestion: Whenever Solana's global per-block CU limit (48,000,000 CU) is reached, validator clients may prioritize transactions with higher per-CU priority fees.

State Cost Per Transaction

Each write operation incurs a small additional network cost. If you expect a single compressed account to amass a large amount of state updates, the lifetime cost of the compressed account may be higher than its uncompressed equivalent, which currently has a fixed per-byte rent cost at creation.

Whenever a transaction writes to a compressed account, it nullifies the previous compressed account state and appends the new compressed account as a leaf to the state tree. Both of these actions incur costs that add to Solana's base fee.

Type	Lamports	Notes
Solana base fee	5000 per signature	Compensates validators for processing transactions
Write new compressed account state	~300 per leaf (default)	Depends on tree depth: $\left( 2^{\text{tree\_depth}} \times \text{tree\_account\_rent\_cost} \times \text{rollover\_threshold} \right)$ ~300 for the default depth of 26
Nullify old compressed account state	5000 per transaction	Reimburses the cost of running a Forester transaction. The current default Forester node implementation can be found here
Create addresses	5000 per transaction	Same as nullify

Next Steps

Now you're familiar with the core concepts of ZK Compression, you're ready to take the next step! Dive into building a program or application with ZK Compression, or learn how to set up and run your own node. For those interested in learning more about the fundamentals of ZK and its applications on Solana, we recommend reading the following:

• Zero-Knowledge Proofs: An Introduction to the Fundamentals
• Zero-Knowledge Proofs: Its Applications on Solana