Derive LightAccount and add a compression_info: Option<CompressionInfo> field
Accounts
Derive LightAccounts and add #[light_account] on init accounts
Program module
Add #[light_program] on top of #[program]
Instructions (swap, deposit, withdraw, …)
No 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.
Agent skill
Use the light-sdk agent skill to build rent-free DeFi programs:
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.
---description: Add rent-free accounts to an Anchor DeFi programallowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression---## Add rent-free accounts to an Anchor DeFi programContext:- Guide: https://zkcompression.com/light-token/defi/programs- Skills and resources index: https://zkcompression.com/skill.md- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/light-sdk- Crates: light-sdk (features: anchor, v2, cpi-context), light-sdk-macros, light-token (features: anchor), light-anchor-spl- AMM reference: https://github.com/Lightprotocol/cp-swap-referenceKey macros/APIs: #[light_program], LightAccount, LightAccounts, #[light_account(init)], CompressionInfo### 1. Index project- Grep `#\[program\]|anchor_lang|Account<|Accounts|InitSpace|seeds|init|payer` across src/- Glob `**/*.rs` and `**/Cargo.toml` for project structure- Identify: existing program module, account structs, PDA seeds, token accounts, init instructions- Read Cargo.toml — note existing dependencies and framework version- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel### 2. Read references- WebFetch the guide above- WebFetch skill.md — check for a dedicated skill and resources matching this task- TaskCreate one todo per phase below to track progress### 3. Clarify intention- AskUserQuestion: what is the goal? (new program from scratch, migrate existing program to rent-free, add rent-free accounts to specific instructions)- AskUserQuestion: which account types need to be rent-free? (PDAs, token accounts, ATAs, mints)- Summarize findings and wait for user confirmation before implementing### 4. Create plan- Based on steps 1–3, draft an implementation plan- Follow the guide's step order: Dependencies → State Struct → Program Module → Accounts Struct → Instructions- Identify which existing structs need changes (CompressionInfo field, LightAccount derive, etc.)- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)- Present the plan to the user for approval before proceeding### 5. Implement- Add deps if missing: Bash `cargo add light-sdk@0.19 --features anchor,v2,cpi-context` and `cargo add light-sdk-macros@0.19` and `cargo add light-token@0.4 --features anchor` and `cargo add light-anchor-spl@0.31`- Follow the guide and the approved plan- Write/Edit to create or modify files- TaskUpdate to mark each step done### 6. Verify- Bash `anchor build`- Bash `anchor test` if tests exist- TaskUpdate to mark complete### Tools- mcp__zkcompression__SearchLightProtocol("<query>") for API details- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture- Task subagent with Grep/Read/WebFetch for parallel lookups- TaskList to check remaining work
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.
Example: Trait Implementation
pub struct AmmSdk { pub pool_state_pubkey: Pubkey, pub observation_key: Pubkey, pub token_0_vault: Pubkey, pub token_1_vault: Pubkey, pub token_0_mint: Pubkey, pub token_1_mint: Pubkey, pub lp_mint: Pubkey, pub amm_config: Pubkey,}pub enum AmmInstruction { Swap, Deposit, Withdraw,}impl LightProgramInterface for AmmSdk { type Variant = LightAccountVariant; type Instruction = AmmInstruction; fn program_id() -> Pubkey { PROGRAM_ID } fn instruction_accounts(&self, ix: &Self::Instruction) -> Vec<Pubkey> { match ix { AmmInstruction::Swap => vec![ self.pool_state_pubkey, self.observation_key, self.token_0_vault, self.token_1_vault, self.token_0_mint, self.token_1_mint, ], AmmInstruction::Deposit | AmmInstruction::Withdraw => vec![ self.pool_state_pubkey, self.observation_key, self.token_0_vault, self.token_1_vault, self.token_0_mint, self.token_1_mint, self.lp_mint, ], } } fn load_specs( &self, cold_accounts: &[AccountInterface], ) -> Result<Vec<AccountSpec<Self::Variant>>, Box<dyn Error>> { // Build AccountSpec for each cold account by matching pubkey // and deserializing its data into the macro-generated variant. let mut specs = Vec::new(); for account in cold_accounts { let pubkey = account.key(); if pubkey == self.pool_state_pubkey || pubkey == self.observation_key { let parsed: PoolState = AnchorDeserialize::deserialize(&mut &account.data()[8..])?; specs.push(AccountSpec::Pda(PdaSpec { interface: account.clone(), variant: parsed.into() })); } else if pubkey == self.token_0_vault || pubkey == self.token_1_vault { specs.push(AccountSpec::Token(account.clone())); } // ... } Ok(specs) }}
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.
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?
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?
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?
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
