> ## Documentation Index
> Fetch the complete documentation index at: https://www.zkcompression.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Considerations
> Overview to considerations of ZK Compression, namely larger transaction size, higher compute unit usage, and per-transaction state cost.
# 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-tokens/overview), [Compressed PDAs](/compressed-pdas/overview) |
# 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.
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. 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](https://eprint.iacr.org/2019/458.pdf) 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**](https://solana.com/developers/guides/advanced/how-to-use-priority-fees) **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). |
**In practice:** A transfer that updates one leaf on one tree is **5,000 + 300** lamports (V2) or **10,000 + 300** (V1). Creating 10 new outputs on one tree is **5,000 + 3,000** (same for both).
# Next Steps
You're ready to take the next step and start building!