Skip to main content
The Light-SDK sponsors rent-exemption for your PDAs, token accounts, and mints. 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, see the Pinocchio Programs guide.
Use the light-sdk agent skill to build rent-free DeFi programs:
Add the marketplace and install:
For orchestration, install the general skill:
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. 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 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 want to migrate your program to rent-free accounts and would like hands-on support, join our tech Discord, or email us.

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. swap, deposit, withdraw): 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