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
Addcompression_info field and derive LightAccount:
Step 3: Program
Add#[light_program] above #[program]:
Step 4: Accounts Struct
DeriveLightAccounts on your Accounts struct and add #[light_account(...)] next to #[account(...)].
- PDAs
- Token Account
- Associated Token Account (ATA)
- Mint
Full Accounts Struct
Full Accounts Struct
We also need to add
light_token_interface_config, rent_sponsor, and light_token_cpi_authority.Step 5: Instructions
Replacespl_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.
Example: Initialize
Example: Initialize
Client SDK
To make it easy for clients to integrate with your program, implement theLightProgramInterface trait in your program’s SDK crate.
For a detailed example of how clients use this trait, check out the Router Integration page.
Example: Trait Implementation
Example: Trait Implementation
Testing
Example: Integration Test
Example: Integration Test
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 viacreate_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
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 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.
Can active pools get compressed?
Can active pools get compressed?
No. Any write bumps the virtual rent balance. Active accounts do not get compressed.
Do I need to run infrastructure?
Do I need to run infrastructure?
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.
What if the indexer is down?
What if the indexer is down?
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.