#[account(init)] with #[light_account(init)].
| Regular PDA | Light-PDA | |
|---|---|---|
| 100-byte account | ~1,600,000 lamports | ~11,500 lamports |
What changes
| Area | Change |
|---|---|
| State struct | Derive LightAccount, add compression_info: CompressionInfo |
| Accounts struct | Derive LightAccounts, add #[light_account] on init accounts |
| Program module | Add #[light_program] above #[program] |
| Instructions (reads, updates, closes) | No program changes. Client prepends a load instruction if account is cold. |
Step 1: Dependencies
Step 2: State struct
Addcompression_info field and derive LightAccount:
Step 3: Program module
Add#[light_program] above #[program]. Define the CPI signer constant with your program ID:
Step 4: Accounts struct
DeriveLightAccounts on your Accounts struct and add #[light_account(...)] next to #[account(...)].
Only the init struct derives LightAccounts. The increment and close structs
are standard Anchor:
Full Example
- Program
- Client
lib.rs
View counter example on Github: counter
How it works
The SDK pays the rent-exemption cost. After extended inactivity, cold accounts auto-compress. Your program only ever interacts with hot accounts. Clients can safely load cold accounts back into the onchain Solana account space when needed viacreate_load_instructions.
| Hot (active) | Cold (inactive) | |
|---|---|---|
| Storage | On-chain | Compressed |
| Latency/CU | No change | +load instruction |
| Your program code | No change | No change |
FAQ
How does it prevent re-init attacks?
How does it prevent re-init attacks?
When creating an
account for the first time, the SDK provides a proof that the account doesn’t
exist in the cold address space. The SVM already verifies this for the onchain
space. Both address spaces are checked before creation, preventing re-init
attacks, even if the account is currently cold.
Who triggers compression?
Who triggers compression?
Miners (Forester nodes) compress accounts that have been inactive for an extended period of time (when their virtual rent balance drops below threshold).
In practice, having to load cold accounts should be rare. The common path (hot) has no extra overhead and does not increase CU or txn size.
How is the SDK able to sponsor rent exemption?
How is the SDK able to sponsor rent exemption?
When accounts compress after extended inactivity, the on-chain rent-exemption is released back
to the rent sponsor. This creates a revolving lifecycle: active “hot” accounts hold a
rent-exempt lamports balance, inactive “cold” accounts release it back. The
rent sponsor must be derived from the program owner. For all mint, ATA, and
token accounts, the Light Token Program is the rent sponsor. For your own program-owned PDAs, the SDK derives a rent sponsor address automatically.
Do rent-free accounts increase CU?
Do rent-free accounts increase CU?
Hot path (e.g. reads, updates, closes): No. Active accounts do not add CU overhead to your instructions.First time init + loading cold accounts: Yes, adds up to 15k-400k CU,
depending on number and type of accounts being initialized or loaded.