Skip to main content

Rent Sponsorship

Rent sponsorship is a built-in feature of the Light SDK’s that sponsors rent-exemption for all account types to reduce creation cost: mints, token accounts, and PDAs. This is dealt with under the hood in a way that doesn’t disrupt the UX of what your users are used to with SPL-token.Rent-exemption: sponsored by a rent sponsor PDA.Every Solana account requires a rent-exempt balance in SOL upon creation. A rent sponsor PDA by Light Protocol pays the rent-exemption cost for the account so account creators never lock up SOL for rent.Top-ups: paid by the fee payer.The feePayer on the transaction bumps a small virtual rent balance (766 lamports by default) on each write to keep the account active (hot balance). If you’re building a wallet or dApp, set your application as the fee payer and your users never pay rent or top-ups.
“Cold” accounts virtual rent balance below threshold (eg 24h without write bump) get auto-compressed. The cold account’s state is cryptographically preserved on the Solana ledger. Users can load a cold account into hot state in-flight when using the account again.

Light Token Program

Light token is a high-performance token standard that is functionally equivalent to SPL, but stores mint and token accounts more efficiently. This reduces account creation cost while being more CU efficient than SPL on hot paths.Creation CostCU Performance
Yes! Light Token is deployed on devnet — start integrating today with our Quickstart and Toolkits.For production on mainnet, use Compressed Tokens V1, which are live and supported by leading wallets such as Phantom and Backpack.
No. The light-token-sdk methods are a superset of the SPL-token API. Find examples below.
LightSPL
Get/Create ATAgetOrCreateAtaInterface()getOrCreateAssociatedTokenAccount()
Derive ATAgetAssociatedTokenAddressInterface()getAssociatedTokenAddress()
TransfertransferInterface()transferChecked()
Get BalancegetAtaInterface()getAccount()
Yes, light-token accounts can hold tokens from light, SPL, or Token 2022 mints.SPL tokens can be deposited into light-token accounts and withdrawn back to SPL token accounts via the transferInterface method.
The token standard pays rent-exemption cost for you. To prevent griefing, “rent” is paid over time to keep an account in memory. This is dealt with under the hood in a way that doesn’t disrupt the UX of what your users are used to with SPL-token.
  1. A rent sponsor PDA by Light Protocol pays the rent-exemption cost for the account.
  2. Transaction fee payers bump a virtual rent balance when writing to the account, which keeps the account “hot”.
  3. “Cold” accounts virtual rent balance below threshold (eg 24h without write bump) get auto-compressed.
  4. The cold account’s state is cryptographically preserved on the Solana ledger. Users can load a cold account into hot state in-flight when using the account again.
The account is automatically compressed. Your tokens are cryptographically preserved as a compressed token account (rent-free). The account is loaded into hot account state in-flight when someone interacts with it again.
Extensions are under development. Additional extensions can be requested.Coming soon:
  • MetadataPointer
  • TokenMetadata
  • InterestBearingConfig
  • GroupPointer
  • GroupMemberPointer
  • TokenGroup
  • TokenGroupMember
  • MintCloseAuthority
  • TransferFeeConfig
  • DefaultAccountState
  • PermanentDelegate
  • TransferHook
  • Pausable
  • ConfidentialTransferMint
  • ConfidentialTransferFeeConfig
  • ConfidentialMintBurn
  • light-token: Solana account that holds token balances of light-mints, SPL or Token 22 mints.
  • Compressed token: Compressed account storing token data. Rent-free, for storage and distribution.

PDA Accounts

A standard Solana PDA with sponsored rent-exemption. Seeds, bump derivation, and invoke_signed work the same way. Your instruction handlers for reads, updates, and closes don’t change.
A compressed account with a derived address. Programs invoke the Light System program instead of the System program to create and update compressed accounts. Compressed PDAs are always compressed and require a validity proof for every read and write.

PDA accounts overview

No. Add compression_info: CompressionInfo to your state struct, derive LightAccount and LightAccounts, and add #[light_program] above #[program]. Your instruction logic for reads, updates, and closes stays the same. The client prepends a load instruction if the account is cold.

Light-PDA guide

The SDK sponsors rent-exemption for your Light-PDAs. After extended inactivity, the account compresses to cold state and the rent-exempt lamports return to the rent sponsor. The common path (hot accounts) has no extra overhead.
  1. A rent sponsor PDA by Light Protocol pays the rent-exemption cost for the account.
  2. Transaction fee payers bump a virtual rent balance when writing to the account, which keeps the account “hot”.
  3. “Cold” accounts virtual rent balance below threshold (eg 24h without write bump) get auto-compressed.
  4. The cold account’s state is cryptographically preserved on the Solana ledger. Users can load a cold account into hot state in-flight when using the account again.
The account data is cryptographically preserved in compressed state. The client prepends a load instruction when someone interacts with it again — your program code doesn’t change. Reads, updates, and closes work the same way regardless of whether the account is hot or cold.

I don’t see the question I want answered

DM us @lightprotocol on X (Twitter) or Discord.

Learn Core Concepts