Skip to main content
The Light-SDK pays rent-exemption for your PDAs, token accounts, and mints (98% cost savings). Your program logic stays the same.

What Changes

Audit overhead is minimal as your program logic is mostly untouched. The rest is macro-generated. If you don’t use Anchor, let us know. References for native solana-program integration coming soon.
You can find a complete rent-free AMM reference implementation here.

Step 1: Dependencies

Step 2: State Struct

Add compression_info field and derive LightAccount:

Step 3: Program

Add #[light_program] above #[program]:

Step 4: Accounts Struct

Derive LightAccounts on your Accounts struct and add #[light_account(...)] next to #[account(...)].
We also need to add light_token_interface_config, rent_sponsor, and light_token_cpi_authority.

Step 5: Instructions

Replace spl_token with light_token instructions as you need. The API is a superset of SPL-token so switching is straightforward. Examples include: MintToCpi, TransferCpi, TransferInterfaceCpi, CreateTokenAccountCpi, and CreateTokenAtaCpi.

Client SDK

To make it easy for clients to integrate with your program, implement the LightProgramInterface trait in your program’s SDK crate. For a detailed example of how clients use this trait, check out the Router Integration page.

Testing


How it works

The SDK pays the rent-exemption cost. Inactive (cold) accounts auto-compress. Your program only ever interacts with hot accounts. Clients can load cold accounts back when needed via create_load_instructions. Under the hood, clients use AccountInterface - a superset of Solana’s Account that unifies hot and cold state. See Router Integration for details.

Existing programs

If you have an existing program that you would like to migrate to rent-free accounts, join our tech Discord for migration support.

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 automatically compress when virtual rent is below threshold (e.g., multiple epochs without any writes). In practice, cold markets should be rare. The common path (hot) has no extra overhead and does not increase CU or txn size.
No. Any write bumps the virtual rent balance. Active accounts do not get compressed.
No. Helius and Triton run the Interface RPC endpoints, self-hosting the Photon indexer is optional. Helius Labs maintains the open-source Photon indexer implementation.
Hot markets work all the same as long as Solana is up. Cold accounts cannot be loaded into hot state until your indexer or RPC provider recovers. Note that compression is cryptographically verifiable, so integrity and safety are not dependent on the indexer or any other external service beyond the onchain protocol.

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