> ## Documentation Index
> Fetch the complete documentation index at: https://luminouslabs-cc5545c6-docs-main-reorder.mintlify.site/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
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.
* 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. 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](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
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:
( 2tree\_depth × tree\_account\_rent\_cost × rollover\_threshold)
≈ `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
You're ready to take the next step and start building!