Overview
The sections below describe compressed account tradeoffs: larger tx size, higher CU when reading/writing state trees, and per-transaction state cost. These apply when your transaction reads or writes compressed state (e.g. Compressed Tokens or Compressed PDAs).| Primitive | Tx size / CU / State cost | More |
|---|---|---|
| Compressed Token / Compressed PDA | The limits below apply to every operation. | Compressed Tokens, Compressed PDAs |
Limitations of compressed account operations
When your transaction reads or writes compressed state, consider:- 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.
- You can decompress and compress accounts at will.
- 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. When your transaction reads or writes compressed state, size increases 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.
- For V2: The real byte overhead is 1 or 129 bytes, depending on how cold the account is. For V1: it’s always 128 bytes.
- You must send the account data you want to read/write on-chain.
High Compute Unit Usage
System CU usage when reading/writing compressed state:
- ~100,000 CU for validity proof verification (constant per transaction that touches compressed state)
- ~100,000 CU system use (state tree Poseidon hashing et al.)
- ~6,000 CU per compressed account read/write
- 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
Writing compressed account state costs a network fee per state tree plus rollover per new leaf. New addresses cost a one-time fee. All amounts are in addition to Solana’s base fee.| What | Lamports | When |
|---|---|---|
| Solana base fee | 5,000 per signature | Every transaction |
| State tree (V2) | 5,000 per tree | Once per tree per instruction, whether you read, write, or both. |
| State tree (V1) | 5,000 per tree | Charged separately for trees you read from (nullify) and trees you write to (create). So 1 read + 1 write on same tree = 10,000. |
| New leaf (rollover) | ~300 per leaf | Each new state leaf (any tree; default depth 26). |
| New address | 10,000 per address | One-time when creating an address (v2 address tree). |