Skip to main content
A Light-PDA is a standard Solana PDA. Seeds, bump derivation, and invoke_signed work the same way. Your instruction handlers for reads, updates, and closes don’t change.

What changes

Audit overhead is minimal as your program logic is mostly untouched. The rest is macro-generated.
Install the agent skill:
See the AI tools guide for dedicated skills.

Step 1: Dependencies

Step 2: State struct

Add compression_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

Derive LightAccounts 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

lib.rs
View counter example on Github: counter

How it works

The SDK sponsors rent-exemption so you don’t pay the full rent-exempt balance upfront. After extended inactivity, the account compresses to cold state and returns the rent-exempt balance to the rent sponsor. Clients call create_load_instructions to load a cold account back on-chain when it’s needed again. Your program only ever interacts with hot accounts.

FAQ

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.
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.
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.
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.

API is in Beta and subject to change.Questions or need hands-on support? Telegram | email | Discord